1. Bootloader基础概念
什么是Bootloader
Bootloader，说白了就是系统上电后第一个跑起来的程序。它比你的主应用代码更早获得CPU控制权，负责完成一些「脏活累活」——比如初始化硬件、配置时钟、搬运固件，最后才把控制权交给真正的应用程序。
我刚开始做嵌入式时，总觉得Bootloader可有可无。直到有一次，产品量产时发现固件烧录效率太低，每台设备都要开盖用JTAG刷写，那叫一个痛苦。后来加了Bootloader，直接通过串口升级，生产效率翻了好几倍。嗯，从那以后我再也不敢小看Bootloader了。
你想想看，Bootloader就像是一个「引路人」。它自己不干正事，但它知道怎么把正事交给对的人。没有它，你的MCU上电后只能执行固定地址的代码，想升级？想切换启动模式？门都没有。
Bootloader在嵌入式系统中的作用
Bootloader的核心作用，我总结为以下四点：
- 硬件初始化：时钟、内存、外设等基础配置。这些工作通常由Bootloader完成，APP直接拿来用就行。
- 固件升级：这是Bootloader最常用的功能。通过串口、CAN、以太网等接口接收新固件，写入Flash，然后跳转执行。
- 启动引导：根据条件选择启动哪个APP。比如检测到按键按下就进入升级模式，否则正常启动。
- 安全校验：检查固件的完整性、合法性。防止被篡改的固件运行，这在工业、汽车领域尤其重要。
我个人习惯：在设计Bootloader时，会预留一个「强制升级」的入口。比如上电时检测某个GPIO电平，或者检测Flash中某个标志位。这样即使APP跑飞了，也能通过硬件手段强制进入升级模式，不至于变砖。
我在项目中遇到过最典型的场景：某款设备部署在偏远地区，OTA升级到一半断电了。重启后APP校验失败，Bootloader检测到固件不完整，自动回滚到上一个可用版本。这就是Bootloader的「保命」能力。
常见的Bootloader方案对比
市面上常见的Bootloader方案，我整理了一个表格，方便你对比：
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| MCU原厂Bootloader | 简单产品、快速原型 | 开箱即用、稳定可靠 | 功能固定、难以定制 |
| 自研Bootloader | 量产产品、特殊需求 | 完全可控、可定制 | 开发周期长、调试复杂 |
| 开源Bootloader（如MCUboot） | 中大型项目、需要OTA | 功能完善、社区活跃 | 学习成本高、资源占用大 |
| RTOS自带Bootloader | 使用RTOS的项目 | 与系统集成度高 | 依赖特定RTOS |
为什么会有这么多方案？因为不同项目对Bootloader的要求天差地别。比如一个简单的智能灯泡，用原厂Bootloader就够了。但一个汽车ECU，必须支持安全启动、固件加密、多分区管理，那就得自研或者用MCUboot这种成熟的方案。
避坑指南：我曾经在一个项目里直接用了某款MCU的原厂Bootloader，结果发现它不支持双分区备份。OTA升级一旦失败，设备就变砖了。后来我换成了自研方案，加了A/B分区回滚机制，才彻底解决这个问题。所以选方案时，一定要先想清楚你的升级策略。
我个人比较推荐的做法是：
- 小项目（< 64KB Flash）：用原厂Bootloader，省事
- 中项目（64KB - 512KB Flash）：自研一个轻量级Bootloader，只做升级和跳转
- 大项目（> 512KB Flash）：上MCUboot，功能全、社区支持好
这里有个关键点：Bootloader的大小直接影响你的Flash分区规划。我见过有人把Bootloader写得比APP还大，结果Flash不够用，只能重新设计。所以写Bootloader时，心里要有个数——它只是引路人，不是主角。
注意：Bootloader和APP的链接脚本一定要分开。我见过新手把两个工程的链接脚本混在一起，结果跳转时地址全乱了，程序直接跑飞。记住，Bootloader和APP是两个独立的固件，各自有各自的起始地址和中断向量表。
好了，关于Bootloader的基础概念就聊到这里。下一章我们会深入讲解Bootloader与APP之间的跳转机制，包括中断向量表的重映射、栈指针的切换、以及如何确保跳转后系统稳定运行。这些都是实际项目中容易踩坑的地方，我会结合自己的经验一一说明。