4、BootROM（一级引导）：片上ROM代码执行、启动介质选择（eMMC/NAND）、安全启动校验
好，我们进入第四讲。这一章聊的是车机系统启动的「第一口气」——BootROM。
你想想看，芯片上电那一刻，内存还没初始化，Flash还没准备好，CPU怎么知道自己该干嘛？答案就在芯片内部那片只读存储器里，也就是BootROM。它出厂就写死了，谁也改不了。说白了，这是芯片厂商给你铺好的第一条路。
4.1 BootROM到底在干什么？
我个人习惯把BootROM比作「芯片的出厂设置」。它干的事情其实很纯粹，就三件：
- 初始化最基本的硬件：比如CPU核心、中断向量表、堆栈指针。注意，这里只初始化最必要的东西，不是全量初始化。
- 检测启动介质：看看你是从eMMC启动，还是NAND Flash，还是SD卡，还是USB？
- 加载并校验下一级引导程序：也就是SPL（Secondary Program Loader）或者叫MLO。这一步通常伴随着安全校验。
我在项目中遇到过一个问题：某款芯片的BootROM在检测eMMC时，默认只支持HS200模式。结果我们用的eMMC颗粒只支持HS400，导致启动卡死。嗯，这种坑，芯片手册里往往只写一行字，但实际排查要花两天。
4.2 启动介质选择：eMMC vs NAND
BootROM怎么知道从哪个设备启动？它有一套固定的优先级策略。我列个表，你一看就明白：
| 启动介质 | 典型场景 | BootROM检测方式 | 我的经验 |
|---|---|---|---|
| eMMC | 车机主存储，主流方案 | 发送CMD0/CMD1，读取CID/CSD | 注意分区配置，BootROM只认特定分区 |
| NAND Flash | 低成本方案，老平台常见 | 读取ID字节，匹配时序参数 | 坏块管理是噩梦，BootROM不处理坏块 |
| SD卡 | 工厂烧录、调试模式 | SPI模式或SD模式检测 | 我习惯用SD卡做紧急恢复 |
| USB/串口 | 开发调试、刷机模式 | 检测D+/D-电平或RX引脚电平 | 量产时一定要禁用，否则有安全风险 |
这里有个关键点：BootROM的启动顺序通常由芯片的BOOT引脚电平决定。你设计硬件时，这几个引脚一定要拉对。我曾经见过一个项目，硬件工程师把BOOT引脚悬空了，结果芯片每次启动都随机选介质，时好时坏。排查了三天才发现是这个问题。
4.3 安全启动校验：从BootROM就开始的信任链
车机系统为什么特别强调安全启动？因为一旦BootROM被篡改，整个系统就沦陷了。所以，现代车规级芯片的BootROM都内置了安全启动机制。
它的流程大致是这样的：
- BootROM读取eMMC/NAND中特定位置的公钥哈希（通常是SHA256或SHA512）。
- 用这个哈希验证下一级引导程序（SPL）的数字签名。签名算法常见的是RSA2048或ECDSA。
- 如果签名验证通过，才把控制权交给SPL。否则，芯片直接死循环或进入安全错误状态。
你可能会问：「公钥哈希存在Flash里，那BootROM怎么保证它没被改过？」
好问题。答案是：公钥哈希本身是烧写在芯片的一次性可编程（OTP）区域里的。这个区域出厂后只能写一次，谁也改不了。BootROM只信任OTP里的哈希值。
核心要点：安全启动的根信任，就是芯片OTP里的那几字节数据。这是整个信任链的锚点。
4.4 代码层面的视角：BootROM怎么加载SPL？
我们来看一个简化的伪代码流程。虽然你拿不到芯片厂商的BootROM源码，但逻辑是通用的：
// BootROM 伪代码示意
void bootrom_main() {
// 1. 初始化最小系统
init_cpu();
init_stack();
// 2. 根据BOOT引脚选择启动介质
boot_device_t dev = detect_boot_device();
// 3. 从介质读取SPL头部
spl_header_t header;
read_spl_header(dev, &header);
// 4. 安全校验（如果使能）
if (secure_boot_enabled()) {
// 从OTP读取公钥哈希
uint8_t expected_hash[32];
read_otp_hash(expected_hash);
// 验证SPL签名
if (!verify_signature(&header, expected_hash)) {
// 校验失败，死循环
while(1);
}
}
// 5. 加载SPL到SRAM
load_spl_to_sram(dev, header.load_addr);
// 6. 跳转到SPL入口
jump_to(header.entry_point);
}这段代码里，verify_signature 是最关键的一步。我建议你在做安全启动调试时，先把这个函数的行为摸清楚。比如，它用的是RSA还是ECDSA？签名长度是多少？这些信息芯片手册里都有，但往往藏在附录里。
我的小技巧：调试安全启动时，可以先在芯片的OTP里烧录一个「测试公钥」，对应的私钥自己保管。这样既能验证流程，又不会影响量产密钥。我曾经用这个方法，帮团队节省了两周的调试时间。
4.5 避坑指南：BootROM阶段的常见问题
嗯，这里我总结几个实战中踩过的坑，你遇到了可以少走弯路：
- eMMC的Boot分区配置：很多芯片的BootROM只认eMMC的Boot Area Partition 1。如果你把SPL放到了User Data分区，它根本不会去读。我建议你在硬件设计阶段就把分区规划好。
- NAND的坏块问题：BootROM通常不处理NAND坏块。如果你的SPL恰好写在坏块上，启动就挂了。解决方案是：要么用eMMC，要么在NAND的BBT（Bad Block Table）里预留好位置。
- 时钟配置：BootROM阶段用的是芯片内部RC振荡器，精度不高。如果你在SPL里突然切到外部晶振，时序没衔接好，可能会死机。我习惯在SPL里先稳定时钟，再干别的。
- 安全启动的调试模式：有些芯片有「调试模式」，可以绕过安全校验。量产时一定要关闭这个模式，否则等于给攻击者留了后门。
警告：千万不要在生产环境中使用「调试模式」或「测试公钥」。我曾经见过一个团队，量产时忘了切回正式密钥，结果所有车机的安全启动都是摆设。这个锅，谁也背不起。
4.6 小结
BootROM阶段虽然代码量不大，但它是整个启动流程的基石。我个人觉得，理解BootROM的关键就三点：
- 它怎么找到启动介质？——靠BOOT引脚和硬件检测。
- 它怎么保证安全？——靠OTP里的根信任和签名校验。
- 它怎么把接力棒交给SPL？——加载到SRAM，然后跳转。
下一章，我们会深入SPL（二级引导）的细节。到时候你会看到，BootROM只是开了个头，真正的硬件初始化才刚刚开始。