一、U-Boot概述：从历史到启动流程
大家好，我是你们的讲师。今天咱们聊聊U-Boot——这个嵌入式世界里几乎绕不开的“老伙计”。
说实话，我入行那会儿，U-Boot还不叫U-Boot，叫PPCBoot。那时候的嵌入式Linux生态远没有现在这么成熟，一个能用的bootloader简直就是宝贝。后来PPCBoot和ARMBoot合并，才成了我们今天用的U-Boot。嗯，这段历史挺有意思的，我待会儿细说。
1.1 U-Boot的历史：一个开源项目的进化
U-Boot的全称是“Universal Boot Loader”，通用引导加载程序。它最早起源于2000年左右，由德国工程师Wolfgang Denx主导开发。
关键时间节点：
| 年份 | 事件 |
|---|---|
| 1999年 | PPCBoot诞生，专为PowerPC架构设计 |
| 2002年 | PPCBoot与ARMBoot合并，正式更名为U-Boot |
| 2008年 | U-Boot加入对MIPS、x86等架构的支持 |
| 2010年后 | 引入设备树（Device Tree）、FIT镜像等现代特性 |
我个人觉得，U-Boot能活到现在，核心原因就两个：一是它支持几乎你能想到的所有CPU架构（ARM、x86、RISC-V、MIPS、PowerPC……），二是它的社区非常活跃。我在项目中遇到过客户非要换芯片平台，结果U-Boot改改配置就能跑，省了大把时间。
核心观点：U-Boot不是“一个”bootloader，而是一个“bootloader框架”。你拿到手的U-Boot，其实是针对你特定板子的定制版本。
1.2 U-Boot的作用：它到底在干什么？
说白了，U-Boot就干三件事：
- 初始化硬件——把CPU、内存、串口、网卡这些外设“唤醒”
- 加载操作系统——从Flash、SD卡、网络等介质把内核镜像读到内存
- 传递启动参数——告诉内核“你该从哪里挂载根文件系统”
你想想看，如果没有U-Boot，CPU上电后直接跑Linux内核行不行？理论上可以，但实际不行。因为Linux内核假设硬件已经处于一个“可用”的状态——比如内存控制器已经初始化好了，时钟已经稳定了。而这些工作，恰恰是U-Boot来做的。
一个小技巧：我习惯在U-Boot里加一个“硬件自检”功能，上电后先跑一遍内存测试。曾经有块板子内存虚焊，U-Boot直接报错，省了我半天调试时间。
1.3 嵌入式系统的启动流程：从按下电源到进入Shell
好，咱们来画一张图，把整个启动流程串起来。这张图我手绘过无数次，每次给新人讲都靠它。
这张图里，我特别想强调一下SPL这个阶段。为什么要有SPL？因为有些芯片的片上SRAM只有几十KB，根本放不下完整的U-Boot。所以先跑一个极简的SPL，把DDR初始化好，再把完整的U-Boot从Flash搬到内存里。
我曾经在一个项目里踩过坑：SPL编译出来太大了，超过了芯片的SRAM大小。结果板子死活起不来，串口一点输出都没有。后来查了半天才发现是SPL里加了一个不必要的驱动。嗯，从那以后我每次编译SPL都会先看一眼size。
1.4 启动流程的详细拆解
咱们把上面那张图展开，看看每个阶段具体干了什么。
阶段1：上电复位
CPU上电后，PC指针指向一个固定的地址。这个地址通常映射到芯片内部的ROM（只读存储器）。
阶段2：BootROM
芯片厂商固化在ROM里的代码。它会做最基础的初始化——比如设置CPU模式、关闭看门狗、初始化时钟。然后根据启动引脚的电平，决定从NAND Flash、SD卡还是UART加载下一级代码。
注意：BootROM是只读的，你改不了。如果BootROM有bug，只能换芯片批次。我遇到过一款芯片的BootROM在读取某些NAND Flash时会丢数据，最后只能换Flash型号。
阶段3：SPL
SPL是U-Boot源码里编译出来的一个小镜像。它的主要任务：
- 初始化DDR控制器
- 初始化存储介质（比如eMMC、NAND）
- 从存储介质加载完整的U-Boot到DDR
- 跳转到U-Boot入口
阶段4：U-Boot完整版
这时候U-Boot已经跑在DDR里了，可以做更复杂的事情：
- 初始化网卡、USB、显示等外设
- 解析环境变量（比如bootargs、bootcmd）
- 提供命令行交互（你可以敲命令）
- 加载并启动内核
阶段5：加载内核
U-Boot根据环境变量里的配置，从指定位置读取内核镜像（zImage或Image），放到内存指定地址，然后跳转过去。同时通过设备树（DTB）把硬件信息传给内核。
一个实用的经验：我习惯在U-Boot里加一个“启动计数”功能。每次启动成功就加1，连续失败3次就自动进入恢复模式。这个功能用环境变量就能实现，代码不超过20行，但救过我好几次命。
1.5 为什么你需要理解这些？
你可能会问：“我只是想写个打包脚本，了解启动流程干嘛？”
原因很简单：打包脚本的本质，就是把U-Boot镜像、内核镜像、设备树、根文件系统按照正确的格式和位置组织起来。如果你不知道SPL和U-Boot的关系，不知道内核应该放在哪个偏移地址，那打包出来的固件大概率是跑不起来的。
我见过太多新人，拿着别人的打包脚本改改就用，结果板子起不来，又不知道怎么调试。最后发现是镜像的加载地址写错了。嗯，这种问题其实完全可以避免——只要你理解了启动流程。
我的建议：刚开始学的时候，别急着写脚本。先拿一块开发板，用串口线连上，看着U-Boot的启动日志一行一行地读。把每个阶段打印的信息和硬件行为对应起来。这个习惯我一直保持到现在。
好了，这一章的内容就到这里。U-Boot的历史、作用和启动流程，是后续所有打包脚本的基础。下一章我们会深入U-Boot的源码结构，看看那些打包脚本到底在操作哪些文件。
可可精品资料库