第三章 BootROM原理：S32G启动的第一道关卡

大家好，我是你们的嵌入式安全讲师。今天我们来聊聊S32G的BootROM——这颗芯片上电后第一个执行的代码。说实话，BootROM是很多工程师容易忽略的部分，但恰恰是它决定了整个系统的安全根基。

我个人习惯把BootROM比作「芯片的看门人」。你想想看，芯片一上电，CPU从复位向量取指，这时候Flash还没初始化，DDR也没准备好，谁来干活？就是BootROM。它固化在芯片内部ROM里，出厂就写死了，改不了。嗯，这既是好事也是坏事——好处是它绝对可信，坏处是你没法打补丁。

3.1 S32G BootROM启动流程

BootROM的启动流程，说白了就是一条流水线。我把它拆成几个关键步骤：

  1. 硬件初始化：上电后，BootROM先做最基本的硬件设置。比如配置时钟、初始化SRAM、设置堆栈指针。这一步很快，大概几百微秒。
  2. 启动模式检测：BootROM会读取FCCU（故障收集与控制单元）的状态，判断当前处于哪种启动模式。这个后面细说。
  3. 镜像加载与校验：根据启动模式，从对应介质加载Boot镜像，然后做安全校验。校验通过才执行，否则进入错误处理。
  4. 跳转到Boot镜像：校验通过后，BootROM把控制权交给Boot镜像（比如HSE固件或SBL）。

我在项目中遇到过一个问题：客户说芯片上电后一直起不来，串口也没输出。查了半天，发现是FCCU里记录了上一次的故障状态，导致BootROM认为系统有严重错误，直接进入了安全锁定状态。所以啊，FCCU的状态一定要在开发阶段留意。

关键点：BootROM的执行是原子的、不可中断的。它不会加载操作系统，也不会初始化外设驱动。它的任务只有一个——把可信的Boot镜像安全地加载到内存里。

3.2 启动模式选择：FCCU/串行下载/Flash启动

S32G支持三种启动模式，由FCCU的状态和外部引脚共同决定。我画个表格方便你对比：

启动模式 触发条件 典型场景 安全等级
FCCU启动 FCCU检测到严重故障 系统恢复、故障诊断 最高（强制安全）
串行下载 特定引脚电平或FCCU状态 工厂烧录、开发调试 低（无校验）
Flash启动 正常启动条件 产品量产、正常启动 高（需签名校验）

3.2.1 FCCU启动模式

FCCU是S32G的安全监控单元。它负责收集硬件故障（比如时钟失效、电压异常、看门狗超时）。如果FCCU检测到不可恢复的故障，BootROM会强制进入FCCU启动模式。

这个模式下，BootROM只会加载一个最小的安全固件，用来做故障记录和系统恢复。说白了，就是「救砖模式」。我曾经在调试一块板子时，不小心把Flash里的Boot镜像擦除了，结果芯片反复重启。后来通过FCCU模式进入串行下载，才重新烧录了镜像。

注意：FCCU启动模式下，BootROM不会做任何安全校验。因为它假设系统已经处于不安全状态，首要任务是记录故障，而不是保证安全。

3.2.2 串行下载模式

串行下载模式，顾名思义，就是通过串口（UART或USB）把镜像下载到芯片里。这个模式主要用于开发阶段和工厂烧录。

BootROM在串行下载模式下会做两件事：

  • 初始化串口外设，等待主机发送数据
  • 接收镜像数据，写入SRAM或Flash

嗯，这里要注意：串行下载模式默认不开启安全校验。也就是说，任何人都可以通过串口往芯片里写代码。所以量产产品一定要禁用这个模式，或者用硬件引脚锁定。

我建议你在开发板上保留串行下载功能，但产品板上一定要把相关引脚拉死，防止被攻击者利用。

3.2.3 Flash启动模式

这是产品量产后的主要启动方式。BootROM会从外部Flash（比如QuadSPI连接的NOR Flash）加载Boot镜像。

Flash启动的流程是这样的：

  1. BootROM初始化Flash控制器
  2. 读取Flash头部的启动配置信息（比如镜像地址、大小、签名）
  3. 加载镜像到SRAM
  4. 做安全校验（签名验证或MAC校验）
  5. 校验通过后跳转执行

这里有个坑：Flash的初始化参数必须和硬件设计匹配。比如时钟频率、时序参数、引脚复用。我见过一个案例，工程师把Flash的CS引脚接错了，结果BootROM死活读不到数据。查了两天才发现是原理图错误。

3.3 BootROM安全校验机制

安全校验是BootROM的核心功能。S32G的BootROM支持两种校验方式：

  • RSA签名验证：使用公钥验证镜像的数字签名
  • CMAC消息认证码：使用对称密钥验证镜像的完整性

这两种方式有什么区别？我简单说一下：

校验方式 密钥管理 性能 适用场景
RSA签名 公钥存储在OTP，私钥在服务器 较慢（毫秒级） 安全要求高的产品
CMAC 对称密钥存储在OTP或HSE 较快（微秒级） 性能敏感的场景

BootROM的校验流程大致如下：

// 伪代码示意
bootrom_main() {
    // 1. 读取镜像头部
    header = read_flash_header();
    
    // 2. 根据配置选择校验方式
    if (header.auth_type == RSA) {
        // RSA验证：用OTP中的公钥解密签名
        hash = sha256(header.image_data);
        result = rsa_verify(otp_public_key, header.signature, hash);
    } else if (header.auth_type == CMAC) {
        // CMAC验证：用HSE中的密钥计算MAC
        result = cmac_verify(hse_key, header.image_data, header.mac);
    }
    
    // 3. 校验失败则进入错误处理
    if (result != PASS) {
        fccu_report_fault(FCCU_FAULT_BOOT_FAILURE);
        enter_serial_download();
    }
    
    // 4. 校验通过，跳转执行
    jump_to(header.image_data);
}

这里有个细节：BootROM的RSA公钥是存储在OTP（一次性可编程存储器）里的。OTP只能写一次，写错了就废了。所以量产前一定要反复确认公钥的哈希值是否正确。

我的经验：在开发阶段，建议先用CMAC校验，因为密钥可以随时更新。等产品定型后，再切换到RSA签名。这样既保证了开发效率，又确保了量产安全。

3.4 避坑指南

最后，我总结几个实际项目中容易踩的坑：

  • OTP烧录错误：OTP一旦烧录就无法修改。我建议在烧录前做三次校验，包括回读验证。
  • Flash时序不匹配：BootROM初始化Flash时用的是默认时序，如果硬件设计用了较慢的Flash，可能导致读取失败。解决办法是在硬件设计阶段就确认Flash的时序参数。
  • FCCU状态未清除：开发过程中，FCCU可能会记录一些调试阶段的故障。下次启动时，BootROM会因为这些历史故障进入安全模式。记得在调试完成后清除FCCU状态。
  • 签名算法版本不匹配：S32G的BootROM支持RSA2048和RSA4096。如果你用RSA4096签名，但BootROM只支持RSA2048，那校验肯定失败。这个在选型时就要确认清楚。

好了，第三章的内容就到这里。BootROM是整个安全启动链条的第一环，也是最关键的一环。下一章我们会讲HSE（硬件安全引擎）的初始化流程，到时候你会看到BootROM和HSE是如何配合工作的。

有什么问题，欢迎在课程群里交流。我们下章见。

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