3. Jetson启动链路与固件验证
Jetson 的启动过程不是“上电即进系统”这么简单，而是一条由多级固件逐段接力、逐级校验、逐级移交控制权的链路。理解这条链路，是定位“卡在开机 Logo”“串口无输出”“反复重启”“进不去根文件系统”等问题的前提。本节按 BootROM → MB1 → MB2 → UEFI → 内核 → 根文件系统的顺序拆解各阶段职责，并给出用串口日志与启动时间分析定位失败点的方法。
一、启动阶段划分与各级职责
Jetson 上电后，最先运行的是芯片内部固化的 BootROM。它不依赖外部存储，负责最基本的硬件初始化，并按启动顺序（如 eMMC、QSPI、SD、USB 恢复模式）寻找可引导介质，读取并验证 MB1。BootROM 阶段几乎没有可读日志，若此阶段失败，通常表现为完全无串口输出或直接进入恢复模式。
MB1 运行在 BPMP（Boot and Power Management Processor）上，负责更完整的时钟、电源、DDR 内存控制器初始化，并加载 MB2。MB1 是“内存能不能用”的关键节点，DDR 参数错误、供电异常常在此暴露。随后 MB2 继续初始化安全与存储子系统，加载并跳转到 UEFI（在较新 Jetpack 中为 UEFI 固件，早期为 cboot）。UEFI 负责设备枚举、启动项选择、加载内核镜像与设备树，并把控制权交给 Linux 内核。内核完成驱动初始化后挂载根文件系统，最终启动用户态 init，进入系统。
可以把这条链路理解为一条“责任链”：每一级只做自己该做的事，然后把控制权交给下一级。定位启动失败的核心思路，就是判断日志停在哪一级、最后一条有效输出属于谁。
二、用串口日志定位失败点
串口是启动调试的第一手工具。Jetson 调试串口通常为 3.3V TTL，参数为 115200 8N1，无流控。连接后应能从上电瞬间看到连续输出。定位时不要只看“最后一行”，而要关注“最后一条属于哪一级”的输出。
# 常用串口工具（Linux 主机）
sudo minicom -D /dev/ttyUSB0 -b 115200
# 或
picocom -b 115200 /dev/ttyUSB0
# 保存完整日志便于比对
picocom -b 115200 /dev/ttyUSB0 | tee boot.log典型判断逻辑如下：若上电后完全无输出，优先怀疑供电、串口接线（TX/RX 是否交叉）、波特率，以及是否误入恢复模式；若出现 MB1 相关字样后中断，重点查 DDR 参数、供电轨与模块焊接；若 MB2 之后无 UEFI 输出，检查 UEFI 分区是否损坏、启动项配置是否正确；若 UEFI 已加载内核但卡在挂载根文件系统，则问题多在 APP 分区、文件系统损坏或内核命令行中的 root= 参数。
三、启动时间分析与常见失败模式
启动时间分析用于区分“慢”和“卡”。可在 UEFI 与内核阶段分别记录时间戳：UEFI 阶段关注启动项枚举与内核加载耗时，内核阶段关注 dmesg 中从内核解压到 init 启动的时间。若某阶段耗时明显超出基线，说明该阶段存在重试或超时，例如存储介质响应慢、设备树匹配失败导致驱动反复探测。
| 现象 | 最可能停在哪一级 | 排查方向 |
|---|---|---|
| 完全无串口输出 | BootROM 之前 | 供电、串口接线、恢复模式 |
| DDR 初始化后中断 | MB1 | DDR 参数、供电轨、焊接 |
| 无 UEFI 输出 | MB2 | UEFI 分区、启动项 |
| 加载内核失败 | UEFI | kernel/dtb 分区、启动项路径 |
| 卡在挂载根文件系统 | Kernel → RootFS | APP 分区、root= 参数、文件系统 |
把启动链路、串口日志与时间分析三者结合，就能把“启动失败”这个笼统现象，收敛到具体某一级固件或某一个分区上，从而选择正确的修复手段，而不是盲目重刷整机。