2. Jetson硬件平台与启动链解析
Jetson 的启动过程不是“上电即运行 Linux”这么简单。它是一条由硬件固化代码逐级接力、最终把控制权交给操作系统的多阶段链路。理解这条链路，是生产测试与烧录验证的基础：只有知道每一级由谁加载、存放在哪里、失败时表现如何，才能在量产线上快速判断一块模组是“没烧进去”“烧错了”还是“硬件本身有问题”。
一、先分清三个层次：模组、载板与启动固件
Jetson 产品由两部分组成：模组（Module）和载板（Carrier Board）。模组上集成了 SoC、LPDDR 内存、eMMC/UFS 或 QSPI 存储、电源管理芯片（PMIC）以及部分时钟与调试接口；载板则提供 USB、以太网、MIPI CSI、PCIe、显示、风扇、按键等外设接口。同一颗模组可以插到不同载板上，因此启动链中“哪些设备可用”既取决于模组型号，也取决于载板设计。
以常见型号为例：Jetson Nano 使用 4GB LPDDR4 与 microSD 启动；Jetson Xavier NX 使用 8GB/16GB LPDDR4x 与 16GB eMMC；Jetson Orin Nano 与 Orin NX 使用 LPDDR5，容量从 4GB 到 16GB 不等，并支持 NVMe 启动。不同型号的 BootROM 版本、MB1 配置、UEFI 设备树都不同，烧录时使用的 BSP 包必须与模组型号严格匹配，否则会出现“烧录成功但无法启动”的现象。
二、启动链的六个阶段
Jetson 的启动顺序可以概括为：BootROM → MB1 → MB2 → UEFI → 内核 → 根文件系统。下面逐级说明。
BootROM 是固化在 SoC 内部只读存储器中的第一段代码，上电复位后由硬件直接执行。它负责初始化最基本的时钟、电源和存储控制器，然后从预定义的启动介质中读取下一级引导程序。BootROM 会按顺序尝试启动设备，例如先 eMMC、再 QSPI、再 SD 卡或 USB 恢复模式。如果所有介质都没有有效引导数据，SoC 会进入恢复模式（Recovery Mode），等待主机通过 USB 灌入数据。生产测试中，lsusb 能看到 NVIDIA 的 0955:7xxx 设备，就说明模组已进入恢复模式，这是烧录的前提。
MB1（Micro Boot 1）是 BootROM 加载的第一段可更新引导代码，通常存放在 QSPI 或 eMMC 的引导分区中。它承担更完整的 DRAM 初始化、安全启动校验和存储驱动加载。MB1 会读取板级配置（如 EEPROM 中的板卡 ID、内存型号），据此选择正确的内存参数。如果载板 EEPROM 内容错误或缺失，MB1 可能无法正确初始化 DRAM，表现为串口无输出或反复重启。
MB2 由 MB1 加载，进一步初始化外设、加载 UEFI 固件。MB2 阶段会处理启动设备选择、A/B 分区切换、安全策略等。在 Orin 系列中，MB2 还负责加载 UEFI 的 PE 镜像。
UEFI 是符合 UEFI 规范的固件层，负责枚举 PCIe、USB、网络等设备，加载设备树（DTB），并最终从启动分区中读取内核镜像。UEFI 阶段可以通过串口进入菜单，查看启动项、修改启动顺序。生产验证时，如果 UEFI 能正常显示启动菜单，说明 BootROM、MB1、MB2 均已通过。
内核由 UEFI 加载 Image 或 kernel 镜像到内存并跳转执行。内核会解析 DTB，挂载驱动，初始化根文件系统所需的存储控制器。此时串口会输出大量 dmesg 日志，是判断启动卡在哪一级的关键依据。
根文件系统是启动链的最后一环。内核通过 root= 参数找到根分区，执行 /sbin/init，启动 systemd 或 init 脚本，最终进入登录界面或应用服务。如果根文件系统损坏或分区表错误，内核会报 VFS: Unable to mount root fs，此时需要重新烧录或修复分区。
三、生产测试中如何逐级验证
在量产线上，我们通常按“先恢复模式、再串口、后系统”的顺序验证。第一步，模组上电后短接恢复按键或拉低 RECOVERY 引脚，主机执行 lsusb，若出现 0955:7xxx 设备，说明 BootROM 已正常运行并进入恢复模式。第二步，使用 flash.sh 或 l4t_initrd_flash.sh 烧录 BSP，烧录过程中串口会依次打印 MB1、MB2、UEFI 的版本信息。第三步，烧录完成后重启，观察串口是否进入 UEFI 菜单、是否加载内核、是否挂载根文件系统。
一个典型的串口日志片段如下：
[0000.000] BootROM v1.0
[0000.120] MB1: DRAM init OK, 8GB LPDDR5
[0000.350] MB2: loading UEFI from QSPI
[0001.200] UEFI: Jetson Orin NX, DTB loaded
[0002.500] Kernel: Linux version 5.10.104-tegra
[0003.800] VFS: Mounted root (ext4) on device 0:1
[0004.100] systemd: Reached target Multi-User System
如果日志停在 MB1 之后没有 MB2，优先怀疑 QSPI 中的 MB2 镜像损坏或 A/B 分区切换失败；如果停在 UEFI 之后没有内核日志，检查 /boot/extlinux/extlinux.conf 中的 LINUX 和 FDT 路径是否正确；如果内核已启动但根文件系统挂载失败，则检查 root= 参数与分区 UUID 是否一致。
四、烧录验证的关键检查点
烧录验证不是“烧完能开机”就结束。生产测试至少应覆盖以下检查点：
- 模组型号匹配：BSP 包中的
board_spec必须与模组 SKU 一致，例如 Orin NX 16GB 与 8GB 的 DTB 不同。 - BootROM 可进入恢复模式：确认 USB 枚举正常，排除供电或按键问题。
- MB1/MB2 版本正确：串口日志中的版本号应与 BSP 发布说明一致。
- UEFI 启动项正确：确认启动顺序指向 eMMC/NVMe 的正确分区。
- 内核与 DTB 匹配：载板变更后必须同步更新 DTB，否则外设可能无法识别。
- 根文件系统完整：检查
/etc/nv_tegra_release版本号，确认与烧录 BSP 一致。
SN_日期.log，一旦后续出现启动异常，可以快速定位是烧录问题还是使用过程中的损坏。
理解启动链的层级关系后，就能把“无法启动”这个模糊现象拆解为具体阶段：是 BootROM 没跑起来，还是 MB1 读不到配置，还是 UEFI 找不到内核，还是根文件系统挂载失败。每一级都有对应的串口特征和验证手段，这正是生产测试中快速排障的核心能力。