1. BootROM概述：什么是BootROM、它在SoC启动流程中的位置、典型功能

各位同学，咱们今天开篇聊一个看似不起眼、但实际决定了整个芯片能否“活过来”的模块——BootROM。

我做了十几年嵌入式底层固件，见过不少工程师把精力全放在操作系统和驱动上，结果板子一上电，串口死活没输出。查来查去，最后发现是BootROM阶段的配置出了问题。说白了，BootROM是SoC上电后执行的第一段代码，它要是没跑对，后面全是白搭。

什么是BootROM

BootROM，全称是 Boot Read-Only Memory。它是一段固化在芯片内部ROM里的启动代码。芯片一上电，CPU复位后第一条指令就从这里取。

你想想看，这时候DDR还没初始化，Flash控制器还没配好，外部存储根本不可见。所以BootROM必须放在芯片内部的ROM里，上电就能用，不需要任何初始化。

核心特点：

  • 只读性：出厂即固化，用户无法修改。这既是优点（安全可靠），也是缺点（出问题只能换芯片）。
  • 位置固定：映射在CPU复位后的默认取指地址，通常是0x00000000或0xFFFF0000。
  • 尺寸极小：一般只有几KB到几十KB。我见过最小的BootROM只有4KB，要完成时钟配置、启动介质检测、代码加载，写得那叫一个精打细算。

我记得有一次调试一个IoT芯片，BootROM只有8KB，里面塞了NAND Flash的ECC校验、USB下载协议、还有安全启动的验签逻辑。当时我就在想，这代码密度比我的衣柜还高。

BootROM在SoC启动流程中的位置

咱们把SoC的完整启动流程拆开看，BootROM处于最前端。我习惯把它画成下面这张图：

SoC 启动流程概览 BootROM 上电即执行 SPL / Preloader 初始化DDR、时钟 Bootloader 加载OS内核 OS 内核 BootROM 内部执行流程 时钟与PLL初始化 配置系统主频 启动介质检测 eMMC/NAND/SPI 加载SPL到SRAM 校验完整性 跳转到SPL 释放控制权 • BootROM 是 SoC 启动的第一阶段，完全在芯片内部 ROM 中运行 • 它负责将第二级启动加载器（SPL/Preloader）从外部存储加载到内部 SRAM • 整个流程从复位到跳转，通常要求在几十毫秒内完成 ⚠ 注意：BootROM 执行期间，外部 DDR 尚未初始化，只能使用内部 SRAM

从这张图可以看得很清楚：BootROM是启动链的第一棒。它跑完了，把控制权交给SPL（Secondary Program Loader），SPL再加载完整的Bootloader，最后Bootloader拉起操作系统。

这里有个关键点——BootROM执行时，外部DDR还没初始化。所以它只能用芯片内部那块很小的SRAM。我见过不少工程师在移植时忽略了这一点，在BootROM里试图分配大数组，结果直接栈溢出。嗯，这坑我踩过。

BootROM的典型功能

别看BootROM代码量小，它要干的事情可不少。我把它归纳为以下几个核心功能：

功能模块 具体职责 我的经验
基础硬件初始化 配置CPU时钟、PLL、看门狗、中断向量表 有一次看门狗没关，BootROM跑到一半被复位了，查了两天才发现
启动介质检测 按优先级扫描eMMC、NAND Flash、SPI NOR、USB等介质 我习惯把最常用的介质放在第一位，能省几十毫秒
代码加载与校验 从检测到的介质读取SPL到SRAM，做CRC或哈希校验 安全启动场景下，这里还要做RSA验签，耗时大头
安全启动 验证下一级镜像的签名，确保未被篡改 曾经遇到过签名算法太慢，导致启动超时，被迫换用ECC
回退/恢复机制 主镜像损坏时，从备份区或USB下载模式启动 这个功能救过我的命——有一次刷机刷半路断电了

我的建议：

在设计BootROM时，启动介质检测的顺序直接影响启动时间。如果你知道产品99%的场景都用eMMC启动，那就把eMMC放在检测列表第一位。别让BootROM先把SPI、USB、SD卡都轮询一遍，最后才找到eMMC——每多一次轮询，就是几十毫秒的浪费。

一个典型的BootROM代码骨架

下面这段代码是我从某个ARM Cortex-A系列芯片的BootROM里简化出来的。它展示了最核心的流程：

// BootROM 主流程（简化版）
void bootrom_main(void)
{
    // 1. 关闭看门狗
    watchdog_disable();

    // 2. 配置系统时钟到最高频率
    pll_config(SYS_CLK_1GHZ);

    // 3. 初始化启动介质控制器
    boot_device_t dev = boot_device_detect();

    // 4. 从介质读取SPL到SRAM
    int ret = load_image(dev, SPL_OFFSET, SRAM_BASE, SPL_MAX_SIZE);
    if (ret != 0) {
        // 加载失败，进入USB下载模式
        enter_usb_download_mode();
        return;
    }

    // 5. 校验镜像完整性
    if (verify_image(SRAM_BASE, SPL_MAX_SIZE) != 0) {
        // 校验失败，尝试备份
        ret = load_image(dev, BACKUP_OFFSET, SRAM_BASE, SPL_MAX_SIZE);
        if (ret != 0) {
            enter_usb_download_mode();
            return;
        }
    }

    // 6. 跳转到SPL
    jump_to(SRAM_BASE);
}

这段代码看起来简单，但每个函数背后都是血泪史。比如boot_device_detect()，它要尝试不同的通信协议、不同的IO电压、不同的时序参数。我见过一个项目，就因为SPI Flash的时序参数配错了，BootROM死活读不到数据，最后发现是PCB走线长了，信号质量不行。

⚠ 避坑指南：

我曾经在一个量产项目中遇到BootROM偶发加载失败。排查了两个月，最后发现是SRAM的ECC初始化没做。BootROM把SPL加载到SRAM后，SRAM的ECC校验位全是随机值，一读就报错。从那以后，我每次写BootROM都会在第一步把SRAM的ECC初始化好。

BootROM的局限性

说了这么多BootROM的好处，也得聊聊它的短板。毕竟它只是启动链的第一环，不是万能的：

  • 不可更新：一旦芯片流片，BootROM里的代码就焊死了。如果发现bug，只能通过SPL打补丁，或者直接换芯片。
  • 资源极度受限：ROM空间小，SRAM也小。你没法在BootROM里做复杂的事情，比如文件系统解析、网络协议栈。
  • 调试困难：BootROM执行时，调试器通常还没连上。出了问题只能靠GPIO点灯、串口打印或者逻辑分析仪。

我记得有一次，芯片的BootROM里有个时序bug，导致某些批次的eMMC读数据会丢bit。因为ROM不能改，最后只能在SPL里加了一段补偿代码，每次启动时先校准eMMC的采样点。这事儿折腾了整整一个季度。

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