3. ROM Code与一级Bootloader：ROM Code功能与限制、启动设备选择、启动头格式解析、一级Bootloader（SPL）加载机制
大家好，我是你们的嵌入式系统讲师。今天咱们来聊聊BSP启动链里最底层、也最容易被忽视的一环——ROM Code和一级Bootloader。说白了，这是芯片上电后执行的第一段代码，它决定了你的系统能不能“活过来”。
我做了这么多年BSP开发，见过太多工程师在应用层写得飞起，一到启动阶段就抓瞎。其实这部分没那么玄乎，咱们把它拆开揉碎了讲清楚。
3.1 ROM Code：芯片出厂自带的“硬核”固件
ROM Code，顾名思义，是固化在芯片内部ROM（只读存储器）里的一段程序。芯片一上电，CPU复位后第一条指令就从这里取。它有几个特点：
- 不可修改：出厂就写死了，你没法改。所以它必须足够稳定、足够通用。
- 功能有限：ROM空间很金贵，通常只有几十KB到几百KB。它只做最核心的事——初始化硬件、选择启动设备、加载下一级代码。
- 平台相关：不同厂商、不同芯片的ROM Code实现天差地别。但核心逻辑大同小异。
核心功能清单：
- 初始化CPU核心、Cache、MMU（通常只开指令Cache）
- 配置系统时钟、PLL
- 初始化片内SRAM（通常很小，几十KB到几百KB）
- 检测启动引脚电平，确定启动设备
- 从启动设备读取启动头（Boot Header）
- 根据启动头信息，加载一级Bootloader到片内SRAM
- 跳转到一级Bootloader执行
嗯，这里要注意：ROM Code不会初始化DDR。为什么？因为DDR初始化需要复杂的时序训练，ROM Code那点空间根本放不下。这个活要留给后面的一级Bootloader去做。
3.2 启动设备选择：芯片怎么知道从哪启动？
芯片上电后，ROM Code做的第一件事就是“看引脚”。芯片厂商会预留一组启动选择引脚（Boot Mode Pins），比如BOOT[3:0]。这些引脚在复位时被采样，ROM Code根据采样值决定从哪个设备加载代码。
常见的启动设备有：
| 启动设备 | 特点 | 典型场景 |
|---|---|---|
| NAND Flash | 容量大、成本低，但需要ECC和坏块管理 | 消费电子、工业控制 |
| eMMC | 内置控制器，使用方便，速度快 | 手机、平板、高端嵌入式 |
| SD卡 | 可插拔，调试方便 | 开发板、原型验证 |
| SPI Nor Flash | 接口简单，支持XIP（片上执行） | 低功耗、小容量场景 |
我个人习惯在开发板上用SD卡启动，调试起来特别方便。换一个固件，插拔一下SD卡就行。但量产时一定要切回eMMC或NAND，不然生产线上会疯掉。
避坑指南：我曾经在一个项目里，因为启动引脚的上拉电阻没焊好，导致芯片死活不从eMMC启动。查了两天才发现是引脚电平不对。所以，硬件工程师画板子时，启动引脚的电阻一定要再三确认。
3.3 启动头格式解析：ROM Code的“导航地图”
ROM Code从启动设备读数据，不是随便读的。它需要先读一个固定格式的“启动头”（Boot Header）。这个头里包含了关键信息：代码长度、加载地址、校验和、签名等。
不同芯片的启动头格式不一样，但核心字段大同小异。我以某款主流ARM SoC为例：
// 启动头结构体示例
typedef struct {
uint32_t magic; // 魔数，用于校验合法性，比如0xEA000000
uint32_t load_addr; // 一级Bootloader加载到SRAM的地址
uint32_t image_size; // 镜像大小（字节）
uint32_t checksum; // 校验和，ROM Code会计算并比对
uint32_t entry_point; // 入口地址，通常等于load_addr
uint8_t reserved[16]; // 保留字段，厂商自定义
uint8_t signature[256]; // 数字签名（安全启动时使用）
} boot_header_t;
ROM Code读取启动头的流程大致如下：
- 从启动设备的固定偏移（比如0x0或0x200）读取启动头
- 校验魔数，确认这是一个合法的启动头
- 计算校验和，与头里的checksum比对
- 如果校验通过，根据image_size和load_addr，将后续数据加载到SRAM
- 跳转到entry_point执行
你想想看，如果校验和不对，ROM Code会怎么办？它会尝试下一个启动设备。这就是所谓的“启动设备回退”机制。比如先从SD卡启动，失败后尝试eMMC，再失败尝试NAND。这个顺序也是由启动引脚决定的。
注意：安全启动场景下，启动头里还会包含数字签名。ROM Code会用芯片内部固化的公钥验证签名，防止恶意固件运行。这个机制一旦开启，你就必须用厂商提供的签名工具对镜像签名，否则芯片直接“罢工”。
3.4 一级Bootloader（SPL）加载机制：从“小”到“大”的跳板
一级Bootloader，通常叫SPL（Secondary Program Loader）或MLO（MMC Loader）。它体积很小，一般只有几十KB，刚好能塞进片内SRAM。
为什么需要SPL？因为ROM Code太“笨”了，它只能做简单的事。真正的硬件初始化——比如DDR初始化、时钟树配置、外设控制器初始化——都需要更复杂的代码。这些代码放在ROM里不现实，所以需要SPL来做这个“中间人”。
SPL的加载机制是这样的：
- ROM Code从启动设备读取启动头，找到SPL镜像的位置和大小
- 将SPL镜像加载到片内SRAM（比如0x20000000）
- 跳转到SPL入口执行
- SPL开始运行，初始化DDR、配置时钟、初始化存储控制器
- SPL从启动设备加载二级Bootloader（比如U-Boot）到DDR
- 跳转到二级Bootloader执行
说白了，SPL就是一个“小Loader”，它的使命就是加载“大Loader”。
SPL的典型大小：
- 不带DDR初始化：16KB ~ 32KB
- 带DDR初始化：32KB ~ 64KB
- 带安全启动：64KB ~ 128KB
我在项目中遇到过一个问题：SPL编译出来只有30KB，但片内SRAM只有64KB。按理说够用，但运行时总是莫名其妙地崩溃。后来发现是SPL的栈和堆设置太大，把代码空间给挤占了。所以，写SPL时一定要精打细算，能省则省。
3.5 知识体系核心逻辑图
下面我用一张SVG图来总结本章的核心逻辑。这张图展示了从芯片上电到SPL加载完成的完整流程：
这张图把整个流程串起来了。你从上往下看，每一步都环环相扣。任何一个环节出问题，系统都起不来。
我的经验：调试启动问题时，我习惯用示波器抓启动引脚的波形，确认芯片确实读到了正确的电平。然后再用逻辑分析仪抓SPI或NAND的通信波形，看ROM Code有没有真的去读设备。这些手段比单纯看代码日志要直观得多。
好了，这一章的内容就到这里。ROM Code和SPL是BSP启动链的基石，理解透了，后面的二级Bootloader和内核启动才能顺理成章。下一章咱们聊聊二级Bootloader——U-Boot的启动流程，那又是另一番天地。
可可精品资料库