3、Bootloader设计要点

Bootloader 是 OTA 升级的第一道关卡，也是最后一道防线。说它重要，是因为一旦 Bootloader 出问题，设备基本就变砖了。我这些年经手的项目，至少有一半的升级事故都出在 Bootloader 设计上。

今天咱们就聊聊 Bootloader 的几个核心设计点：启动流程、A/B 双备份、回滚策略，还有签名校验。这些点搞明白了，OTA 升级的底子就算打牢了。

3.1 Bootloader 的启动流程

一个典型的 Bootloader 启动流程，其实没那么复杂。我习惯把它分成四个阶段：

1. 硬件初始化：关看门狗、设置时钟、初始化 DDR/Flash
2. 启动模式判断：检查启动引脚、检测升级请求标志
3. 镜像校验与选择：校验签名、检查版本、决定启动哪个分区
4. 跳转执行：设置栈指针、跳转到应用入口

嗯，这里要注意一个细节：硬件初始化要尽量精简。我在项目中遇到过，Bootloader 里初始化了太多外设，结果跳转时没清理干净，应用跑起来就崩了。所以我的原则是——只初始化必要的外设，够用就行。

3.2 双备份机制（A/B 系统）

双备份，说白了就是准备两套应用分区。一套在跑，另一套等着被升级。这样即使升级过程中断电、断网，设备还能从另一套系统启动。

我最早做 OTA 时用的是单分区方案，升级失败就只能进 recovery 模式，用户体验极差。后来换了 A/B 系统，才算是真正解决了「升级变砖」的问题。

A/B 系统的分区布局

分区	用途	大小建议
Bootloader	启动管理、升级入口	64KB - 256KB
Slot A (应用)	当前运行的应用镜像	根据固件大小定
Slot B (应用)	备份/待升级镜像	与 Slot A 相同
Metadata	记录当前槽位、升级状态	4KB - 16KB

Metadata 这块很多人会忽略。我建议用 冗余存储 + CRC 校验，防止写入时掉电导致状态丢失。我曾经就吃过这个亏，Metadata 写了一半断电，重启后 Bootloader 不知道该启动哪个分区，直接卡死了。

A/B 切换逻辑

切换逻辑其实就一句话：新镜像跑成功了，才切换槽位。具体流程如下：

1. 设备当前从 Slot A 启动
2. OTA 下载新镜像到 Slot B
3. 重启后 Bootloader 检测到 Slot B 有新镜像，尝试启动
4. 如果 Slot B 启动成功（应用上报健康状态），则标记 Slot B 为 active
5. 如果启动失败，回退到 Slot A

3.3 回滚策略

回滚策略，说白了就是「万一新版本翻车了，怎么退回去」。我见过不少团队只做了升级，没做回滚，结果线上出问题只能派人去现场刷机。

常见的回滚策略有三种：

策略	原理	适用场景
自动回滚	新版本启动失败，自动切回旧版本	大多数 IoT 设备
手动回滚	保留旧版本，用户/运维手动触发回滚	网关、边缘计算设备
版本锁定	升级后锁定版本，不允许回滚到旧版	安全合规要求高的场景

我个人比较推荐 自动回滚 + 有限次数重试 的组合。比如：新版本启动失败，自动回滚到旧版本，并记录失败次数。如果连续失败 3 次，就停止自动升级，等待人工介入。这样可以避免「升级-回滚-再升级」的死循环。

3.4 签名校验流程

签名校验是 OTA 升级的安全基石。没有签名校验，攻击者可以随便往设备里刷恶意固件。我见过一些团队为了省事，只在服务器端做校验，设备端直接信任下载下来的数据——这等于把家门钥匙挂在门外。

签名校验的标准流程

1. 固件打包：在服务器端，用私钥对固件哈希值签名，生成签名文件
2. 固件分发：固件 + 签名文件一起下发到设备
3. 设备端校验：Bootloader 用公钥解密签名，得到哈希值，再与本地计算的固件哈希比对
4. 一致则通过，不一致则拒绝启动

这里的关键是 公钥的存储安全。公钥如果被篡改，签名校验就形同虚设。我建议把公钥烧录在芯片的一次性可编程区域（OTP）或安全元件中，防止被替换。

代码示例：签名校验核心逻辑

// 伪代码：Bootloader 中的签名校验
int verify_firmware(uint8_t *firmware, uint32_t size, 
                    uint8_t *signature, uint32_t sig_len) {
    uint8_t hash[SHA256_DIGEST_LENGTH];
    
    // 1. 计算固件哈希
    sha256(firmware, size, hash);
    
    // 2. 用公钥解密签名，得到原始哈希
    uint8_t decrypted_hash[SHA256_DIGEST_LENGTH];
    rsa_decrypt(signature, sig_len, public_key, decrypted_hash);
    
    // 3. 比对哈希值
    if (memcmp(hash, decrypted_hash, SHA256_DIGEST_LENGTH) == 0) {
        return VERIFY_SUCCESS;
    } else {
        return VERIFY_FAILED;
    }
}

3.5 整体流程框架图

下面这张图把 Bootloader 的启动、A/B 切换、回滚和签名校验串在了一起。你可以把它当作设计时的参考蓝图。

这张图把整个流程串起来了。你可以看到，签名校验在启动早期就执行了，通不过就直接拒绝，不给你后续操作的机会。A/B 切换和回滚策略则是在 Metadata 读取之后才决策的。