这是一个非常关键的设计选择。简单来说，U-Boot运行在EL2是因为它是非安全世界的引导加载程序，而EL2是非安全世界的最高特权级。

这背后的逻辑主要包含以下三点：

1. 非安全世界的“天花板”：EL2

首先需要明确一点：EL3只属于安全世界。

• BL31 (EL3)：是安全监控器，负责世界切换。
• U-Boot (BL33)：属于非安全世界。

在非安全世界中，特权级的层级是：

• EL2 (Hypervisor)：最高特权，用于虚拟化。
• EL1 (OS Kernel)：操作系统内核运行层级。

当BL31通过eret将CPU交给U-Boot时，SCR寄存器的NS位会被置为1（Non-secure）。此时，CPU不能进入EL3（除非再次触发SMC），所以在非安全世界里，EL2就是它能获得的最高特权级。

2. 为虚拟化做准备

这是U-Boot运行在EL2的核心价值。

• 场景：现代嵌入式设备经常需要运行虚拟化环境（如车载系统同时运行Android和Linux，或者KVM虚拟化）。
• 需求：虚拟机监控器需要运行在EL2。
• U-Boot的角色：U-Boot作为引导程序，它需要有能力加载Hypervisor镜像，并对其进行初始化。
• 特权要求：如果U-Boot运行在EL1，它就没有权限去配置EL2的寄存器（如配置Stage-2转换表、虚拟中断控制器等）。只有运行在EL2，U-Boot才能完整地初始化虚拟化环境，然后再降级到EL1去启动客户机操作系统。

3. 启动Linux内核的灵活性

Linux内核对启动时的异常等级有要求，U-Boot运行在EL2可以提供最大的灵活性：

• 情况A：不需要虚拟化
  U-Boot (EL2) 可以在启动Linux内核前，主动执行eret降级到EL1，然后跳转到Linux。这是传统非虚拟化场景的标准流程。
• 情况B：需要虚拟化
  U-Boot (EL2) 可以直接将控制权交给运行在EL2的Hypervisor（如Xen或KVM），或者启动支持虚拟化的Linux内核（现代Linux内核可以在EL2启动，并自己开启虚拟化功能）。

反之，如果U-Boot运行在EL1：
它将无法启动运行在EL2的Hypervisor，也失去了配置虚拟化硬件的能力。

总结对比

一句话总结：
U-Boot运行在EL2，是因为作为非安全世界的引导程序，它需要**最高的权限（EL2）**来初始化虚拟化环境或启动Hypervisor；如果不需要虚拟化，它也有能力自行降级到EL1去启动普通内核。这体现了“由高向低启动容易，由低向高启动不可能”的原则。