1. 为什么要告别SD卡性能、稳定性和启动体验的全方位对比先说说我自己的经历。去年年初我拿到Orin Nano Developer Kit的时候第一批就买了好几张不同品牌的TF卡。一开始觉得没啥问题系统能起来、Python脚本能跑、摄像头推流也凑合。但用了一两个星期之后问题开始集中暴露——最典型的就是开机过程中偶发卡在Ubuntu logo界面要不就是跑模型推理的时候SD卡指示灯常亮整机所有IO操作全部卡住连SSH都敲不进命令。后来我用iostat看了一下磁盘utilization读取队列动不动就堆到几百SD卡的随机读写能力根本扛不住Orin Nano这种级别的数据吞吐。如果你只是用Jetson做点GPIO点灯、跑个几MB的小模型SD卡确实够用。但凡是涉及ROS2、容器镜像、模型权重文件、数据集缓存这些场景SD卡天生就是短板。这里有个很容易被忽视的数据点Orin Nano的CPU和GPU性能远超前代但Developer Kit默认的SD卡槽走的是SDIO接口理论带宽也就几十MB/s级别随机IOPS更是低得可怜。而NVMe SSD哪怕是最入门的PCIe 3.0 x1盘顺序读都能跑800MB/s以上随机4K读取的IOPS是SD卡的几十倍。这个差距不是纸面上的是你在实际使用中每次敲命令、每次加载权重、每次启动容器都能感知到的差距。再把稳定性拿出来说。SD卡长期运行掉卡、文件系统损坏是圈内非常普遍的问题。我见过不少人在Jetson上跑着跑着系统突然只读重启后进不了桌面最后排查发现是SD卡Controller过热或者坏块累积导致的。用NVMe硬盘盒把系统装进SSD一方面SSD本身有过热保护和磨损均衡另一方面NVMe盘的可靠性设计完全是另一个量级。如果你做的是长时间的机器人巡检、边缘视频分析这类7x24小时任务SD卡方案除非有严格的只读保护和掉电冗余否则迟早出问题。还有启动速度。原厂SD卡冷启动到Ubuntu桌面普遍在40秒到1分钟上下换NVMe之后可以压到20秒以内。这个体验提升对开发调试来说特别明显——你一天可能要重启几十次每次省30秒一天下来就是十几分钟。当然最直接的理由还有一个SD卡烧录问题是新手最常踩的坑。镜像写入SD卡后经常出现分区表不对、引导文件缺失导致无法启动的情况。而NVMe硬盘盒配合离线烧录方式本质上走的是“整盘写入”的流程容错率比制作SD卡高得多。这也是我写这篇内容的核心动机——把整套离线烧录流程拆开讲明白每一步在做什么、为什么这么做让手里只有一块Orin Nano和一台普通电脑的人也能顺利上车。2. 硬件准备清单与避坑选型硬盘盒、SSD、供电和连接线烧录NVMe系统第一步是把手头的硬件搞清楚。Jetson Orin Nano Developer Kit本体带一个M.2 Key M插槽这个插槽同时支持NVMe协议和SATA协议的SSD。很多人误以为只要有M.2接口就能用实际上从启动引导和系统镜像的角度我强烈建议直接用NVMe协议的盘不要选SATA协议的M.2盘。原因很简单NVIDIA的官方烧录工具和Ubuntu for Tegra的引导流程对NVMe支持最成熟SATA盘虽然在部分版本的L4T里也能识别但会遇到更多兼容性和性能上的麻烦。接下来是硬盘盒的选择。既然叫“硬盘盒”它承担的角色是让SSD通过USB接口连接到烧录主机。这里有几个关键的选型参数主控芯片常见的USB转NVMe桥接方案有Realtek RTL9210B、JMicron JMS583、ASMedia ASM2362等。从我在多个平台上的兼容性实测来看RTL9210B表现最稳尤其是在Linux主机和Windows主机之间来回切换的场景识别率最高。速率规格硬盘盒的USB接口至少选USB 3.2 Gen 210Gbps的不要去买老旧USB 3.0桥接方案的盒子。虽然烧录过程本身的瓶颈不一定在硬盘盒上但后面如果你想把NVMe盘拆下来当普通移动硬盘用高速方案会实用得多。供电标准NVMe盘工作电流在1A上下普通硬盘盒用USB供电就能带起来。但要注意有些劣质硬盘盒的供电线路偷工减料插到电脑前置USB口时会出现识别不稳定、拷贝过程中掉盘。我建议先用主机后置USB口或者带独立供电的USB Hub烧录过程中不建议插在键盘旁边的USB 2.0口上。再说SSD本身。容量方面JetPack 5.x/6.x完整安装后占用大概在15GB到30GB之间加上Docker镜像和CUDA缓存64GB的盘有点紧张但勉强够128GB是起步推荐256GB以上用起来没有焦虑。颗粒类型方面普通TLC盘足够QLC盘在长时间大量写入时会掉速读多写少的开发者场景倒也能接受。品牌上尽量不要选太冷门的小厂盘优先考虑三星、西数、铠侠这些核心主控和固件成熟的品牌兼容性问题少一些。连接线也是容易被忽略的坑。硬盘盒一般附赠一根C to C线但很多送的线其实是USB 2.0的纯充电用途数据速率极低。烧录Ubuntu镜像包通常有3GB到6GB用USB 2.0连接会慢得让人怀疑人生。如果你发现硬盘盒识别出来了但拷贝速度只有30MB/s先换线大概率是线的问题。另外烧录完成后从电脑拔出SSD、装回Orin Nano的M.2槽这个过程注意不要带电插拔关机断电后再操作。还有一点就是我强烈建议准备第二块存储介质。不需要是NVMe随便一个小容量U盘或者SD卡都行原因后面说。3. 离线烧录镜像的准备如何在没有外网的环境下把一切备齐标题里特意强调“离线”这意味着你的烧录环境可能没有外网或者访问外部服务器很不稳定。离线烧录的第一步是在有网络的环境中把需要的文件提前准备好拷贝到U盘或移动硬盘里。首先要下载的是Jetson平台的Ubuntu系统镜像。这里有个常见的困惑普通x86电脑上用的Ubuntu Desktop ISO镜像能不能直接烧录到Jetson上答案是不能。Jetson是ARM架构且硬件平台高度定制必须使用NVIDIA发布的L4TLinux for Tegra分支也就是JetPack SDK里包含的系统镜像。在Ubuntu上打开终端用lsblk查看磁盘信息可以看到主板上的eMMC或者NVMe盘。如果你下载的是一个BSP包比如Jetson_Linux_R36.x.x_aarch64.tbz2里面并不直接是一个现成的.img文件而是一个完整的BSP源码加根文件系统框架需要通过NVIDIA提供的脚本生成烧录镜像。不过对于普通用户来说更推荐的路径是直接用SDK Manager来下载系统镜像它会自动把BSP和RootFS合并成一个可烧录的镜像。SDK Manager支持下载到本地缓存之后在离线状态下仍然可以继续烧录。具体操作是在有网环境下启动SDK Manager下载需要的JetPack版本下载完成后关闭软件把对应版本的整个缓存目录拷贝到U盘。如果你选择纯命令行方式那就要手动合并BSP和RootFS。以JetPack 5.1.3为例需要下载三个东西Jetson_Linux_R35.5.0_aarch64.tbz2、Tegra_Linux_Sample-Root-Filesystem_R35.5.0_aarch64.tbz2以及你要安装的CUDA、cuDNN这些附加组件的.deb包。BSP是系统核心RootFS是根文件系统两者缺一不可。离线环境下生成完整镜像的命令流程如下这里假设你已经在有网的机器上下好了两个压缩包# 创建BSP解压目录 mkdir -p jetson_bsp tar -xjf Jetson_Linux_R35.5.0_aarch64.tbz2 -C jetson_bsp # 进入Linux_for_Tegra目录 cd jetson_bsp/Linux_for_Tegra # 将RootFS解压到指定目录 sudo tar -xjf Tegra_Linux_Sample-Root-Filesystem_R35.5.0_aarch64.tbz2 -C rootfs # 应用L4T环境配置 sudo tools/l4t_create_default_user.sh -u ubuntu -p 123456 --autologin如果你用的是新版JetPack 6.x还需要先运行sudo tools/l4t_flash_from_storage.sh之类的前置脚本初始化根文件系统。不同版本的脚本名和参数会有差异最好看一下Linux_for_Tegra目录里的README_txt文档。镜像准备好之后还有一个关键动作制作一个可启动的烧录U盘。这里不是说把Ubuntu安装镜像做成启动盘而是把上面生成的整个Linux_for_Tegra目录复制到一张FAT32格式化的U盘里。因为离线环境下你需要在Orin Nano上运行的其实是一个最小化的Linux环境通过nv_tegra相关的钳制工具来烧写NVMe盘。这里补充一个很多人不知道的操作JetPack 5.1.2以上的版本NVIDIA官方支持直接从U盘启动一个内存中的烧录环境Recovery模式内嵌工具。你只需要把U盘插入Orin Nano的USB口然后按住Recovery按键上电设备会进入一个基于BusyBox的最小系统里面有lsblk、dd、fdisk这些基础工具。这个模式原本是用来配合主机端刷机的但你在离线环境下完全可以利用它直接操作NVMe盘。所以完整的离线准备清单是一台能上网的电脑用于下载JetPack、BSP、RootFS等镜像文件一张至少32GB的U盘格式化为FAT32或ext4用于存放镜像和启动烧录环境一个NVMe硬盘盒用于把系统写入SSD一根高质量C to C数据线把所有这些准备好之后离线烧录的大前提就成立了。你不需要在Orin Nano上连接任何外部网络也不需要额外的SD卡。4. 核心烧录流程从Recovery模式到完整系统写入把所有材料备齐之后来到最核心的烧录环节。我这里写的是我试过至少五六遍之后总结出的最稳流程每一步都给出必要的解释方便你遇到问题时自己定位。4.1 通过Recovery模式进入烧录状态Orin Nano Developer Kit的板卡上有一个Micro USB接口这个接口不是用来调试的而是用来和主机通信、执行底层烧录的。你需要先把USB线从电脑连到板子的Micro USB口注意不是Type-C供电口。然后按住板子上的Recovery按键在电源接口附近一个小按钮保持按住的状态下接通电源或者按一下Reset键。两三秒后松开Recovery键板子就会进入Recovery模式。在主机上执行lsusb能看到一个NVIDIA Corp的设备类似0955:7023这就说明连接正常。4.2 使用官方刷写脚本写入NVMe盘进入Recovery模式后在主机上进入Linux_for_Tegra目录执行sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_nvme.xml ubuntu这条命令的意思是把系统安装到外部NVMe设备上使用flash_l4t_nvme.xml这个配置模板。ubuntu参数表示使用默认的rootfs用户名。脚本执行过程中会自动完成分区、格式化、写入BootLoader、根文件系统灌入、内核和DTB部署等操作。整个过程在USB 3.0连接下大概10到15分钟如果用的是USB 2.0线时间会翻倍。如果你用的镜像版本不支持l4t_initrd_flash.sh那就用经典方式sudo ./flash.sh -c tools/kernel_flash/flash_l4t_nvme.xml nvme0n1p1注意旧版本的flash.sh和NVMe烧录参数和新的不太一样新版更推荐l4t_initrd_flash.sh它在内部会先打包一个initrd镜像再写入NVMe处理依赖的更干净。如果你的环境变量里缺少某些依赖库脚本会报错提示根据提示安装即可。烧录完成后脚本会输出类似*** The target t186ref has been flashed successfully. ***的字样。此时断电拔掉USB线把SSD从硬盘盒里拆出来装回Orin Nano板载的M.2插槽。4.3 首次启动与系统验证装上NVMe盘之后上电开机。Orin Nano的BootLoader默认会优先尝试从NVMe启动——前提是NVMe盘里有可用的引导记录。如果一切正常你会看到NVIDIA logo然后进入Ubuntu系统初始化界面。首次启动建议先跑几个命令验证系统状态# 查看系统版本 cat /etc/nv_tegra_release # 查看内核版本 uname -a # 确认NVMe盘挂载情况 lsblk # 查看NVMe设备详细信息 sudo nvme list如果lsblk里能看到nvme0n1并且根文件系统挂载在/dev/nvme0n1p1说明烧录成功。如果开机卡在NVIDIA logo不动大概率是BootLoader没装上回到上一步重新烧录时确认--external-device nvme0n1p1参数没有写错。这里还有一个非常重要的点如果你之前设置过从SD卡启动且SD卡还插在卡槽里Orin Nano可能会优先从SD卡启动。拔掉SD卡确保只从NVMe引导。4.4 离线环境下没有第二台电脑时怎么办前面讲的流程需要一台电脑配合USB线操作。如果你的场景极端一点只有Orin Nano本身和一个空NVMe盘没有第二台电脑那就要走另一条路用U盘里的烧录环境直接操作NVMe盘。具体做法是准备一个U盘格式化为FAT32把完整的Linux_for_Tegra目录放进U盘然后插到Orin Nano上按住Recovery键上电。此时板载BootROM会读取U盘里的引导文件进入一个内存版的最小系统。在这个环境下你可以用lsblk看到NVMe盘用dd直接写入系统镜像# 先给NVMe盘分区 sudo parted /dev/nvme0n1 --script mklabel gpt sudo parted /dev/nvme0n1 --script mkpart primary ext4 1MiB 100% # 写入镜像 sudo dd if/path/to/system.img of/dev/nvme0n1p1 bs4M statusprogress这种方式虽然慢一点但完全不依赖任何外部电脑真正做到了纯离线、纯板端操作。不过要注意这个模式下驱动NVMe需要内核模块新版L4T的initrd里默认是带NVMe驱动的老版本可能需要自己在U盘里准备对应模块那就复杂多了。所以除非没有电脑可用否则我还是推荐USB线直连主机的方式。5. 首次启动后的事情扩展分区、换源、DPI配置和SSD寿命优化系统能起来这只是第一步。NVMe盘虽然快但如果分区表没有正确扩展你会很快遇到磁盘空间不足的问题。默认的Ubuntu镜像烧录时只会分一个相对较小的根分区把剩余空间留着。所以开机第一件事就是扩展根分区到整个NVMe盘容量。在终端执行sudo growpart /dev/nvme0n1 1 sudo resize2fs /dev/nvme0n1p1growpart是用来扩展分区的参数里的1表示第一个分区resize2fs是把文件系统扩展到整个分区大小。执行完之后用df -h看一下根目录容量应该已经变成SSD全容量了。这个操作对NVMe盘的寿命没有影响因为本质上只是更新了分区表和文件系统元数据不是重新格式化。然后是Ubuntu系统本身的源配置。离线环境指的是烧录时没网不代表你完全不用网。如果你所在网络环境访问Ubuntu官方源很慢建议换成国内镜像源。修改/etc/apt/sources.listUbuntu 22.04及以上版本用的是DEB822格式在/etc/apt/sources.list.d/ubuntu.sources里配置Types: deb URIs: http://mirrors.aliyun.com/ubuntu/ Suites: jammy jammy-updates jammy-backports Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg改完之后执行sudo apt update整个过程会快很多。这里也顺便说一句如果你在装机过程中发现DNS解析不了先检查/etc/resolv.conf确保nameserver 8.8.8.8或者对应的内网DNS在里面。NVMe盘还有一个很多人忽略的性能和寿命问题——TRIM。在Ubuntu上ext4文件系统默认支持discard挂载选项但SSD需要定时执行fstrim才能彻底释放已删除空间的映射。建议用一个systemd定时器或者直接改/etc/cron.daily/fstrim让它每天自动执行一次。执行sudo fstrim -v /可以看到实际释放了多少空间。这个操作对延长NVMe寿命、保持写入性能有明显帮助尤其是你经常删除Docker镜像、卸载大型软件包的场景。说到Docker这也是Jetson开发者的高频场景。JetPack自带的Docker默认使用overlay2存储驱动配合NVMe盘能把容器启动速度提升到接近原生进程的体验。如果你在SD卡上跑过Docker应该能明显感觉到容器拉取镜像时每次写层都特别慢换成NVMe之后这个体验彻底改变。在Orin Nano上装Docker后记得把Docker数据目录默认放到NVMe盘上它本来就在根分区所以不用额外配置。还有一点是关于NVMe盘的温度管理。Orin Nano Developer Kit的散热器覆盖不到M.2插槽位置高负载跑AI推理时SSD温度很容易超过70°C。NVMe盘到了80°C会开始降速保护影响推理吞吐。如果你长时间跑重负载任务建议给NVMe盘加一块薄型散热片或者确保机箱风道能把热风带走。这不算烧录范畴的问题但确实是换NVMe之后最容易忽视的差异点。6. 从SD卡迁移到NVMe的完整记录数据、环境与Docker镜像如果你手头已经在SD卡上跑了一段时间的系统里面有不少环境配置和代码直接把SD卡扔掉重新从零配置一遍太浪费了。最合理的路径是用NVMe烧录一个干净系统然后把SD卡里的数据迁移过去。先说最核心的数据迁移。SD卡挂到Orin Nano机上之后用lsblk确认SD卡的设备名一般是/dev/mmcblk0p1。创建一个挂载点然后直接拷贝用户目录sudo mkdir -p /mnt/sd sudo mount /dev/mmcblk0p1 /mnt/sd sudo rsync -av --progress /mnt/sd/home/ /home/这里推荐用rsync而不是cp因为rsync支持断点续传、保留权限、软链接迁移大量文件时更稳妥。如果你是整个家目录都拷小心别把.config里缓存了旧硬件信息的目录也拷过来最好只拷贝自己明确需要的目录比如~/projects、~/catkin_ws、~/anaconda3、~/.ssh这些。然后是Docker镜像。Docker的镜像和容器数据默认存在/var/lib/docker直接整个目录拷贝到NVMe上最省事。但要注意版本兼容性——如果SD卡系统和你NVMe系统用的是同一个JetPack大版本镜像直接拷贝过来大概率能用如果跨大版本比如从JetPack 5升到6很多基于L4T的镜像会因为基础库版本不匹配而无法启动这时候最好重新拉镜像或者重新构建。Python环境的迁移也要特别留意。Jetson的很多Python包都包含CUDA扩展比如torch、torchvision、onnxruntime-gpu这些包在安装时做了深度绑定。如果SD卡和NVMe系统的JetPack版本一致直接拷贝site-packages目录通常没问题如果不一致建议用pip freeze requirements.txt导出依赖列表在新系统上重新安装虽然耗时但更干净。这里分享一个我踩过的坑我从SD卡迁移到NVMe之后发现所有Python程序启动都变慢排查了很久才意识到是家目录里残留了旧的.cache和.local里面存了很多编译缓存的.so文件路径还是指向旧的内核模块。删掉~/.cache和~/.local/lib/python3.8/site-packages之后整个系统飞一样快。迁移数据时不要盲目全部拷贝只复制真正需要的业务数据和环境配置。如果你在SD卡上配了CUDA环境变量、ROS2环境变量、Jetson相关的/etc/profile.d脚本这些也要手动迁移。最简单粗暴的方式是直接对比SD卡和NVMe系统的/etc/profile.d/目录把所有.sh脚本拷贝过来然后重启终端验证。还有一个小细节很多人在SD卡上手动装过SWAP文件或者zram配置迁移到NVMe之后建议重新配置SWAP大小。虽然NVMe快但发生SWAP时仍然会占用磁盘IO对SSD寿命也有影响。如果你内存够用8GB或以上可以在/etc/sysctl.conf里把vm.swappiness调低到10甚至直接关掉SWAP让系统更依赖物理内存减少对SSD的磨损。数据迁移完成后建议连续运行一段时间观察系统日志有没有异常报错。NVMe盘和SD卡的电源管理策略不太一样有些在SD卡上正常的时钟同步、休眠唤醒流程在NVMe启动后可能会因为驱动加载顺序不同而出现警告。看到dmesg里有NVMe相关的警告信息一般不影响使用但如果出现nvme nvme0: I/O error就要立刻检查供电和散热了。7. 换NVMe之后经常遇到的几个坑和对应的排查思路最后把这段时间我在社区里看到的高频问题汇总一下基本覆盖“烧录失败”“启动失败”“性能异常”三大类。7.1 烧录时报chip is in debug mode或USB write failed这个基本可以确定是主机和Orin Nano之间的USB连接问题。换一根短一点、质量好一点的USB线最好直接连主机后置USB口不要经过Hub。另外确认你按Recovery键的时机——要先按住Recovery再上电/Reset不能先上电再按。如果lsusb都看不到NVIDIA设备说明板子根本没进入Recovery模式检查按键是否按到位。7.2 烧录完成后第一次开机黑屏或卡logo依次排查三件事第一确认NVMe盘已经装回M.2插槽并锁好第二拔掉所有SD卡和U盘避免BootLoader错误引导到其他介质第三如果是通过硬盘盒烧录的重新检查最终镜像是不是完整落在了nvme0n1p1而不是写到了某个外部设备上。实在不行重新烧一遍——大多数情况下是烧录参数里指定了内部eMMC而不是外部NVMe。7.3 系统能启动但性能没有明显提升NVMe盘跑道了SD卡的速度多半是因为SSD运行在PCIe 2.0速率。在Orin Nano上查看sudo lspci | grep -i nvme如果链路速率显示Gen2而盘支持Gen3检查一下M.2插槽周围有没有物理损坏或者SSD是不是老款不支持Gen3。还有一种可能是你的SSD本身是SATA协议的却被当成NVMe使用这种情况速率上限就卡在SATA的水平。7.4 升级系统内核之后NVMe驱动丢失JetPack系统升级内核后NVMe驱动模块有可能没有被重新打包进initrd导致启动时找不到根文件系统。解决方法是手动重新生成initrdsudo update-initramfs -c -k $(uname -r)然后再用nvflash或者其他方式重新烧录一次。这个问题在跨越内核大版本升级时出现过不是什么罕见事情。7.5 温度引起的SSD降速如果你在跑连续推理时观察到的性能时不时掉一截先看nvme smart-log里的温度读数sudo nvme smart-log /dev/nvme0n1温度超过70°C就要注意了。给M.2盘加散热片、优化机箱风道、降低环境温度是解决降速最直接的手段。Orin Nano Developer Kit的M.2位置本身没有主动散热所以这个坑几乎是所有换NVMe的人都会遇到提前处理比事后排查省心。从SD卡换到NVMe盘烧录这个动作本身只花十几分钟但它带来的使用体验提升是全面的。离线场景下这套流程所有依赖都可以提前准备好操作过程中随时可以用lsblk、dmesg这些基础命令自查本质上比做一张可启动SD卡还要直白。希望这篇内容能帮你省掉那些我当年反复折腾的弯路。
阅读完成 · 觉得有帮助?