3、Bootloader设计：一级启动与二级启动，安全校验机制
好，咱们今天聊聊Bootloader。说实话，这是整个固件在线升级方案里最核心、也最容易翻车的地方。我见过不少项目，应用层代码写得漂漂亮亮，结果Bootloader一跑就死机，最后整颗卫星都得回厂重刷。嗯，咱们得把这事整明白。
3.1 为什么需要两级启动？
你想想看，星载计算机上电那一刻，CPU刚醒来，外设还没初始化，内存可能都还没稳定。这时候如果直接加载一个几百KB的固件镜像，风险太大了。我个人习惯的做法，是把启动过程拆成两级：
- 一级启动（Primary Bootloader）：固化在ROM里，不可修改。负责最基本的硬件初始化，然后去校验二级Bootloader。
- 二级启动（Secondary Bootloader）：存放在Flash里，可以升级。负责加载应用固件，处理升级流程。
为什么要这么分？说白了，一级启动是「保底」的。就算二级Bootloader刷坏了，一级启动还在，还能通过某种方式恢复。我在项目中遇到过，有一次二级Bootloader的Flash区域被宇宙射线打坏了几个bit，结果一启动就校验失败。还好一级启动里有个回退逻辑，直接跳到备份区，卫星才没丢。
核心原则：一级启动越简单越好，只做最必要的事。复杂逻辑都交给二级启动。
3.2 一级启动设计要点
一级启动的代码量，我建议控制在2KB以内。为什么？因为很多MCU的ROM空间就那么点，而且代码越少，出bug的概率越低。
一级启动通常做这几件事：
- 时钟初始化：把CPU时钟从默认的低速模式切换到工作频率。注意，这里不要做太复杂的PLL配置，稳定第一。
- 关键外设初始化：比如看门狗、基本的中断控制器。其他外设留给二级启动去搞。
- 校验二级Bootloader：这是重点。用CRC或者哈希算法，检查二级Bootloader的完整性。
- 跳转：如果校验通过，就跳转到二级Bootloader的入口地址。
这里有个坑，我提醒一下：跳转前一定要关中断，把栈指针重新设置好。不然跳过去之后，中断向量表乱了，程序直接飞掉。
// 一级启动跳转示例（简化版）
void jump_to_secondary(void) {
// 1. 关中断
__disable_irq();
// 2. 重置栈指针
__set_MSP(*(uint32_t*)SECONDARY_BOOT_ADDR);
// 3. 获取二级Bootloader的入口地址
uint32_t entry = *(uint32_t*)(SECONDARY_BOOT_ADDR + 4);
// 4. 跳转
void (*bootloader)(void) = (void (*)(void))entry;
bootloader();
// 这里永远不会回来
}
警告：跳转前记得把用过的外设复位到默认状态。我曾经忘了关一个定时器，跳转后二级Bootloader初始化时发现定时器还在跑，直接卡死在中断里。
3.3 二级启动设计要点
二级启动就灵活多了。它负责加载应用固件，同时处理在线升级的整个流程。我个人习惯把二级启动分成几个阶段：
| 阶段 | 任务 | 说明 |
|---|---|---|
| 初始化 | 完整硬件初始化 | 包括DDR、Flash控制器、通信接口等 |
| 校验 | 检查应用固件完整性 | 使用签名验证，防止篡改 |
| 加载 | 将固件从Flash拷贝到RAM | 如果支持XIP（就地执行），可以跳过 |
| 跳转 | 执行应用固件 | 同样要关中断、重置栈 |
二级启动里，我最看重的是「升级失败后的恢复机制」。你想想看，卫星在天上，升级到一半突然通信断了怎么办？固件写到一半掉电了怎么办？
我的做法是：永远保留一个「黄金备份」。Flash里至少放两个应用固件区：一个运行区，一个备份区。升级时先写备份区，校验通过后再把备份区的内容复制到运行区。如果升级过程中出问题，二级启动检测到运行区校验失败，就自动从备份区启动。
小技巧：在Flash里留一个「启动标志」字节。每次启动时，二级启动先检查这个标志。如果标志显示「上次升级未完成」，就直接跳到备份区。这个标志要放在独立的Flash扇区里，防止被意外擦除。
3.4 安全校验机制
安全校验，说白了就是确保你加载的固件是「对的」。对在哪里？两个维度：
- 完整性：固件没有被损坏或篡改
- 合法性：固件来自可信的源头
完整性校验，我一般用CRC32或者SHA256。CRC32速度快，适合在启动时快速检查。SHA256更安全，但计算量大。我的建议是：一级启动用CRC32，二级启动用SHA256。
合法性校验，就得用数字签名了。流程大概是这样的：
- 地面站用私钥对固件镜像签名
- 星载计算机用公钥验证签名
- 验证通过才允许加载
公钥存在哪里？存在一级启动的ROM里。这样就算二级Bootloader被攻破了，攻击者也改不了公钥。
// 签名验证伪代码
bool verify_firmware(uint8_t* firmware, uint32_t size, uint8_t* signature) {
// 1. 计算固件的哈希值
uint8_t hash[32];
sha256_calculate(firmware, size, hash);
// 2. 用公钥解密签名，得到原始哈希
uint8_t decrypted_hash[32];
rsa_decrypt(signature, decrypted_hash, PUBLIC_KEY);
// 3. 比较两个哈希
return memcmp(hash, decrypted_hash, 32) == 0;
}
重要提醒：公钥一定要在编译一级启动时就固化进去。我见过有人把公钥放在Flash里，结果被攻击者替换了公钥，整个安全体系就形同虚设了。
3.5 避坑指南
做Bootloader这些年，我踩过的坑不少。挑几个典型的说说：
- 中断向量表重映射：跳转到应用固件后，中断向量表要重新指向应用区。不然按个按钮，CPU跑到了Bootloader的中断处理函数里，直接死机。
- 看门狗定时器：启动过程中，看门狗可能会超时复位。我习惯在进入二级启动前先喂一次狗，然后设置一个较长的超时时间。
- Flash擦写寿命：星载Flash的擦写次数有限，一般10万次左右。频繁升级会消耗寿命。我建议在升级前先检查Flash的磨损情况，如果某个扇区擦写次数太多，就换一个扇区用。
- 时序问题：有些外设初始化需要时间，比如DDR的PLL锁定。如果跳转太快，外设还没准备好，应用固件一运行就出错。嗯，这里要加适当的延时。
最后说一句：Bootloader的设计，本质上是在「简单可靠」和「功能丰富」之间找平衡。我个人更倾向于简单。毕竟在太空中，你没法远程debug，越简单的逻辑越不容易出错。