企业官网建设流程全解析

第一次给 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/memory@0/reg

前者会显示类似NVIDIA Jetson Orin NX 16GB Developer Kit的信息，后者能看到内存大小。8GB 版本的 Orin NX 不支持 Super 模式，后面所有关于 Super 模式的性能调优操作都可以跳过。

1.2 eMMC 与 SD 卡：烧录目标和启动介质的选择

Jetson Orin NX 核心板自带 eMMC 存储，8GB 版对应 32GB eMMC，16GB 版对应 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-jetpack

2. 主机准备和设备进入恢复模式：最容易翻车的一步

2.1 主机环境检查清单

刷机不是把开发板插上电脑就行，主机侧的环境直接影响成功率。官方推荐使用 Ubuntu x86_64 主机，我实测下来 Ubuntu 20.04 和 22.04 都没问题，Ubuntu 24.04 需要额外处理一些依赖库，不建议新手用。

主机侧必须满足的条件：

• 至少 50GB 空闲磁盘空间，因为 JetPack 完整下载包加解压后的 rootfs 很容易超过 30GB。
• 一个可用的 USB-C 数据线。这里特别强调是"数据线"，不是"充电线"。很多翻车现场就是线的问题，能充电但不能传数据，lsusb 死活不识别。
• 主机在刷机过程中不能进入休眠。建议在电源设置里把自动挂起关掉，或者干脆用caffeinate（macOS）或修改 logind 配置（Ubuntu）锁住。
• 如果走 SDK Manager 路线，要提前在浏览器登录 NVIDIA 账号，并预留大量时间给它下载组件。

2.2 让开发板进入 USB 恢复模式的标准动作

Orin NX 核心板本身没有 USB 口，需要配合载板使用。无论你用的是官方 Developer Kit 载板，还是第三方的载板，基本都有 Recovery 和 Reset 两个按钮，但位置和手感差异很大，建议先看载板的原理图或说明书。

进入恢复模式的标准操作：

1. 给载板接上 DC 电源，但先不要开机。
2. 找到 Recovery 按钮，按住不要松。
3. 按住 Recovery 的同时，按一下 Reset 按钮。
4. 等待 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 mmcblk0p1

mmcblk0p1表示写入 eMMC 的第一个分区。如果你烧的是 Orin NX 16GB Super 模组，目标设备名就是jetson-orin-nx-devkit，不需要额外指定 Super 之类的东西。整个刷写过程会打印详细的进度，大概 10 到 15 分钟。

3.3 烧录过程中的三个高频失败点

我把刷机过程中最容易出问题的环节总结成一张表，方便你对照排查：

烧录过程中，开发板最好单独接一个 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-smi

uname -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 盘上，编译完再装回系统目录；二是扩大 swap，Jetson 默认的 zram 在编译大项目时容易触发 OOM。我通常加一个 4GB 的 swapfile：

sudo 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/fstab

4.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-6

JetPack 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/cuda

5.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-alternatives：

sudo 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_TYPE=RELEASE \ -D CMAKE_INSTALL_PREFIX=/usr/local \ -D WITH_CUDA=ON \ -D CUDA_ARCH_BIN=8.7 \ -D CUDA_ARCH_PTX=8.7 \ -D WITH_OPENGL=ON \ -D WITH_OPENMP=ON \ -D BUILD_EXAMPLES=OFF \ -D BUILD_opencv_python3=ON \ -D BUILD_opencv_world=OFF \ -D WITH_CUDNN=ON \ -D OPENCV_DNN_CUDA=ON \ ..

这里的CUDA_ARCH_BIN=8.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_LIST="8.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% 完成，但解压时报同样的错。排查链路如下：

1. 先对比文件大小。官网页面会标明文件字节数，ls -l查看实际大小，差一个字节都不行。
2. 再用校验和验证。官网每个文件旁都有 SHA256 值：

sha256sum Jetson_Linux_R36.4.0_aarch64.tbz2

3. 如果校验值对不上，重新下载。不要用断点续传，直接把旧文件删掉，重新下载完整文件。

这个报错也会出现在 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 ldconfig

7.3 刷机后进不了系统的恢复思路

刷机后最糟的情况是开机卡在 Logo，或者反复重启。我的处理顺序是：

1. 先接串口看日志，定位卡在哪个阶段。
2. 如果能进恢复模式，重刷系统。做法和第一次刷机一样，只是先格式化 eMMC：

sudo ./flash.sh -r jetson-orin-nx-devkit mmcblk0p1

-r参数会先擦除用户数据再写系统，适合系统损坏但引导区还正常的场景。

3. 如果连恢复模式都进不去，检查载板电源灯、核心板是否插紧。

其实只要 eMMC 引导区没有被破坏，Jetson 几乎不存在真正变砖的可能。刷机过程中的风险操作是刷到一半断电，所以务必保证 DC 电源稳定。

7.4 跑起来之后怎么确认 CUDA 真的在干活

配置完所有环境后，我习惯用一个最简单的 PyTorch 张量运算来验证：

import torch x = torch.randn(1000, 1000, device='cuda') 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。整个过程犯一次错很正常，关键是知道去哪查、怎么验证——希望这篇记录能帮你少走这几段弯路。