1. BootLoader 概述：嵌入式系统的“第一行代码”
大家好，我是你们这门课的老朋友。今天咱们聊聊 BootLoader——嵌入式系统里那个“看不见的守门人”。
很多刚入行的朋友觉得 BootLoader 就是一段启动代码，跑完就完事了。其实不然。我做了十几年固件，见过太多因为 BootLoader 没写好，整机变砖的案例。说白了，BootLoader 是系统上电后执行的第一段程序，它决定了你的设备能不能“活”起来。
1.1 什么是 BootLoader？
BootLoader，直译就是“引导加载器”。它是一段固化在非易失性存储器（比如 Flash、ROM）里的程序，负责在 CPU 复位后完成最基本的硬件初始化，然后加载并跳转到操作系统或应用程序。
你可以把它理解成“电脑的 BIOS + 启动菜单”。但嵌入式里的 BootLoader 更精简，也更贴近硬件。
核心定义：BootLoader 是嵌入式系统上电后第一个执行的软件实体，它负责从“裸金属”状态过渡到可运行操作系统的状态。
我个人习惯把 BootLoader 分成两个阶段：
- 第一阶段（汇编阶段）：设置异常向量表、初始化 CPU 寄存器、关闭看门狗、初始化内存控制器。这段代码通常用汇编写，因为这时候 C 语言运行时环境还没准备好。
- 第二阶段（C 语言阶段）：更复杂的硬件初始化（比如 Flash、网卡、串口）、检测启动介质、加载内核镜像、传递启动参数。这时候可以用 C 语言了，开发效率高很多。
嗯，这里要注意：有些 MCU（比如 Cortex-M 系列）的启动流程和 ARM9/A7 不太一样，但“先汇编后 C”这个思路是通用的。
1.2 BootLoader 在嵌入式系统中的作用
你想想看，一个嵌入式设备从按下电源到跑起业务逻辑，中间要经历多少步？BootLoader 就是那个“总导演”。
| 作用 | 具体说明 | 我踩过的坑 |
|---|---|---|
| 硬件初始化 | 设置时钟、配置 GPIO、初始化 DDR/Flash、使能 MMU/MPU | 有一次 DDR 时序参数配错了，系统跑起来随机死机，查了两天才发现是 BootLoader 里初始化顺序不对 |
| 启动介质管理 | 从 NAND、eMMC、SD 卡、SPI Flash 或网络加载内核 | NAND 的坏块管理没处理好，升级一次就变砖，后来老老实实加了 BBT（坏块表） |
| 系统引导 | 解析内核镜像格式（zImage、uImage、FIT）、设置启动参数、跳转到内核入口 | —— |
| 安全校验 | 验证镜像签名、校验哈希、解密固件（这是咱们这门课的重点） | 早期项目没做签名校验，被人在升级包塞了恶意代码，整批设备被远程控制 |
| 恢复与升级 | 提供串口/网络下载接口、支持双备份启动、失败回滚 | —— |
避坑指南：我曾经在一个量产项目里，BootLoader 的 DDR 初始化代码是从参考设计直接复制过来的。结果换了另一批 DDR 颗粒后，低温环境下频繁启动失败。后来发现是时序参数没按 datasheet 重新算。记住：BootLoader 里的硬件参数，一定要对着芯片手册逐项确认。
1.3 常见 BootLoader 类型
嵌入式世界里 BootLoader 种类不少，但真正广泛使用的就那么几个。我按应用场景给大家梳理一下。
1.3.1 按复杂度分类
- 单阶段 BootLoader：代码量极小（几百字节到几 KB），直接完成初始化并跳转。常见于 8 位/16 位 MCU，比如 STM8、PIC。我早期做 8051 项目时，BootLoader 就 128 字节，只够做串口下载。
- 两阶段 BootLoader：第一阶段（SPL）初始化最小系统，第二阶段（U-Boot SPL 之后的完整 U-Boot）做完整初始化。这是目前 ARM Linux 设备的主流方案。
- 多阶段 BootLoader：比如 Intel 的 Slim Bootloader，分多个阶段逐步建立执行环境，安全性更高，但复杂度也上去了。
1.3.2 按功能定位分类
| 类型 | 典型代表 | 适用场景 | 特点 |
|---|---|---|---|
| 通用型 | U-Boot | ARM/MIPS/RISC-V Linux 设备 | 功能最全，支持网络、文件系统、多种启动介质；但代码量大（几百 KB） |
| 轻量型 | Barebox、GRUB（嵌入式版） | 资源受限的 Linux 设备 | 比 U-Boot 精简，启动更快 |
| MCU 专用 | STM32 Bootloader、TI ROM Bootloader | 单片机产品 | 通常由芯片厂商提供，集成在 ROM 里，用户可自定义二次 Bootloader |
| 安全型 | TF-A（Trusted Firmware-A）、OP-TEE 中的 Boot | 需要安全启动的 ARMv8 设备 | 支持链式信任、安全世界/非安全世界切换 |
| 专有型 | RedBoot、LILO、vivi | 历史遗留项目或特定芯片 | 逐渐被 U-Boot 取代，但老项目里还能见到 |
我的建议：如果你做新产品选型，优先考虑 U-Boot。它生态最好，社区活跃，文档也多。但如果你做的是电池供电的 IoT 设备，U-Boot 可能太重了，可以考虑自己写一个精简的二次 Bootloader，只保留串口下载和 Flash 擦写功能。
1.4 BootLoader 的典型启动流程
为了让大家有个直观印象，我画了一张流程图。这是最经典的 ARM Linux 启动路径。
这张图里，我特意把“校验签名/哈希”标成了橙色。为什么？因为这是安全升级的核心环节。很多设备被攻击，就是在这个环节出了问题——要么没做校验，要么校验逻辑有漏洞。
1.5 为什么 BootLoader 安全升级这么重要？
你想想看，BootLoader 是系统里权限最高的代码。它运行在最高特权级（比如 ARM 的 SVC 模式或 EL3），能访问所有内存和外设。如果 BootLoader 被篡改，整个系统就沦陷了。
我见过最典型的攻击场景：攻击者通过串口或网络，向处于升级模式的 BootLoader 发送一个伪造的固件包。BootLoader 没做签名校验，直接写入 Flash。重启后，恶意代码就获得了系统控制权。
安全升级的核心目标：确保只有经过授权的、完整的、未被篡改的固件才能被 BootLoader 加载和执行。这通常通过数字签名、哈希校验、加密传输和回滚保护来实现。
后面的课程里，我会带大家一步步实现这些机制。从最简单的 CRC 校验，到完整的 RSA + AES 安全升级方案，咱们都会讲到。
1.6 本章小结
这一章咱们把 BootLoader 的底子打好了：
- 它是什么——系统上电后的第一段代码
- 它做什么——硬件初始化、加载内核、安全校验、恢复升级
- 它有哪些——从 U-Boot 到 MCU 自带 Bootloader，各有各的战场
我个人觉得，理解 BootLoader 最好的方式就是动手。找一块开发板，把 U-Boot 的源码下载下来，从 start.S 开始读，配合硬件手册看每一行汇编在干什么。当年我就是这么入门的，虽然过程痛苦，但收获巨大。