企业官网建设流程全解析

很多人第一次接触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系统（L4T，Linux 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的容器化改动比较大，生态还在追，有些第三方库踩坑时找不到参考。

这里给一张对应关系表，方便查：

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的标准操作流程是：

1. 给开发板断电（拔掉电源适配器）；
2. 按住Recovery键不放；
3. 插上电源适配器；
4. 等待几秒，松开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. APX

0955是NVIDIA的USB Vendor ID，7023是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 SSD（Nano有eMMC版本），写入速度很快，但校验和确认阶段比较慢。总体下来，顺利的话40分钟到1小时，网络差或者组件选得多，两小时也正常。

等待期间不要去做以下动作：

• 不要动USB线，哪怕它看起来很松；
• 不要打开SDK Manager里其他需要访问同一下载目录的功能；
• 不要合上笔记本盖子，很多笔记本合盖会休眠，USB设备随即掉线。

刷写过程中，开发板可能会自动重启，这是正常现象。有的开发板会重启不止一次，屏幕上可能出现Ubuntu的启动日志，这些都不需要你干预。SDK Manager界面上会显示当前正在进行的步骤，耐心等就好。

刷写完成后，SDK Manager会提示你设置Jetson的用户名、密码和主机名。这一步是给板子上的Ubuntu系统创建初始账户用的，设置完它就尝试通过SSH连接到开发板，然后把SDK组件推到板子上。也有人在这儿卡住，因为开发板重启后网络没获取到IP，SDK 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设备挂起。

排查链路：

1. 换一根短的高质量USB-C线；
2. 如果主机是笔记本，尽量用支持PD供电的Type-C口，避免用扩展坞；
3. 关闭主机的USB自动挂起功能。在Ubuntu上可以执行sudo systemctl mask sleep.target suspend.target来临时禁用休眠，再试一次；
4. 开发板端如果是第三方载板，检查它的刷机口是否需要外部供电，有的载板必须同时插上模块电源和底板电源。

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 couldn't 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 SSD，JetPack刷写时会自动创建多个分区，其中可写的数据分区用户通常可以自由使用。我个人拿到任何一台新的Orin，会先扩充一下根文件系统分区占用，然后用df -h确认/分区空间符合预期。如果刷完系统后发现根分区可用空间特别小，比如只有几个GB，很可能是L4T版本对分区大小的自动调整逻辑没跑，可以执行系统自带的扩容脚本（在JetPack 6上这一步一般会自动完成，JetPack 5有些版本需要手动触发）。具体判断方法：df -h /，如果可用空间小于10GB而你的板子存储明显更大，就是没扩容完，网上搜索对应JetPack版本的扩容命令即可。反正开工前把这件事做完，别等把模型数据拷进去才发现空间不够。

刷机这件事，最怕的不是技术和网络，而是准备工作时图省事。线材不换、Recovery Mode不验证、组件乱勾一堆，出了问题又到处问，浪费时间。按我上面这套流程走，提前把能确认的都确认好，剩下的交给SDK Manager和一点耐心，基本都能顺利跑起来。如果你是在第三方载板上折腾Orin NX，记住一句话：先查载板厂商的兼容说明，再动手刷，能省掉九成麻烦。