MCUboot 整理

因为孤陋寡闻,看到MCUboot在做的A/B Image的方案时大惊失色,居然有两种我从来没想过的妙法,求助为Deepseek帮忙整理,我就是简单搬运下。

MCUboot作为专为资源受限微控制器设计的开源安全引导加载程序,支持多种固件升级模式,其中Overwrite(覆盖)、Swap(交换)和Direct XIP(就地执行) 是最核心的三种方案。以下是这三种方案的详细对比,涵盖工作原理、优缺点及适用场景:


📊 三种方案核心特性对比

特性 Overwrite模式 Swap模式 Direct XIP模式
升级机制 新固件直接覆盖主槽(Primary Slot) 主槽(Slot0)与备槽(Slot1)内容交换 新固件在备槽(Slot1)中直接执行
回滚支持 ❌ 不支持(旧固件被覆盖) ✅ 支持(旧固件保留在备槽) ✅ 支持(旧固件保留在主槽)
启动时间 中等(需擦写主槽) 较长(需多次擦写+交换) 最短(无需拷贝或交换)
空间需求 最小(无需备用槽和暂存区) 最大(需备用槽+暂存区Scratch) 中等(需备用槽,无需暂存区)
Flash擦写次数 2次擦除(主槽+备槽) + 1次写入(主槽) 多次擦写(与Slot大小相关) 0次(仅写入备槽)
安全校验 ✅ 升级前校验备槽固件 ✅ 交换前校验备槽固件 ✅ 跳转前校验备槽固件
适用存储类型 片上Flash 片上Flash 片上Flash(外部Flash需地址映射)
加密支持 ✅ 支持 ✅ 支持 ⚠️ 外部Flash不支持加密

🔍 详细方案解析

1. Overwrite模式

  • 工作原理
    新固件下载至备槽(Slot1)→ 重启后Bootloader校验固件 → 直接覆盖主槽(Slot0) → 跳转至主槽运行。
  • 优点
    • 代码量最小,Bootloader占用资源少;
    • 实现简单,适合Flash空间紧张的场景。
  • 缺点
    • 无回滚能力,升级失败可能变砖;
    • 升级时间长(需完整擦写主槽)。
  • 适用场景
    对空间敏感、无需版本回退的轻量级设备(如传感器节点)。

2. Swap模式

  • 工作原理
    新固件下载至备槽(Slot1)→ 重启后Bootloader校验固件 → 通过暂存区(Scratch)交换主备槽内容 → 跳转至主槽运行新固件。
  • 优点
    • 支持版本回滚(旧固件保留在备槽);
    • 升级过程可恢复(交换失败可回退)。
  • 缺点
    • 需额外暂存区(Scratch),占用Flash空间;
    • 启动时间最长(交换操作耗时)。
  • 适用场景
    需高可靠性的设备(如工业控制器、医疗设备)。

3. Direct XIP模式

  • 工作原理
    新固件下载至备槽(Slot1)→ 重启后Bootloader校验固件 → 直接跳转至备槽执行(无需拷贝或交换)。
  • 优点
    • 启动最快(无擦写操作);
    • 保留旧固件在主槽,支持快速回退。
  • 缺点
    • 不支持外部Flash或加密固件(需地址映射);
    • 需确保备槽地址可执行(链接脚本需适配)。
  • 适用场景
    启动速度要求高的场景(如实时控制系统),且使用片上Flash。

⚖️ 方案选择建议

考量因素 推荐方案 理由
空间紧张 Overwrite Bootloader体积最小,无额外分区需求
高可靠性要求 Swap 支持回滚,抗升级中断
快速启动 Direct XIP 无拷贝操作,启动延迟最低
外部Flash存储 Overwrite/Swap Direct XIP受限于地址映射
固件加密 Overwrite/Swap Direct XIP与加密不兼容

💎 总结

  • Overwrite:轻量易实现,牺牲回滚能力换取空间优化;
  • Swap:功能全面,适合对可靠性要求高的场景;
  • Direct XIP:性能最优,但受限于硬件存储布局。

实际选型需结合Flash容量、启动速度、回滚需求硬件支持(如外部Flash)综合评估。对于资源极度受限的设备,可优先测试Overwrite;若需平衡安全与效率,Swap是通用选择;而Direct XIP更适合实时性要求严苛的系统。