4、固件加载核心机制：从启动设备读取头部信息、校验签名与完整性、解压缩算法（LZMA/Gzip）、跳转到固件入口点
固件加载，说白了就是 BootROM 把存放在外部存储设备上的固件，搬到内部 RAM 里，然后跳过去执行。这个过程看似简单，但里面全是坑。我这些年调试过的启动失败案例，十有八九都出在这几个环节上。
你想想看，BootROM 本身只有几 KB 到几十 KB，它要完成读取、校验、解压、跳转这一整套动作。任何一个环节出问题，设备就变砖了。嗯，咱们今天就把这个流程拆开揉碎了讲清楚。
核心流程一览：
- 从启动设备读取固件头部信息
- 校验签名与完整性
- 解压缩算法（LZMA / Gzip）
- 跳转到固件入口点
4.1 从启动设备读取头部信息
BootROM 上电后第一件事，就是按照预定义的启动设备列表，挨个尝试读取固件头部。这个头部通常放在存储介质的固定偏移位置——比如 SPI Flash 的 0x0 地址，或者 eMMC 的 Boot Partition 1 的起始扇区。
头部信息长什么样？我直接给个典型结构体定义，你一看就明白：
// 典型的固件头部结构
typedef struct {
uint32_t magic; // 魔数，用于识别固件格式，比如 0x4649524D ("FIRM")
uint32_t header_size; // 头部自身大小
uint32_t firmware_size; // 固件总大小（压缩后）
uint32_t load_addr; // 加载到 RAM 的目标地址
uint32_t entry_point; // 固件入口地址
uint32_t checksum; // 头部校验和
uint8_t hash[32]; // SHA-256 哈希值
uint8_t signature[256]; // RSA 签名
uint32_t compression; // 压缩算法标识：0=无压缩，1=Gzip，2=LZMA
uint32_t reserved[8]; // 保留字段
} firmware_header_t;这里有个细节我特别想强调：魔数一定要选对。我曾经见过一个项目，工程师把魔数定义成 0xDEADBEEF，结果 SPI Flash 里全 0xFF 的时候，BootROM 误判为有效头部，直接跑去加载垃圾数据。后来我们改成 0x4649524D（"FIRM" 的 ASCII），配合额外的反转位校验，才彻底解决这个问题。
我的建议：头部结构体最好按 4 字节对齐，所有字段用固定大小类型（uint32_t / uint8_t），不要用 int 这种平台相关的类型。跨芯片移植时能省很多麻烦。
4.2 校验签名与完整性
头部读进来之后，BootROM 要干两件事：完整性校验和签名校验。完整性校验保证固件没被篡改或损坏，签名校验保证固件来自可信源。
完整性校验通常用哈希算法，比如 SHA-256。BootROM 把固件内容算一遍哈希，跟头部里存的哈希值比对。不一样？直接停。
签名校验更复杂一些。常见做法是用 RSA 或 ECDSA。BootROM 内部预置了公钥，用这个公钥去解签名，得到哈希值，再跟固件的哈希比对。嗯，这里要注意，公钥是烧死在 BootROM 里的，改不了。所以一旦芯片出厂，能启动的固件就被锁死了。
| 校验类型 | 算法 | 作用 | 典型耗时（@200MHz） |
|---|---|---|---|
| 完整性校验 | SHA-256 | 检测固件是否损坏 | ~5ms（256KB 固件） |
| 签名校验 | RSA-2048 | 验证固件来源可信 | ~50ms |
| 签名校验 | ECDSA P-256 | 验证固件来源可信 | ~15ms |
避坑指南：我曾经遇到过一个 case，BootROM 的 SHA-256 实现有 bug，处理非对齐数据时算出来的哈希值不对。固件明明没坏，就是启动不了。排查了整整两天才发现是哈希算法实现的问题。所以，BootROM 里的密码学算法一定要经过充分的单元测试，最好有硬件加速器加持。
4.3 解压缩算法（LZMA / Gzip）
固件为什么要压缩？说白了就是为了省存储空间。SPI Flash 贵啊，能省一点是一点。而且压缩后的固件读取时间更短，整体启动速度反而可能更快。
BootROM 里常见的压缩算法有两种：Gzip 和 LZMA。Gzip 解压速度快，但压缩率一般。LZMA 压缩率高，但解压需要更多内存和计算时间。
| 算法 | 压缩率（典型） | 解压速度 | 内存需求 | 适用场景 |
|---|---|---|---|---|
| Gzip | 50% ~ 60% | 快（~10MB/s @200MHz） | ~32KB | 启动时间敏感的场景 |
| LZMA | 30% ~ 40% | 慢（~3MB/s @200MHz） | ~128KB | 存储空间敏感的场景 |
解压缩的实现有几个关键点：
- 解压缓冲区要足够大——LZMA 需要字典缓冲区，太小了解不出来。
- 解压时要支持流式处理——BootROM 的 RAM 有限，不能把整个固件读进来再解压，得边读边解。
- 解压后的固件不能覆盖解压器自身——这是个经典问题。解压器代码本身也在 RAM 里跑，如果解压目标地址跟解压器代码重叠，那就自毁了。
我的经验：我习惯在固件头部里加一个字段，标明解压后的固件大小。这样 BootROM 可以提前检查目标地址范围，避免覆盖。另外，解压器的代码最好放在 BootROM 的末尾，跟固件加载地址留出足够的安全间距。
4.4 跳转到固件入口点
解压完成后，固件已经完整地躺在 RAM 里了。最后一步：跳过去执行。
跳转不是简单的函数调用。BootROM 需要做几件事：
- 关闭中断——确保跳转过程中不会被中断打断。
- 设置栈指针——固件入口点通常需要一个新的栈，BootROM 要把 SP 指向固件指定的栈地址。
- 清理 BSS 段——有些 BootROM 会帮固件把 BSS 段清零，但不是必须的。我建议固件自己处理。
- 跳转——用汇编指令直接修改 PC 寄存器，或者用函数指针跳转。
// 跳转到固件入口点的汇编代码示例（ARM Cortex-M）
__attribute__((naked)) void jump_to_firmware(uint32_t entry, uint32_t sp) {
__asm volatile (
"MSR MSP, %0\n" // 设置主栈指针
"ISB\n" // 指令同步屏障
"BX %1\n" // 跳转到入口地址
:
: "r"(sp), "r"(entry)
: "memory"
);
}这里有个容易忽略的细节：跳转前要把外设恢复到初始状态。BootROM 可能初始化了某些外设（比如时钟、DDR 控制器），如果不恢复，固件启动时可能会出问题。我见过一个案例，BootROM 把 PLL 配成了 400MHz，跳转后固件又配了一次，结果中间产生了 glitch，系统直接死掉。
我的建议：在跳转前，BootROM 最好把用过的外设都复位到默认状态。如果实在不方便复位，至少要在文档里明确告诉固件开发者：哪些外设已经被初始化了，初始值是什么。这样固件才能正确处理。
嗯，固件加载的核心机制就这些。从读取头部到跳转入口，每一步都环环相扣。你想想看，BootROM 在只有几 KB 代码的情况下，要完成哈希计算、RSA 验签、LZMA 解压、安全跳转这一整套动作，确实不容易。但正是这些机制，保证了设备从冷启动到固件运行的安全可靠。