第一次给 Jetson Orin NX Super 刷系统我差点把刚拆封的开发板折腾成砖——倒不是硬件损坏而是刷到一半主机突然断连重启后 eMMC 处于一个半空状态连恢复模式都进得磕磕绊绊。后来把整条链路重新捋了一遍从下载 JetPack、进入 USB 恢复模式到最终把 CUDA 环境配到能正常编译和推理完整跑通之后才发现这个过程其实不复杂但每一步都有看似正常实则坑人的细节。这篇文章就把我从零开始烧录 Jetson Orin NX Super 到配置 CUDA 环境、OpenCV with CUDA、PyTorch 的完整过程记录下来顺便把我踩过的坑、排查思路和最终的配置清单一并放出来。无论你是刚拿到板子的小白还是被刷机报错卡住的老手这篇应该能帮你省下不少折腾时间。1. 刷机前必须想明白的三件事模组版本、烧录载体与Super模式1.1 确认手里的模组8GB 与 16GB 的镜像差异Jetson Orin NX 有两个存储/内存规格8GB 和 16GB。两者外观几乎一样但刷机时能使用的镜像和后续性能表现有区别。尤其是标题里带Super的 Orin NX 16GB是 NVIDIA 在 JetPack 6.2 之后通过新的电源管理策略开放出来的性能模式GPU 频率可以从 918MHz 提升到 1.1GHz内存带宽也从 102.4GB/s 涨到 136.5GB/s整体性能提升在 20% 到 25% 左右。所以刷机之前第一件事先确认你手里的模组到底是哪个版本。最可靠的方式是看模组外壳上的丝印或者直接问卖家要规格书。如果已经能开机也可以在系统里执行cat /proc/device-tree/model cat /proc/device-tree/memory0/reg前者会显示类似NVIDIA Jetson Orin NX 16GB Developer Kit的信息后者能看到内存大小。8GB 版本的 Orin NX 不支持 Super 模式后面所有关于 Super 模式的性能调优操作都可以跳过。1.2 eMMC 与 SD 卡烧录目标和启动介质的选择Jetson Orin NX 核心板自带 eMMC 存储8GB 版对应 32GB eMMC16GB 版对应 16GB eMMC。烧录系统有两个方向一是写入板载 eMMC二是写入 SD 卡。我个人的建议是如果只是日常开发、跑模型推理优先烧进 eMMC。eMMC 的随机读写比大部分 SD 卡稳定长时间跑训练或者频繁读写日志时不容易出现 IO 错误。SD 卡方案的优势在于可以准备多张卡每张卡放不同的系统或环境切换方便也方便在变砖后用另一张卡救急。但要注意一个隐藏问题Orin NX 16GB 模组的 eMMC 只有 16GB而 JetPack 完整安装后 rootfs 会占用 10GB 以上如果再装 CUDA 相关工具链、TensorRT、OpenCV 源码编译产物空间会非常紧张。这一点在后面的存储整理部分我会专门展开。1.3 Super 模式不是刷出来的是 JetPack 版本给的很多第一次接触 Orin NX Super 的人会误以为刷机时有个Super 模式的开关勾选后就能获得更高性能。实际上不是这样。Super 模式是 Jetson Linux 36.4 / JetPack 6.2 开始针对 Orin NX 16GB 模组开放的新电源模式。刷完系统后它默认就是可用的只是默认电源模式可能不是最大性能档。你需要用nvpmodel工具去查询和切换sudo nvpmodel -q sudo nvpmodel -m 0其中-m 0代表 MaxN 模式也就是最大性能档。具体有哪些模式可以执行nvpmodel --print-all查看。如果查询结果里没有带 GPU 频率 1.1GHz 的档位再检查一下 JetPack 版本是不是 6.2 以上cat /etc/nv_tegra_release dpkg -l | grep nvidia-jetpack2. 主机准备和设备进入恢复模式最容易翻车的一步2.1 主机环境检查清单刷机不是把开发板插上电脑就行主机侧的环境直接影响成功率。官方推荐使用 Ubuntu x86_64 主机我实测下来 Ubuntu 20.04 和 22.04 都没问题Ubuntu 24.04 需要额外处理一些依赖库不建议新手用。主机侧必须满足的条件至少 50GB 空闲磁盘空间因为 JetPack 完整下载包加解压后的 rootfs 很容易超过 30GB。一个可用的 USB-C 数据线。这里特别强调是数据线不是充电线。很多翻车现场就是线的问题能充电但不能传数据lsusb 死活不识别。主机在刷机过程中不能进入休眠。建议在电源设置里把自动挂起关掉或者干脆用caffeinatemacOS或修改 logind 配置Ubuntu锁住。如果走 SDK Manager 路线要提前在浏览器登录 NVIDIA 账号并预留大量时间给它下载组件。2.2 让开发板进入 USB 恢复模式的标准动作Orin NX 核心板本身没有 USB 口需要配合载板使用。无论你用的是官方 Developer Kit 载板还是第三方的载板基本都有 Recovery 和 Reset 两个按钮但位置和手感差异很大建议先看载板的原理图或说明书。进入恢复模式的标准操作给载板接上 DC 电源但先不要开机。找到 Recovery 按钮按住不要松。按住 Recovery 的同时按一下 Reset 按钮。等待 2 秒后松开 Recovery。此时开发板不会正常启动而是进入烧录模式。如果你的操作正确在主机上执行lsusb应该能看到一行类似ID 0955:7023 NVIDIA Corp. APX的输出。每个 JetPack 版本对应的 APX 设备 ID 可能略有不同但厂商名一定是 NVIDIA。2.3 判断设备状态lsusb 与串口双保险我遇到过 lsusb 什么都查不到的情况这时候不要急着怀疑开发板坏了。先换USB线、换USB口甚至换一台电脑试试。USB-C 口接触不良或者主机 USB 控制器供电能力不足都会导致 APX 设备不上线。如果换了线还是没有再接上串口调试线用screen /dev/ttyUSB0 115200看启动日志。载板上一般有 UART 调试接口能看到 CPU 初始化是否正常。这一步能帮你区分开发板没通电和开发板没进恢复模式这两种情况。提示刷机过程中不要让主机锁屏或者合上笔记本盖USB 会话一旦中断eMMC 写入到一半就会处于残留状态虽然可以重刷但会白白浪费大量排错时间。3. 两条烧录路径的完整对比与实操记录3.1 SDK Manager 的图形化流程与踩坑点SDK Manager 是 NVIDIA 提供的图形化刷机工具适合不想碰命令行的开发者。它的逻辑是先让你选主机型号、目标设备型号和 JetPack 版本然后自动下载组件并写入。我在 Ubuntu 22.04 上安装 SDK Manager 时遇到过缺少依赖的问题。解决方式是先安装基础依赖sudo apt update sudo apt install python3-pip python3-apt python3-debian python3-termcolor sshpass然后下载 SDK Manager 的 .deb 包安装。启动后登录 NVIDIA 账号选中 Jetson Orin NX勾选需要的 JetPack 版本。这里要注意SDK Manager 默认会同时勾选Host Machine上安装的组件如果你不想让主机的 CUDA、cuDNN 被改动把 Host Machine 的选项全部取消只保留 Target Device 的烧录和组件安装。烧录时SDK Manager 会提示你手动把开发板进入恢复模式然后它会自己检测 USB 设备。检测到后就开始下载并写入 eMMC。这个下载过程非常吃网络容易中断。下载中断最典型的表现就是后面解压时报gzip: stdin: invalid compressed>cd Linux_for_Tegra sudo tar xpf ../Tegra_Linux_Sample-Root-Filesystem_R36.4.0_aarch64.tbz2 -C rootfs/ sudo ./apply_binaries.sh接下来把开发板进入恢复模式确认lsusb能看到 NVIDIA APX 后执行sudo ./flash.sh jetson-orin-nx-devkit mmcblk0p1mmcblk0p1表示写入 eMMC 的第一个分区。如果你烧的是 Orin NX 16GB Super 模组目标设备名就是jetson-orin-nx-devkit不需要额外指定 Super 之类的东西。整个刷写过程会打印详细的进度大概 10 到 15 分钟。3.3 烧录过程中的三个高频失败点我把刷机过程中最容易出问题的环节总结成一张表方便你对照排查现象根因处理方式USB 设备识别后刷到一半断开数据线质量差、主机休眠、USB 口供电不足换线、换口、关闭自动休眠下载包解压报 invalid compressed data网络中断导致压缩包不完整对比文件大小和校验和重新下载刷机进度条停在某个百分比不动目标板供电不足或 USB 控制器带宽被抢占给载板接独立 DC 电源拔掉无关 USB 设备烧录过程中开发板最好单独接一个 5V 或 12V 的 DC 电源不能只依赖 USB 供电。Orin NX 在烧录时虽然不像满载推理那么耗电但 USB 的 5V 供电在写入 eMMC 时依然可能出现电压波动导致刷写失败。4. 首次开机后的初始化换源、扩容与 Super 模式确认4.1 首次开机设置与版本验证刷机完成后开发板会自动重启。第一次开机进入 Ubuntu 初始化向导设置语言、用户名、密码、时区、Wi-Fi。这里有个小建议用户名用全小写字母不要带特殊符号后面很多编译脚本对路径里的空格和特殊字符非常敏感。进入系统后先验证几个关键信息uname -a cat /etc/nv_tegra_release dpkg -l | grep nvidia-jetpack nvidia-smiuname -a应该能看到tegra字样内核版本一般是 5.15 或更高。如果nvidia-smi提示找不到命令不要慌Jetson 上最常用的 GPU 监控工具其实不是 nvidia-smi而是tegrastats和后面会提到的jtop。JetPack 6.x 部分版本自带 nvidia-smi但很多裁剪过的系统里并没有。4.2 apt 换源与存储空间整理Jetson 的软件源分为两部分Ubuntu 源和 NVIDIA 源。默认的 Ubuntu 源访问速度在国内可能偏慢建议换成国内镜像源。编辑/etc/apt/sources.list把ports.ubuntu.com替换成你常用的镜像地址。注意 Jetson 是 arm64 架构所以走的是ports源不是普通 x86 的archive.ubuntu.com。NVIDIA 的源在/etc/apt/sources.list.d/nvidia-l4t-apt-source.list里这个源不要随便换它是 JetPack 组件升级的核心来源。每次apt update时如果卡在 NVIDIA 源上可以等一段时间重试或者把apt-get换成apt自动重试机制会好一点。空间问题这时候就会冒出来。16GB eMMC 的 Orin NX 刷完 JetPack 后可用空间往往只剩 3GB 左右。我做的第一件事是清理 apt 缓存sudo apt clean sudo apt autoremove --purge du -sh /var/cache/apt/archives如果你打算从头编译 OpenCV with CUDA这个空间是绝对不够的。两个思路一是把 OpenCV 的 build 目录放到外接 NVMe SSD 或 U 盘上编译完再装回系统目录二是扩大 swapJetson 默认的 zram 在编译大项目时容易触发 OOM。我通常加一个 4GB 的 swapfilesudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo /swapfile none swap sw 0 0 | sudo tee -a /etc/fstab4.3 用 nvpmodel 和 jtop 确认 Super 模式生效系统初始化完成后第一时间确认 Super 模式是否已经生效。执行sudo nvpmodel -q正常输出里应该有多个电源模式其中 MaxN 模式的 GPU 最高频率是 1100MHz。再安装jtop做可视化监控sudo pip3 install jetson-stats sudo jtop在 jtop 的页面里可以看到实时的 GPU 频率、温度、显存占用。如果 GPU 频率能跑到 1100MHz 左右说明 Super 模式已经在最高性能档工作了。还有一个容易被忽略的细节Orin NX 的散热。Super 模式下 25W 的功耗在被动散热片上撑不了多久就会降频。如果你没有主动散热风扇建议用nvpmodel -m 1选一个 15W 或 20W 的档位性能虽然略降但稳定性和寿命更有保障。5. CUDA 环境的核心思路Toolkit、软链与多版本切换5.1 nvcc 找不到的本质Toolkit 与 runtime 的区别JetPack 刷完系统后系统里其实已经装了大量 CUDA 运行库比如 libcudart.so、libcublas.so这些是运行 CUDA 程序时必需的。但如果你直接执行nvcc -V可能会提示command not found。原因是nvcc编译器属于 CUDA Toolkit 的一部分而 JetPack 默认只装了 runtime 层没有把完整 Toolkit 装进来。这属于正常现象补装即可sudo apt install nvidia-jetpack或者只装编译器sudo apt install cuda-toolkit-12-6JetPack 6.2 对应 CUDA 12.6。不要凭感觉装成 CUDA 13.0虽然 x86 桌面显卡上 CUDA 13.0 已经很常见但 Jetson 上的 CUDA 版本完全由 JetPack 决定。装完之后nvcc -V就能用了。如果还是提示找不到检查一下/usr/local/cuda/bin是否在 PATH 里export PATH/usr/local/cuda/bin:$PATH echo export PATH/usr/local/cuda/bin:$PATH ~/.bashrc export CUDA_HOME/usr/local/cuda5.2 多版本 CUDA 共存与切换的两种方案Jetson 的 CUDA 版本虽然跟着 JetPack 走但在实际开发中你可能会因为装某些第三方包在/usr/local/下多出另一个 CUDA 目录比如/usr/local/cuda-12.6和/usr/local/cuda-13.0并存。多版本同时存在本身不冲突冲突的是/usr/local/cuda这个软链接指向谁。系统默认nvcc、cmake找 CUDA 时通常走的是/usr/local/cuda这个不带版本号的软链接。最优雅的管理方式是update-alternativessudo update-alternatives --install /usr/local/cuda cuda /usr/local/cuda-12.6 0 sudo update-alternatives --install /usr/local/cuda cuda /usr/local/cuda-13.0 1 sudo update-alternatives --config cuda切换后执行nvcc -V确认当前生效版本。注意如果切换了 CUDA 版本之前编译好的 OpenCV 和 PyTorch 的 CUDA runtime 可能就不匹配了最典型的症状是运行时报libcudart.so.12找不到。这种情况下需要把对应的/usr/local/cuda-12.6/lib64导出到LD_LIBRARY_PATH或者重新编译目标项目。另外如果你用 conda不要在 conda 环境里单独装cudatoolkit。Jetson 的 CUDA 体系是系统级的conda 里装的那一套在 Jetson 上经常会出现版本对不上的问题。正确做法是让 conda 环境直接继承系统的/usr/local/cuda通过设置CONDA_OVERRIDE_CUDA或者干脆不用cudatoolkit包。5.3 与 TensorRT、cuDNN 的对齐JetPack 里 TensorRT 和 cuDNN 版本与 CUDA 版本是配套发布的。比如 JetPack 6.2 默认的 TensorRT 10.x对应 CUDA 12.6、cuDNN 8.9。手动单独升级 TensorRT 或 cuDNN 的风险在于新版本可能依赖更高的小版本 CUDA 库导致运行时报符号找不到。最稳妥的方式是整包安装sudo apt install nvidia-jetpack它会把所有配套组件按官方版本拉齐。如果项目里必须用特定版本的 PyTorch 或 TensorRT先查一下该版本官方文档里声明支持的 JetPack 版本再决定要不要改动系统组件。6. OpenCV with CUDA 和 PyTorch 版本匹配的实战记录6.1 OpenCV with CUDA 的编译参数与耗时Jetson 系统里预装的 OpenCV 是 ARM 版但默认不启用 CUDA 加速。如果你需要跑 YOLO 这类检测模型或者做视频解码相关的图像处理建议自己编译一个带 CUDA 的 OpenCV。编译之前先确认源码版本。我用的版本是 OpenCV 4.10.0搭配 contrib 模块。cmake 配置的核心参数cmake -D CMAKE_BUILD_TYPERELEASE \ -D CMAKE_INSTALL_PREFIX/usr/local \ -D WITH_CUDAON \ -D CUDA_ARCH_BIN8.7 \ -D CUDA_ARCH_PTX8.7 \ -D WITH_OPENGLON \ -D WITH_OPENMPON \ -D BUILD_EXAMPLESOFF \ -D BUILD_opencv_python3ON \ -D BUILD_opencv_worldOFF \ -D WITH_CUDNNON \ -D OPENCV_DNN_CUDAON \ ..这里的CUDA_ARCH_BIN8.7是关键。Jetson Orin 系列 GPU 架构是 Ampere计算能力是 8.7和桌面 RTX 30 系不一样桌面 Ampere 是 8.6。如果填错架构编译出来的库要么跑不起来要么 JIT 编译时极慢。编译时间取决于你用的模组。在 Orin NX Super 的 MaxN 模式下全核并行编译 OpenCV 4.10 大概需要 1 到 1.5 小时。记得先加 swap否则很容易在链接阶段被 OOM 杀掉。编译完成后sudo make install sudo ldconfig然后用cv2.cuda.getCudaEnabledDeviceCount()验证 CUDA 是否真正生效。6.2 PyTorch 在 Jetson 上的特殊安装方式JetPack 环境下安装 PyTorch 是个独立话题因为它不能在系统里直接pip install torch。PyTorch 官方在 PyPI 上发布的 aarch64 wheel 要么是 CPU 版要么不支持 JetPack 的 CUDA 体系。正确的安装方式是使用 NVIDIA 为 JetPack 预编译的 wheel。以 JetPack 6.2 / PyTorch 2.5.0 为例下载对应的 wheel 文件后pip3 install torch-2.5.0-cp310-cp310-linux_aarch64.whl安装完成后验证import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))如果torch.cuda.is_available()返回 False不要急着重装 PyTorch。先确认系统 CUDA 是否正常执行cd /usr/local/cuda/samples/1_Utilities/deviceQuery sudo make ./deviceQuery如果 deviceQuery 能通过说明系统 CUDA 没问题问题出在 PyTorch wheel 版本与系统 CUDA 不匹配换对应的 wheel 版本重新装。如果你需要源码编译 PyTorch编译前务必设置export TORCH_CUDA_ARCH_LIST8.7这个变量决定 PyTorch 是否针对 Orin 的 GPU 架构生成 SASS 代码。不设置的话PyTorch 默认生成一堆 Fallback 代码跑起来性能惨不忍睹。6.3 深度学习推理时的 CUDA 版本匹配原则在 Jetson 上跑深度学习项目我总结了一个简单的匹配原则跟着 JetPack 走不要自己折腾版本。也就是说JetPack 6.2 对应 CUDA 12.6、cuDNN 8.9、TensorRT 10.x、Python 3.10你的 PyTorch、ONNX Runtime、OpenCV 都应该以这个版本组合为前提来安装。任何试图在 conda 里单独装 CUDA 13.0、或者在系统里强制降级 CUDA 的做法都会引发连锁反应最常见的就是某个库编译时链接到了错误版本的 libcublas。7. 刷机与配环境中高频报错的排查链路7.1 gzip: stdin: invalid compressed data 的完整排查链路这个报错几乎每个刷过 Jetson 的人都见过。它的字面意思是解压时发现数据不是合法的 gzip 流但根源多半是压缩包下载不完整。我在刷机时遇到的场景是从官网下载Jetson_Linux_R36.4.0_aarch64.tbz2下载工具显示 100% 完成但解压时报同样的错。排查链路如下先对比文件大小。官网页面会标明文件字节数ls -l查看实际大小差一个字节都不行。再用校验和验证。官网每个文件旁都有 SHA256 值sha256sum Jetson_Linux_R36.4.0_aarch64.tbz2如果校验值对不上重新下载。不要用断点续传直接把旧文件删掉重新下载完整文件。这个报错也会出现在 apt 安装 deb 包的过程中。此时是/var/cache/apt/archives/里的 deb 包损坏解决方式是清理后重新更新sudo apt clean sudo apt update sudo apt install --reinstall 包名7.2 CUDA Samples 编译报错的定位方法JetPack 自带 CUDA Samples但很多时候deviceQuery编译会报找不到头文件或者链接时找不到libcudart.so。这类问题九成出在环境变量上。按顺序检查/usr/local/cuda软链接是否存在指向哪个版本nvcc -V是否正常输出/etc/ld.so.conf.d/下是否有 cuda 的路径文件ldconfig -p | grep cudart是否能搜到运行库。如果路径都存在但还是编译不过查看samples/Makefile里CUDA_PATH是不是写死了某个路径。在 Jetson 上最简单的方式是直接导出export CUDA_HOME/usr/local/cuda export LD_LIBRARY_PATH/usr/local/cuda/lib64:${LD_LIBRARY_PATH} sudo ldconfig7.3 刷机后进不了系统的恢复思路刷机后最糟的情况是开机卡在 Logo或者反复重启。我的处理顺序是先接串口看日志定位卡在哪个阶段。如果能进恢复模式重刷系统。做法和第一次刷机一样只是先格式化 eMMCsudo ./flash.sh -r jetson-orin-nx-devkit mmcblk0p1-r参数会先擦除用户数据再写系统适合系统损坏但引导区还正常的场景。如果连恢复模式都进不去检查载板电源灯、核心板是否插紧。其实只要 eMMC 引导区没有被破坏Jetson 几乎不存在真正变砖的可能。刷机过程中的风险操作是刷到一半断电所以务必保证 DC 电源稳定。7.4 跑起来之后怎么确认 CUDA 真的在干活配置完所有环境后我习惯用一个最简单的 PyTorch 张量运算来验证import torch x torch.randn(1000, 1000, devicecuda) y torch.mm(x, x) print(y.sum().item())再加上tegrastats观察 GPU 频率和显存占用。如果运行期间 GPU 频率有波动、显存有占用说明 CUDA 链路是通的。之后再跑一个 YOLO 或 TensorRT 的 demo 做端到端验证。整套流程走完板子的 From zero to CUDA 就算正式结束了。第二次刷机时我全程下来只花了 40 分钟和第一次折腾大半天形成鲜明对比。如果你正准备刷机我的建议顺序是先在主机上把 JetPack 完整下载好再插开发板进恢复模式刷完先装nvidia-jetpack再配置 PATH 和软链接最后编译 OpenCV 和安装 PyTorch。整个过程犯一次错很正常关键是知道去哪查、怎么验证——希望这篇记录能帮你少走这几段弯路。
Jetson Orin NX Super 刷机到 CUDA 环境配置完整指南
第一次给 Jetson Orin NX Super 刷系统我差点把刚拆封的开发板折腾成砖——倒不是硬件损坏而是刷到一半主机突然断连重启后 eMMC 处于一个半空状态连恢复模式都进得磕磕绊绊。后来把整条链路重新捋了一遍从下载 JetPack、进入 USB 恢复模式到最终把 CUDA 环境配到能正常编译和推理完整跑通之后才发现这个过程其实不复杂但每一步都有看似正常实则坑人的细节。这篇文章就把我从零开始烧录 Jetson Orin NX Super 到配置 CUDA 环境、OpenCV with CUDA、PyTorch 的完整过程记录下来顺便把我踩过的坑、排查思路和最终的配置清单一并放出来。无论你是刚拿到板子的小白还是被刷机报错卡住的老手这篇应该能帮你省下不少折腾时间。1. 刷机前必须想明白的三件事模组版本、烧录载体与Super模式1.1 确认手里的模组8GB 与 16GB 的镜像差异Jetson Orin NX 有两个存储/内存规格8GB 和 16GB。两者外观几乎一样但刷机时能使用的镜像和后续性能表现有区别。尤其是标题里带Super的 Orin NX 16GB是 NVIDIA 在 JetPack 6.2 之后通过新的电源管理策略开放出来的性能模式GPU 频率可以从 918MHz 提升到 1.1GHz内存带宽也从 102.4GB/s 涨到 136.5GB/s整体性能提升在 20% 到 25% 左右。所以刷机之前第一件事先确认你手里的模组到底是哪个版本。最可靠的方式是看模组外壳上的丝印或者直接问卖家要规格书。如果已经能开机也可以在系统里执行cat /proc/device-tree/model cat /proc/device-tree/memory0/reg前者会显示类似NVIDIA Jetson Orin NX 16GB Developer Kit的信息后者能看到内存大小。8GB 版本的 Orin NX 不支持 Super 模式后面所有关于 Super 模式的性能调优操作都可以跳过。1.2 eMMC 与 SD 卡烧录目标和启动介质的选择Jetson Orin NX 核心板自带 eMMC 存储8GB 版对应 32GB eMMC16GB 版对应 16GB eMMC。烧录系统有两个方向一是写入板载 eMMC二是写入 SD 卡。我个人的建议是如果只是日常开发、跑模型推理优先烧进 eMMC。eMMC 的随机读写比大部分 SD 卡稳定长时间跑训练或者频繁读写日志时不容易出现 IO 错误。SD 卡方案的优势在于可以准备多张卡每张卡放不同的系统或环境切换方便也方便在变砖后用另一张卡救急。但要注意一个隐藏问题Orin NX 16GB 模组的 eMMC 只有 16GB而 JetPack 完整安装后 rootfs 会占用 10GB 以上如果再装 CUDA 相关工具链、TensorRT、OpenCV 源码编译产物空间会非常紧张。这一点在后面的存储整理部分我会专门展开。1.3 Super 模式不是刷出来的是 JetPack 版本给的很多第一次接触 Orin NX Super 的人会误以为刷机时有个Super 模式的开关勾选后就能获得更高性能。实际上不是这样。Super 模式是 Jetson Linux 36.4 / JetPack 6.2 开始针对 Orin NX 16GB 模组开放的新电源模式。刷完系统后它默认就是可用的只是默认电源模式可能不是最大性能档。你需要用nvpmodel工具去查询和切换sudo nvpmodel -q sudo nvpmodel -m 0其中-m 0代表 MaxN 模式也就是最大性能档。具体有哪些模式可以执行nvpmodel --print-all查看。如果查询结果里没有带 GPU 频率 1.1GHz 的档位再检查一下 JetPack 版本是不是 6.2 以上cat /etc/nv_tegra_release dpkg -l | grep nvidia-jetpack2. 主机准备和设备进入恢复模式最容易翻车的一步2.1 主机环境检查清单刷机不是把开发板插上电脑就行主机侧的环境直接影响成功率。官方推荐使用 Ubuntu x86_64 主机我实测下来 Ubuntu 20.04 和 22.04 都没问题Ubuntu 24.04 需要额外处理一些依赖库不建议新手用。主机侧必须满足的条件至少 50GB 空闲磁盘空间因为 JetPack 完整下载包加解压后的 rootfs 很容易超过 30GB。一个可用的 USB-C 数据线。这里特别强调是数据线不是充电线。很多翻车现场就是线的问题能充电但不能传数据lsusb 死活不识别。主机在刷机过程中不能进入休眠。建议在电源设置里把自动挂起关掉或者干脆用caffeinatemacOS或修改 logind 配置Ubuntu锁住。如果走 SDK Manager 路线要提前在浏览器登录 NVIDIA 账号并预留大量时间给它下载组件。2.2 让开发板进入 USB 恢复模式的标准动作Orin NX 核心板本身没有 USB 口需要配合载板使用。无论你用的是官方 Developer Kit 载板还是第三方的载板基本都有 Recovery 和 Reset 两个按钮但位置和手感差异很大建议先看载板的原理图或说明书。进入恢复模式的标准操作给载板接上 DC 电源但先不要开机。找到 Recovery 按钮按住不要松。按住 Recovery 的同时按一下 Reset 按钮。等待 2 秒后松开 Recovery。此时开发板不会正常启动而是进入烧录模式。如果你的操作正确在主机上执行lsusb应该能看到一行类似ID 0955:7023 NVIDIA Corp. APX的输出。每个 JetPack 版本对应的 APX 设备 ID 可能略有不同但厂商名一定是 NVIDIA。2.3 判断设备状态lsusb 与串口双保险我遇到过 lsusb 什么都查不到的情况这时候不要急着怀疑开发板坏了。先换USB线、换USB口甚至换一台电脑试试。USB-C 口接触不良或者主机 USB 控制器供电能力不足都会导致 APX 设备不上线。如果换了线还是没有再接上串口调试线用screen /dev/ttyUSB0 115200看启动日志。载板上一般有 UART 调试接口能看到 CPU 初始化是否正常。这一步能帮你区分开发板没通电和开发板没进恢复模式这两种情况。提示刷机过程中不要让主机锁屏或者合上笔记本盖USB 会话一旦中断eMMC 写入到一半就会处于残留状态虽然可以重刷但会白白浪费大量排错时间。3. 两条烧录路径的完整对比与实操记录3.1 SDK Manager 的图形化流程与踩坑点SDK Manager 是 NVIDIA 提供的图形化刷机工具适合不想碰命令行的开发者。它的逻辑是先让你选主机型号、目标设备型号和 JetPack 版本然后自动下载组件并写入。我在 Ubuntu 22.04 上安装 SDK Manager 时遇到过缺少依赖的问题。解决方式是先安装基础依赖sudo apt update sudo apt install python3-pip python3-apt python3-debian python3-termcolor sshpass然后下载 SDK Manager 的 .deb 包安装。启动后登录 NVIDIA 账号选中 Jetson Orin NX勾选需要的 JetPack 版本。这里要注意SDK Manager 默认会同时勾选Host Machine上安装的组件如果你不想让主机的 CUDA、cuDNN 被改动把 Host Machine 的选项全部取消只保留 Target Device 的烧录和组件安装。烧录时SDK Manager 会提示你手动把开发板进入恢复模式然后它会自己检测 USB 设备。检测到后就开始下载并写入 eMMC。这个下载过程非常吃网络容易中断。下载中断最典型的表现就是后面解压时报gzip: stdin: invalid compressed>cd Linux_for_Tegra sudo tar xpf ../Tegra_Linux_Sample-Root-Filesystem_R36.4.0_aarch64.tbz2 -C rootfs/ sudo ./apply_binaries.sh接下来把开发板进入恢复模式确认lsusb能看到 NVIDIA APX 后执行sudo ./flash.sh jetson-orin-nx-devkit mmcblk0p1mmcblk0p1表示写入 eMMC 的第一个分区。如果你烧的是 Orin NX 16GB Super 模组目标设备名就是jetson-orin-nx-devkit不需要额外指定 Super 之类的东西。整个刷写过程会打印详细的进度大概 10 到 15 分钟。3.3 烧录过程中的三个高频失败点我把刷机过程中最容易出问题的环节总结成一张表方便你对照排查现象根因处理方式USB 设备识别后刷到一半断开数据线质量差、主机休眠、USB 口供电不足换线、换口、关闭自动休眠下载包解压报 invalid compressed data网络中断导致压缩包不完整对比文件大小和校验和重新下载刷机进度条停在某个百分比不动目标板供电不足或 USB 控制器带宽被抢占给载板接独立 DC 电源拔掉无关 USB 设备烧录过程中开发板最好单独接一个 5V 或 12V 的 DC 电源不能只依赖 USB 供电。Orin NX 在烧录时虽然不像满载推理那么耗电但 USB 的 5V 供电在写入 eMMC 时依然可能出现电压波动导致刷写失败。4. 首次开机后的初始化换源、扩容与 Super 模式确认4.1 首次开机设置与版本验证刷机完成后开发板会自动重启。第一次开机进入 Ubuntu 初始化向导设置语言、用户名、密码、时区、Wi-Fi。这里有个小建议用户名用全小写字母不要带特殊符号后面很多编译脚本对路径里的空格和特殊字符非常敏感。进入系统后先验证几个关键信息uname -a cat /etc/nv_tegra_release dpkg -l | grep nvidia-jetpack nvidia-smiuname -a应该能看到tegra字样内核版本一般是 5.15 或更高。如果nvidia-smi提示找不到命令不要慌Jetson 上最常用的 GPU 监控工具其实不是 nvidia-smi而是tegrastats和后面会提到的jtop。JetPack 6.x 部分版本自带 nvidia-smi但很多裁剪过的系统里并没有。4.2 apt 换源与存储空间整理Jetson 的软件源分为两部分Ubuntu 源和 NVIDIA 源。默认的 Ubuntu 源访问速度在国内可能偏慢建议换成国内镜像源。编辑/etc/apt/sources.list把ports.ubuntu.com替换成你常用的镜像地址。注意 Jetson 是 arm64 架构所以走的是ports源不是普通 x86 的archive.ubuntu.com。NVIDIA 的源在/etc/apt/sources.list.d/nvidia-l4t-apt-source.list里这个源不要随便换它是 JetPack 组件升级的核心来源。每次apt update时如果卡在 NVIDIA 源上可以等一段时间重试或者把apt-get换成apt自动重试机制会好一点。空间问题这时候就会冒出来。16GB eMMC 的 Orin NX 刷完 JetPack 后可用空间往往只剩 3GB 左右。我做的第一件事是清理 apt 缓存sudo apt clean sudo apt autoremove --purge du -sh /var/cache/apt/archives如果你打算从头编译 OpenCV with CUDA这个空间是绝对不够的。两个思路一是把 OpenCV 的 build 目录放到外接 NVMe SSD 或 U 盘上编译完再装回系统目录二是扩大 swapJetson 默认的 zram 在编译大项目时容易触发 OOM。我通常加一个 4GB 的 swapfilesudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile echo /swapfile none swap sw 0 0 | sudo tee -a /etc/fstab4.3 用 nvpmodel 和 jtop 确认 Super 模式生效系统初始化完成后第一时间确认 Super 模式是否已经生效。执行sudo nvpmodel -q正常输出里应该有多个电源模式其中 MaxN 模式的 GPU 最高频率是 1100MHz。再安装jtop做可视化监控sudo pip3 install jetson-stats sudo jtop在 jtop 的页面里可以看到实时的 GPU 频率、温度、显存占用。如果 GPU 频率能跑到 1100MHz 左右说明 Super 模式已经在最高性能档工作了。还有一个容易被忽略的细节Orin NX 的散热。Super 模式下 25W 的功耗在被动散热片上撑不了多久就会降频。如果你没有主动散热风扇建议用nvpmodel -m 1选一个 15W 或 20W 的档位性能虽然略降但稳定性和寿命更有保障。5. CUDA 环境的核心思路Toolkit、软链与多版本切换5.1 nvcc 找不到的本质Toolkit 与 runtime 的区别JetPack 刷完系统后系统里其实已经装了大量 CUDA 运行库比如 libcudart.so、libcublas.so这些是运行 CUDA 程序时必需的。但如果你直接执行nvcc -V可能会提示command not found。原因是nvcc编译器属于 CUDA Toolkit 的一部分而 JetPack 默认只装了 runtime 层没有把完整 Toolkit 装进来。这属于正常现象补装即可sudo apt install nvidia-jetpack或者只装编译器sudo apt install cuda-toolkit-12-6JetPack 6.2 对应 CUDA 12.6。不要凭感觉装成 CUDA 13.0虽然 x86 桌面显卡上 CUDA 13.0 已经很常见但 Jetson 上的 CUDA 版本完全由 JetPack 决定。装完之后nvcc -V就能用了。如果还是提示找不到检查一下/usr/local/cuda/bin是否在 PATH 里export PATH/usr/local/cuda/bin:$PATH echo export PATH/usr/local/cuda/bin:$PATH ~/.bashrc export CUDA_HOME/usr/local/cuda5.2 多版本 CUDA 共存与切换的两种方案Jetson 的 CUDA 版本虽然跟着 JetPack 走但在实际开发中你可能会因为装某些第三方包在/usr/local/下多出另一个 CUDA 目录比如/usr/local/cuda-12.6和/usr/local/cuda-13.0并存。多版本同时存在本身不冲突冲突的是/usr/local/cuda这个软链接指向谁。系统默认nvcc、cmake找 CUDA 时通常走的是/usr/local/cuda这个不带版本号的软链接。最优雅的管理方式是update-alternativessudo update-alternatives --install /usr/local/cuda cuda /usr/local/cuda-12.6 0 sudo update-alternatives --install /usr/local/cuda cuda /usr/local/cuda-13.0 1 sudo update-alternatives --config cuda切换后执行nvcc -V确认当前生效版本。注意如果切换了 CUDA 版本之前编译好的 OpenCV 和 PyTorch 的 CUDA runtime 可能就不匹配了最典型的症状是运行时报libcudart.so.12找不到。这种情况下需要把对应的/usr/local/cuda-12.6/lib64导出到LD_LIBRARY_PATH或者重新编译目标项目。另外如果你用 conda不要在 conda 环境里单独装cudatoolkit。Jetson 的 CUDA 体系是系统级的conda 里装的那一套在 Jetson 上经常会出现版本对不上的问题。正确做法是让 conda 环境直接继承系统的/usr/local/cuda通过设置CONDA_OVERRIDE_CUDA或者干脆不用cudatoolkit包。5.3 与 TensorRT、cuDNN 的对齐JetPack 里 TensorRT 和 cuDNN 版本与 CUDA 版本是配套发布的。比如 JetPack 6.2 默认的 TensorRT 10.x对应 CUDA 12.6、cuDNN 8.9。手动单独升级 TensorRT 或 cuDNN 的风险在于新版本可能依赖更高的小版本 CUDA 库导致运行时报符号找不到。最稳妥的方式是整包安装sudo apt install nvidia-jetpack它会把所有配套组件按官方版本拉齐。如果项目里必须用特定版本的 PyTorch 或 TensorRT先查一下该版本官方文档里声明支持的 JetPack 版本再决定要不要改动系统组件。6. OpenCV with CUDA 和 PyTorch 版本匹配的实战记录6.1 OpenCV with CUDA 的编译参数与耗时Jetson 系统里预装的 OpenCV 是 ARM 版但默认不启用 CUDA 加速。如果你需要跑 YOLO 这类检测模型或者做视频解码相关的图像处理建议自己编译一个带 CUDA 的 OpenCV。编译之前先确认源码版本。我用的版本是 OpenCV 4.10.0搭配 contrib 模块。cmake 配置的核心参数cmake -D CMAKE_BUILD_TYPERELEASE \ -D CMAKE_INSTALL_PREFIX/usr/local \ -D WITH_CUDAON \ -D CUDA_ARCH_BIN8.7 \ -D CUDA_ARCH_PTX8.7 \ -D WITH_OPENGLON \ -D WITH_OPENMPON \ -D BUILD_EXAMPLESOFF \ -D BUILD_opencv_python3ON \ -D BUILD_opencv_worldOFF \ -D WITH_CUDNNON \ -D OPENCV_DNN_CUDAON \ ..这里的CUDA_ARCH_BIN8.7是关键。Jetson Orin 系列 GPU 架构是 Ampere计算能力是 8.7和桌面 RTX 30 系不一样桌面 Ampere 是 8.6。如果填错架构编译出来的库要么跑不起来要么 JIT 编译时极慢。编译时间取决于你用的模组。在 Orin NX Super 的 MaxN 模式下全核并行编译 OpenCV 4.10 大概需要 1 到 1.5 小时。记得先加 swap否则很容易在链接阶段被 OOM 杀掉。编译完成后sudo make install sudo ldconfig然后用cv2.cuda.getCudaEnabledDeviceCount()验证 CUDA 是否真正生效。6.2 PyTorch 在 Jetson 上的特殊安装方式JetPack 环境下安装 PyTorch 是个独立话题因为它不能在系统里直接pip install torch。PyTorch 官方在 PyPI 上发布的 aarch64 wheel 要么是 CPU 版要么不支持 JetPack 的 CUDA 体系。正确的安装方式是使用 NVIDIA 为 JetPack 预编译的 wheel。以 JetPack 6.2 / PyTorch 2.5.0 为例下载对应的 wheel 文件后pip3 install torch-2.5.0-cp310-cp310-linux_aarch64.whl安装完成后验证import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))如果torch.cuda.is_available()返回 False不要急着重装 PyTorch。先确认系统 CUDA 是否正常执行cd /usr/local/cuda/samples/1_Utilities/deviceQuery sudo make ./deviceQuery如果 deviceQuery 能通过说明系统 CUDA 没问题问题出在 PyTorch wheel 版本与系统 CUDA 不匹配换对应的 wheel 版本重新装。如果你需要源码编译 PyTorch编译前务必设置export TORCH_CUDA_ARCH_LIST8.7这个变量决定 PyTorch 是否针对 Orin 的 GPU 架构生成 SASS 代码。不设置的话PyTorch 默认生成一堆 Fallback 代码跑起来性能惨不忍睹。6.3 深度学习推理时的 CUDA 版本匹配原则在 Jetson 上跑深度学习项目我总结了一个简单的匹配原则跟着 JetPack 走不要自己折腾版本。也就是说JetPack 6.2 对应 CUDA 12.6、cuDNN 8.9、TensorRT 10.x、Python 3.10你的 PyTorch、ONNX Runtime、OpenCV 都应该以这个版本组合为前提来安装。任何试图在 conda 里单独装 CUDA 13.0、或者在系统里强制降级 CUDA 的做法都会引发连锁反应最常见的就是某个库编译时链接到了错误版本的 libcublas。7. 刷机与配环境中高频报错的排查链路7.1 gzip: stdin: invalid compressed data 的完整排查链路这个报错几乎每个刷过 Jetson 的人都见过。它的字面意思是解压时发现数据不是合法的 gzip 流但根源多半是压缩包下载不完整。我在刷机时遇到的场景是从官网下载Jetson_Linux_R36.4.0_aarch64.tbz2下载工具显示 100% 完成但解压时报同样的错。排查链路如下先对比文件大小。官网页面会标明文件字节数ls -l查看实际大小差一个字节都不行。再用校验和验证。官网每个文件旁都有 SHA256 值sha256sum Jetson_Linux_R36.4.0_aarch64.tbz2如果校验值对不上重新下载。不要用断点续传直接把旧文件删掉重新下载完整文件。这个报错也会出现在 apt 安装 deb 包的过程中。此时是/var/cache/apt/archives/里的 deb 包损坏解决方式是清理后重新更新sudo apt clean sudo apt update sudo apt install --reinstall 包名7.2 CUDA Samples 编译报错的定位方法JetPack 自带 CUDA Samples但很多时候deviceQuery编译会报找不到头文件或者链接时找不到libcudart.so。这类问题九成出在环境变量上。按顺序检查/usr/local/cuda软链接是否存在指向哪个版本nvcc -V是否正常输出/etc/ld.so.conf.d/下是否有 cuda 的路径文件ldconfig -p | grep cudart是否能搜到运行库。如果路径都存在但还是编译不过查看samples/Makefile里CUDA_PATH是不是写死了某个路径。在 Jetson 上最简单的方式是直接导出export CUDA_HOME/usr/local/cuda export LD_LIBRARY_PATH/usr/local/cuda/lib64:${LD_LIBRARY_PATH} sudo ldconfig7.3 刷机后进不了系统的恢复思路刷机后最糟的情况是开机卡在 Logo或者反复重启。我的处理顺序是先接串口看日志定位卡在哪个阶段。如果能进恢复模式重刷系统。做法和第一次刷机一样只是先格式化 eMMCsudo ./flash.sh -r jetson-orin-nx-devkit mmcblk0p1-r参数会先擦除用户数据再写系统适合系统损坏但引导区还正常的场景。如果连恢复模式都进不去检查载板电源灯、核心板是否插紧。其实只要 eMMC 引导区没有被破坏Jetson 几乎不存在真正变砖的可能。刷机过程中的风险操作是刷到一半断电所以务必保证 DC 电源稳定。7.4 跑起来之后怎么确认 CUDA 真的在干活配置完所有环境后我习惯用一个最简单的 PyTorch 张量运算来验证import torch x torch.randn(1000, 1000, devicecuda) y torch.mm(x, x) print(y.sum().item())再加上tegrastats观察 GPU 频率和显存占用。如果运行期间 GPU 频率有波动、显存有占用说明 CUDA 链路是通的。之后再跑一个 YOLO 或 TensorRT 的 demo 做端到端验证。整套流程走完板子的 From zero to CUDA 就算正式结束了。第二次刷机时我全程下来只花了 40 分钟和第一次折腾大半天形成鲜明对比。如果你正准备刷机我的建议顺序是先在主机上把 JetPack 完整下载好再插开发板进恢复模式刷完先装nvidia-jetpack再配置 PATH 和软链接最后编译 OpenCV 和安装 PyTorch。整个过程犯一次错很正常关键是知道去哪查、怎么验证——希望这篇记录能帮你少走这几段弯路。
