4. Bootloader 与启动流程

Jetson Orin 的启动过程是一条由硬件信任根逐级向操作系统延伸的信任链。理解这条链路上每个阶段的职责、运行位置和可干预点，是 BSP 开发、定制启动介质、裁剪启动时间以及排查“上电无显示”“卡在 UEFI”“找不到根文件系统”等问题的前提。Orin 的启动阶段大致可划分为 BootROM → MB1 → MB2 → BPMP-FW → UEFI → c-boot → Linux Kernel，其中 MB1/MB2 属于 NVIDIA 专有的 Bootloader 组件，UEFI 与 c-boot 则承担了更接近通用平台的引导职责。

核心原理：信任链与阶段职责

BootROM 是固化在芯片内部的只读代码，上电后首先运行。它读取启动介质上的引导配置，验证并加载 MB1。MB1 运行在 BPMP 微控制器上，负责最基础的时钟、电源和引脚初始化，随后加载 MB2。MB2 运行在 CPU 上，完成 DRAM 初始化——这是整个启动流程中最关键的一步，因为后续所有代码都需要内存。DRAM 就绪后，MB2 加载 BPMP-FW 固件，由 BPMP 接管电源与时钟的运行时管理，再加载 UEFI。

UEFI 是通用可扩展固件接口，在 Orin 上承担设备枚举、引导设备选择、加载 c-boot 的职责。c-boot 是 NVIDIA 基于 U-Boot 定制的引导加载程序，负责加载 Linux 内核、设备树和 initrd，并把控制权交给内核。整条链路每一级都验证下一级的签名，形成从 BootROM 到内核的信任链。

方法流程：启动介质选择与配置

Orin 支持从 eMMC、NVMe、SD 卡以及网络/USB 恢复模式启动。启动顺序由 UEFI 的引导项和烧录时的配置共同决定。常见做法是把引导分区放在 eMMC，根文件系统放在 NVMe，以兼顾稳定性和性能。

# 查看当前引导项（在 UEFI Shell 或系统内）
efibootmgr -v

# 烧录时指定存储介质（flash.sh 示例）
sudo ./flash.sh jetson-orin-nano-devkit internal
sudo ./flash.sh jetson-orin-nano-devkit nvme0n1p1

# 从 NVMe 启动需先确认 UEFI 能枚举到该设备
# 串口日志中查找：BlockDevice / NVMe namespace

切换启动介质时，必须确认三件事：UEFI 能枚举到目标设备、目标设备上有有效的引导分区、引导分区中的内核与设备树匹配当前硬件。任何一环缺失都会导致启动停在 UEFI 或进入恢复模式。

案例场景：启动日志分析

假设一块 Orin 开发板上电后串口无输出，或输出停在某一行。此时应按阶段逐段排查。下表给出常见日志锚点与对应判断。

误区与复盘

• 误区一：认为换一块 NVMe 就能直接启动。实际上 UEFI 需要能枚举该设备，且引导分区必须存在，否则仍从 eMMC 启动。
• 误区二：忽略串口日志。Orin 启动问题绝大多数可以通过 115200 波特率的串口日志定位到具体阶段。
• 误区三：把 c-boot 当成 U-Boot 直接改。c-boot 是定制版本，修改引导参数应优先通过 UEFI 引导项或 extlinux.conf。
• 复盘要点：先确认供电与串口，再按 BootROM→MB1→MB2→UEFI→c-boot 的顺序逐段验证，最后检查内核与根文件系统。