3. Bootloader 核心任务：硬件初始化、设备树加载、内核镜像加载、参数传递

说实话，很多人觉得 Bootloader 就是个「跳板」——把内核从闪存搬到内存，然后一跳了事。但我在嵌入式这行干了十几年，踩过的坑告诉我：Bootloader 干得好不好，直接决定了内核能不能活下来。

这一章，咱们就掰开揉碎，看看 Bootloader 到底要干哪四件大事。我习惯把这四件事称为「启动四板斧」：硬件初始化、设备树加载、内核镜像加载、参数传递。少一斧，系统就起不来。

核心观点：Bootloader 不是简单的「加载器」，它是硬件与内核之间的「翻译官」和「管家」。硬件初始化让系统「活过来」，设备树让内核「认得出」，镜像加载让内核「跑得动」，参数传递让内核「干得对」。

3.1 硬件初始化：让系统先「活过来」

上电那一刻，CPU 还处于「混沌」状态。时钟没配、内存没初始化、串口还不能用。这时候 Bootloader 的第一件事，就是把这些基础硬件「唤醒」。

我遇到过不少新手，上来就调内核，结果发现串口死活没输出。查了半天，原来是 Bootloader 里根本没初始化串口控制器。嗯，这种问题其实很常见。

硬件初始化通常分几步走：

  1. 关闭中断与 MMU——刚上电时，所有外设中断都是不可控的，必须关掉。MMU 也得关，因为此时页表还没建立。
  2. 配置系统时钟——CPU 主频、总线频率、外设时钟，都得按硬件设计配好。配错了，系统要么跑飞，要么功耗异常。
  3. 初始化 DDR 控制器——内存是系统的「工作台」，DDR 的时序参数、刷新率、地址映射，一个都不能错。
  4. 初始化串口——串口是调试的「眼睛」，我习惯在初始化完串口后立刻打印一行字符，确认系统已经「活过来了」。
  5. 初始化其他关键外设——比如 NAND Flash 控制器、eMMC 控制器、网络控制器等，取决于你的启动介质。

我的习惯：在硬件初始化阶段，每完成一个模块，就通过 GPIO 翻转一个电平。这样用示波器一看，就知道系统卡在哪一步。比看串口日志还快。

3.2 设备树加载：让内核「认得出」硬件

早期 Linux 内核里，板级信息都是硬编码在 arch/arm/mach-xxx 下的。换一块板子就得重新编译内核。后来设备树（Device Tree）出现了，把硬件描述从内核代码里「剥离」出来。

设备树说白了，就是一份描述硬件拓扑的「清单」。Bootloader 要做的，就是把这份清单从存储介质里读出来，放到内存里，然后把地址告诉内核。

加载设备树时，有几个关键点：

  • 设备树文件（.dtb）必须与内核版本匹配——不匹配的话，内核可能认不出某些外设，甚至直接 panic。
  • 设备树必须放在内存的特定位置——通常是内核镜像之后、initramfs 之前。位置不对，内核就找不到它。
  • Bootloader 可以修改设备树——比如根据硬件版本调整某些节点，或者覆盖掉一些默认值。我经常在 U-Boot 里用 fdt set 命令临时改参数。

我曾经踩过的坑：有一次升级内核，忘了更新设备树。结果新内核里某个驱动改了寄存器映射，旧设备树里的地址对不上，系统启动到一半就挂了。排查了整整一天，最后发现是 .dtb 没同步更新。从那以后，我每次升级内核都会把设备树一起编译、一起烧录。

3.3 内核镜像加载：让内核「跑得动」

内核镜像通常以压缩格式存储在闪存里（比如 zImage、Image.gz）。Bootloader 需要把它解压到内存的指定位置，然后跳转过去执行。

加载过程看起来简单，但有几个细节必须注意：

步骤 说明 常见问题
读取镜像 从 NAND、eMMC、SD 卡或网络读取内核镜像到临时缓冲区 读取地址与内存区域重叠，导致数据被覆盖
校验完整性 通过 CRC32 或 SHA256 校验镜像是否损坏 校验失败时没有回退机制，系统直接卡死
解压镜像 将压缩的内核解压到运行地址（通常是内存起始偏移处） 解压后的内核覆盖了解压器自身，导致解压失败
跳转执行 设置 CPU 寄存器（如 r0、r1、r2），然后跳转到内核入口 寄存器传参错误，内核无法获取设备树地址

你想想看，如果内核镜像加载地址和内存中的其他数据冲突了，会发生什么？轻则解压失败，重则系统直接死机。所以，加载地址的选择非常关键。我一般会在内存布局图里预留一块「安全区」，专门放内核镜像。

3.4 参数传递：让内核「干得对」

内核启动时，需要知道一些「上下文信息」：根文件系统在哪？控制台用哪个串口？内存有多大？这些信息，就是通过 Bootloader 传递过去的。

参数传递主要有两种方式：

  • ATAG（ARM 时代的老方法）——通过寄存器 r2 传递 ATAG 列表的地址。每个 ATAG 是一个结构体，包含内存大小、命令行参数等信息。现在基本被设备树取代了。
  • 设备树（现代方法）——通过寄存器 r2 传递设备树基地址。内核从设备树中解析内存布局、外设信息、以及 chosen 节点里的 bootargs。

这里有个细节：寄存器 r0、r1、r2 的值在跳转到内核前必须设置正确。以 ARM64 为例：

  • r0：必须为 0
  • r1：机器类型 ID（ARM32 用，ARM64 已废弃）
  • r2：设备树基地址（或 ATAG 地址）

避坑指南：我曾经在移植 U-Boot 到一块新板子时，发现内核启动后打印 Uncompressing Linux... done, booting the kernel. 然后就卡死了。查了两天，最后发现是 r2 寄存器传的设备树地址不对——我忘了把设备树加载地址对齐到 64 字节边界。内核要求设备树基地址必须 64 字节对齐，否则直接拒绝启动。

3.5 四板斧的协作流程

这四件事不是孤立干的，它们有严格的先后顺序。我画了一张图，帮你理清这个流程：

Bootloader 四板斧协作流程图 Bootloader 四板斧协作流程 上电复位 硬件初始化 关中断/MMU 配时钟 初始化 DDR 初始化串口 加载设备树 加载内核镜像 参数传递 → 跳转内核 r0=0, r1=机器ID r2=设备树基地址

从图上你能看到，硬件初始化是基础，没有它后面什么都干不了。设备树和内核镜像的加载顺序可以互换，但参数传递必须在跳转前完成。说白了，这四板斧是一环扣一环的，哪一环断了，系统就起不来。

3.6 实战中的一些建议

最后，分享几个我在实际项目中总结的经验：

  • 调试信息要留足——在 Bootloader 的每个关键步骤后打印状态信息。出问题时，这些日志就是你的「救命稻草」。
  • 内存布局要提前规划好——内核加载地址、设备树地址、initramfs 地址、临时缓冲区地址，这些都要在项目初期就定下来，避免后期冲突。
  • 版本管理要严格——Bootloader、设备树、内核镜像，这三者的版本必须一一对应。我习惯在每次发布时，把三者的版本号写在一个文档里，随固件一起发布。
  • 回滚机制不能少——万一新版本启动失败，Bootloader 要能回滚到上一个可用版本。这个机制我建议在项目一开始就做进去，别等出了问题再补。

一个小技巧：在 U-Boot 里，可以用 bdinfo 命令查看当前板级信息，用 fdt addr 查看设备树加载地址，用 iminfo 检查内核镜像的完整性。这些命令在调试时非常有用。

好了，这一章的内容就到这里。Bootloader 的四板斧——硬件初始化、设备树加载、内核镜像加载、参数传递——每一斧都有它的门道。理解了这些，你就掌握了嵌入式系统启动的核心脉络。

← 上一章 📖 返回目录 下一章 →