1. Bootloader 概述：嵌入式系统的“第一行代码”
大家好，我是你们的讲师。今天咱们聊聊 Bootloader。说白了，它就是嵌入式系统上电后执行的第一段程序。你想想看，CPU 一上电，PC 指针指向一个固定地址，比如 0x00000000，那里放的就是 Bootloader。
我刚开始做嵌入式那会儿，总觉得 Bootloader 就是个“跳板”，把内核加载起来就完事了。后来踩的坑多了才发现——Bootloader 是硬件调试的第一道关卡。它要是跑不起来，后面的 Linux 内核、文件系统全是空中楼阁。
核心认知：Bootloader 不是操作系统的一部分，它是硬件初始化和系统启动的“总指挥”。没有它，你的嵌入式设备就是一块砖。
1.1 什么是 Bootloader？
Bootloader，直译就是“引导加载程序”。它的工作分两阶段：
- 第一阶段（汇编阶段）：初始化 CPU、关闭看门狗、设置时钟、初始化 DDR。这段代码通常用汇编写，跟硬件绑得死死的。
- 第二阶段（C 语言阶段）：初始化串口、网卡、Flash，然后从存储介质（NAND、eMMC、SD 卡）里把操作系统内核加载到内存，最后跳过去执行。
我习惯把 Bootloader 比作“嵌入式系统的 BIOS”。但跟 PC 的 BIOS 不一样，Bootloader 更灵活，也更“裸”——它直接面对寄存器，没有任何操作系统帮你兜底。
我的经验：调试 Bootloader 时，串口是最可靠的“眼睛”。我每次做新板子，第一件事就是确保串口能打印出字符。串口不亮，后面全是盲调。
1.2 Bootloader 在嵌入式系统中的角色
Bootloader 的角色可以归纳为三点：
| 角色 | 具体职责 | 为什么重要 |
|---|---|---|
| 硬件初始化 | 设置时钟、PLL、DDR 时序、中断向量表 | 硬件上电后处于“混沌”状态，必须由 Bootloader 梳理清楚 |
| 系统加载 | 从 Flash/网络/串口读取内核镜像，校验后加载到内存 | 没有这一步，操作系统连影子都没有 |
| 调试与恢复 | 提供命令行接口，支持内存读写、Flash 擦写、网络下载 | 板子起不来时，这是唯一的“救命稻草” |
我记得有一次，客户板子上的 DDR 时序参数配错了，内核一加载就死机。我就是在 U-Boot 命令行里，用 md 命令读内存，发现数据全是乱的，才定位到问题。你看，Bootloader 的调试角色有多关键。
1.3 常见 Bootloader 方案对比
市面上主流的 Bootloader 方案有三个：U-Boot、Barebox、Coreboot。我挨个说说我的使用感受。
1.3.1 U-Boot（Universal Bootloader）
U-Boot 是嵌入式领域的“老大哥”。支持架构最全——ARM、x86、RISC-V、MIPS 都能跑。社区活跃，资料多，遇到问题基本能搜到答案。
但 U-Boot 也有缺点：代码量大，编译慢，配置复杂。我刚开始用的时候，光 make menuconfig 里的选项就能看花眼。
适用场景：产品级项目、多平台支持、需要网络启动和复杂分区管理的场景。
1.3.2 Barebox
Barebox 是从 U-Boot 分支出来的，但设计理念更“现代”。它借鉴了 Linux 内核的驱动模型，代码结构清晰，POSIX 接口更友好。我个人挺喜欢 Barebox 的设备树支持——比 U-Boot 的 fdt 命令好用多了。
不过 Barebox 的社区规模小，支持的板子没 U-Boot 多。如果你用的是冷门 SoC，可能得自己移植。
我的建议：如果你团队里有 Linux 内核开发经验的人，Barebox 上手会很快。它的 Kconfig 和驱动框架跟内核几乎一样。
1.3.3 Coreboot
Coreboot 主要面向 x86 平台，目标是“极速启动”。它只做最必要的硬件初始化，然后就把控制权交给 payload（比如 SeaBIOS、UEFI、Linux 内核）。启动速度可以做到几百毫秒。
但 Coreboot 的硬件适配门槛高——你得懂 x86 的南北桥、SMBus、ACPI 这些东西。我当年调一块 Intel 的板子，光看 datasheet 就花了两周。
避坑指南：Coreboot 对显卡初始化支持有限。如果你需要显示输出，建议配合 SeaBIOS 或 UEFI payload 使用。我曾经在这上面栽过跟头——板子启动飞快，但屏幕一直黑着。
1.4 三种方案对比一览
| 特性 | U-Boot | Barebox | Coreboot |
|---|---|---|---|
| 主要架构 | ARM、x86、RISC-V、MIPS | ARM、x86、MIPS | x86（为主）、ARM（实验性） |
| 代码规模 | 大（~1M 行） | 中（~300K 行） | 小（~200K 行） |
| 启动速度 | 中等（2-5 秒） | 中等（2-4 秒） | 极快（<1 秒） |
| 社区活跃度 | 高 | 中 | 中 |
| 学习曲线 | 陡峭 | 中等 | 陡峭（需 x86 背景） |
| 调试能力 | 强（命令行丰富） | 强（类 Linux shell） | 弱（依赖 payload） |
1.5 Bootloader 启动流程总览
下面这张图是我自己总结的 Bootloader 典型启动流程。不管用哪个方案，核心步骤都差不多：
1.6 如何选择 Bootloader？
这个问题没有标准答案。我一般按下面几个维度来选：
- 硬件平台：ARM 平台首选 U-Boot，x86 平台看 Coreboot，想尝鲜可以试 Barebox。
- 团队经验：团队熟悉 Linux 内核？Barebox 上手快。团队做过单片机？U-Boot 资料多，遇到问题好找人问。
- 启动速度要求：消费类产品要求 1 秒内开机？Coreboot 是首选。工业设备不差那几秒？U-Boot 更稳妥。
- 调试需求：开发阶段需要频繁调试硬件？U-Boot 的命令行最丰富。产品稳定后想精简代码？Barebox 的模块化设计更好裁剪。
我的忠告：别为了“炫技”选一个团队没人懂的 Bootloader。我见过一个项目，选了 Barebox 但团队只会 U-Boot，结果移植花了三个月，得不偿失。选方案，先看人，再看技术。
1.7 本章小结
这一章我们聊了 Bootloader 是什么、它在系统里的角色，以及三种主流方案的对比。说白了，Bootloader 就是嵌入式系统的“开门人”——门开得好不好，直接决定后面系统跑得顺不顺。