NVIDIA Jetson 为什么选择 UEFI，而不是 U-Boot？

B站 嵌入式孙老师博主个人介绍博主书籍-京东购买链接*Yocto项目实战教程加博主微信进技术交流群jerrydevNVIDIA Jetson 为什么选择 UEFI而不是 U-Boot很多做嵌入式 Linux 的同学看到 Jetson Orin、Jetson Thor 的启动结构时第一反应可能是为什么 NVIDIA Jetson 不像 RK、i.MX、Allwinner 那样使用 U-Boot为什么新版本 Jetson 变成了 UEFI那之前的 CBoot 又是什么这个问题表面上是在问UEFI 和 U-Boot 的区别本质上其实是在问Jetson 到底是一块普通 ARM 开发板还是一个面向量产、安全、OTA、AI 边缘计算的复杂计算平台答案也很直接Jetson 并不是不能用 U-Boot而是从 Orin / Thor 这一代开始NVIDIA 官方 BSP 更适合使用 UEFI 来统一管理启动、安全、OTA、多启动设备和量产维护。一、先把几个概念讲清楚1. U-Boot 是什么U-Boot 是一个具体的开源 bootloader 项目。在很多嵌入式 Linux 平台中启动链路通常是BootROM ↓ SPL / TPL ↓ U-Boot ↓ Linux Kernel ↓ RootFS比如 RK3568、RK3588、i.MX6、i.MX8、Allwinner、STM32MP1 等平台很多都是这个思路。U-Boot 负责初始化部分硬件 选择启动设备 读取 kernel / dtb / initrd 传递 bootargs 启动 Linux kernel所以在传统嵌入式 Linux 里U-Boot 是非常重要的一环。2. UEFI 是什么UEFI 不是某一个具体 bootloader 程序而是一套标准。更准确地说UEFI Unified Extensible Firmware Interface 统一可扩展固件接口它定义的是操作系统启动之前平台固件应该如何工作 平台固件和操作系统之间应该如何交互 启动项、启动顺序、安全启动、EFI 应用应该如何管理可以类比理解类型标准具体实现编程语言C 语言标准GCC / Clang操作系统接口POSIXLinux / BSD启动固件UEFIEDK2 / NVIDIA Jetson UEFI嵌入式 bootloader无统一强标准U-Boot所以U-Boot 是一个具体 bootloader UEFI 是一套启动固件标准 Jetson UEFI 是 NVIDIA 基于 EDK2 做出来的具体 UEFI 固件NVIDIA 文档中也明确说明UEFI 是一种行业规范用来描述平台固件和操作系统之间的标准接口并且在 Jetson Linux 中替代 CBoot 作为 CPUBL也就是 CPU bootloader。3. CBoot 又是什么CBoot 是 NVIDIA 之前在 Jetson 平台上使用的自家 bootloader。可以简单理解为CBoot NVIDIA 老版本 Jetson 使用的后级 bootloader在早期 Jetson Linux rel-32 时代Jetson 平台大量使用 CBoot。到了 Jetson Linux rel-34 之后NVIDIA 开始使用 UEFI 替代 CBoot。NVIDIA 官方文档明确写到CBoot was used in the prior rel-32 release, and is now replaced with UEFI starting with rel-34 release and onward。也就是说Jetson 的历史大致可以这样看早期 Jetson BootROM → TegraBoot / CBoot / U-Boot → Linux Jetson rel-32 BootROM → MB1 / MB2 / CBoot → Linux Jetson rel-34 之后 BootROM → MB1 / MB2 → UEFI → Linux二、Jetson 真的完全没用过 U-Boot 吗不是。Jetson 不是从来没有用过 U-Boot。在较早的 Jetson Nano、TX1、TX2 时代NVIDIA L4T 文档里明确写到U-Boot 是部分受支持平台上的默认 bootloader。旧版 flashing 文档中也提到Jetson Nano、Jetson TX1 需要 U-BootJetson TX2 默认使用 U-Boot并由 U-Boot 从 rootfs 的/boot/Image加载 Linux kernel。所以不能简单说Jetson 从来不用 U-Boot更准确的说法应该是早期 Jetson 支持过 U-Boot 中间阶段大量使用 NVIDIA 自家的 CBoot Orin / Thor 这类新平台官方主启动链改成 UEFI三、Jetson 的启动链和普通 ARM 板不一样普通 ARM Linux 板子经常是BootROM ↓ SPL ↓ U-Boot ↓ Linux但 Jetson Orin 这类平台的官方启动结构是BootROM ↓ PSCROM ↓ MB1 ↓ MB2 ↓ UEFI ↓ Linux KernelNVIDIA 当前 Jetson Boot Architecture 文档中Orin 系列启动流明确包含 BootROM、PSCROM、MB1、MB2、UEFI 等阶段Thor 文档中也继续采用 NVIDIA 自己的多阶段安全启动结构。这说明一个重要事实Jetson 的 bootloader 不是一个单独的u-boot.bin而是一整套启动体系。它包括BootROM MB1 MB2 BCT 安全固件 UEFI L4TLauncher / GRUB kernel / dtb / initrd rootfs四、为什么 U-Boot 在 Jetson 新平台上的价值下降了因为 Jetson 上很多传统上由 U-Boot 负责的事情已经被 NVIDIA 的前级固件体系接管了。比如DDR 初始化 PMIC 配置 pinmux 配置 GPIO 初始状态 安全认证 fuse 检查 启动链校验 firmware 加载 RCM / flash 流程这些工作不是从 UEFI 才开始做也不是 U-Boot 能完全替代的。以 Orin 为例MB1 是 NVIDIA 拥有的二进制组件用户可以通过 MB1-BCT 对它的行为进行平台化配置MB1 会做早期初始化、加载 firmware、配置 PMIC、创建 memory carveout并加载下一级 bootloader。所以在 Jetson 上即使引入 U-Boot它也只能放在后级BootROM ↓ MB1 ↓ MB2 ↓ U-Boot ↓ Linux但是这样做的价值并不大因为前面最关键的 NVIDIA 平台私有启动、安全、烧录、BCT、firmware 加载流程仍然绕不开 MB1 / MB2。五、NVIDIA 为什么选择 UEFI1. UEFI 更适合标准化启动Jetson 越来越不像传统开发板而更像一台 ARM64 AI 计算机。它要支持eMMC 启动 SD 启动 NVMe 启动 USB 启动 PXE 网络启动 HTTP Boot GRUB EFI Application 多启动项 启动顺序管理这些正是 UEFI 擅长的领域。在 Jetson UEFI 文档中NVIDIA 提供了 Boot Order Selection并支持通过DefaultBootPriority配置启动设备顺序例如DefaultBootPriority { data usb,nvme,emmc,sd,ufs; locked; };也就是说UEFI 不是简单地把 kernel 拉起来而是提供了更标准的 Boot Manager 机制。对于一块量产平台来说这很重要。因为产品可能有不同启动介质开发阶段USB / NVMe 量产阶段eMMC / UFS 维护阶段Recovery / Network Boot 升级阶段A/B Slot / OTA如果都通过一套标准启动框架管理平台维护会更清晰。2. UEFI 更适合安全启动Jetson 面向机器人、工业视觉、自动驾驶、边缘 AI、医疗设备、安防、储能等场景这些场景不只是要求能启动 Linux更要求启动链可信 固件不可被篡改 kernel 不可被替换 rootfs 可加密 支持 OP-TEE 支持 fTPM 支持 Secure Boot 支持防回滚NVIDIA Secure Boot 文档中说明Jetson 的 Root of Trust 从 NVIDIA SoC fuse 开始用来认证 boot code到 bootloader 之后当前 bootloader也就是 UEFI会使用 UEFI Security Keys 机制继续认证后续 payload。可以理解为两段安全链NVIDIA SoC 安全链 BootROM → MB1 → MB2 → UEFI UEFI 安全链 UEFI → EFI Application / GRUB / Kernel / initrd如果使用 U-BootNVIDIA 需要额外维护 U-Boot 和整套安全链的深度适配。而使用 UEFI可以更自然地复用标准化的 Secure Boot、EFI 应用签名、Boot Manager、UEFI variables 等机制。3. UEFI 更适合 OTA 和 A/B 冗余量产产品最怕什么不是第一次能不能启动而是升级失败怎么办 断电升级怎么办 kernel 损坏怎么办 rootfs A 启不起来怎么办 如何回退到 B bootloader 怎么保证冗余Jetson 的 bootloader 更新和冗余机制不是只改一个环境变量这么简单。NVIDIA 的 Update and Redundancy 文档中提到boot slot 由 BootROM 选择MB1 和 MB2 会使用 slot number。这说明 Jetson 的 A/B 冗余不是单纯 Linux 层逻辑而是深入到启动链前级。UEFI 放在 MB2 后面可以更好地承接Boot slot Rootfs A/B Boot chain status Kernel / DTB selection Recovery boot OTA rollback对于 NVIDIA 来说用 UEFI 统一维护这部分比在 U-Boot 上重新适配一套完整机制更合理。4. UEFI 更适合 GRUB / EFI 生态Jetson 默认 OS Loader 是 L4TLauncher。在较新的 Jetson UEFI 文档中NVIDIA 明确说明 L4TLauncher 是 UEFI 的默认 OS Loader路径通常对应EFI/BOOT/BOOTAA64.efi同时Jetson 也支持使用 GRUB 启动。文档中说明如需使用 GRUB需要挂载 ESP 分区备份默认的BOOTAA64.efi然后安装grub-efi-arm64-bin等组件。这让 Jetson 的启动方式更接近标准 ARM64 计算平台UEFI ↓ BOOTAA64.efi / L4TLauncher / GRUB ↓ extlinux.conf / grub.cfg ↓ Image DTB initrd ↓ Linux这对于 Ubuntu、Yocto、自定义 rootfs、多系统启动、NVMe 启动都更友好。5. UEFI 更适合“边缘服务器化”的 Jetson过去我们看嵌入式板子更多关注能不能启动 Linux 网口能不能通 串口有没有 log 设备树对不对但现在的 Jetson Orin / Thor 更像边缘 AI 服务器。它关心的是多启动介质 安全启动 远程升级 OTA 回滚 NVMe rootfs PXE 网络启动 磁盘加密 OP-TEE fTPM 启动 logo 量产烧录 版本冗余 平台配置这些能力如果全部堆在 U-Boot 里当然也不是完全做不到但 NVIDIA 需要承担很高的长期维护成本。UEFI 的优势在于标准化 生态成熟 安全模型清晰 和 ARM64 Server / PC 启动模型接近 更适合复杂平台维护所以 NVIDIA 选择 UEFI不是因为 U-Boot 不行而是因为 Jetson 的平台定位变了。六、UEFI 替代的是谁不是 MB1 / MB2而是 CBoot这一点很容易混淆。UEFI 并不是替代 BootROM、MB1、MB2。它替代的是后级 CPU bootloader也就是过去的 CBoot。可以这样画老的理解BootROM ↓ MB1 / MB2 ↓ CBoot ↓ Linux新的理解BootROM ↓ MB1 / MB2 ↓ UEFI ↓ L4TLauncher / GRUB ↓ Linux所以 UEFI 不是把整个启动链都替换了而是把 CBoot 这一层换成了更标准、更开放、更适合复杂启动场景的固件框架。七、对比一下 U-Boot、CBoot、UEFI项目U-BootCBootUEFI本质开源 bootloader 项目NVIDIA 自家 bootloader启动固件标准常见场景传统嵌入式 Linux老版本 JetsonPC、服务器、ARM64 平台、新 Jetson是否标准化嵌入式生态标准事实但不是 UEFI 规范NVIDIA 私有行业规范可定制性很强依赖 NVIDIA BSP可改但固件体系更复杂安全启动可支持但需平台适配NVIDIA 自家体系标准 Secure Boot 生态多启动设备支持但平台相关支持有限Boot Manager 天然支持GRUB / EFI app非原生非原生原生支持Jetson 新平台不是官方主链路被替代官方主链路一句话总结U-Boot 更像传统嵌入式 bootloader CBoot 是 NVIDIA 过去的私有 bootloader UEFI 是 NVIDIA 新平台选择的标准化启动固件体系八、这对 Jetson Orin / Thor Bring-up 有什么影响如果你做过 RK、i.MX再来看 Jetson很容易用错思路。在 RK 平台上你可能重点看u-boot defconfig u-boot dts SPL bootcmd extlinux.conf但在 Jetson Orin / Thor 上应该换成这个思路早期硬件初始化 MB1-BCT / MB2-BCT pinmux / GPIO / pad voltage pinmux 配置表 / MB1 配置 PMIC / 上电时序 PMIC Configuration / BCT PCIe / USB / UPHY UPHY Lane Configuration 启动设备顺序 UEFI BootOrder / DefaultBootPriority 启动模式 L4TLauncher Boot Mode kernel / dtb / initrd extlinux.conf / boot 分区 / kernel-dtb 分区 rootfs APP 分区 / NVMe / eMMC / UFS / Yocto rootfs 安全启动 fuse / PKC / SBK / UEFI Secure Boot Keys也就是说Jetson 的适配重点不是问U-Boot 在哪里而是应该问MB1-BCT 配对了吗 pinmux 对了吗 PMIC 时序对了吗 UEFI boot order 对了吗 kernel dtb 选对了吗 extlinux.conf 对了吗 rootfs 分区对了吗这才是 Jetson bring-up 的核心。九、用 Thor / Orin 的启动链再串一次以现代 Jetson 平台来理解可以简化成上电 ↓ BootROM ↓ NVIDIA 安全启动前级 ↓ MB1 ↓ MB2 ↓ UEFI ↓ L4TLauncher / GRUB ↓ Linux Kernel DTB initrd ↓ RootFS其中BootROM 芯片内部固化代码负责最早期启动和安全根 MB1 早期平台初始化读取 BCT配置部分硬件 MB2 继续初始化加载后级 bootloader参与 flashing / RCM / cold boot UEFI 标准化后级启动固件管理启动顺序、启动模式、EFI app、安全启动 L4TLauncher / GRUB OS Loader负责加载 kernel / dtb / initrd Linux Kernel 真正进入操作系统这和传统嵌入式 Linux 的区别非常明显。传统板子经常是BootROM → SPL → U-Boot → LinuxJetson 新平台更像BootROM → NVIDIA 前级固件 → UEFI → OS Loader → Linux十、为什么这个变化很重要因为这代表 Jetson 的定位变化了。早期 Jetson 更像开发板能跑 Linux 能跑 CUDA 能接摄像头 能做 AI demo现在 Jetson Orin / Thor 更像量产级边缘 AI 平台机器人 工业视觉 自动驾驶 边缘服务器 多传感器融合 高可靠 OTA 安全启动 设备加密 长期维护当平台从“开发板”走向“量产计算平台”启动系统就不能只追求简单而要追求标准化 安全性 可维护性 可升级性 可恢复性 生态兼容性这就是 NVIDIA 从 CBoot 转向 UEFI 的核心原因。十一、最终总结NVIDIA Jetson 为什么选择 UEFI而不是继续走 U-Boot可以总结成 6 点1. Jetson 的早期启动链高度平台私有MB1 / MB2 / BCT 无法被 U-Boot 简单替代。 2. U-Boot 更适合传统嵌入式 Linux而 Orin / Thor 更像标准 ARM64 AI 计算平台。 3. UEFI 天然支持 Boot Manager、BootOrder、EFI Application、GRUB、PXE、NVMe、USB 等标准启动能力。 4. Jetson 的 Secure Boot、OP-TEE、fTPM、磁盘加密、A/B、OTA 等能力更适合和 UEFI 体系结合。 5. CBoot 是 NVIDIA 旧版本私有 bootloaderrel-34 之后被 UEFI 替代属于平台演进而不是简单换名字。 6. NVIDIA 选择 UEFI本质是为了量产、安全、维护、标准化和复杂启动场景而不是因为 U-Boot 不够好。最关键的一句话是Jetson 不是不用 U-Boot而是新一代 Jetson 已经不再是普通 ARM 开发板 它需要的是一套更标准、更安全、更适合量产维护的启动固件体系。所以对于 Jetson Orin / Thor 开发者来说最实用的理解不是纠结为什么没有 U-Boot而是建立新的启动认知BootROM / MB1 / MB2 负责 NVIDIA 平台早期启动和安全链 UEFI 负责标准化启动管理 L4TLauncher / GRUB 负责加载 OS extlinux.conf / kernel dtb / initrd 负责进入 Linux理解了这条链路再看 Jetson 的刷机、BCT、pinmux、UEFI、OTA、rootfs、Yocto 适配就会清晰很多。