4、TPL阶段详解：TPL的引入背景、TPL与SPL的区别、TPL的典型应用场景

好，咱们接着聊U-Boot的启动流程。前面几章我们把SPL（Secondary Program Loader）聊透了，但你可能在阅读某些新款SoC的启动日志时，会看到一个陌生的名字——TPL。我第一次看到它的时候也愣了一下，心想：怎么又多了一个Loader？

其实TPL的出现，说白了就是为了解决一个很现实的问题：SPL在某些场景下，已经快被撑爆了。嗯，这里要注意，不是SPL不好，而是硬件越来越复杂了。

咱们先回忆一下SPL的定位。SPL是固化在ROM里的BootROM加载进来的第一阶段引导程序，它的核心任务就两个：初始化DDR内存，然后加载U-Boot proper。听起来很简单对吧？

但问题来了。现在的SoC越来越复杂，尤其是那些带DDR初始化、带安全启动、带DDR训练、带电源管理序列的芯片。SPL的代码体积被限制得很死——通常只有16KB到64KB。你想想看，一个DDR训练算法可能就要吃掉几十KB，再加上安全校验、时钟配置、外设初始化……SPL很快就塞不下了。

我在项目中遇到过一款车规级芯片，它的SPL空间只有32KB。但DDR训练代码就占了28KB，剩下的4KB连个像样的日志打印都塞不进去。当时我们团队讨论了好几种方案，最后决定引入TPL来分担压力。

核心矛盾：SPL的尺寸限制 vs. 硬件初始化代码的膨胀需求。

TPL的引入，本质上就是把SPL的职责拆成两段：TPL负责最底层、最吃空间的硬件初始化（比如DDR训练），SPL则负责加载U-Boot proper。

很多人问我：TPL和SPL到底有啥区别？不都是Loader吗？

嗯，从代码结构上看，它们确实很像——都是基于U-Boot的代码框架，都支持设备树，都支持命令行（虽然很少用）。但它们的定位和职责完全不同。我习惯用下面这张表来对比：

你看，TPL其实比SPL更“底层”。它做的事情，SPL以前也做，但SPL做不下了，就拆出来给TPL。说白了，TPL就是SPL的“减负方案”。

那什么情况下你会用到TPL呢？我总结了三个最常见的场景：

这是最典型的情况。有些高端SoC的DDR控制器支持多通道、多速率、多颗粒类型，训练算法动辄几十KB。比如我调试过的一款FPGA+ARM的异构芯片，它的DDR训练代码有48KB，而SPL总共才64KB。如果不引入TPL，SPL连个日志缓冲区都分配不出来。

解决方案：TPL负责DDR训练，训练完成后把DDR配置参数传给SPL。SPL直接使用已经初始化好的DDR，加载U-Boot proper。

有些芯片要求启动过程必须逐级签名验证。BootROM验证TPL的签名，TPL验证SPL的签名，SPL再验证U-Boot proper的签名。每一级都只做一件事：验证+加载下一级。这样安全等级更高，但代价就是多了一级启动延迟。

我曾经调试过一个车规级项目，客户要求启动链必须满足ASIL-B等级。我们不得不把安全校验逻辑从SPL拆到TPL里，因为SPL既要校验又要加载，代码复杂度太高，评审过不了。

有些SoC在启动时需要执行复杂的电源上电序列——比如先给CPU核心供电，再给DDR供电，再给外设供电。这些序列通常需要等待特定时间、检查电压状态。如果把这些逻辑塞进SPL，SPL的代码量会急剧膨胀。

TPL可以专门处理这些电源管理任务，完成后才让SPL接手。嗯，这里要注意，TPL运行时的功耗通常很低，因为它只用了最基本的硬件资源。

我的建议：如果你在移植U-Boot时发现SPL的代码体积超过限制，或者SPL的初始化逻辑越来越复杂，不妨考虑引入TPL。虽然多了一级启动，但换来的是代码结构的清晰和可维护性。

下面这张图是我画的TPL启动流程，你可以直观地看到TPL在整个启动链中的位置：

曾经踩过的坑：我曾经在一个项目中，TPL和SPL使用了不同的DDR配置参数。TPL训练完DDR后，SPL又用自己的参数重新配置了一遍，结果导致系统崩溃。后来我们统一了配置结构体，TPL把训练结果通过一个固定地址传给SPL，问题才解决。

所以我的建议是：TPL和SPL之间一定要约定好数据传递的接口，别各搞各的。

最后，我分享一个实用的判断方法。你在移植U-Boot时，可以问自己三个问题：

如果以上任意一个问题的答案是“是”，那你就该考虑引入TPL了。如果三个都是“否”，那老老实实用SPL就好，别给自己找麻烦。

嗯，关于TPL就聊这么多。记住一句话：TPL不是必须的，但当你需要它的时候，它就是你最好的朋友。