4、Bootloader设计：启动流程、向量表重映射与固件签名校验
好，咱们进入Bootloader的设计环节。这部分我把它看作是OTA升级的“守门员”——它决定了你的设备能不能安全、可靠地完成升级。说白了，Bootloader就是上电后第一个跑起来的程序，它负责检查要不要升级、升级谁、怎么升级。
我个人习惯把Bootloader设计成“小而精”的模块。为什么？因为Bootloader一旦出问题，设备就变砖了。我在项目中遇到过好几次因为Bootloader写得太大、太复杂，结果升级过程中把自己搞崩溃的情况。嗯，那滋味可不好受。
4.1 Bootloader的启动流程
一个典型的Bootloader启动流程，我把它拆成下面几步：
- 硬件初始化：关看门狗、设置系统时钟、初始化堆栈。这一步要快，别磨蹭。
- 检查启动原因：是上电复位？还是看门狗复位？还是从APP跳过来的？
- 检查升级标志：在Flash的某个固定位置，看看有没有“我要升级”的标记。
- 固件校验：如果有新固件，先验签名、验CRC。通不过？那就别升级了。
- 跳转执行：要么跳转到APP，要么进入升级模式。
你想想看，这个流程其实很像一个安检通道。每个步骤都有明确的目的，不能乱。
核心原则：Bootloader的代码要尽量精简，不要依赖复杂的库函数。我见过有人把RTOS都塞进Bootloader里，结果升级时内存不够，直接死机。
4.2 向量表重映射
这是Bootloader设计里最容易踩坑的地方。什么是向量表？就是中断服务函数的入口地址表。芯片上电后，默认从Flash起始地址（通常是0x08000000）读取向量表。
但问题来了：你的APP可能放在0x08020000，那中断来了怎么办？芯片还是去0x08000000找中断函数，结果找到的是Bootloader的，不是APP的。这就乱套了。
解决方案就是向量表重映射。说白了，就是告诉CPU：“嘿，别去老地方找中断了，去新地址找。”
具体怎么做？以STM32为例，有两种方式：
- 方式一：修改SCB->VTOR寄存器。这是最常用的方法。在跳转到APP之前，把VTOR的值改成APP的起始地址。
- 方式二：使用Bootloader做中断转发。Bootloader自己接管所有中断，然后根据当前运行的是Bootloader还是APP，决定把中断转发给谁。这种方式更灵活，但代码量也更大。
我个人推荐方式一，简单直接。但要注意一点：VTOR寄存器不是所有芯片都支持。我记得有一次用某款国产MCU，它的VTOR是只读的，折腾了我一整天。最后只能用方式二，自己写了个中断转发表。
我的经验：在跳转到APP之前，一定要把Bootloader用到的所有外设都关掉，尤其是中断。我曾经因为忘了关定时器中断，结果APP一启动就被中断打飞了。
下面是一个简单的向量表重映射代码示例：
/* 假设APP起始地址为0x08020000 */
#define APP_ADDRESS 0x08020000
/* 跳转到APP的函数 */
void jump_to_app(void)
{
uint32_t app_stack;
void (*app_entry)(void);
/* 1. 关闭所有中断 */
__disable_irq();
/* 2. 关闭所有外设时钟（根据实际情况） */
/* ... */
/* 3. 设置向量表偏移 */
SCB->VTOR = APP_ADDRESS;
/* 4. 从APP向量表读取栈顶指针和入口地址 */
app_stack = *(uint32_t *)APP_ADDRESS;
app_entry = (void (*)(void))(*(uint32_t *)(APP_ADDRESS + 4));
/* 5. 设置主栈指针 */
__set_MSP(app_stack);
/* 6. 使能中断并跳转 */
__enable_irq();
app_entry();
}
这里有个细节：先关中断，再改VTOR，最后开中断。顺序不能乱。为什么？因为如果在改VTOR的过程中来了中断，CPU会去一个不确定的地方找中断函数，结果就是HardFault。
4.3 固件签名校验
固件签名校验，说白了就是确保你下载的固件是“正品”，不是被人篡改过的。这在OTA升级里尤其重要——你想想看，如果升级包在半路上被人改了，设备下载了一个带后门的固件，那后果不堪设想。
我常用的签名校验流程是这样的：
- 生成签名：在PC端，用私钥对固件哈希值进行签名，生成签名数据。
- 打包：把固件、签名数据、公钥（或公钥哈希）打包成一个升级包。
- 验签：设备收到升级包后，用公钥解密签名，得到哈希值A。然后自己计算固件的哈希值B。如果A==B，说明固件没被改过。
这里用的算法，我推荐ECDSA（椭圆曲线数字签名算法）。为什么？因为它的签名短、计算快，适合资源受限的嵌入式设备。RSA也行，但密钥太长，算起来也慢。
| 算法 | 签名长度 | 计算速度 | 推荐场景 |
|---|---|---|---|
| ECDSA (P-256) | 64字节 | 快 | 大部分BLE设备 |
| RSA (2048) | 256字节 | 慢 | 资源较丰富的设备 |
| HMAC-SHA256 | 32字节 | 极快 | 对称密钥场景（不推荐用于OTA） |
注意：HMAC虽然快，但它是对称的。也就是说，知道密钥的人也能伪造签名。在OTA升级里，我建议用非对称签名，私钥只保存在服务器端，设备只存公钥。这样就算设备被破解了，攻击者也拿不到私钥。
我曾经在一个项目中，客户要求用HMAC做签名校验。我当时就提醒过：“这样不安全。”但客户说“没事，我们的产品不值钱。”结果呢？产品上市三个月，就被人破解了，伪造的固件满天飞。后来还是改成了ECDSA。
验签的代码实现，我一般会放在Bootloader里。因为APP可能已经被篡改了，你不能信任APP的验签结果。只有Bootloader是“可信根”。
/* 验签函数伪代码 */
bool verify_firmware(uint8_t *firmware, uint32_t len,
uint8_t *signature, uint8_t *public_key)
{
uint8_t hash[32];
uint8_t computed_hash[32];
/* 1. 计算固件的SHA256哈希 */
sha256(firmware, len, hash);
/* 2. 用公钥验证签名 */
if (ecdsa_verify(public_key, hash, signature) == 0) {
return true; /* 验签通过 */
} else {
return false; /* 验签失败 */
}
}
这里有个容易被忽略的点：公钥怎么存？我建议把公钥直接编译进Bootloader的代码里，或者写在Flash的只读区域。千万不要从升级包里读取公钥——那等于把锁的钥匙放在锁旁边，毫无意义。
避坑指南：我曾经把公钥放在升级包的头部，想着“这样方便更换”。结果被安全审计的人骂了一顿。后来改成把公钥哈希也存一份在Bootloader里，验签时先比对公钥哈希，再验签名。这样就算升级包被换了公钥，也过不了哈希比对这一关。
最后，总结一下Bootloader设计的三个关键点：
- 启动流程要清晰：先初始化，再判断，最后跳转。每一步都要有明确的退出条件。
- 向量表重映射要小心：关中断、改VTOR、开中断，顺序不能错。不同芯片的VTOR实现可能不同，一定要看数据手册。
- 固件签名校验要可靠：用非对称算法，公钥固化在Bootloader里。验签失败就拒绝升级，别给攻击者留机会。
嗯，Bootloader这部分就讲到这里。下一章咱们聊聊升级过程中的“断点续传”和“失败回滚”，这两个功能在实际项目中非常实用。