📺B站 嵌入式孙老师：博主个人介绍
📘博主书籍-京东购买链接*：Yocto项目实战教程
📘加博主微信，进技术交流群：jerrydev
NVIDIA 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 |
| 操作系统接口 | POSIX | Linux / BSD |
| 启动固件 | UEFI | EDK2 / 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-Boot，Jetson 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 为什么选择 UEFI？
1. 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-Boot，NVIDIA 需要额外维护 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-Boot | CBoot | UEFI |
|---|---|---|---|
| 本质 | 开源 bootloader 项目 | NVIDIA 自家 bootloader | 启动固件标准 |
| 常见场景 | 传统嵌入式 Linux | 老版本 Jetson | PC、服务器、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 旧版本私有 bootloader，rel-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 适配，就会清晰很多。
