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

关注

原创最新推荐文章于 2026-09-26 09:02:57 发布 411 阅读 AI 写同款· GEO 优化 ›

NVIDIA JETSON AGX XAVIER 刷机后黑屏问题排查指南本文针对NVIDIA JETSON AGX XAVIER刷机后出现黑屏的常见问题，提供了一套从硬件连接到软件层面的系统性排查指南。文章详细讲解了如何通过检查HDMI线缆与转接器、使用串口控制台获取启动日志、调整显示配置及选择合适JetPack版本等方法，帮助开发者快速定位并解决黑屏故障，确保设备正常启动并投入AI开发工作。阅读详情

📺 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 Kernel

NVIDIA 当前 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 → Linux

Jetson 新平台更像：

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 适配，就会清晰很多。

收录于

NVIDIA

标签

#mybatis #音视频 #c语言 #开发语言 #udp

Jetson orin更改uefi启动logo sudo ./flash.sh -r -k A_cpu-bootloader 载板参数（根据你实际硬件来写） mmcblk0p1。以上是nvidia官方给的流程，切记这些操作不能在jetson设备上，否则后面编译不过，小编已经替大家测试过了。pc机是X86主机，ubuntu18.04和ubuntu20.04的设备均可以，本次使用ubuntu18.04。sudo ./flash,sh 载板参数（实际硬件来写）mmcblk0p1。然后开始刷机可以全部覆盖也可以单独刷引导程序。阅读详情

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

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

一、先把几个概念讲清楚

1. U-Boot 是什么？

2. UEFI 是什么？

3. CBoot 又是什么？

二、Jetson 真的完全没用过 U-Boot 吗？

三、Jetson 的启动链和普通 ARM 板不一样

四、为什么 U-Boot 在 Jetson 新平台上的价值下降了？

五、NVIDIA 为什么选择 UEFI？

1. UEFI 更适合标准化启动

2. UEFI 更适合安全启动

3. UEFI 更适合 OTA 和 A/B 冗余

4. UEFI 更适合 GRUB / EFI 生态

5. UEFI 更适合“边缘服务器化”的 Jetson

六、UEFI 替代的是谁？不是 MB1 / MB2，而是 CBoot

老的理解

新的理解

七、对比一下 U-Boot、CBoot、UEFI

八、这对 Jetson Orin / Thor Bring-up 有什么影响？

九、用 Thor / Orin 的启动链再串一次

十、为什么这个变化很重要？

十一、最终总结

相关推荐