1. Bootloader 概述：嵌入式系统的“第一行代码”
大家好，我是你们这门课的老朋友。咱们今天聊聊 Bootloader。
说白了，Bootloader 就是嵌入式系统上电后，CPU 执行的第一段正经程序。它不像你的应用代码那样跑业务逻辑，它的任务很简单——把系统从“死寂”状态带到“活蹦乱跳”的状态。
我刚开始做嵌入式那会儿，总觉得 Bootloader 是个可有可无的东西。直到有一次，产品量产了 5000 台，结果有 200 台死活起不来。查了三天，发现是 Flash 里存的应用程序校验码被烧录工具写错了位置。嗯，从那以后，我再也不敢轻视 Bootloader 了。
1.1 什么是 Bootloader？
Bootloader，直译就是“引导加载程序”。它通常存放在非易失性存储器（比如 Flash、EEPROM）的起始地址。芯片复位后，CPU 从复位向量指向的地址开始执行，那里就是 Bootloader 的入口。
它的核心职责就三个：
- 初始化硬件——把时钟、内存、外设这些基础资源准备好
- 加载应用程序——从 Flash、SD 卡、网络等介质把真正的应用代码搬进 RAM
- 跳转执行——把 CPU 控制权交给应用程序
你想想看，如果没有 Bootloader，芯片上电后 CPU 都不知道该干什么。它就像一把钥匙，帮你打开系统的大门。
核心概念：Bootloader 是嵌入式系统的“第一段代码”，它负责从硬件复位到应用程序启动之间的所有过渡工作。
1.2 Bootloader 在嵌入式系统中的角色
Bootloader 的角色，我习惯用三个词概括：初始化者、搬运工、守护者。
初始化者
芯片上电时，寄存器都是默认值。时钟可能跑在内部低速振荡器上，内存控制器还没配置，外设接口也没初始化。Bootloader 要做的第一件事，就是把 CPU 主频提上去，把 SDRAM 初始化好，把堆栈指针设置正确。没有这一步，后面的代码根本跑不起来。
我在一个 STM32 项目里遇到过，Bootloader 里忘了配置 Flash 等待周期，结果 CPU 跑到 72MHz 时直接从 Flash 读出了乱码。系统偶尔启动成功，偶尔死机。查了整整两天才找到原因——说白了就是时序没对齐。
搬运工
应用程序通常存储在 Flash 或外部存储器里。Bootloader 需要把这些代码从存储介质搬到 RAM 中，或者直接在 Flash 里跳转执行。对于需要从 SD 卡或网络升级的设备，Bootloader 还得实现文件系统解析或网络协议栈。
守护者
这是 Bootloader 最容易被忽视的角色。量产烧录时，Bootloader 要校验应用程序的完整性；运行时升级时，Bootloader 要保证即使升级失败，系统还能回滚到上一个可用版本。说白了，它就是系统的最后一道防线。
个人经验：我建议你在 Bootloader 里至少保留一个“安全启动模式”。当应用程序校验失败时，Bootloader 不要直接死机，而是进入一个等待固件升级的状态。这个设计救过我无数次。
1.3 常见 Bootloader 方案对比
市面上的 Bootloader 方案不少，我挑几个典型的说说。
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 芯片内置 BootROM | MCU、SoC 出厂自带 | 无需额外开发，稳定可靠 | 功能固定，无法定制 |
| U-Boot | ARM Linux、嵌入式 Linux | 功能强大，支持网络/文件系统 | 体积大，复杂度高 |
| MCU 自研 Bootloader | STM32、GD32、NXP 等 MCU | 轻量灵活，可定制升级策略 | 开发工作量大，需自行调试 |
| MCUBoot | Zephyr、Mynewt 等 RTOS | 开源，支持签名/加密/回滚 | 依赖 RTOS 生态 |
| TI SBL / X-Loader | TI 平台（OMAP、Sitara） | 与 TI 芯片深度绑定 | 平台局限性大 |
我个人最常用的是 MCU 自研 Bootloader 和 MCUBoot。前者适合小资源、高定制场景；后者适合需要安全升级的 RTOS 项目。
举个例子，我之前做一个智能电表项目，Flash 只有 128KB，RAM 只有 32KB。U-Boot 根本塞不进去，MCUBoot 又依赖 RTOS。最后我手写了一个不到 4KB 的 Bootloader，只实现了串口升级和 CRC 校验。够用就好，别贪多。
避坑指南：我曾经在一个项目里直接拿芯片内置的 BootROM 做量产烧录，结果发现它不支持自定义加密算法。客户要求固件必须 AES 加密传输，内置 BootROM 根本做不到。最后只能硬着头皮加了一个二级 Bootloader。所以，选方案前一定要搞清楚你的升级和烧录需求。
1.4 Bootloader 的核心工作流程
不管哪种方案，Bootloader 的执行流程都大同小异。我画了一张图，帮你理清思路。
这张图展示的是最通用的流程。实际项目中，你可能会在“检测启动模式”这一步加入更多判断条件，比如：
- 检测某个 GPIO 引脚电平（按住按键进入升级）
- 检测 Flash 中某个标志位（上次升级失败标记）
- 检测串口/网络是否有升级请求（超时则正常启动）
我个人习惯在 Bootloader 里加一个“超时等待”机制。上电后先等 500ms，如果收到升级指令就进升级模式，否则直接跳转应用程序。这样既不影响正常启动速度，又给升级留了窗口。
1.5 本章小结
Bootloader 是嵌入式系统的基石。它不复杂，但很重要。选方案时别盲目追求功能全，够用就好。开发时多想想异常情况——升级失败怎么办？校验不通过怎么办？这些才是 Bootloader 真正考验功底的地方。