企业官网建设流程全解析

1. 从“一键还原”的幻想说起：Jetson 刷机到底难在哪

很多人第一次给 Jetson 刷系统，脑子里浮现的画面大概是这样的：插上 U 盘，点一下“下一步”，等进度条走完，重启，完事。毕竟 Windows 上有 Ghost，安卓手机有各种一键刷机工具，连机顶盒都能“免拆刷机”，凭什么一块小小的 Jetson 开发板要搞得这么复杂？

我当初也是这么想的。手里拿到一块 Jetson Orin Nano，满心欢喜准备部署一个视觉推理项目，结果开机黑屏，串口没有任何输出，连 BIOS 都进不去。那一刻我才意识到，Jetson 的刷机和普通消费电子产品的刷机完全是两码事。它更像是给一台没有显示器、没有键盘、没有操作系统的“裸机”做心脏搭桥手术——你得从外部把引导程序、固件、内核、根文件系统一层一层地“灌”进去，而且每一步都不能出错。

这篇文章就是把我踩过的坑、查过的资料、反复失败后总结出来的完整流程，原原本本地写出来。不管你是刚拿到 Jetson Nano、Orin NX、AGX Orin 的新手，还是已经用过一段时间但遇到系统崩溃需要重装的开发者，这篇内容都能帮你少走弯路。核心关键词包括Jetson、Recovery 模式、APX、bct_mem、刷机，我会围绕这些概念把整个流程拆解得清清楚楚。

先说结论：Jetson 刷机之所以难，根本原因在于它的启动链路和普通 PC 完全不同。普通 PC 有 BIOS/UEFI 固件，你插个 U 盘就能引导；Jetson 的引导链是BootROM → BCT → Bootloader → Kernel，其中 BootROM 是固化在芯片里的，你改不了，但你可以通过Recovery 模式让芯片进入一种特殊的“等待主机灌数据”的状态，然后由主机端的刷机工具通过 USB 把整套系统镜像写进去。这个过程涉及分区表、内存配置、固件签名等多个环节，任何一个环节的参数不对，都会导致刷机失败或者刷完起不来。

所以，如果你还抱着“一键还原”的心态，建议先调整预期。接下来的内容，我会从 Recovery 模式的进入方法讲起，然后一步步带你完成刷机，最后分享几个我实际踩过的坑和排查思路。

2. Recovery 模式与 APX：Jetson 刷机的入口

2.1 Recovery 模式到底是什么

Recovery 模式是 Jetson 芯片内部 BootROM 提供的一种特殊启动状态。当你通过特定的硬件操作（通常是按住 Recovery 按钮再上电，或者短接特定引脚）让芯片进入这个模式时，BootROM 不会去加载板载的固件，而是会通过 USB 接口等待主机发送指令。此时，如果你在主机上运行lsusb命令，会看到一个NVIDIA Corp.的设备，ID 通常是0955:7xxx这样的格式，这就是所谓的APX 模式。

APX 是 NVIDIA 内部用来描述这种“等待主机灌数据”状态的术语，你可以把它理解为芯片在说：“我准备好了，你把系统镜像发过来吧。”这个模式下，芯片没有任何操作系统在运行，完全依赖主机端的工具来驱动整个刷机过程。

注意：Recovery 模式和 APX 模式在大多数语境下是可以互换的，但严格来说，Recovery 模式是硬件层面的启动状态，APX 是 USB 层面的设备标识。你进入 Recovery 模式后，主机识别到的就是 APX 设备。

2.2 不同型号的 Recovery 进入方法

Jetson 家族型号众多，进入 Recovery 模式的方法略有差异。我整理了一个对照表，方便你快速找到自己板子的操作方式：

这里有一个非常关键的细节：按住 Recovery 按钮的时机。很多新手失败的原因就是按早了或者按晚了。正确的做法是：先按住 Recovery 按钮不松手，然后给板子上电（或者按 Power 键），保持按住状态大约 2 到 3 秒，然后再松开。如果你先上电再按 Recovery，芯片可能已经完成了 BootROM 阶段的初始化，就不会进入 APX 模式了。

2.3 验证是否成功进入 APX 模式

在 Linux 主机上，你可以用以下命令确认：

lsusb | grep -i nvidia

如果输出类似Bus 001 Device 012: ID 0955:7020 NVIDIA Corp.的内容，说明已经成功进入 APX 模式。在 Windows 主机上，你可以在设备管理器里看到“NVIDIA APX”设备。如果没看到，先检查 USB 线是否支持数据传输（有些线只能充电），然后检查 Recovery 操作是否正确。

提示：如果你用的是虚拟机，需要确保 USB 设备已经直通到虚拟机里。我遇到过好几次因为 VMware 没有自动挂载 USB 设备，导致lsusb死活看不到 NVIDIA 设备的情况。

3. 刷机前的准备工作：比刷机本身更重要

3.1 主机环境的选择与配置

Jetson 刷机对主机环境有比较明确的要求。官方推荐使用Ubuntu 18.04 或 20.04的物理机，因为刷机工具flash.sh和 SDK Manager 在 Linux 下运行最稳定。如果你只有 Windows 电脑，可以考虑用 WSL2，但 USB 直通可能会有问题，我实测下来 WSL2 的 USB 支持并不总是可靠，尤其是涉及大量数据传输时容易断连。

如果你坚持用虚拟机，VMware Workstation 的 USB 直通相对成熟，但需要在虚拟机设置里把 USB 控制器设为USB 3.0，并且在刷机过程中不要插拔其他 USB 设备，否则可能导致设备重新枚举，刷机中断。

主机硬盘空间也是一个容易被忽略的点。完整的 JetPack SDK 下载下来大约 20 到 30 GB，解压后可能超过 50 GB。如果你要刷的是 AGX Orin 这种大容量型号，根文件系统镜像本身就有十几 GB，加上临时文件，建议预留至少 100 GB 的可用空间。

3.2 下载正确的 BSP 和根文件系统

NVIDIA 的刷机包通常以BSP（Board Support Package）的形式发布，里面包含了引导程序、内核、设备树、固件等。你需要根据 Jetson 型号和 JetPack 版本下载对应的包。比如 Jetson Orin Nano 对应的是 JetPack 5.1.2 或 6.x，Jetson Nano 对应的是 JetPack 4.6.x。

下载页面通常会提供两个压缩包：一个是BSP 包（文件名类似Jetson_Linux_R35.x.x_aarch64.tbz2），另一个是根文件系统包（文件名类似Tegra_Linux_Sample-Root-Filesystem_R35.x.x_aarch64.tbz2）。两个包缺一不可，BSP 包提供引导和内核，根文件系统包提供完整的 Ubuntu 用户空间。

注意：不同 JetPack 版本对应的 L4T 版本号不同，比如 JetPack 5.1.2 对应 L4T 35.4.1，JetPack 6.0 对应 L4T 36.3.0。下载时一定要核对版本号，BSP 和根文件系统必须来自同一个 L4T 版本，否则刷完可能起不来。

3.3 解压与目录结构

下载完成后，解压 BSP 包：

tar -xjf Jetson_Linux_R35.4.1_aarch64.tbz2 cd Linux_for_Tegra

然后把根文件系统包解压到rootfs目录：

sudo tar -xjf ../Tegra_Linux_Sample-Root-Filesystem_R35.4.1_aarch64.tbz2 -C rootfs/

解压完成后，你还需要运行apply_binaries.sh脚本，把 NVIDIA 的专有驱动和库文件复制到根文件系统中：

sudo ./apply_binaries.sh

这一步非常关键，如果跳过，刷出来的系统会缺少 GPU 驱动、CUDA 库等核心组件，虽然能开机，但跑不了任何 AI 推理任务。

3.4 bct_mem 文件的作用与常见问题

在Linux_for_Tegra/bootloader目录下，你会看到一堆bct_mem开头的文件，比如bct_mem_4GB.cfg、bct_mem_8GB.cfg等。这些是Boot Configuration Table的内存配置文件，用来告诉 BootROM 当前板子的内存容量和时序参数。

如果你刷机时选错了bct_mem文件，比如给 8GB 内存的板子用了 4GB 的配置，刷机过程可能看起来正常，但刷完后系统会不稳定，甚至无法启动。我遇到过一块 Orin Nano 8GB，因为误用了 4GB 的配置，开机后串口输出一堆内存初始化错误，最后只能重新进入 Recovery 模式重刷。

提示：flash.sh脚本通常会自动检测内存容量并选择正确的bct_mem文件，但如果你用的是自定义载板或者修改过配置，最好手动确认一下。

4. 正式刷机：从命令行到系统启动

4.1 flash.sh 的基本用法

进入Linux_for_Tegra目录后，刷机命令的基本格式是：

sudo ./flash.sh <target> <rootdev>

其中<target>是板子型号对应的配置名，比如jetson-orin-nano-devkit、jetson-agx-orin-devkit、jetson-nano-devkit等。<rootdev>通常是mmcblk0p1，表示把根文件系统刷到 eMMC 或 SD 卡的第一分区。

以 Jetson Orin Nano 为例，完整命令是：

sudo ./flash.sh jetson-orin-nano-devkit mmcblk0p1

执行后，脚本会先检查 APX 设备是否在线，然后依次写入 BCT、引导程序、内核、设备树、根文件系统。整个过程根据板子型号和 USB 速度，可能需要 10 到 30 分钟。

4.2 刷机过程中的关键阶段

刷机过程大致分为以下几个阶段，每个阶段都有对应的日志输出：

1. BCT 写入阶段：脚本会把bct_mem配置和 BCT 数据写入芯片的引导存储区。如果这一步失败，通常会提示Error: Return value 1或者failed to write bct。
2. Bootloader 写入阶段：包括nvtboot、cboot、U-Boot等引导程序。这一步如果失败，可能是 USB 连接不稳定或者 BSP 包不完整。
3. 分区表写入阶段：脚本会根据配置文件创建 GPT 分区表，划分出APP、kernel、kernel-dtb、A_kernel等分区。
4. 根文件系统写入阶段：这是最耗时的阶段，脚本会把rootfs目录下的所有文件打包成system.img，然后写入 eMMC 或 SD 卡。如果主机硬盘空间不足，这一步会失败。
5. 校验与重启：写入完成后，脚本会校验数据完整性，然后自动重启板子。

4.3 刷机失败的常见报错与排查

刷机失败时，日志通常会给出一些线索。我整理了几个最常见的报错和对应的排查方向：

注意：刷机过程中不要拔掉 USB 线，也不要让主机进入休眠状态。我有一次因为笔记本自动休眠，导致刷机中断，板子变砖，只能重新进入 Recovery 模式重刷。

4.4 刷机完成后的首次启动

刷机完成后，板子会自动重启。首次启动会比平时慢一些，因为系统需要初始化各种服务、扩展根文件系统、生成 SSH 密钥等。如果你接了串口调试线，可以在串口终端看到完整的启动日志。如果没有串口线，可以接 HDMI 显示器，或者等几分钟后通过 SSH 连接。

首次启动后，建议先运行以下命令检查系统状态：

sudo apt update sudo apt upgrade

然后确认 GPU 驱动和 CUDA 是否正常：

nvidia-smi nvcc --version

如果nvidia-smi能正常输出 GPU 信息，说明刷机成功，系统已经可以正常使用了。

5. 那些让我差点放弃的坑：真实排查记录

5.1 刷完起不来：串口日志里的秘密

有一次给 Jetson Xavier NX 刷完系统，板子死活起不来，HDMI 黑屏，SSH 连不上。我接上串口调试线，看到日志停在Starting kernel ...之后就没了。这种情况通常是设备树或者内核参数有问题。

排查过程是这样的：首先确认 BSP 包和根文件系统版本一致，然后检查flash.sh使用的设备树文件是否正确。Xavier NX 有多个载板配置，如果你用的是第三方载板，可能需要手动指定设备树。最后发现是flash.sh默认用了官方开发套件的设备树，而我的载板是定制的，引脚定义不同，导致内核在初始化阶段就挂了。

解决办法是找到载板厂商提供的设备树文件，替换Linux_for_Tegra/kernel/dtb目录下的对应文件，然后重新刷机。这个坑让我明白，Jetson 刷机不是“刷完就行”，还要确保硬件配置和软件配置匹配。

5.2 bct_mem 选错导致的内存初始化失败

前面提到过bct_mem文件的重要性，这里再展开说一下。Jetson 的内存控制器需要在 BootROM 阶段就完成初始化，而初始化的参数就写在bct_mem文件里。如果你给 8GB 的板子用了 4GB 的配置，BootROM 会按照 4GB 的地址空间去初始化内存，结果就是高地址的内存无法访问，系统跑着跑着就崩溃。

更麻烦的是，这种问题不一定在刷机阶段暴露出来。有时候刷机过程完全正常，但系统启动后运行一段时间才出现随机崩溃。我当初排查了很久，最后对比了官方文档才发现是bct_mem文件用错了。

提示：如果你不确定该用哪个bct_mem文件，可以查看Linux_for_Tegra/bootloader目录下的README或者直接看flash.sh脚本里的自动检测逻辑。大多数情况下，脚本会自动选对，但自定义载板需要格外小心。

5.3 USB 线材与端口的玄学问题

这个问题听起来很low，但确实坑了我好几次。Jetson 刷机对 USB 线材的要求比普通外设高得多，因为刷机过程中要传输几十 GB 的数据，而且对时序有一定要求。我一开始用了一根普通的手机充电线，结果刷机到一半就报USB timeout，换了三根线才找到一根能稳定工作的。

另外，主机的 USB 端口也有讲究。前置面板的 USB 口通常是通过内部排线连接到主板的，供电和信号质量都不如后置的直连端口。我后来固定用主板后置的 USB 3.0 口，刷机成功率明显提高。

5.4 根文件系统空间不足的尴尬

Jetson Nano 的 eMMC 只有 16GB，刷完 JetPack 后可用空间只剩几个 GB。如果你要部署的模型和数据集比较大，很快就会爆盘。我当初没注意，刷完系统后直接往/home里拷了一个 10GB 的数据集，结果系统直接卡死，重启后进入紧急模式。

解决办法有两个：一是刷机时选择把根文件系统放到 SD 卡上（需要修改flash.sh的参数），二是刷完后用gparted扩展分区。但扩展分区有风险，操作不当可能导致分区表损坏。我后来养成了一个习惯：刷机前先规划好存储方案，如果 eMMC 不够用，直接刷到 NVMe SSD 上。

6. 刷机之外的思考：如何让 Jetson 更“抗造”

6.1 系统备份与快速恢复

既然刷机这么麻烦，最好的策略就是刷好一次之后做好备份。Jetson 支持通过flash.sh的-r参数读取板子上的系统镜像，也可以直接用dd命令备份整个 eMMC 或 SSD。我通常会在系统配置完成后，用以下命令做一个完整备份：

sudo dd if=/dev/mmcblk0 of=jetson_backup.img bs=4M status=progress

备份文件可以存到外部硬盘或 NAS 上。下次系统崩溃时，直接用dd写回去，比重新刷机快得多。不过要注意，dd备份的是整个磁盘，包括分区表和引导程序，恢复时目标磁盘容量不能小于源磁盘。

6.2 容器化部署减少系统污染

另一个减少刷机频率的方法是尽量用容器来部署应用。NVIDIA 提供了l4t-base和l4t-ml等 Docker 镜像，里面已经包含了 CUDA、cuDNN、TensorRT 等组件。你可以把应用跑在容器里，这样即使应用环境搞乱了，删掉容器重新拉一个就行，不用重刷整个系统。

我现在的做法是：系统刷好后只装最基本的驱动和 Docker，所有 AI 推理任务都跑在容器里。这样即使某个项目的依赖冲突了，也不会影响整个系统。

6.3 串口调试线是必备工具

如果你经常折腾 Jetson，强烈建议备一根串口调试线。Jetson 的串口调试接口通常是 3.3V TTL 电平，用 CP2102 或 FT232 芯片的 USB 转串口模块就可以。接上串口后，你可以看到完整的启动日志，即使 HDMI 没输出、SSH 连不上，也能通过串口判断问题出在哪个阶段。

我用的是一根 CP2102 模块，接在 Jetson 的 UART 引脚上，波特率设为 115200。每次刷机后第一次启动，我都会开着串口终端，观察启动过程。如果卡住了，日志会告诉我卡在哪一步，排查起来比盲猜快得多。

6.4 关于 Recovery 模式的几个冷知识

最后分享几个关于 Recovery 模式的冷知识。第一，Recovery 模式下板子的功耗比正常运行时低，因为大部分外设都没有初始化，所以如果你用电池供电，不用担心耗电问题。第二，Recovery 模式下的 USB 设备描述符是固定的，如果你在主机上看到多个 NVIDIA 设备，可能是板子没有正确进入 Recovery，或者 USB 集线器有问题。第三，有些载板设计了自动进入 Recovery 的电路，比如通过特定的 GPIO 电平触发，如果你经常刷机，可以考虑加一个按钮或者跳线，省去每次短接的麻烦。

刷机这件事，说到底就是一层窗户纸。第一次做的时候觉得复杂得不行，做多了之后发现流程其实很固定：进入 Recovery，确认 APX 设备，运行flash.sh，等进度条走完，重启。真正难的是遇到问题时怎么排查，而排查的关键在于理解每个阶段在做什么，以及日志在告诉你什么。希望这篇内容能帮你少走一些弯路，顺利把 Jetson 跑起来。