3. IGX软件栈与系统启动链路
NVIDIA IGX平台的软件栈并非“上电即进系统”的黑盒，而是一条由固件、引导程序、内核、根文件系统和容器运行时逐级交接的启动链。理解这条链路的每一级“谁把控制权交给谁、依赖什么介质、失败时停在哪里”，是定位启动类故障的基础。IGX Orin开发者套件与量产模组的启动路径基本一致，差别主要在于引导介质（eMMC、NVMe、USB、网络）和是否启用安全启动。
启动链的六个阶段
从按下电源到容器内应用开始运行，控制权依次经过以下阶段：
- BootROM：固化在芯片内的只读代码，上电复位后最先执行。它读取启动模式引脚（strap）决定从哪个介质加载下一级引导程序，并完成最基础的DRAM初始化。BootROM不可修改，因此它决定了“能不能找到引导介质”这一最底层问题。
- Bootloader（引导加载程序）：IGX使用UEFI固件配合U-Boot/EDK II引导链。它负责初始化更完整的DDR、时钟、存储控制器，加载并校验内核镜像与设备树（DTB），最后跳转到内核入口。
- UEFI：提供标准化的固件接口，管理启动项（BootOrder）、变量存储和引导设备枚举。在IGX上，UEFI还承担安全启动的镜像验签职责。
- Kernel（内核）：解压后接管硬件，加载驱动、挂载根文件系统、启动init进程（PID 1）。
- Rootfs（根文件系统）：提供用户空间工具、库和系统服务，通常来自eMMC/NVMe分区或网络挂载。
- Container Runtime（容器运行时）：在IGX上通常是containerd配合NVIDIA Container Toolkit，负责拉取镜像、挂载GPU设备节点、启动容器化应用。
这六个阶段形成一条严格的依赖链：前一级失败，后一级根本不会被执行。因此排障的第一步永远是“确定当前停在哪一级”，而不是盲目重刷系统。
逐级交接的介质与依赖
BootROM阶段不依赖任何外部存储，它只认启动模式引脚。IGX模组上通常有BOOT_MODE[3:0]引脚，量产板通过电阻上下拉固定为从eMMC或QSPI启动；开发者套件则可能保留拨码开关，允许切换到USB恢复模式。如果引脚状态错误，BootROM会去错误的介质找引导程序，表现为“上电无任何串口输出”或“反复复位”。
Bootloader阶段开始依赖存储介质。U-Boot会打印DDR容量、存储设备枚举结果和分区表。此时应重点观察：DDR训练是否通过、eMMC/NVMe是否被识别、引导分区（通常是mmcblk0p1或nvme0n1p1）是否可读。若DDR训练失败，日志会停在“DRAM init”附近；若介质未识别，则看不到分区列表。
UEFI阶段的核心是启动项管理。IGX使用UEFI变量保存BootOrder，启动项指向\EFI\BOOT\BOOTAA64.EFI或厂商定制的引导程序。安全启动开启时，UEFI会用预置的PK/KEK/db密钥验证引导程序签名，验签失败会直接拒绝执行并记录事件。这一阶段的典型故障是“刷了非签名镜像后无法启动”。
Kernel阶段依赖设备树（DTB）与内核命令行（cmdline）。DTB描述硬件拓扑，cmdline指定根文件系统位置，例如root=/dev/nvme0n1p2 rootwait rw。若DTB与模组型号不匹配，会出现驱动probe失败或外设不可用；若cmdline中的根分区UUID错误，内核会报“VFS: Unable to mount root fs”。
Rootfs阶段由init进程接管。systemd会按依赖顺序启动服务，任何关键服务失败都可能让系统停在emergency mode。此时应检查分区是否完整挂载、文件系统是否损坏（可用fsck修复）、以及/etc/fstab中的UUID是否与实际分区一致。
Container Runtime是最后一环。containerd启动后，NVIDIA Container Toolkit通过nvidia-container-runtime把GPU设备节点、驱动库和CUDA兼容层注入容器。若容器启动失败，常见原因是镜像架构不匹配（arm64 vs amd64）、GPU设备节点未挂载、或nvidia-container-cli版本与驱动不兼容。
实操：用串口日志定位启动失败
IGX调试串口通常为115200 8N1。上电后应立即捕获完整日志，而不是只看最后几行。下面是一段示例日志片段（属于教学示例，非实测结果）：
[0000.000] BootROM: boot mode = eMMC
[0000.120] BootROM: loading BL2 from mmc0
[0001.340] BL2: DDR init OK, 32GB
[0002.100] U-Boot: mmc0 detected, 64GB
[0002.450] U-Boot: reading boot.scr
[0003.010] UEFI: BootOrder = 0001,0002
[0003.220] UEFI: Secure Boot enabled, verifying...
[0003.500] UEFI: signature check FAILED
[0003.510] UEFI: boot aborted
这段日志明确指向UEFI安全启动验签失败。处理方式不是重刷整个系统，而是确认当前镜像是否使用正确的签名密钥，或临时关闭安全启动进行验证。若日志停在“DDR init”之前，则应检查供电和启动模式引脚；若停在“reading boot.scr”，则应检查引导分区是否损坏。
启动检查点速查表
| 阶段 | 关键依赖 | 典型失败现象 | 优先检查 |
|---|---|---|---|
| BootROM | 启动模式引脚、供电 | 无串口输出、反复复位 | BOOT_MODE引脚、电源轨 |
| Bootloader | DDR、存储介质 | 卡在DDR init或介质枚举 | DDR训练日志、eMMC/NVMe识别 |
| UEFI | BootOrder、安全启动密钥 | 验签失败、无启动项 | PK/KEK/db、BootOrder变量 |
| Kernel | DTB、cmdline | Kernel panic、驱动probe失败 | DTB型号、root=参数 |
| Rootfs | 分区UUID、文件系统 | mount失败、emergency mode | fstab、fsck、分区表 |
| Runtime | 镜像、GPU设备节点 | 容器启动失败、GPU不可见 | 镜像架构、nvidia-container-cli |
掌握这条启动链的关键，不在于记住每个阶段的代码细节，而在于建立“控制权交接点”的意识：每一级都有明确的输入（介质、镜像、配置）和输出（下一级入口）。当系统启动失败时，先通过串口日志确定最后成功执行的阶段，再针对该阶段的依赖项逐一排查，就能把模糊的“起不来”转化为可操作的检查点。