1. Bootloader 概述：它到底是什么？

说实话，我刚入行那会儿，对 Bootloader 的理解特别肤浅。觉得不就是一段上电后跑的小程序嘛，跳转到主程序就完事了。后来被现实狠狠教育了几次——有一次产品量产了，发现固件有 bug，但设备已经封在壳子里，没有 Bootloader，只能拆机用烧录器。那场面，别提多狼狈了。

所以今天咱们好好聊聊 Bootloader。你把它理解成「嵌入式系统的接生婆」就行——它负责把操作系统或者应用程序，从存储介质里请出来，然后交棒给它。

1.1 什么是 Bootloader？

Bootloader，直译就是「引导加载程序」。它是一段在系统上电或复位后，最先执行的代码。它的生命周期很短——完成初始化硬件、加载镜像、跳转执行后，它就功成身退了。

我习惯把 Bootloader 分成两个阶段：

• 第一阶段（Stage 1）：汇编写的，极简。初始化 CPU、关闭看门狗、设置时钟、初始化 DDR/SDRAM。这段代码通常放在片内 SRAM 或 ROM 里跑。
• 第二阶段（Stage 2）：C 语言写的，功能丰富。支持文件系统、网络协议、命令行交互。真正的「重活」都在这里。

为什么分两段？说白了，第一段太依赖硬件，用汇编更可控；第二段逻辑复杂，用 C 开发效率高。我在 STM32 上做过一个项目，第一段只有 200 行汇编，第二段写了 3000 多行 C，分工非常清晰。

1.2 Bootloader 在嵌入式系统中的作用

你想想看，一个嵌入式设备从按下电源键到开始干活，中间发生了什么？

1. 硬件初始化：CPU 复位后，时钟、内存、外设都还是「原始状态」。Bootloader 得先把它们配置好。
2. 镜像加载：从 Flash、SD 卡、网络或者串口，把真正的应用程序读到内存里。
3. 校验与安全：检查镜像的 CRC、签名，防止被篡改或者加载了损坏的固件。
4. 启动决策：判断是正常启动，还是进入升级模式、恢复模式。
5. 跳转执行：把 CPU 控制权交给应用程序。

Bootloader 还有一个隐藏作用——救命。设备变砖了？只要 Bootloader 还在，就能通过串口或网口重新烧录固件。没有 Bootloader，变砖就是真砖。

1.3 常见的 Bootloader 方案对比

市面上 Bootloader 方案不少，我挑几个主流的说说。每个我都实际用过，优缺点都是踩坑踩出来的。

方案	适用场景	优点	缺点
U-Boot	ARM、MIPS、RISC-V 等，Linux 系统	功能强大，支持网络/文件系统/命令行；社区活跃	体积大（几百 KB），复杂度高，新手难上手
Barebox	ARM、x86，Linux 系统	代码结构清晰，POSIX 风格 API，调试方便	生态不如 U-Boot，文档较少
MCUboot	MCU（STM32、nRF52 等），RTOS 或裸机	轻量（几 KB），支持安全启动和固件升级	功能单一，不支持网络
自研 Bootloader	资源受限的 MCU，或特殊硬件需求	完全可控，体积最小，无冗余功能	开发周期长，调试困难，bug 得自己扛

简单总结一下选型思路：

• 跑 Linux 的复杂 SoC → U-Boot 或 Barebox
• 资源紧张的 MCU → MCUboot 或 自研
• 需要安全启动、OTA 升级 → MCUboot
• 硬件特殊、没有现成方案 → 自研

1.4 Bootloader 的启动流程（核心框架）

下面这张图，是我自己画的一个通用 Bootloader 启动流程。不管用哪种方案，骨架都差不多。

这个流程里，有几个关键点我想强调一下：

• 汇编阶段越短越好。我见过有人把串口打印也写在汇编里，调试起来痛苦得要命。汇编只做不得不做的事，剩下的交给 C。
• 校验不能省。哪怕只是简单的 CRC16，也能避免加载了损坏的镜像导致死机。我在一个工业项目里，就是靠 CRC 校验发现 Flash 有个坏块，及时切换了备份区。
• 跳转前要清理现场。关闭中断、禁用 MMU、恢复默认异常向量表。不然应用程序一跑就崩。