4、BootROM与一级引导：SoC启动流程、BootROM固化逻辑、一级引导加载程序（SPL/FSBL）设计

好，咱们今天聊点硬核的。BootROM和一级引导，说白了就是芯片上电后，第一条指令从哪里来，谁把系统“踹”起来的那点事。

我刚开始接触车载SoC时，觉得这玩意儿离应用层太远，不就是个固化代码嘛。直到有一次，板子死活起不来，示波器挂上去一看，BootROM压根没找到合法的启动介质。嗯，从那以后，我再也不敢小看这“第一公里”了。

4.1 SoC的启动流程：从复位向量到第一行代码

芯片上电后，硬件逻辑会强制PC指针指向一个固定地址。这个地址，就是复位向量。对于ARM Cortex-A系列，通常是0x00000000或0xFFFF0000。但这里有个坑——此时DDR还没初始化，你根本没法把代码跑在内存里。

所以，BootROM必须放在芯片内部的SRAM或者ROM里。上电即用，无需配置。

整个启动流程，我习惯把它拆成三个阶段：

• 阶段一：硬件固化——BootROM执行，初始化最基本的时钟、看门狗、启动介质控制器。
• 阶段二：一级引导——从Flash/SD卡/eMMC中加载SPL或FSBL到SRAM。
• 阶段三：二级引导——SPL初始化DDR，加载完整的U-Boot或裸机程序。

你想想看，这就像接力赛。BootROM是第一棒，它只跑一小段，然后把棒子交给SPL。SPL再跑一段，最后交给操作系统。每一棒都不能掉链子。

4.2 BootROM固化逻辑：芯片出厂就写死的“铁规矩”

BootROM是芯片出厂时掩膜在ROM里的代码。用户改不了，也删不掉。它的任务很明确：

• 检测启动引脚的电平状态（比如拉高从SD卡启动，拉低从NAND启动）
• 初始化对应的外设控制器（SDIO、SPI、NAND控制器等）
• 读取固定偏移位置的签名或头部信息
• 验证镜像的合法性（如果使能了安全启动）
• 跳转到SPL/FSBL的入口

我在项目中遇到过一个问题：某款SoC的BootROM只支持从eMMC的特定分区（比如BOOT1）加载。结果同事把镜像写到了用户分区，板子死活不跑。查了两天才发现，是BootROM的“铁规矩”限制了搜索路径。

举个例子，典型的BootROM加载流程如下：

// 伪代码示意
void bootrom_main(void) {
    uint32_t boot_mode = read_boot_pins();
    switch (boot_mode) {
        case BOOT_SD:
            sd_init();
            sd_read(0x200, buf, 0x8000); // 从偏移0x200读32KB
            break;
        case BOOT_NAND:
            nand_init();
            nand_read(0x0, buf, 0x8000);
            break;
    }
    if (secure_boot_enabled()) {
        verify_signature(buf);
    }
    jump_to(buf + HEADER_SIZE);
}

看到了吗？它只读固定偏移、固定大小。所以你的SPL镜像必须放在正确的位置，否则BootROM根本找不到。

4.3 一级引导加载程序（SPL/FSBL）设计

SPL（Secondary Program Loader）或者FSBL（First Stage Boot Loader），是BootROM加载进来的第一个用户可控代码。它的主要任务是什么？

• 初始化DDR控制器（这是最关键的一步）
• 配置系统时钟到目标频率
• 加载完整的引导程序（如U-Boot）到DDR
• 可选：验证下一级镜像的完整性

我个人习惯把SPL设计得尽量精简。为什么？因为SRAM太小了。很多SoC的SRAM只有64KB或128KB。你想想看，一个U-Boot编译出来动不动几百KB，根本塞不下。所以SPL必须“瘦身”。

4.3.1 SPL的内存布局

典型的SPL内存布局如下：

地址范围	用途	大小
0x0000_0000 - 0x0000_7FFF	BootROM保留区	32KB
0x0000_8000 - 0x0001_7FFF	SPL代码段	64KB
0x0001_8000 - 0x0001_FFFF	SPL数据段/堆栈	32KB
0x8000_0000 - ...	DDR（SPL初始化后可用）	动态

这里有个细节：SPL的链接脚本必须指定加载地址为SRAM。我见过有人直接把U-Boot的链接脚本拿来用，结果SPL跑在DDR地址上，DDR还没初始化，直接死机。

4.3.2 SPL的代码设计要点

写SPL时，有几个坑我踩过，分享给你：

• 不要用全局变量初始化——SPL的BSS段可能还没清零，全局变量默认值不可靠。我建议在入口处手动清零BSS。
• 关中断——BootROM可能没关中断，SPL启动时先关掉所有中断，防止意外触发。
• DDR训练参数要固化——DDR初始化需要时序参数，我建议把这些参数放在SPL的头部，而不是硬编码在代码里。这样换DDR颗粒时，只需要改头部，不用重新编译SPL。

4.3.3 安全启动中的SPL设计

在车载场景下，SPL必须支持安全启动。BootROM验证SPL的签名，SPL再验证U-Boot的签名。这个信任链不能断。

我曾经在项目中设计过这样的流程：

// SPL安全启动伪代码
void spl_main(void) {
    // 1. 初始化必要外设（串口、定时器）
    early_init();

    // 2. 初始化DDR
    ddr_init(ddr_params);

    // 3. 从存储介质读取U-Boot镜像到DDR
    load_image(CONFIG_UBOOT_OFFSET, CONFIG_UBOOT_SIZE, DDR_BASE);

    // 4. 验证U-Boot签名
    if (verify_image(DDR_BASE, CONFIG_UBOOT_SIZE, public_key) != OK) {
        // 验证失败，进入恢复模式
        enter_recovery_mode();
        while(1);
    }

    // 5. 跳转到U-Boot
    jump_to(DDR_BASE + HEADER_SIZE);
}

这里要注意，公钥必须放在SPL内部，或者由BootROM传递过来。公钥被篡改，整个信任链就崩塌了。

4.4 避坑指南：我踩过的那些坑

做一级引导这么多年，我总结了几条血泪教训：

• BootROM的启动介质优先级——有些SoC支持多个启动介质，优先级是固定的。我曾经以为SD卡启动失败后会回退到eMMC，结果它直接死在那了。查手册才发现，回退逻辑需要硬件引脚配置，不是自动的。
• SPL的大小限制——BootROM只加载固定大小的SPL。如果你SPL编译出来超了，BootROM只加载前64KB，后面的代码缺失，跑起来必崩。我建议在链接脚本里加一个.size_check段，超了直接报错。
• DDR初始化失败后的恢复——DDR初始化一旦失败，系统就彻底哑了。我建议在SPL里加一个“看门狗喂狗”机制，如果DDR初始化超时，复位到恢复模式，从USB或串口下载固件。

好了，这一章的内容就到这里。下一章我们会聊二级引导加载程序，也就是U-Boot的完整启动流程。到时候我会讲讲U-Boot的板级初始化、设备树传递、以及如何从U-Boot跳转到Linux内核。咱们下章见。