Jetson 刷机文档看不动?这篇把 NVIDIA Flashing Support 讲清楚了

NVIDIA Jetson `Flashing Support` 中文精译整理

来源页面：

原文链接：https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/SD/FlashingSupport.html
文档版本：Jetson Linux Developer Guide r36.3

说明：

这是一份基于 NVIDIA 原页面整理的中文精译版，命令、文件名、脚本名尽量保持原样，方便直接对照官方文档操作。
对明显偏工程实践的地方，补了“使用建议”和“适用范围”说明，方便落到实际场景里。
原始 HTML、英文 Markdown 和图片资源仍保存在同目录下的 source/ 与 media/flashing_support/ 中，便于离线核对。

1. 这篇文档在讲什么

主要讲 Jetson 平台的刷写、克隆、备份、恢复，以及启动介质相关配置。NVIDIA 重点介绍了两套工具：

flash.sh传统刷写脚本，用于刷 Bootloader、内核，以及可选的根文件系统。
l4t_initrd_flash.sh基于恢复态 initrd 的刷写脚本，既能刷内部存储，也能刷外部 NVMe、USB 等设备。它实际借助内核完成刷写，因此通常比 flash.sh 更快。

这页里最值得先记住的结论之一是：

对 Jetson Orin NX / Orin Nano，正式推荐的刷写方式是 initrd flash
尤其是使用 NVMe 作为外部根文件系统时，更应优先使用 l4t_initrd_flash.sh
若量产系统后续需要 OTA，一定要注意 flash.sh 与 initrd flash 的分区布局并不相同

2. 开始前需要具备的目录

开始刷机前，主机侧（你的电脑） BSP 目录里至少要有这些内容：

bootloader含 TegraFlash、CFG、BCT 等 Bootloader 与刷写工具
kernel含 /Image、DTB 文件、内核模块
rootfs你下载并展开后的根文件系统
nv_tegra用户态二进制与示例程序

另外还有两个前提：

主机必须通过 USB 线连接到 Jetson 的恢复口
开始刷写前，要先让板子进入 Force Recovery Mode

3. `flash.sh` 的基础用法

基本形式：

sudo ./flash.sh [options] <board> <rootdev>

参数含义：

<board>指设备所使用的板级配置。flash.sh 会读取对应的 <board>.conf 文件，并根据其中定义的分区布局、BCT、DTB、固件等内容进行刷写。
<rootdev>指根文件系统所在设备，比如：

mmcblk0p1：本地 eMMC 或 SD 卡分区
internal：内部介质
external：外部介质
nvme0n1p1 / sda1：具体外部分区

如果只想看命令帮助：

./flash.sh -h

4. 基础刷写流程

4.1 安装刷写依赖

sudo tools/l4t_flash_prerequisites.sh

4.2 刷写目标板

让目标板进入 Force Recovery Mode
执行：

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

例如：

sudo ./flash.sh <board> mmcblk0p1

4.3 使用 NVIDIA 提供的便捷脚本

sudo ./nvsdkmanager_flash.sh [--storage <storage>]

--storage 可取值示例：

nvme0n1p1：外部 NVMe SSD
sda1：外部 USB 存储
mmcblk1p1：外部 SD 卡

原文要点：

对 Orin 系列来说，如果带 --storage，除了外部设备会被刷写，内部 eMMC 还会写入一个小型启动分区，用来把外部设备当作 rootfs
如果不带 --storage，系统默认认为设备有内部 eMMC，或者在没有 eMMC 的情况下已经插好了 SD 卡

5. 按 UUID 或设备名指定 rootfs

5.1 按 UUID 挂载 rootfs

内部存储：

sudo ./flash.sh <board> internalsudo ./flash.sh --reuse-uuid <board> internal

说明：

系统会把新的 rootfs UUID 写到 bootloader/l4t-rootfs-uuid.txt
如果你想固定 UUID，可以先手动写入这个文件，再用 --reuse-uuid

外部存储：

sudo ./flash.sh <board> externalsudo ./flash.sh --reuse-uuid <board> external

对应 UUID 文件：

bootloader/l4t-rootfs-uuid.txt_ext

5.2 按分区设备名挂载 rootfs

USB 设备：

sudo ./flash.sh <board> sda<x>

NVMe 设备：

sudo ./flash.sh <board> nvme0n1p<x>

重要提醒：

这种方式只会把一个很小的启动分区刷到 Jetson 内部存储
它的作用是让系统去挂载外接 USB 或 NVMe 上的根文件系统
它不会把外部存储本身的 rootfs 内容真正写进去

6. 板级配置文件与后续刷写镜像生成

<board>.conf 本质上就是一个 bash 脚本，用来定义：

BCT
DTB
内核
固件
分区布局

关键点：

flash.sh 只能使用在板级配置文件里定义的一份分区配置文件
l4t_initrd_flash.sh 除了板级配置里定义的分区文件外，还能在 --external-device 场景下通过 -c 再额外传入一份外部设备分区布局文件

如果你想先把镜像准备好，后面再执行正式刷写，可以按这个思路理解：

把板子接入恢复模式
读取 EEPROM 和芯片信息
生成后续刷写所需镜像
之后在 bootloader/ 下执行：

cd bootloadersudo bash ./flashcmd.txt

这适合：

你想把刷写准备和真正刷写分开
你想先做离线镜像准备
工厂或批量生产环境

7. 克隆 Jetson 与备份恢复

7.1 克隆：只复制 `APP` 根文件系统分区

原文给出的 flash.sh 克隆方法：

sudo ./flash.sh -r -k APP -G <clone> <board> mmcblk0p1

作用：

生成一个稀疏镜像 <clone>
再生成一个完整原始镜像 <clone>.raw

例如 <clone> 为 original.img 时，会得到：

original.img
original.img.raw

然后把生成的镜像复制到：

sudo cp <clone>.img bootloader/system.img

再刷到目标板：

目标板已经刷过：

sudo ./flash.sh -r -k APP <board> mmcblk0p1

目标板从未刷过：

sudo ./flash.sh -r <board> mmcblk0p1

注意：

克隆只覆盖 APP 分区，不等于完整整机备份
如果源板在 oem-config 中把 APP 扩到很大，目标板分区配置也要同步调整
对外部存储上的 rootfs，例如 NVMe，NVIDIA 明确要求看后面的 Cloning rootfs with initrd

7.2 备份与恢复：比克隆更完整

原文定义：

clone：只包含 APP 文件系统分区
backup：包含设备内部 eMMC 与 QSPI 中的所有分区

8. RCM 模式下从 NFS 启动

命令：

sudo ./flash.sh -N <ip_addr>:<root_path> --rcm-boot <board> eth0

含义：

<ip_addr>：主机 IP
<root_path>：NFS 根目录
<board>：目标设备的板级配置

这个模式适合：

调试网络根文件系统
某些验证场景
不想立刻把完整 rootfs 刷进本地介质的情况

9. `flash.sh` 重要参数速览

原文给了完整参数表。实际使用时，先记住这些高频参数就够了：

-c <cfgfile>：指定分区配置文件
-d <dtbfile>：指定设备树
-k <partition_id>：只刷特定分区
-r：跳过重新生成 system.img，复用已有镜像
-u <PKC_key_file>：ODM 融合板 PKC key
-v <SBK_key_file>：Secure Boot Key
-I <initrd>：指定 initrd 文件
--user_key <user_key_file>：用于加解密内核、DTB、initrd 的用户密钥

如果你只改了某个分区，-k 会非常有用，可以明显缩小刷写范围。

10. 刷写到 USB、NVMe、SD 卡

10.1 外部存储设备总体原则

initrd 刷写工具支持外部设备。Jetson Linux 支持的外部设备类型主要是：

/dev/sd*：SCSI/USB 存储
/dev/nvme*n*：NVMe

默认外部分区布局常见文件：

Linux_for_Tegra/tools/kernel_flash/flash_l4t_t234_nvme.xml

原文说明：

这份分区布局默认按 64GB 及以上 的外部介质设计
如果你的设备更小，要修改：

板级配置里的 ROOTFSSIZE
分区布局文件中的 num_sectors

10.2 只刷某个分区

sudo ./flash.sh -k <partition_name> [--image <image_name>] <board> <rootdev>

原文示例：

只刷 QSPI：

sudo ./flash.sh --no-systemimg -c bootloader/generic/cfg/flash_t234_qspi.xml <board> <rootdev>

只刷 NVMe：

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-only --network usb0 --external-device nvme0n1 -c tools/kernel_flash/flash_l4t_t234_nvme.xml <board> <rootdev>

只刷 NVMe 上的 APP 分区：

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-only --network usb0 -k APP --external-device nvme0n1 -c tools/kernel_flash/flash_l4t_t234_nvme.xml <board> <rootdev>

10.3 SD 卡

原文这一节还顺带介绍了：

生成 SD 卡镜像
用 Etcher 刷写
用 dd 刷写
将根分区扩满整张卡
Orin Nano Devkit 从 JetPack 5 升到 JetPack 6

但对 Orin NX 的实际迁移来说，这部分通常不是重点，除非你的系统本来就跑在 SD 卡上。

11. `initrd` 刷写：这才是 Orin NX/Nano 的重点

11.1 `initrd flash` 是什么

它是 NVIDIA 推荐的恢复态刷写方案，既能刷内部介质，也能刷外部介质。相关工具在：

Linux_for_Tegra/tools/kernel_flash/

更详细的工作流在：

README_initrd_flash.txt

该 README 涵盖的场景包括：

刷内部存储
刷外部 NVMe / USB
根文件系统 A/B
磁盘加密
单独分区刷写
融合板刷写
Massflash
分开生成内外部镜像再组合刷写

11.2 使用前要求

原文列出的要求：

要用质量好的 USB-C / micro-USB 线
先执行：

sudo tools/l4t_flash_prerequisites.sh

initrd 刷写依赖 IPv6 fc00:1:1::/48 的 NFS 与 SSH 通信

意味着：

主机系统、防火墙必须允许 IPv6
NVIDIA 验证环境至少是 Ubuntu 18.04 及以上

11.3 对有内部存储设备的基本刷法

cd Linux_for_Tegrasudo ./tools/kernel_flash/l4t_initrd_flash.sh <board-name> <rootdev>

但原文紧接着特别说：

对没有内部存储的设备，例如 Jetson Orin Nano 和 Jetson Orin NX，要参考“刷写到外部存储设备”这一套方法

这句话很关键，因为很多人会下意识把 Orin NX 当成传统 eMMC 设备来刷，结果一开始方向就偏了。

12. 用 `initrd` 克隆 rootfs

这是 Orin NX / 外部 NVMe 场景里非常关键的一段。

步骤如下：

让 Jetson 进入 Recovery Mode
在主机执行：

cd Linux_for_Tegrasudo ./tools/kernel_flash/l4t_initrd_flash.sh --initrd <board-name> <rootdev>

进入 Jetson 侧 bash shell
插一个 USB 盘到 Jetson 上，把 rootfs 分区做成完整原始镜像：

mount /dev/sda1 /mntdd if=<rootfs partition> of=/mnt/system.img.rawsyncumount /mnt

其中：

/dev/sda1：插入 Jetson 的 USB 盘
<rootfs partition>：

eMMC 设备可能是 /dev/mmcblk0p1
NVMe 设备可能是 /dev/nvme0n1p1

把 USB 盘拔下来，接回主机
把 system.img.raw 拷到主机
转成稀疏镜像：

cd Linux_for_Tegra./bootloader/mksparse --fillpattern=0 system.img.raw system.img

这段在工程上很有价值，因为它是 NVIDIA 页面里对“外部 rootfs 克隆”写得最直接的一段。

13. 自定义 BSP 与 `initrd` 镜像分离刷写

原文还给了一个很实用的思路：

用一份“原始 BSP”做稳定刷写环境
用另一份“修改过的 BSP”生成你想刷进去的内容
最后借助 --use-backup-image 在原始环境中把内容刷进去

示例流程：

复制一份原始 Linux_for_Tegra
在修改版 BSP 中做你的改动
在修改版 BSP 中运行 --no-flash
如有需要，把生成的 tools/kernel_flash/images 拷回原始 BSP
在原始 BSP 中执行：

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --use-backup-image --external-device nvme0n1p1 -c ./tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs jetson-orin-nano-devkit nvme0n1p1

这种做法更适合：

你对 BSP 做了裁剪或改动
改动过的 BSP 不能稳定进入 initrd flash
想把“刷写环境”和“刷写内容”解耦

14. 多机量产刷写

NVIDIA 提供了 massflash 工作流，典型流程是：

用 --no-flash --massflash <x> --network usb0 生成 massflash 包
把多台设备接到主机
都置入 RCM
执行：

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --network usb0 --massflash 5

还可以搭配：

--keep
--reuse
--showlogs

但要注意：

原文前面明确说过，Orin NX 的 backup image massflash workflow 3 当前不可用
所以你在 Orin NX 上做批量“整板还原”时，不要把所有 massflash 都视为完全可套用

15. 不读 EEPROM、扩容内部根分区、驱动更新验证

这一页还覆盖了这些场景：

不读取 EEPROM 的刷写
扩大内部根分区
验证驱动更新是否成功

这些内容更偏专项运维。如果你当前目标是“把一块完整 Orin NX 迁到一块空板”，它们不是第一优先级。

16. `oem-config` 重新配置与无头模式

这一大段讲的是首次上电时常见的配置界面。若你刷的是一块“全新板”或“重置后的板”，大概率会用到。

16.1 UART 端口可切换

如果开发板在 40 针排针上有 UART，可以把：

nv-oem-config-uart-port=ttyGS0

改成：

nv-oem-config-uart-port=ttyTHS0

16.2 无头模式流程

在首次启动前，主机上先打开串口终端，例如：

putty
screen

原文不推荐 minicom，原因是它在这个场景下处理 UTF-8 会有问题。

16.3 `oem-config` 界面流程图

欢迎页：

许可协议：

语言选择：

地区选择：

键盘布局：

时区选择：

系统时钟是否使用 UTC：

全名输入：

用户名输入：

密码输入：

密码确认：

是否创建 swap：

创建 swap 选择：

APP 分区大小：

主网络接口：

主机名：

是否安装 Chromium：

Chromium 安装确认：

原文里有几个细节，实际操作时很值得留意：

推荐系统时钟设为 UTC
用户名建议简单、全小写
如果你做 AI / 深度学习，NVIDIA 倾向建议开启 swap
但 swap 会增加 SD 卡写入，可能缩短寿命
oem-config 的 Wi-Fi 配置有已知问题，必要时用 nmcli 后配

17. 修改 RAM Disk

如果你需要改 initrd，这一页也给了一个典型流程：

解包 initrd
在临时目录中改内容
重新打包
替换 /boot/l4t_initrd.img

这类操作通常适合：

自定义 early boot 行为
改刷写或启动早期逻辑

18. 打开 USB3 Recovery Mode

本页还专门讲了：

AGX Orin
Orin NX
Orin Nano

如何启用 USB3 恢复模式。

这通常和刷机带宽、恢复链路稳定性有关。若你用的是自定义载板，这一节值得认真看一遍。

19. Orin NX / Nano 专用结论

19.1 官方推荐：`initrd flash`

原文这里写得非常直接：

Initrd flash is the official method of flashing Jetson Orin NX series and Jetson Orin Nano series with NVMe as the external storage device.

默认 NVMe 场景示例：

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -p "-c ./bootloader/generic/cfg/flash_t234_qspi.xml" -c ./tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs --network usb0 jetson-orin-nano-devkit nvme0n1p1

此外，原文还给了：

rootfs A/B
磁盘加密
A/B + 加密

三种派生工作流。

19.2 `flash.sh` 仍可用于开发，但不应替代正式方案

原文直接提醒：

Orin NX / Nano 的官方方法是 initrd flashing
flash.sh 使用的内存布局和 initrd flashing 不同
如果你要保证 OTA 成功，生产系统必须使用 initrd flashing

这背后的实际含义是：

开发调试、单分区刷写时，flash.sh 可以辅助使用
但真正要交付、复制、量产、保持后续一致性时，应当回到 initrd flash

20. PXE 启动服务器配置

最后一节讲的是：

DHCP
TFTP
NFS
UEFI PXE 启动

这套方案更适合：

网络引导
统一实验环境
磁盘无状态或集中式根文件系统

如果你现在只是做两块 Orin NX 之间的迁移，这一节更适合作为扩展阅读，不是主流程，后面会单独出一篇的。

21. 面向 Orin NX 迁移的实操结论

基于这一页内容，可以先归纳出下面几个判断：

对 Orin NX，如果根文件系统在 NVMe 上，首选 l4t_initrd_flash.sh
若只是复制系统内容，不要把“克隆 APP/rootfs”和“整机全分区备份”混为一谈
若目标板是空板，通常至少要考虑两部分：

QSPI / 启动链
外部 NVMe 上的 rootfs

若你后续还想做 OTA，一开始就要按 initrd flash 的官方布局走
Orin NX 的 backup image massflash 有限制，做量产恢复时要额外谨慎

NVIDIA Jetson Flashing Support 中文精译整理