U-Boot

原创于 2025-03-09 14:55:57 发布 · 936 阅读

CC 4.0 BY-SA版权

文章标签：

第一、启动设备的硬件特性

U-Boot的SPL阶段实现的策略布局，应该是跟SoC片上存储设备（SRAM、BootROM代码具体特性的实现）和片外启动介质设备（SD卡/eMMC/HyperFlash/FlexSPI NOR Flash/常规NOR Flash/nand Flash）的属性紧密相关。启动设备中有个典型的特性就是XIP特性（eXcute In Place）。

U-Boot的完全体形态通常运行在DDR里，或者非典型的HyperFlash这种XIP设备里，硬件资源不受限，不会给uboot实现其完全特性带来限制，因此不涉及。

执行XIP场景

BootROM直接在XIP启动设备上运行uboot的SPL，甚至是运行完全体的U-Boot形态。

执行非XIP场景

BootROM将uboot的SPL复制到片上SRAM内运行SPL。

# 关于XIP设备作为启动设备的情况

个人见解：1. 随机访问、支持直接总线； 2. 持久性存储设备；

为什么需要关心XIP术语？因为，他与uboot的启动过程有关系，这是典型场景，为此引出了许多关于存储设备的知识，如何使用它们，都有必要足够了解。

XIP存储设备不需要像非XIP存储设备那样需要执行复杂的过程，比如非XIP设备需要初始化存储控制器。所以XIP的访问更加简单，且兼容性更加高，尤其适合BootROM、uboot这种场景。XIP设备可直接执行uboot代码，但是仍然需要uboot的SPL部分代码，因为uboot的标准布局里，将代码从存储设备拷贝到DDR的这部分工作仍然属于SPL的核心职责之一。

即使非XIP设备也能用于BootROM启动uboot，但是需要提前初始化非XIP设备的控制器，且其内部存储数据不支持高速随机访问，需要复制到片上内存SRAM里运行，片上SRAM存储空间小，一般只能存放U-Boot的SPL部分。eMMC 虽为非 XIP 设备，但其接口协议标准化程度高，Boot ROM 可能内置 eMMC 控制器驱动，无需用户配置即可直接读取数据到 RAM。因此，BootROM对非XIP设备的支持情况，具体取决于SoC厂商某款特定芯片BootROM的具体适配支持情况。

所以，无论是XIP设备亦或非XIP设备，区别是BootROM的支持力度、uboot的SPL代码执行位置其他部分都是相同的。

- 非XIP设备需要多一步将SPL复制到片上SRAM内执行，而XIP设备直接运行SPL部分的代码；
- 因为虽然SRAM可以修改存储信息但空间小，XIP设备只读，都无法得到充足可修改的存储空间，所以这就是为什么uboot的SPL阶段必须包含将完全版的U-Boot复制到DDR这一功能。

这里是uboot官网的信息：

The main U-Boot binary may be too large to be loaded directly by the Boot ROM. This was the original driver for splitting up U-Boot into multiple boot stages.

U-Boot typically goes through the following boot phases where TPL, VPL, and SPL are optional. While many boards use SPL only few use TPL.

- TPL

Tertiary Program Loader. Very early init, as tiny as possible. This loads SPL (or VPL if enabled).

- VPL

Verifying Program Loader. Optional verification step, which can select one of several SPL binaries, if A/B verified boot is enabled. Implementation of the VPL logic is work-in-progress. For now it just boots into SPL.

- SPL

Secondary Program Loader. Sets up SDRAM and loads U-Boot proper. It may also load other firmware components.

- U-Boot

U-Boot proper. This is the only stage containing command. It also implements logic to load an operating system, e.g. via UEFI.

总结：主uboot（完全体版本）的镜像存储体量过大，对于非XIP启动设备（比如eMMC），无法加载到片上SRAM（存储空间不够）；对于XIP启动设备（比如NOR Flash），虽然有充足空间存储，但是无法他是只读属性，不支持变量，无法写入变量，所以也不能支持完全体的U-Boot，所以必然会启用大容量的DDR运行U-Boot的完全体（U-Boot proper版本）。其中初始化DDR并将U-Boot proper复制到DDR最后跳转到主U-Boot的是在U-Boot的SPL阶段执行的。所以，一般U-Boot的SPL版本与U-Boot完全体版本的执行设备不一样：U-Boot的SPL形态是在SoC片上BootROM指定的启动设备里直接（XIP）或间接（BootROM从非XIP设备复制SPL到SRAM）执行SPL，最后到U-Boot proper完全体版本在DDR上运行。

注意：至于STM32MP157d是否真的不在NOR Flash上运行uboot的SPL代码这个问题，目前答案还不太敢确定，需要进一步核实。当然可以将NOR Flash上的uboot-SPL部分复制到片上SRAM中运行，这是一种主流的说法，可能也更加适合Cortex-A7去运行代码，且可以修改变量。这种行为都是由STM32MP157d的BootROM固化代码的执行实现确定的。下面的说法是STM32MP157d可以直接在XIP启动设备（NOR Flash）上运行uboot的SPL，但是不能修改变量，还有其他编程限制比如代码重定位问题、访问延迟问题等，但是至少理论上是可行的。

总之，各种启动细节受限于多个方面：

1. 启动存储设备的属性：若启动设备的属性越牛逼，那么uboot的运行过程就能越简单；

1.1 是否支持XIP特性，支持的性能到达哪种程度；

2. SoC厂商的具体支持特性的实现

拓展：新的XIP启动介质设备

NXP i.MX RT系列跨界处理器：
该系列芯片支持从XIP的HyperFlash或FlexSPI NOR Flash直接运行完整BootLoader（非U-Boot SPL），但其启动流程与传统Linux SoC不同。