3. Bootloader 核心功能解析：硬件初始化、内存映射、设备树传递、启动介质选择
说实话，很多人觉得 Bootloader 就是个“跳板”——把内核从 Flash 搬到内存，然后跳过去就完事了。但你要是真这么想，迟早会在项目里栽跟头。我这些年调过的板子少说也有几十块，每次出问题，十有八九都出在这四个环节上：硬件初始化、内存映射、设备树传递、启动介质选择。
咱们一个一个拆开讲。
3.1 硬件初始化：别让 CPU 在“裸奔”状态下跑
CPU 上电后，寄存器全是默认值。时钟没配、中断向量表没设、栈指针还是 0。这时候你要是直接跳 C 语言入口，大概率会跑飞。我见过一个同事，Debug 了三天，最后发现是 PLL 没锁住，CPU 一直跑在内部低速时钟上。
硬件初始化，说白了就是给 CPU 穿好衣服再出门。核心步骤就这几步：
- 关中断——上电瞬间谁都不知道外设是什么状态，先关掉所有中断，防止意外触发。
- 设置异常向量表——把异常处理入口告诉 CPU，不然复位、缺页、软中断来了都不知道往哪跳。
- 初始化栈指针——C 语言需要栈，没栈就没局部变量，没法调用函数。
- 配置时钟树——PLL、分频器、外设时钟，这一步错了后面全白搭。
- 初始化关键外设——比如串口（用来打印调试信息）、定时器（用来做超时保护）。
我个人习惯：在汇编阶段只做最少的初始化——关中断、设栈、配时钟。剩下的外设初始化，等跳到 C 语言 main 函数后再做。这样代码好维护，也方便调试。
这里贴一段典型的 ARM Cortex-M 启动汇编，你看一眼就明白了：
; 汇编启动代码片段（ARM Cortex-M）
Reset_Handler:
; 1. 关中断
CPSID I
; 2. 设置栈指针
LDR SP, =_estack
; 3. 清零 BSS 段
LDR R0, =_sbss
LDR R1, =_ebss
MOVS R2, #0
B .L2
.L1:
STR R2, [R0]
ADDS R0, R0, #4
.L2:
CMP R0, R1
BCC .L1
; 4. 跳转到 C 语言 main
BL main
我曾经踩过一个坑：某款国产 MCU 的 BSS 段清零必须在配时钟之前做，否则 SRAM 某些区域会读出随机值。后来查勘误手册才发现，是芯片内部电源管理时序的问题。所以，别迷信“标准启动流程”，每款芯片都得看数据手册。
3.2 内存映射：谁在哪个地址，你得心里有数
内存映射，就是告诉 CPU：“你的 Flash 在 0x08000000，SRAM 在 0x20000000，外设寄存器在 0x40000000 附近。” 说白了，就是一张地址分配表。
Bootloader 里做内存映射，通常要干三件事：
- 配置 MPU（内存保护单元）——给不同区域设置访问权限。比如 Flash 区域只读，SRAM 区域可读写，外设区域禁止非特权访问。
- 重映射中断向量表——Bootloader 和应用程序的中断向量表不能冲突。Bootloader 运行时，向量表在 Flash 起始地址；跳转前，得把向量表重映射到应用程序的起始地址。
- 设置 MMU（如果芯片支持）——像 Cortex-A 系列，需要开 MMU 做虚拟地址映射。Bootloader 里一般只做一级页表映射，够用就行。
你想想看，如果向量表没重映射，应用程序里发生了一个中断，CPU 还是会跳到 Bootloader 的中断处理函数。那不就乱套了吗？
我建议：在跳转到应用程序之前，一定要把 Bootloader 用到的中断全部关掉，并且把向量表基地址寄存器改成应用程序的地址。这一步漏了，应用程序大概率跑不起来。
3.3 设备树传递：给内核递一张“硬件清单”
设备树（Device Tree），你可以把它理解成一张硬件配置清单。内核启动时，需要知道板子上有哪些外设、挂在哪条总线上、中断号是多少、时钟频率是多少。这些信息，Bootloader 得通过某种方式传给内核。
在 ARM Linux 世界里，标准做法是：
- Bootloader 把设备树二进制文件（.dtb）加载到内存的某个固定地址。
- 在跳转到内核之前，把设备树地址放在寄存器 r2（ARM32）或 x1（ARM64）里。
- 内核启动后，从寄存器里拿到设备树地址，解析出硬件信息。
这里有个细节：设备树文件是编译好的二进制，不是文本。你可以在编译时把 .dtb 和 Bootloader 打包在一起，也可以从存储介质里单独加载。我个人习惯把 .dtb 放在一个固定分区里，这样更新设备树时不用重新烧 Bootloader。
// 伪代码：Bootloader 传递设备树给内核
void boot_linux(void)
{
// 1. 加载设备树到内存地址 0x48000000
load_device_tree("kernel.dtb", 0x48000000);
// 2. 加载内核到内存地址 0x40008000
load_kernel("zImage", 0x40008000);
// 3. 设置启动参数
// r0 = 0
// r1 = 机器类型（新内核已废弃）
// r2 = 设备树地址
asm volatile (
"mov r0, #0\n"
"mov r1, #0xFFFFFFFF\n" // 旧内核需要，新内核忽略
"mov r2, #0x48000000\n"
"bx r0\n" // 跳转到内核入口
);
}
注意：设备树地址必须对齐到 8 字节边界，否则内核解析时会报错。我遇到过有人把地址写成了 0x48000001，结果内核直接 panic。这种低级错误，查起来特别费时间。
3.4 启动介质选择：从哪启动，谁说了算？
嵌入式设备里，启动介质五花八门：NOR Flash、NAND Flash、eMMC、SD 卡、SPI Flash、甚至 USB 或网络。Bootloader 得知道“我该从哪读数据”。
启动介质的选择，通常有两种策略：
| 策略 | 原理 | 适用场景 |
|---|---|---|
| 固定优先级 | 按硬件决定的顺序尝试，比如先看 SPI Flash，再看 eMMC，最后看 SD 卡 | 产品定型后，启动介质固定不变 |
| 动态检测 | 通过 GPIO 电平、拨码开关或 OTP 区域决定启动介质 | 开发阶段或需要现场升级的场景 |
我做过一个项目，产品需要支持两种启动方式：正常量产用 eMMC，产线测试用 SD 卡。方案就是用一个 GPIO 引脚做选择——上电时检测电平，高电平从 eMMC 启动，低电平从 SD 卡启动。代码逻辑很简单：
// 启动介质选择伪代码
int select_boot_medium(void)
{
if (GPIO_ReadPin(BOOT_SEL_PIN) == HIGH) {
return BOOT_FROM_EMMC;
} else {
return BOOT_FROM_SD_CARD;
}
}
void bootloader_main(void)
{
int medium = select_boot_medium();
switch (medium) {
case BOOT_FROM_EMMC:
load_from_emmc();
break;
case BOOT_FROM_SD_CARD:
load_from_sd_card();
break;
default:
// 进入烧录模式，等待 USB/串口下载
enter_download_mode();
break;
}
jump_to_application();
}
我曾经遇到过一个问题：某款 NAND Flash 在低温下读数据会偶尔出错。Bootloader 从 NAND 加载内核时，校验 CRC 失败，导致启动卡死。后来加了重试机制，并且把关键数据放在 NAND 的“好块”区域，才解决。所以，选启动介质时，一定要考虑环境因素——温度、电压、老化，都会影响可靠性。
3.5 一张图看懂 Bootloader 核心流程
说了这么多，咱们用一张 SVG 图把整个流程串起来。你一看就明白这四个环节是怎么衔接的：
嗯，到这里，Bootloader 的四个核心功能就讲完了。硬件初始化是地基，内存映射是布局，设备树传递是沟通，启动介质选择是入口。这四个环节，任何一个出问题，系统都起不来。你在实际项目中，如果遇到启动失败，就按这个顺序排查，基本不会漏。