3、Bootloader的核心功能：硬件初始化、引导加载、启动参数传递、故障恢复
Bootloader 到底在干什么？说白了，它就是个「系统引路人」。芯片上电后，第一个跑起来的代码就是它。它的任务很明确：把硬件拉起来，找到操作系统，把它请进内存，然后功成身退。
我这些年移植过不下十种 Bootloader，从裸机汇编到 U-Boot，从 NOR Flash 到 NAND，踩过的坑不少。今天就把这四大核心功能掰开揉碎了讲清楚。
3.1 硬件初始化：从零搭建运行环境
芯片刚上电时，大部分外设都处于复位状态。时钟没配、内存没初始化、中断向量表还是乱的。这时候你连个 printf 都跑不了。硬件初始化，就是给系统搭好「地基」。
3.1.1 最小系统初始化
这部分通常用汇编写，因为 C 语言运行时环境还没准备好。我习惯把它分成三步：
- 关看门狗 —— 很多芯片默认看门狗是开的，不关掉的话，初始化到一半就被复位了。
- 初始化系统时钟 —— 从内部低速振荡器切换到外部晶振，再倍频到目标频率。
- 初始化堆栈指针 —— 给 C 语言运行准备好栈空间。
核心原则： 硬件初始化要「够用就好」。Bootloader 不需要把所有外设都配一遍，只要把 CPU、内存、串口、存储控制器这几个关键模块拉起来就行。配得越多，启动越慢，出错的概率也越大。
3.1.2 内存控制器与 DDR 初始化
这是硬件初始化里最头疼的部分。DDR 的时序参数、阻抗匹配、刷新周期，任何一个配错了，系统都跑不起来。
我曾经在一个项目中，DDR 初始化代码在开发板上跑得好好的，换到量产板就随机死机。查了两天才发现，是 PCB 走线长度差导致时序偏移。后来我在初始化代码里加了 DDR 训练流程，每次启动时自动校准时序，问题才解决。
我的经验： DDR 初始化完成后，一定要做读写校验。写一个已知模式（比如 0xAA55AA55），读回来对比。如果出错，直接进入故障恢复流程，别硬着头皮往下跑。
3.1.3 存储控制器与串口初始化
存储控制器负责访问 Flash、SD 卡等存储介质。串口则是 Bootloader 的「生命线」—— 调试信息、交互命令都靠它。
串口初始化其实很简单：配波特率、数据位、停止位、校验位。但我建议把波特率设成可配置的，方便调试。U-Boot 里用环境变量 baudrate 来控制，这个设计很实用。
/* 串口初始化示例（简化版） */
void uart_init(int baudrate) {
/* 使能 UART 时钟 */
rcu_periph_clock_enable(RCU_USART0);
/* 配置 GPIO 复用功能 */
gpio_af_set(GPIOA, GPIO_AF_7, GPIO_PIN_9 | GPIO_PIN_10);
/* 配置波特率 */
usart_baudrate_set(USART0, baudrate);
/* 使能 UART */
usart_enable(USART0);
}3.2 引导加载：把内核请进内存
硬件初始化完了，接下来就是找操作系统。引导加载的核心就两件事：从哪里读、读到哪。
3.2.1 存储介质读取
不同的存储介质，读取方式完全不同：
| 存储介质 | 读取方式 | 特点 |
|---|---|---|
| NOR Flash | 直接内存映射（XIP） | 可以像内存一样直接读，但写很慢 |
| NAND Flash | 页读取 + ECC 校验 | 容量大，但可能有坏块，需要纠错 |
| SD/eMMC | 块读取（SD/MMC 协议） | 速度快，但协议复杂 |
| SPI Flash | SPI 命令序列 | 引脚少，适合小容量 |
你想想看，如果从 NAND Flash 启动，Bootloader 必须自己实现 ECC 校验和坏块管理。内核镜像如果恰好存在坏块上，读出来就是错的。我遇到过这种情况，系统启动到一半就崩溃，查到最后发现是 NAND 坏块表没更新。
3.2.2 镜像校验
读进来的数据对不对？得校验。常用的校验方式有：
- CRC32 —— 速度快，适合校验完整性
- SHA256 —— 安全性高，适合校验合法性
- 签名验证 —— 用 RSA/ECDSA 验证镜像是否被篡改
注意： 校验失败时，不要直接死机。应该进入故障恢复模式，提示用户重新烧录或从备份分区启动。我见过有些 Bootloader 校验失败就直接 while(1) 死循环，连个错误信息都不给，这种设计太粗暴了。
3.3 启动参数传递：给内核递「小纸条」
内核启动时需要知道很多信息：内存大小、根文件系统位置、控制台设备、IP 地址……这些信息不能硬编码在内核里，否则换个板子就得重新编译内核。
Bootloader 通过 启动参数 把这些信息传给内核。在 ARM Linux 里，传统方式是 ATAG 列表，新方案是 设备树（DTB）。
3.3.1 ATAG 列表
ATAG 就是一个链表，每个节点包含一个标签和对应的数据。内核启动时从寄存器 R2 拿到 ATAG 列表的基地址，然后逐个解析。
/* ATAG 列表结构 */
struct tag {
struct tag_header hdr;
union {
struct tag_core core;
struct tag_mem32 mem;
struct tag_cmdline cmdline;
/* ... 其他类型 */
} u;
};
/* 示例：传递内存信息 */
struct tag *t = (struct tag *)0x100;
t->hdr.tag = ATAG_MEM;
t->hdr.size = sizeof(struct tag_mem32);
t->u.mem.start = 0x80000000;
t->u.mem.size = 0x10000000; /* 256MB */3.3.2 设备树（DTB）
设备树是现在的主流方案。它把硬件描述和内核代码分离开，同一份内核镜像可以跑在不同板子上，只要换 DTB 文件就行。
我个人更喜欢设备树的方式。ATAG 列表太死板，加一个新参数就得改内核代码。设备树灵活得多，而且 U-Boot 里可以直接用 fdt 命令修改设备树节点，调试起来很方便。
小技巧： 在 U-Boot 里可以用 fdt set 命令动态修改设备树。比如你想临时改一下内存大小，不用重新编译，直接敲命令就行。这在开发阶段特别有用。
3.4 故障恢复：最后的防线
系统总有出问题的时候。镜像损坏了、Flash 擦写失败了、DDR 校验没通过……这时候 Bootloader 不能直接摆烂，得想办法自救。
3.4.1 常见的故障场景
- 镜像校验失败 —— CRC 或签名不对
- 启动介质损坏 —— NAND 坏块、SD 卡损坏
- 配置参数错误 —— 启动参数被意外修改
- 升级中断 —— 烧录过程中掉电，导致镜像不完整
3.4.2 恢复策略
我一般会设计三级恢复机制：
- 自动回滚 —— 如果有备份分区，自动从备份分区启动
- 恢复模式 —— 进入一个最小化的交互环境，等待用户通过串口或网络重新烧录
- 出厂恢复 —— 如果前两级都失败了，从 ROM 里的出厂固件启动
关键设计： Bootloader 本身要有一个「安全区域」，这个区域在正常运行时是只读的，只有进入恢复模式后才能写入。这样即使升级过程中断，Bootloader 本身也不会被破坏，永远有自救的能力。
我曾经在一个产品上吃过亏。当时为了省 Flash 空间，把 Bootloader 和内核放在同一个分区，升级时一起擦写。结果有一次升级掉电，Bootloader 被擦了一半，板子彻底变砖。后来我学乖了，Bootloader 单独放一个分区，而且这个分区在正常模式下是写保护的。
3.5 核心功能关系图
下面这张图展示了四大核心功能之间的关系：
从图上可以看得很清楚：硬件初始化是第一步，它给后续所有操作提供了运行环境。引导加载和启动参数传递是并行关系，一个负责搬数据，一个负责传配置。故障恢复则像一张安全网，任何环节出问题都能兜底。
嗯，这四个功能说起来简单，但每个里面都有不少细节。尤其是硬件初始化里的 DDR 配置和故障恢复里的安全分区设计，稍不注意就会踩坑。后面几章我们会逐个深入，把每个功能的实现细节和移植要点都讲透。