1. Bootloader 基础概念：它到底是什么？
做嵌入式开发这么多年，我见过不少同事一上来就急着写应用层代码，结果板子一上电就跑飞了。为什么？因为压根没搞懂 Bootloader 在干什么。今天咱们就把这个基础打牢。
什么是 Bootloader？
说白了，Bootloader 就是芯片上电后第一个跑的程序。它不像你的业务代码那样处理传感器数据或控制电机，它的任务很简单——把真正的应用程序加载到内存里，然后跳转过去执行。
我习惯把它比作「电脑的 BIOS」。你按下电源键，BIOS 先自检、找硬盘、然后引导操作系统。Bootloader 干的也是类似的活，只不过它面对的是嵌入式 MCU 或 MPU。
核心定义：Bootloader 是一段固化在非易失性存储器（如 Flash）中的启动代码，负责初始化硬件、验证固件完整性、加载并跳转到主应用程序。
Bootloader 在嵌入式系统中的作用
你想想看，如果没有 Bootloader，芯片上电后直接跑应用代码，那万一应用代码写错了、或者升级过程中断电了，板子不就变砖了吗？Bootloader 就是那道「安全防线」。
具体来说，它干这几件事：
- 硬件初始化——设置时钟、配置内存控制器、初始化串口等外设。我记得第一次调 STM32 的 Bootloader，忘了初始化 PLL，结果串口死活打印不出东西，查了整整一下午。
- 固件验证——检查应用程序的 CRC 校验、签名或版本号。如果发现固件损坏，就进入恢复模式等待新固件。
- 固件升级——通过 UART、SPI、I2C、USB、以太网甚至无线方式接收新固件，写入 Flash。
- 跳转执行——一切就绪后，跳转到应用程序的入口地址。
我的习惯：在 Bootloader 里加一个「强制升级」的 GPIO 检测。上电时如果检测到某个引脚被拉低，就停留在 Bootloader 模式等待升级。这个技巧救过我不少次板子。
常见 Bootloader 类型
市面上的 Bootloader 种类不少，但真正用得多的就那么几个。我按使用场景给你梳理一下：
| 名称 | 适用平台 | 特点 | 我个人的评价 |
|---|---|---|---|
| U-Boot | ARM、RISC-V、x86 等（Linux 生态） | 功能强大，支持网络、文件系统、多种启动方式 | Linux 嵌入式开发绕不开的 Bootloader，但配置复杂，新手容易懵 |
| MCUBoot | ARM Cortex-M、RISC-V（RTOS 生态） | 轻量级，支持签名验证、回滚、多镜像 | 我最近几个项目都在用，开源、稳定、文档也不错 |
| 厂商自带 Bootloader | STM32、NXP、TI 等 MCU | 固化在 ROM 里，出厂就有，通常只支持串口/DFU | 适合快速验证，但灵活性差，升级协议不开放 |
| 自定义 Bootloader | 任何平台 | 完全按需定制，体积小、功能精准 | 如果你对安全性和升级流程有特殊要求，这是最佳选择 |
避坑提醒：我曾经在一个项目里直接用了厂商自带的 Bootloader，结果客户要求支持加密升级和版本回滚，厂商的协议根本不开放这些功能。最后只能重写一个自定义 Bootloader，工期翻了一倍。选型时一定要想清楚未来需求。
Bootloader 的启动流程
为了让你更直观地理解，我画了一张流程图。这张图我每次带新人时都会拿出来讲：
这张图里最关键的分支就是「检测升级触发条件」。我习惯的做法是：上电后先检查 GPIO 电平，再检查固件头部的升级标志位，最后检查应用区的 CRC。只要有一个条件满足，就进入升级流程。
Bootloader 与应用程序的内存布局
很多新手搞不清 Bootloader 和应用程序在 Flash 里怎么放。我直接给你一个典型布局：
Flash 地址空间（以 1MB Flash 为例）
0x0800_0000 ┌──────────────────────────────┐
│ Bootloader (64KB) │
│ - 中断向量表 │
│ - 启动代码 │
│ - 升级协议栈 │
0x0801_0000 ├──────────────────────────────┤
│ 应用程序 (896KB) │
│ - 中断向量表（偏移） │
│ - 业务代码 │
│ - 固件版本/CRC 信息 │
0x080F_FFFF └──────────────────────────────┘关键点：应用程序的中断向量表必须偏移！否则中断来了会跳到 Bootloader 的向量表里，程序直接跑飞。我见过有人忘了设 SCB->VTOR，查了三天才找到原因。
选型建议
最后说说怎么选。我个人总结了一个简单的判断逻辑：
- 跑 Linux 的板子——别想了，U-Boot 是事实标准。虽然学习曲线陡，但社区资源丰富，遇到问题基本都能搜到答案。
- 跑 RTOS 的 MCU 项目——优先考虑 MCUBoot。它支持签名验证、多镜像管理、回滚机制，而且和 Zephyr、Mynewt 等 RTOS 深度集成。
- 小批量或原型验证——用厂商自带的 Bootloader 就够了，省时省力。但量产前一定要评估升级安全性。
- 有特殊安全需求——比如军工、医疗、车规，那就老老实实写自定义 Bootloader。加密算法、安全存储、防回滚都得自己掌控。
曾经踩过的坑：有个项目我图省事，直接拿厂商 Bootloader 做量产。结果客户要求 OTA 升级，厂商的 Bootloader 只支持串口。最后硬着头皮在应用层实现了 OTA 接收，再调用 Bootloader 的串口升级接口，代码写得跟屎山一样。从那以后，我每个项目都会提前问清楚：未来要不要 OTA？要不要加密？要不要回滚？
嗯，Bootloader 的基础概念就聊到这儿。记住一句话：Bootloader 不是应用代码的附属品，它是整个系统的「守门员」。守好了，后面怎么折腾都行；守不好，板子变砖就是分分钟的事。