很多人第一次接触NVIDIA Jetson Orin拿到板子第一反应就是赶紧插电开机结果发现设备预装系统版本很旧或者压根没有系统只能从头开始刷JetPack。以我这两年和AGX Orin、Orin NX、Orin Nano折腾下来的经验说句实在话刷JetPack本身不难难的是刷写之前那一堆准备工作以及刷写过程中各种莫名其妙的报错排查。这篇文章我把完整流程和踩过的坑整理出来按这个顺序走能少熬好几个夜。1. 为什么说Orin刷系统九成的坑都出在准备工作1.1 Orin系列几款芯片的刷写差异Jetson Orin系列现在主流有三款AGX Orin性能最强带主动散热、Orin NX模块化设计常用于工控载板、Orin Nano入门级性价比很高。很多人以为它们刷写方式一样实际有细微差别。AGX Orin开发套件是完整的一整块板子自带USB-C口和电源接口刷写最省心。Orin NX和Orin Nano则有两种形态一种是官方开发套件DevKit另一种是你自己设计的或者第三方厂商做的载板。官方DevKit的刷写流程跟AGX基本一致但第三方载板就麻烦一些因为要额外准备载板厂商提供的适配包直接用SDK Manager默认配置可能起不来系统。所以刷写前第一件事先确认你的板子是官方DevKit还是第三方载板。另外还要注意Orin NX和Orin Nano的核心板分不同代际比如Orin NX有16GB和8GB版本Orin Nano也有4GB现在新出的Super版本还把内存提到了8GB。不同模块对应的设备树和刷写包不一样SDK Manager选择设备型号的时候一定选对选错了轻则刷完起不来重则把模块锁死需要恢复模式重新来。1.2 JetPack版本和硬件、Ubuntu版本的对应关系JetPack是NVIDIA给Jetson系列推出的整套SDK包含Linux系统L4TLinux for Tegra、CUDA、cuDNN、TensorRT、DeepStream等一堆组件。JetPack版本跟硬件平台是绑定的不能随便装。比如较老的Xavier系列就不支持最新的JetPack 6而Orin系列可以支持JetPack 5.x和6.x。目前Orin系列主流的推荐是JetPack 5.1.2对应L4T 35.4.1和JetPack 6.0/6.2对应L4T 36.x前者基于Ubuntu 20.04后者基于Ubuntu 22.04。对于做深度学习部署的朋友我建议如果不是必须用某个新特性优先考虑JetPack 5.1.2因为它出来时间最久各家的算子库、ROS包、DeepStream版本适配都比较成熟。JetPack 6.x的容器化改动比较大生态还在追有些第三方库踩坑时找不到参考。这里给一张对应关系表方便查JetPack版本L4T版本基础Ubuntu支持Orin系列JetPack 5.1.235.4.1Ubuntu 20.04全系支持最稳定JetPack 5.1.335.5.0Ubuntu 20.04全系修复部分bugJetPack 6.036.3.0Ubuntu 22.04全系容器化升级JetPack 6.236.4.0Ubuntu 22.04全系新增Orin Nano Super支持1.3 刷写路线的选择SDK Manager还是命令行Jetson刷系统有两条路线一是SDK Manager图形界面二是手写命令行脚本下载L4T驱动包后用flash.sh刷。SDK Manager底层调用的其实还是NVIDIA官方驱动包里的刷写脚本只不过它帮你把下载组件、打包根文件系统、进入刷写模式这些步骤一体化了而且还能顺带帮你安装CUDA、TensorRT这些SDK组件到开发板上。对于绝大多数人我建议直接用SDK Manager。理由很简单命令行方式要手动管理依赖、手动选设备树、手动处理驱动包和根文件系统的合并一步错就白等半小时。SDK Manager虽然也有自己的问题但好歹有图形界面报错信息相对明确社区里遇到的人多搜索解决方案容易。2. 主机端环境一台不背锅的Ubuntu电脑有多重要SDK Manager只能在x86_64架构的Linux上运行Windows和macOS不行ARM架构的Linux也不行。这是一个硬性门槛别指望在Windows的虚拟机里跑——就算虚拟机能识别USB设备刷写过程中也会因为USB协议栈的转发问题频繁断连成功率极低。我见过有人在macOS上装虚拟机跑SDK Manager折腾一整天最后还是老实找了一台Ubuntu主机。2.1 主机系统版本与硬件需求官方要求是Ubuntu 18.04/20.04/22.04的64位系统实际使用中最好用Ubuntu 20.04或22.04的干净系统。主机建议内存不低于8GB实际刷写时SDK Manager会同时跑下载、解压、打包几个进程16GB内存体验好很多。磁盘空间这块容易被忽视SDK Manager下载的安装包和解压后的根文件系统加起来非常占地方建议给存放目录预留至少25GB到30GB空闲空间。我自己的习惯是提前执行df -h看一下确保足够才继续。如果主机本身是NVIDIA GPU显卡电脑装了显卡驱动理论上不影响SDK Manager运行。但有个坑是极少数情况下主机的NVIDIA驱动版本和SDK Manager自带的某个组件检测逻辑冲突导致界面显示异常或者闪退。真遇到的话可以先试着用sudo apt update把系统包更新到最新或者换一个版本的主机系统试试不要一上来就重装驱动容易把主机搞挂。2.2 安装SDK Manager之前的几步准备先到NVIDIA官方开发者网站下载SDK Manager的deb安装包。这里注意NVIDIA官网的下载按钮需要登录开发者账号没有就提前注册一个不然到后面刷写流程会让你登录那时候再注册就打断节奏了。下载完deb包后用命令安装sudo apt install ./sdkmanager_[版本号]_amd64.deb安装结束后会在系统的应用程序列表里出现SDK Manager的图标。首次启动需要接受NVIDIA的许可协议并且会要求登录NVIDIA开发者账号。登录这块经常有人卡住——如果你的网络环境不太稳定登录页面会长时间转圈。等几分钟还不行就重试或者检查一下系统时间是不是准确的系统时间偏差太大时HTTPS证书校验会通不过这也是一种比较隐蔽的原因。另外SDK Manager运行后默认会把下载的安装包放在~/Downloads/nvidia/sdkm_downloads下如果你希望放到别的盘或者空间更大的目录可以在SDK Manager的设置界面改下载路径。这一点很实用我后来就把它改到了一个单独挂载的大分区刷写时就不用担心临时空间不够了。2.3 一个很容易被忽略的权限问题SDK Manager刷写Jetson时需要访问USB设备和执行mount操作这些都需要root权限。SDK Manager图形界面会通过pkexec或sudo机制弹窗让你输入密码如果你用的是精简版Ubuntu或者某个桌面环境把polkit权限管理服务给精简掉了弹窗可能不出现导致刷写卡在等待授权这一步。遇到这种情况可以在终端里直接启动SDK Manager这样授权提示会保持在同一个session里报错信息也能直接看到。提示如果终端启动时提示缺少某种图形库依赖检查是不是用了精简版桌面。装回标准Ubuntu桌面组件通常能解决。3. 让开发板进入Recovery Mode按键、线材与连接顺序3.1 不同Orin设备的Recovery按键位置Recovery Mode在Jetson开发板上是一个非常重要的状态相当于手机刷机时的Fastboot模式。AGX Orin开发套件上有两个按键一个标着Reset一个标着Recovery就在USB-C口旁边。Orin Nano DevKit同样有这两个按键不过位置稍微偏一些。Orin NX如果是装在第三方载板上按键位置就不固定了得看载板的说明书。进入Recovery Mode的标准操作流程是给开发板断电拔掉电源适配器按住Recovery键不放插上电源适配器等待几秒松开Recovery键。这个顺序不能乱。有朋友习惯先插电再按Recovery那样十次有九次进不去。因为Jetson的Recovery按键是在上电瞬间被读到的你必须在上电之前就按住。3.2 连接顺序和USB线材的讲究主机和开发板之间的连接走的是开发板上的USB-C口不是别的USB口。AGX Orin开发套件上有一个Type-C口专门用于刷机旁边通常标注USB或者有对应丝印Orin Nano/Orin NX DevKit则直接通过它们唯一的USB-C口连接。第三方载板的话一般会单独标注一个USB Device或者刷机口。这里要重点说线材。USB-C线看起来长得一样但有的只支持充电不支持数据或者数据线质量差导致传输不稳定。刷机过程中因为线材问题导致USB断连是非常高频的故障点。我的建议是使用原装线或者至少是支持USB 3.0/3.1速率、线径较粗的品牌数据线。另外传输线缆越短越好一米的线比两米的稳得多。别问我怎么知道的问就是被一根杂牌线折磨了一晚上。连接顺序上推荐先用USB-C线把开发板和主机连好再接电源。如果反过来开发板先上电再插USB线部分主机可能无法正确枚举出设备。当然前提是开发板已经进入Recovery状态。3.3 如何确认开发板确实进入了Recovery Mode进入Recovery状态后怎么确认主机已经识别到设备在主机终端执行lsusb如果看到类似下面的输出Bus 001 Device 004: ID 0955:7023 NVIDIA Corp. APX0955是NVIDIA的USB Vendor ID7023是Orin系列在Recovery模式下的Product ID。看到NVIDIA Corp. APX这一行基本就是成功了。这一步强烈建议做。因为很多情况下你以为按住了Recovery键实际没进对状态直接开刷当然失败。养成先lsusb确认、再打开SDK Manager的习惯能排除大量低级错误。另外如果lsusb没有看到设备先换一根USB线再换一个USB口台式机优先用后置USB口最后考虑是不是按键时序出了问题。这三种原因占了识别不到设备的九成以上。4. SDK Manager刷写全流程从登录到首次启动4.1 创建任务时的关键选项打开SDK Manager登录账号之后主界面会要求选择目标硬件平台和需要部署的系统。在Hardware Configuration里首先选择你的设备型号比如Jetson AGX Orin DevKit、Jetson Orin Nano DevKit等。型号选错会导致SDK Manager加载错误的设备配置刷完系统起不来。接下来选择JetPack版本。前面说过优先推荐JetPack 5.1.2如果你想上JetPack 6系列确认你的应用场景里的库都兼容后再选。这里还要注意SDK Manager列出的JetPack版本不是所有设备型号都能选它会根据你选的硬件自动过滤。勾选完版本进入下一步它会列出需要安装的组件。这个界面有一个非常关键的复选列表分为Jetson OS和Jetson SDK Components两大部分。很多人在这里贪多把DeepStream、CUDA、cuDNN、TensorRT、VPI、ISAAC全部勾上结果下载量巨大刷写时间翻倍而且某些组件占用的磁盘空间非常夸张。我的建议是第一次刷写只保留核心组件必选项Jetson OS这是操作系统本体推荐项CUDA、cuDNN、TensorRT可选项DeepStream如果你做视频流分析就用得上不涉及可以暂时不装其他组件用到什么装什么别一次装全。记住SDK Manager刷完系统后组件是可以随时再次运行的它会检测已安装的目标设备并允许你增量安装组件。不用非得一次装齐。4.2 两种模式的本质区别SDK Manager在刷写时会让你选择Jetson OS only还是Jetson OS and SDK Components。前者只刷系统把CUDA等组件留到后续手动装后者在刷系统时同时把SDK组件目标安装到板子。注意这里的机制SDK Manager不是在系统装好后像普通软件那样安装CUDA而是在构建根文件系统阶段就把组件文件放进去这个阶段你主机会执行一个打包操作生成自定义镜像需要一定时间。我见过有人选了Jetson OS only以为后面能在SDK Manager里方便地补装组件结果他想补装CUDA时发现SDK Manager又要重新刷一遍系统非常尴尬。NVIDIA官方SDK Manager的设计就是这样组件安装和系统刷写绑定在同一个流程里还不如一开始就把想要的组件选好。所以要么不想以后麻烦第一次就把需要的组件选上要么就接受后面要重新走一遍刷机流程。4.3 刷写过程中的时间预估和心理预期点击Flash之后SDK Manager会经历下载安装包、解压、创建系统镜像、写入开发板、开发板自动重启并首次开机配置、组件安装几个阶段。整个过程的时间差别很大主要取决于你的网络速度和开发板的存储类型。SDK Manager需要下载的JetPack完整包可能有10GB以上如果你的网速在10MB/s左右单下载就要20分钟以上。写入阶段Orin系列用的是NVMe SSDNano有eMMC版本写入速度很快但校验和确认阶段比较慢。总体下来顺利的话40分钟到1小时网络差或者组件选得多两小时也正常。等待期间不要去做以下动作不要动USB线哪怕它看起来很松不要打开SDK Manager里其他需要访问同一下载目录的功能不要合上笔记本盖子很多笔记本合盖会休眠USB设备随即掉线。刷写过程中开发板可能会自动重启这是正常现象。有的开发板会重启不止一次屏幕上可能出现Ubuntu的启动日志这些都不需要你干预。SDK Manager界面上会显示当前正在进行的步骤耐心等就好。刷写完成后SDK Manager会提示你设置Jetson的用户名、密码和主机名。这一步是给板子上的Ubuntu系统创建初始账户用的设置完它就尝试通过SSH连接到开发板然后把SDK组件推到板子上。也有人在这儿卡住因为开发板重启后网络没获取到IPSDK Manager连不上。如果是用网线直连主机要确保两边在同一网段如果开发板连了路由器等它拿到IP后再继续。4.4 首次启动后的系统表现一切正常的话你会在外接显示器上看到Ubuntu桌面如果接了屏幕的话或者通过ssh [用户名][开发板IP]登录命令行。这里有一个经验很多人刷完板子没接显示器也没有网络然后说刷写失败其实板子早就刷好了只是你不给它接显示器也不告诉它连哪个Wi-Fi它当然无法出现在你的网络里。开发板初始状态是默认不开启Wi-Fi连接的有屏幕的话可以进桌面手动选Wi-Fi没有屏幕就用网线连接路由器然后在路由器后台找它的IP。5. 刷写失败排查实录我把遇到过的问题拆开讲SDK Manager的报错信息有时候很笼统比如弹出Flash Jetson failed或者Target挂载失败没有细节。这里把我实际遇到过的几类问题及排查链路完整写出来希望能帮你少走弯路。5.1 刷写进行到一半提示USB设备断开表现为开发板写入过程中SDK Manager进度条停住随后报错Failed to flash Jetson。此时回到终端看lsusb可能已经找不到NVIDIA设备。根因绝大多数是以下三个USB数据线质量差数据传输量一大就掉线USB口供电不足笔记本的USB口常见尤其是Type-A转Type-C时系统电源管理把USB设备挂起。排查链路换一根短的高质量USB-C线如果主机是笔记本尽量用支持PD供电的Type-C口避免用扩展坞关闭主机的USB自动挂起功能。在Ubuntu上可以执行sudo systemctl mask sleep.target suspend.target来临时禁用休眠再试一次开发板端如果是第三方载板检查它的刷机口是否需要外部供电有的载板必须同时插上模块电源和底板电源。5.2 提示无法读取设备信息或者目标挂载失败这种情况通常是开发板已经进入Recovery模式但SDK Manager无法正确获取设备型号导致。常见原因开发板在REC模式Recovery下USB枚举不稳定主机端需要重新加载USB驱动。可以尝试拔掉USB线重新插再执行lsusb看设备是否重新出现开发板同时连了多个USB设备比如U盘、鼠标、键盘个别情况下会干扰枚举。刷写时尽量只保留刷机线第三方载板某些型号要求先给底板刷一个特殊的Bootloader才能被SDK Manager识别遇到这种情况去看载板厂商文档不要硬刷。还有一个比较少见的坑主机系统是中文环境时SDK Manager对路径中的非ASCII字符处理有问题。如果你用户名或者下载目录路径包含中文刷写时打包根文件系统可能报错。解决办法是换一个纯英文路径或者在设置里重新指定下载目录到/home/你的英文路径下。5.3 刷写成功但系统起不来黑屏或反复重启刷写时没有报错但开发板断电重启后无法进入系统。先看指示灯AGX Orin和Orin Nano DevKit都有电源指示灯如果灯亮但屏幕无信号大概率是显示输出问题可以试试HDMI换DP口或者反过来。如果反复重启电源灯一亮一灭通常是Bootloader和设备树不匹配多半是你选错设备型号了。比如你是Orin NX 16GB却选了Orin NX 8GB的设备类型系统配置的内核设备树与实际硬件不符。这种情况解决办法是重新进入Recovery模式先擦除设备再重新刷写。注意SDK Manager界面里有一个Erase EMMC before flashing的选项如果系统已经损坏无法启动需要勾选这个选项做一次干净的擦除重刷。还有一类黑屏问题是Orin NX和Orin Nano的开发者套件它们在刷写后首次启动时需要较长的初始化时间第一次启动可能黑屏几分钟看起来像死机实际上系统在做文件系统扩容。多等五分钟别急着断电。5.4 网络下载中断SDK Manager报下载失败JetPack安装包较大网络不好时下载到一半会失败。SDK Manager会保留已下载的部分重新开始时会断点续传这个还好。最烦的是下载文件校验失败SDK Manager提示Checksum mismatch。解决办法是手动删除~/Downloads/nvidia/sdkm_downloads下对应的临时文件特别是.part文件然后重新触发下载或者直接把整个sdkm_downloads目录清空重下。另外如果公司网络或校园网有代理SDK Manager的下载可能被代理拦截表现是下载速度极慢或者报SSL错误。如果在Ubuntu系统里设置了代理可以暂时关闭代理再重试。注意刷写过程中不要手动去修改NVIDIA下载目录里的文件哪怕是文件名大小写都会导致校验失败老实等它自己处理就好。6. 刷完之后别急着跑代码先做这三轮验证6.1 第一轮确认系统版本与内核信息通过SSH登录开发板后依次执行下面的命令确认刷写结果# 查看Ubuntu版本 lsb_release -a # 查看L4T版本 cat /etc/nv_tegra_release # 查看内核版本 uname -a预期结果Ubuntu版本对应你选的JetPack基础系统比如Ubuntu 20.04/etc/nv_tegra_release文件里面包含L4T版本号比如# R35 (release) REVISION: 4.1。如果这些都对说明系统本体没问题。6.2 第二轮验证CUDA等组件是否真正可用这时候很多人会习惯性执行nvidia-smi结果发现报错nvidia-smi has failed because it couldnt communicate with the nvidia driver——不用担心Jetson和普通x86的NVIDIA电脑不一样它使用的是Tegra驱动nvidia-smi在某些JetPack版本上默认不直接对应用户态工具或者路径不同。在Orin上推荐使用# 查看系统版本与驱动的版本信息 dpkg -l | grep nvidia-l4t-core # 检查CUDA是否安装 ls /usr/local/cuda/bin/nvcc /usr/local/cuda/bin/nvcc --version如果nvcc正常输出版本号说明CUDA已经可用。不要纠结于nvidia-smi在Jetson上的输出形式而是用nvcc和dpkg来验证。TensorRT的验证可以运行它的自带样例cd /usr/src/tensorrt/samples # 或者直接运行trtexec /usr/src/tensorrt/bin/trtexec --help正常能输出trtexec的help信息说明TensorRT核心库安装没问题。6.3 第三轮安装jtop做一次性能摸底jtop是一个非常实用的Jetson系统监控工具可以看到CPU/GPU频率、温度、内存占用、功耗等实时数据。安装方式sudo pip3 install jetson-stats sudo jtop打开jtop后重点看两个地方一是每个核心的频率是否工作在正常范围如果系统刚启动且没有负载频率低是正常的二是当前电源模式。Orin系列默认是低功耗模式还是全速模式要看JetPack的设置你可以通过以下命令查看CPU的可用模式sudo nvpmodel -q如果只是做模型推理测试我建议把电源模式切换到全功率比如AGX Orin通常有MAXN模式或者nvpmodel -m 0不同JetPack版本0号对应模式可能不同先nvpmodel -q查可选项。另外风扇策略也需要确认有些DevKit默认风扇转速很低高负载下SoC温度窜到80度以上也不转你可以在jtop里手动拉高风扇或者在/etc/下调整散热配置。这一步容易被忽略但直接影响后续跑模型的稳定性。6.4 最后说一个关于存储分区的习惯Orin系列开发板通常板载存储是eMMC或NVMe SSDJetPack刷写时会自动创建多个分区其中可写的数据分区用户通常可以自由使用。我个人拿到任何一台新的Orin会先扩充一下根文件系统分区占用然后用df -h确认/分区空间符合预期。如果刷完系统后发现根分区可用空间特别小比如只有几个GB很可能是L4T版本对分区大小的自动调整逻辑没跑可以执行系统自带的扩容脚本在JetPack 6上这一步一般会自动完成JetPack 5有些版本需要手动触发。具体判断方法df -h /如果可用空间小于10GB而你的板子存储明显更大就是没扩容完网上搜索对应JetPack版本的扩容命令即可。反正开工前把这件事做完别等把模型数据拷进去才发现空间不够。刷机这件事最怕的不是技术和网络而是准备工作时图省事。线材不换、Recovery Mode不验证、组件乱勾一堆出了问题又到处问浪费时间。按我上面这套流程走提前把能确认的都确认好剩下的交给SDK Manager和一点耐心基本都能顺利跑起来。如果你是在第三方载板上折腾Orin NX记住一句话先查载板厂商的兼容说明再动手刷能省掉九成麻烦。
NVIDIA Jetson Orin刷机实战：JetPack刷写完整流程与避坑指南
很多人第一次接触NVIDIA Jetson Orin拿到板子第一反应就是赶紧插电开机结果发现设备预装系统版本很旧或者压根没有系统只能从头开始刷JetPack。以我这两年和AGX Orin、Orin NX、Orin Nano折腾下来的经验说句实在话刷JetPack本身不难难的是刷写之前那一堆准备工作以及刷写过程中各种莫名其妙的报错排查。这篇文章我把完整流程和踩过的坑整理出来按这个顺序走能少熬好几个夜。1. 为什么说Orin刷系统九成的坑都出在准备工作1.1 Orin系列几款芯片的刷写差异Jetson Orin系列现在主流有三款AGX Orin性能最强带主动散热、Orin NX模块化设计常用于工控载板、Orin Nano入门级性价比很高。很多人以为它们刷写方式一样实际有细微差别。AGX Orin开发套件是完整的一整块板子自带USB-C口和电源接口刷写最省心。Orin NX和Orin Nano则有两种形态一种是官方开发套件DevKit另一种是你自己设计的或者第三方厂商做的载板。官方DevKit的刷写流程跟AGX基本一致但第三方载板就麻烦一些因为要额外准备载板厂商提供的适配包直接用SDK Manager默认配置可能起不来系统。所以刷写前第一件事先确认你的板子是官方DevKit还是第三方载板。另外还要注意Orin NX和Orin Nano的核心板分不同代际比如Orin NX有16GB和8GB版本Orin Nano也有4GB现在新出的Super版本还把内存提到了8GB。不同模块对应的设备树和刷写包不一样SDK Manager选择设备型号的时候一定选对选错了轻则刷完起不来重则把模块锁死需要恢复模式重新来。1.2 JetPack版本和硬件、Ubuntu版本的对应关系JetPack是NVIDIA给Jetson系列推出的整套SDK包含Linux系统L4TLinux for Tegra、CUDA、cuDNN、TensorRT、DeepStream等一堆组件。JetPack版本跟硬件平台是绑定的不能随便装。比如较老的Xavier系列就不支持最新的JetPack 6而Orin系列可以支持JetPack 5.x和6.x。目前Orin系列主流的推荐是JetPack 5.1.2对应L4T 35.4.1和JetPack 6.0/6.2对应L4T 36.x前者基于Ubuntu 20.04后者基于Ubuntu 22.04。对于做深度学习部署的朋友我建议如果不是必须用某个新特性优先考虑JetPack 5.1.2因为它出来时间最久各家的算子库、ROS包、DeepStream版本适配都比较成熟。JetPack 6.x的容器化改动比较大生态还在追有些第三方库踩坑时找不到参考。这里给一张对应关系表方便查JetPack版本L4T版本基础Ubuntu支持Orin系列JetPack 5.1.235.4.1Ubuntu 20.04全系支持最稳定JetPack 5.1.335.5.0Ubuntu 20.04全系修复部分bugJetPack 6.036.3.0Ubuntu 22.04全系容器化升级JetPack 6.236.4.0Ubuntu 22.04全系新增Orin Nano Super支持1.3 刷写路线的选择SDK Manager还是命令行Jetson刷系统有两条路线一是SDK Manager图形界面二是手写命令行脚本下载L4T驱动包后用flash.sh刷。SDK Manager底层调用的其实还是NVIDIA官方驱动包里的刷写脚本只不过它帮你把下载组件、打包根文件系统、进入刷写模式这些步骤一体化了而且还能顺带帮你安装CUDA、TensorRT这些SDK组件到开发板上。对于绝大多数人我建议直接用SDK Manager。理由很简单命令行方式要手动管理依赖、手动选设备树、手动处理驱动包和根文件系统的合并一步错就白等半小时。SDK Manager虽然也有自己的问题但好歹有图形界面报错信息相对明确社区里遇到的人多搜索解决方案容易。2. 主机端环境一台不背锅的Ubuntu电脑有多重要SDK Manager只能在x86_64架构的Linux上运行Windows和macOS不行ARM架构的Linux也不行。这是一个硬性门槛别指望在Windows的虚拟机里跑——就算虚拟机能识别USB设备刷写过程中也会因为USB协议栈的转发问题频繁断连成功率极低。我见过有人在macOS上装虚拟机跑SDK Manager折腾一整天最后还是老实找了一台Ubuntu主机。2.1 主机系统版本与硬件需求官方要求是Ubuntu 18.04/20.04/22.04的64位系统实际使用中最好用Ubuntu 20.04或22.04的干净系统。主机建议内存不低于8GB实际刷写时SDK Manager会同时跑下载、解压、打包几个进程16GB内存体验好很多。磁盘空间这块容易被忽视SDK Manager下载的安装包和解压后的根文件系统加起来非常占地方建议给存放目录预留至少25GB到30GB空闲空间。我自己的习惯是提前执行df -h看一下确保足够才继续。如果主机本身是NVIDIA GPU显卡电脑装了显卡驱动理论上不影响SDK Manager运行。但有个坑是极少数情况下主机的NVIDIA驱动版本和SDK Manager自带的某个组件检测逻辑冲突导致界面显示异常或者闪退。真遇到的话可以先试着用sudo apt update把系统包更新到最新或者换一个版本的主机系统试试不要一上来就重装驱动容易把主机搞挂。2.2 安装SDK Manager之前的几步准备先到NVIDIA官方开发者网站下载SDK Manager的deb安装包。这里注意NVIDIA官网的下载按钮需要登录开发者账号没有就提前注册一个不然到后面刷写流程会让你登录那时候再注册就打断节奏了。下载完deb包后用命令安装sudo apt install ./sdkmanager_[版本号]_amd64.deb安装结束后会在系统的应用程序列表里出现SDK Manager的图标。首次启动需要接受NVIDIA的许可协议并且会要求登录NVIDIA开发者账号。登录这块经常有人卡住——如果你的网络环境不太稳定登录页面会长时间转圈。等几分钟还不行就重试或者检查一下系统时间是不是准确的系统时间偏差太大时HTTPS证书校验会通不过这也是一种比较隐蔽的原因。另外SDK Manager运行后默认会把下载的安装包放在~/Downloads/nvidia/sdkm_downloads下如果你希望放到别的盘或者空间更大的目录可以在SDK Manager的设置界面改下载路径。这一点很实用我后来就把它改到了一个单独挂载的大分区刷写时就不用担心临时空间不够了。2.3 一个很容易被忽略的权限问题SDK Manager刷写Jetson时需要访问USB设备和执行mount操作这些都需要root权限。SDK Manager图形界面会通过pkexec或sudo机制弹窗让你输入密码如果你用的是精简版Ubuntu或者某个桌面环境把polkit权限管理服务给精简掉了弹窗可能不出现导致刷写卡在等待授权这一步。遇到这种情况可以在终端里直接启动SDK Manager这样授权提示会保持在同一个session里报错信息也能直接看到。提示如果终端启动时提示缺少某种图形库依赖检查是不是用了精简版桌面。装回标准Ubuntu桌面组件通常能解决。3. 让开发板进入Recovery Mode按键、线材与连接顺序3.1 不同Orin设备的Recovery按键位置Recovery Mode在Jetson开发板上是一个非常重要的状态相当于手机刷机时的Fastboot模式。AGX Orin开发套件上有两个按键一个标着Reset一个标着Recovery就在USB-C口旁边。Orin Nano DevKit同样有这两个按键不过位置稍微偏一些。Orin NX如果是装在第三方载板上按键位置就不固定了得看载板的说明书。进入Recovery Mode的标准操作流程是给开发板断电拔掉电源适配器按住Recovery键不放插上电源适配器等待几秒松开Recovery键。这个顺序不能乱。有朋友习惯先插电再按Recovery那样十次有九次进不去。因为Jetson的Recovery按键是在上电瞬间被读到的你必须在上电之前就按住。3.2 连接顺序和USB线材的讲究主机和开发板之间的连接走的是开发板上的USB-C口不是别的USB口。AGX Orin开发套件上有一个Type-C口专门用于刷机旁边通常标注USB或者有对应丝印Orin Nano/Orin NX DevKit则直接通过它们唯一的USB-C口连接。第三方载板的话一般会单独标注一个USB Device或者刷机口。这里要重点说线材。USB-C线看起来长得一样但有的只支持充电不支持数据或者数据线质量差导致传输不稳定。刷机过程中因为线材问题导致USB断连是非常高频的故障点。我的建议是使用原装线或者至少是支持USB 3.0/3.1速率、线径较粗的品牌数据线。另外传输线缆越短越好一米的线比两米的稳得多。别问我怎么知道的问就是被一根杂牌线折磨了一晚上。连接顺序上推荐先用USB-C线把开发板和主机连好再接电源。如果反过来开发板先上电再插USB线部分主机可能无法正确枚举出设备。当然前提是开发板已经进入Recovery状态。3.3 如何确认开发板确实进入了Recovery Mode进入Recovery状态后怎么确认主机已经识别到设备在主机终端执行lsusb如果看到类似下面的输出Bus 001 Device 004: ID 0955:7023 NVIDIA Corp. APX0955是NVIDIA的USB Vendor ID7023是Orin系列在Recovery模式下的Product ID。看到NVIDIA Corp. APX这一行基本就是成功了。这一步强烈建议做。因为很多情况下你以为按住了Recovery键实际没进对状态直接开刷当然失败。养成先lsusb确认、再打开SDK Manager的习惯能排除大量低级错误。另外如果lsusb没有看到设备先换一根USB线再换一个USB口台式机优先用后置USB口最后考虑是不是按键时序出了问题。这三种原因占了识别不到设备的九成以上。4. SDK Manager刷写全流程从登录到首次启动4.1 创建任务时的关键选项打开SDK Manager登录账号之后主界面会要求选择目标硬件平台和需要部署的系统。在Hardware Configuration里首先选择你的设备型号比如Jetson AGX Orin DevKit、Jetson Orin Nano DevKit等。型号选错会导致SDK Manager加载错误的设备配置刷完系统起不来。接下来选择JetPack版本。前面说过优先推荐JetPack 5.1.2如果你想上JetPack 6系列确认你的应用场景里的库都兼容后再选。这里还要注意SDK Manager列出的JetPack版本不是所有设备型号都能选它会根据你选的硬件自动过滤。勾选完版本进入下一步它会列出需要安装的组件。这个界面有一个非常关键的复选列表分为Jetson OS和Jetson SDK Components两大部分。很多人在这里贪多把DeepStream、CUDA、cuDNN、TensorRT、VPI、ISAAC全部勾上结果下载量巨大刷写时间翻倍而且某些组件占用的磁盘空间非常夸张。我的建议是第一次刷写只保留核心组件必选项Jetson OS这是操作系统本体推荐项CUDA、cuDNN、TensorRT可选项DeepStream如果你做视频流分析就用得上不涉及可以暂时不装其他组件用到什么装什么别一次装全。记住SDK Manager刷完系统后组件是可以随时再次运行的它会检测已安装的目标设备并允许你增量安装组件。不用非得一次装齐。4.2 两种模式的本质区别SDK Manager在刷写时会让你选择Jetson OS only还是Jetson OS and SDK Components。前者只刷系统把CUDA等组件留到后续手动装后者在刷系统时同时把SDK组件目标安装到板子。注意这里的机制SDK Manager不是在系统装好后像普通软件那样安装CUDA而是在构建根文件系统阶段就把组件文件放进去这个阶段你主机会执行一个打包操作生成自定义镜像需要一定时间。我见过有人选了Jetson OS only以为后面能在SDK Manager里方便地补装组件结果他想补装CUDA时发现SDK Manager又要重新刷一遍系统非常尴尬。NVIDIA官方SDK Manager的设计就是这样组件安装和系统刷写绑定在同一个流程里还不如一开始就把想要的组件选好。所以要么不想以后麻烦第一次就把需要的组件选上要么就接受后面要重新走一遍刷机流程。4.3 刷写过程中的时间预估和心理预期点击Flash之后SDK Manager会经历下载安装包、解压、创建系统镜像、写入开发板、开发板自动重启并首次开机配置、组件安装几个阶段。整个过程的时间差别很大主要取决于你的网络速度和开发板的存储类型。SDK Manager需要下载的JetPack完整包可能有10GB以上如果你的网速在10MB/s左右单下载就要20分钟以上。写入阶段Orin系列用的是NVMe SSDNano有eMMC版本写入速度很快但校验和确认阶段比较慢。总体下来顺利的话40分钟到1小时网络差或者组件选得多两小时也正常。等待期间不要去做以下动作不要动USB线哪怕它看起来很松不要打开SDK Manager里其他需要访问同一下载目录的功能不要合上笔记本盖子很多笔记本合盖会休眠USB设备随即掉线。刷写过程中开发板可能会自动重启这是正常现象。有的开发板会重启不止一次屏幕上可能出现Ubuntu的启动日志这些都不需要你干预。SDK Manager界面上会显示当前正在进行的步骤耐心等就好。刷写完成后SDK Manager会提示你设置Jetson的用户名、密码和主机名。这一步是给板子上的Ubuntu系统创建初始账户用的设置完它就尝试通过SSH连接到开发板然后把SDK组件推到板子上。也有人在这儿卡住因为开发板重启后网络没获取到IPSDK Manager连不上。如果是用网线直连主机要确保两边在同一网段如果开发板连了路由器等它拿到IP后再继续。4.4 首次启动后的系统表现一切正常的话你会在外接显示器上看到Ubuntu桌面如果接了屏幕的话或者通过ssh [用户名][开发板IP]登录命令行。这里有一个经验很多人刷完板子没接显示器也没有网络然后说刷写失败其实板子早就刷好了只是你不给它接显示器也不告诉它连哪个Wi-Fi它当然无法出现在你的网络里。开发板初始状态是默认不开启Wi-Fi连接的有屏幕的话可以进桌面手动选Wi-Fi没有屏幕就用网线连接路由器然后在路由器后台找它的IP。5. 刷写失败排查实录我把遇到过的问题拆开讲SDK Manager的报错信息有时候很笼统比如弹出Flash Jetson failed或者Target挂载失败没有细节。这里把我实际遇到过的几类问题及排查链路完整写出来希望能帮你少走弯路。5.1 刷写进行到一半提示USB设备断开表现为开发板写入过程中SDK Manager进度条停住随后报错Failed to flash Jetson。此时回到终端看lsusb可能已经找不到NVIDIA设备。根因绝大多数是以下三个USB数据线质量差数据传输量一大就掉线USB口供电不足笔记本的USB口常见尤其是Type-A转Type-C时系统电源管理把USB设备挂起。排查链路换一根短的高质量USB-C线如果主机是笔记本尽量用支持PD供电的Type-C口避免用扩展坞关闭主机的USB自动挂起功能。在Ubuntu上可以执行sudo systemctl mask sleep.target suspend.target来临时禁用休眠再试一次开发板端如果是第三方载板检查它的刷机口是否需要外部供电有的载板必须同时插上模块电源和底板电源。5.2 提示无法读取设备信息或者目标挂载失败这种情况通常是开发板已经进入Recovery模式但SDK Manager无法正确获取设备型号导致。常见原因开发板在REC模式Recovery下USB枚举不稳定主机端需要重新加载USB驱动。可以尝试拔掉USB线重新插再执行lsusb看设备是否重新出现开发板同时连了多个USB设备比如U盘、鼠标、键盘个别情况下会干扰枚举。刷写时尽量只保留刷机线第三方载板某些型号要求先给底板刷一个特殊的Bootloader才能被SDK Manager识别遇到这种情况去看载板厂商文档不要硬刷。还有一个比较少见的坑主机系统是中文环境时SDK Manager对路径中的非ASCII字符处理有问题。如果你用户名或者下载目录路径包含中文刷写时打包根文件系统可能报错。解决办法是换一个纯英文路径或者在设置里重新指定下载目录到/home/你的英文路径下。5.3 刷写成功但系统起不来黑屏或反复重启刷写时没有报错但开发板断电重启后无法进入系统。先看指示灯AGX Orin和Orin Nano DevKit都有电源指示灯如果灯亮但屏幕无信号大概率是显示输出问题可以试试HDMI换DP口或者反过来。如果反复重启电源灯一亮一灭通常是Bootloader和设备树不匹配多半是你选错设备型号了。比如你是Orin NX 16GB却选了Orin NX 8GB的设备类型系统配置的内核设备树与实际硬件不符。这种情况解决办法是重新进入Recovery模式先擦除设备再重新刷写。注意SDK Manager界面里有一个Erase EMMC before flashing的选项如果系统已经损坏无法启动需要勾选这个选项做一次干净的擦除重刷。还有一类黑屏问题是Orin NX和Orin Nano的开发者套件它们在刷写后首次启动时需要较长的初始化时间第一次启动可能黑屏几分钟看起来像死机实际上系统在做文件系统扩容。多等五分钟别急着断电。5.4 网络下载中断SDK Manager报下载失败JetPack安装包较大网络不好时下载到一半会失败。SDK Manager会保留已下载的部分重新开始时会断点续传这个还好。最烦的是下载文件校验失败SDK Manager提示Checksum mismatch。解决办法是手动删除~/Downloads/nvidia/sdkm_downloads下对应的临时文件特别是.part文件然后重新触发下载或者直接把整个sdkm_downloads目录清空重下。另外如果公司网络或校园网有代理SDK Manager的下载可能被代理拦截表现是下载速度极慢或者报SSL错误。如果在Ubuntu系统里设置了代理可以暂时关闭代理再重试。注意刷写过程中不要手动去修改NVIDIA下载目录里的文件哪怕是文件名大小写都会导致校验失败老实等它自己处理就好。6. 刷完之后别急着跑代码先做这三轮验证6.1 第一轮确认系统版本与内核信息通过SSH登录开发板后依次执行下面的命令确认刷写结果# 查看Ubuntu版本 lsb_release -a # 查看L4T版本 cat /etc/nv_tegra_release # 查看内核版本 uname -a预期结果Ubuntu版本对应你选的JetPack基础系统比如Ubuntu 20.04/etc/nv_tegra_release文件里面包含L4T版本号比如# R35 (release) REVISION: 4.1。如果这些都对说明系统本体没问题。6.2 第二轮验证CUDA等组件是否真正可用这时候很多人会习惯性执行nvidia-smi结果发现报错nvidia-smi has failed because it couldnt communicate with the nvidia driver——不用担心Jetson和普通x86的NVIDIA电脑不一样它使用的是Tegra驱动nvidia-smi在某些JetPack版本上默认不直接对应用户态工具或者路径不同。在Orin上推荐使用# 查看系统版本与驱动的版本信息 dpkg -l | grep nvidia-l4t-core # 检查CUDA是否安装 ls /usr/local/cuda/bin/nvcc /usr/local/cuda/bin/nvcc --version如果nvcc正常输出版本号说明CUDA已经可用。不要纠结于nvidia-smi在Jetson上的输出形式而是用nvcc和dpkg来验证。TensorRT的验证可以运行它的自带样例cd /usr/src/tensorrt/samples # 或者直接运行trtexec /usr/src/tensorrt/bin/trtexec --help正常能输出trtexec的help信息说明TensorRT核心库安装没问题。6.3 第三轮安装jtop做一次性能摸底jtop是一个非常实用的Jetson系统监控工具可以看到CPU/GPU频率、温度、内存占用、功耗等实时数据。安装方式sudo pip3 install jetson-stats sudo jtop打开jtop后重点看两个地方一是每个核心的频率是否工作在正常范围如果系统刚启动且没有负载频率低是正常的二是当前电源模式。Orin系列默认是低功耗模式还是全速模式要看JetPack的设置你可以通过以下命令查看CPU的可用模式sudo nvpmodel -q如果只是做模型推理测试我建议把电源模式切换到全功率比如AGX Orin通常有MAXN模式或者nvpmodel -m 0不同JetPack版本0号对应模式可能不同先nvpmodel -q查可选项。另外风扇策略也需要确认有些DevKit默认风扇转速很低高负载下SoC温度窜到80度以上也不转你可以在jtop里手动拉高风扇或者在/etc/下调整散热配置。这一步容易被忽略但直接影响后续跑模型的稳定性。6.4 最后说一个关于存储分区的习惯Orin系列开发板通常板载存储是eMMC或NVMe SSDJetPack刷写时会自动创建多个分区其中可写的数据分区用户通常可以自由使用。我个人拿到任何一台新的Orin会先扩充一下根文件系统分区占用然后用df -h确认/分区空间符合预期。如果刷完系统后发现根分区可用空间特别小比如只有几个GB很可能是L4T版本对分区大小的自动调整逻辑没跑可以执行系统自带的扩容脚本在JetPack 6上这一步一般会自动完成JetPack 5有些版本需要手动触发。具体判断方法df -h /如果可用空间小于10GB而你的板子存储明显更大就是没扩容完网上搜索对应JetPack版本的扩容命令即可。反正开工前把这件事做完别等把模型数据拷进去才发现空间不够。刷机这件事最怕的不是技术和网络而是准备工作时图省事。线材不换、Recovery Mode不验证、组件乱勾一堆出了问题又到处问浪费时间。按我上面这套流程走提前把能确认的都确认好剩下的交给SDK Manager和一点耐心基本都能顺利跑起来。如果你是在第三方载板上折腾Orin NX记住一句话先查载板厂商的兼容说明再动手刷能省掉九成麻烦。
