2、硬件初始化与Bootloader：CPU复位、ROM代码、SPL、U-Boot的使命，如何加载内核到内存
大家好，我是你们的嵌入式Linux内核启动讲师。今天我们来聊聊整个启动流程的起点——硬件初始化与Bootloader。说实话，很多工程师学了多年Linux，对内核本身很熟，但一提到上电那一刻CPU在干什么，就有点懵了。我当年刚入行时也是这样，总觉得Bootloader就是个“黑盒子”，直到自己亲手调过一块板子，才真正理解它的使命。
嗯，咱们今天就把这个“黑盒子”彻底打开。你想想看，一块芯片从复位到最终运行Linux内核，中间经历了多少道关卡？每一关都有它的设计哲学。
2.1 CPU复位后的第一行代码
芯片上电那一刻，CPU的复位逻辑会强制PC指针指向一个固定地址。这个地址，就是所谓的“复位向量”。对于ARM Cortex-A系列，通常是0x00000000或0xFFFF0000；对于RISC-V，一般是0x80000000附近。但这里有个坑——此时内存还没初始化，CPU只能执行片内ROM里的代码。
核心要点：复位后CPU处于最原始的状态——MMU关闭、Cache关闭、中断屏蔽。你连栈指针都没有，只能用汇编写代码。
我个人习惯把这段代码称为“上帝模式”下的代码。为什么？因为此时你没有任何依赖，只能靠寄存器活着。我在项目中遇到过一块国产芯片，它的复位向量指向了一个奇怪的地址，结果我查了两天手册才发现，原来是芯片的启动模式选择引脚没拉对。嗯，这种低级错误，犯过一次就再也不会忘了。
2.2 ROM代码：芯片出厂自带的“小管家”
大多数现代SoC内部都有一小块ROM，出厂时固化了启动代码。这段代码的任务很简单：检测启动介质，把下一级代码加载到SRAM或DDR中。常见的启动介质有：
- NAND Flash——需要ECC校验，ROM代码会做简单的坏块跳过
- eMMC/SD卡——通过SD/MMC控制器读取
- SPI NOR Flash——最简单，直接XIP执行
- UART/USB——调试用，从串口或USB下载
ROM代码的大小通常只有几十KB，所以它只能做最基础的事情。说白了，它就是个“引路人”，把你带到下一站。
避坑指南：我曾经在调试一块新板子时，发现ROM代码死活读不到eMMC。折腾了半天，最后发现是eMMC的供电时序没满足要求。ROM代码对时序非常敏感，尤其是上电复位信号。建议大家在硬件设计阶段就仔细核对启动介质的时序参数。
2.3 SPL：U-Boot的“瘦身版”
ROM代码加载完SPL（Secondary Program Loader）后，控制权就交给了SPL。SPL是什么？说白了，它是U-Boot的精简版本。为什么需要SPL？因为U-Boot太大了，ROM代码那点SRAM装不下。SPL只做三件事：
- 初始化DDR控制器——这是最关键的一步
- 从启动介质加载完整的U-Boot到DDR
- 跳转到U-Boot入口
SPL的代码量通常控制在几十KB以内。我见过一些团队为了省事，直接把U-Boot塞进SPL，结果DDR还没初始化就崩了。嗯，这种“偷懒”的代价往往更大。
注意：SPL阶段的DDR初始化参数非常敏感。不同频率、不同容量的DDR颗粒，时序参数完全不同。我曾经因为照搬参考设计的参数，导致板子在高温下频繁死机。后来老老实实按照DDR厂商的仿真报告重新配置，问题才解决。
2.4 U-Boot：真正的“Bootloader”
当U-Boot被加载到DDR后，它才真正开始大展拳脚。U-Boot的使命可以概括为：
- 硬件初始化——时钟、串口、网络、存储控制器等
- 环境变量管理——保存启动参数、IP地址、启动命令等
- 内核加载——从Flash、网络或硬盘读取内核镜像到内存
- 设备树传递——把硬件描述信息传给内核
- 启动内核——跳转到内核入口，交出控制权
我个人最喜欢U-Boot的一点是它的命令行交互。你可以随时打断启动流程，手动输入命令调试。比如：
# 从eMMC读取内核到内存地址0x80000000
mmc read 0x80000000 0x800 0x4000
# 设置启动参数
setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 rw
# 启动内核
bootm 0x80000000 - 0x83000000你想想看，如果没有U-Boot，你每次改个内核参数都得重新烧写整个镜像，那得多痛苦？
2.5 内核加载到内存的完整流程
好了，现在我们把整个流程串起来。下面这张图是我自己画的，帮你直观理解从复位到内核加载的完整链路：
这张图把整个流程分成了四个阶段。每个阶段都有明确的职责边界。我个人觉得，理解这个分层设计是掌握启动流程的关键。为什么？因为每一层都在为下一层做准备，就像盖房子一样，地基没打好，上层建筑再漂亮也没用。
2.6 内核加载的几种方式
U-Boot加载内核的方式有很多种，我挑几个常见的说说：
| 加载方式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 从Flash读取 | 量产产品 | 稳定可靠，无需网络 | 更新固件需要重新烧写 |
| 从网络加载（TFTP） | 开发调试 | 快速迭代，无需烧写 | 依赖网络环境 |
| 从USB加载 | 现场升级 | 方便携带，即插即用 | 速度较慢 |
| 从SD卡加载 | 原型验证 | 灵活，可更换介质 | 可靠性不如eMMC |
我在项目中用得最多的是TFTP方式。调试阶段，每次修改内核后只需要重新编译，然后通过TFTP下载到板子上，几秒钟就能看到效果。但量产时一定要切回Flash加载，毕竟客户不会给你配个服务器。
2.7 设备树与启动参数传递
U-Boot加载内核时，还需要传递两个关键信息：设备树（DTB）和启动参数（bootargs）。设备树描述了硬件拓扑结构，比如CPU数量、内存大小、外设地址等。启动参数则告诉内核根文件系统在哪里、控制台用哪个串口等。
这里有个细节：设备树在内存中的存放地址必须与内核约定的地址一致。我见过有人把设备树放错了位置，结果内核启动时死活找不到串口，打印信息全没了。嗯，这种问题排查起来特别痛苦，因为你看不到任何输出。
我的经验：建议在U-Boot中设置一个固定的设备树加载地址，比如0x83000000。然后在bootcmd中明确指定这个地址。这样无论你怎么改内核，设备树的位置都不会变，减少出错概率。
2.8 跳转到内核：最后的交接
当U-Boot完成所有准备工作后，它会执行一条特殊的指令跳转到内核入口。对于ARM架构，通常是跳转到内核镜像的起始地址。此时，U-Boot会做最后几件事：
- 关闭MMU和Cache（有些架构需要）
- 设置寄存器传递参数（如r0、r1、r2）
- 清空指令流水线
- 跳转到内核入口
从这一刻起，U-Boot的使命就结束了。内核开始接管一切。你想想看，从复位到这一刻，芯片经历了多少层代码的接力？每一层都在为下一层铺路，环环相扣。这就是嵌入式系统的魅力——看似复杂，实则每个环节都有它的道理。
好了，关于硬件初始化与Bootloader的内容就讲到这里。下一章我们会深入内核的入口代码，看看内核是如何接管系统的。到时候再聊！
本章小结：
- CPU复位后执行ROM代码，ROM代码加载SPL
- SPL初始化DDR后加载U-Boot
- U-Boot完成硬件初始化、加载内核、传递设备树和启动参数
- 最终跳转到内核入口，交出控制权