1. Bootloader 概述：嵌入式系统的“第一行代码”
大家好，我是你们这门课的老朋友。今天咱们聊聊 Bootloader——嵌入式系统里那个最不起眼、却又最关键的“看门人”。
说白了，Bootloader 就是系统上电后，CPU 执行的第一段用户程序。它负责把硬件从“混沌”状态拉起来，然后引导操作系统或应用固件进入正轨。没有它，你的 MCU 就是一坨硅片，啥也干不了。
1.1 Bootloader 在嵌入式系统中的角色
我经常跟团队里的新人说：Bootloader 就像机场的塔台。飞机（CPU）落地后，塔台要指挥它滑行到正确的停机位（内存地址），然后乘客（应用程序）才能下机。如果塔台指挥错了，飞机可能撞楼，系统直接死机。
具体来说，Bootloader 承担这几个关键任务：
- 硬件初始化：设置时钟、配置 GPIO、初始化 DDR/SRAM、使能 MMU/Cache。这些事必须在跳转主程序前做完。
- 内存布局规划：决定代码段、数据段、堆栈放在哪。我见过一个项目，因为 Bootloader 没正确配置 SDRAM 时序，导致主程序跑起来后随机死机——查了三天才发现是初始化顺序错了。
- 固件加载与校验：从 Flash、SD 卡、网络等介质读取固件，做 CRC/SHA 校验，确保固件没被篡改或损坏。
- 启动模式选择：支持正常启动、恢复模式、固件升级模式。比如长按某个按键进入 DFU 模式。
- 看门狗管理：在启动阶段喂狗，防止系统在初始化过程中被复位。
1.2 主流 Bootloader 对比
市面上的 Bootloader 方案不少，但真正经得起量产考验的，也就那么几个。我按自己的经验给大家梳理一下：
| 特性 | U-Boot | MCUboot | TinyBoot |
|---|---|---|---|
| 适用场景 | Linux 嵌入式系统（ARM/RISC-V/MIPS） | MCU 固件安全升级（Cortex-M/RISC-V） | 资源受限 MCU（8/16/32位） |
| 代码规模 | 100KB~500KB（含驱动） | 8KB~32KB | 2KB~8KB |
| 支持 Flash 分区 | 需手动配置 | 原生支持双分区/交换分区 | 极简单分区 |
| 安全特性 | 可选（需额外配置） | 内置签名验证、抗回滚 | 无 |
| 学习曲线 | 陡峭（配置复杂） | 中等（文档完善） | 平缓（代码简单） |
| 社区活跃度 | 极高（Denx 维护） | 高（Linux Foundation 旗下） | 低（个人项目为主） |
我个人习惯这样选型：
- 跑 Linux 的板子，无脑上 U-Boot。它虽然臃肿，但驱动全、社区大，遇到问题好搜。
- 做 IoT 设备、需要 OTA 安全升级的 MCU 项目，首选 MCUboot。它把签名验证、双分区回滚都封装好了，省心。
- 如果 MCU 只有 8KB Flash、2KB RAM，那就自己写个 TinyBoot 级别的 loader，或者用芯片原厂提供的 boot 代码改一改。
1.3 Bootloader 的核心工作流程
不管用哪个 Bootloader，它的启动流程都大同小异。我画了一张图，把关键步骤串起来：
你想想看，这个流程里每一步都可能出问题。比如硬件初始化顺序错了，外设可能无法正常工作；启动模式检测逻辑写反了，正常启动进了升级模式，用户拿到设备一脸懵。
我记得有一次调试一个量产项目，Bootloader 里检测升级按键的 GPIO 配置错了，导致设备一上电就进入 DFU 模式。客户反馈说“你们的设备怎么插电就死机”。后来发现是 GPIO 内部上拉没使能，电平状态不稳定。从那以后，我写 GPIO 检测逻辑一定会加去抖和默认状态处理。
1.4 为什么你需要自己写 Bootloader？
有人可能会问：既然有 U-Boot、MCUboot 这些现成的，为什么还要自己写？
我的回答是：现成的 Bootloader 解决的是通用问题，而你的产品往往有特殊需求。比如：
- 你的 Flash 分区布局很特殊，需要支持多个固件镜像并行存储。
- 你的安全要求极高，需要自定义加密算法和签名验证流程。
- 你的 MCU 资源太紧张，MCUboot 都嫌大。
- 你需要支持非标准的启动介质，比如 SPI NAND、QSPI Flash。
说白了，理解 Bootloader 的架构设计，不是为了让你重复造轮子，而是让你在需要定制时，知道从哪里下手、怎么避坑。