介绍MCUboot支持的四种升级模式(2)

介绍MCUboot支持的四种升级模式，分别是Overwrite、Swap、Direct XIP和加载到RAM中执行。由于FSP不支持第四种——加载到RAM中执行，因为我们重点介绍前三种。

Direct XIP（Execute In Place）模式

MCUboot Direct XIP模式流程图

接下来我们看第三种升级模式，Direct XIP（Execute In Place），跟前两种模式Overwrite和Swap最大的不同在于，代码是就地执行的，即升级后的代码直接在Secondary Slot中执行。

上电后芯片中烧录的是Bootloader和Primary Slot中User Application v1.0，运行的过程中，芯片收到升级指令，接收新firmware并烧录到Secondary Slot中，然后跳转至Secondary Slot中执行。

如果查看升级操作的起始状态和结束状态会发现，芯片从运行Primary Slot中的低版本v1.0代码变为运行Secondary Slot中的高版本v2.0代码，因此完成了一次升级。

从Direct XIP模式的流程可以看出它的一些特点：

支持代码回滚/回退/降级。由于升级完成后，低版本v1.0 Image依然存储在芯片中，因此若在高版本v2.0 上发现bug需要修复，则有机会重新执行升级程序使得代码回到v1.0。

升级过程中不涉及对flash的擦除和写入操作，因此Boot时间较短，是三种模式中时间最短的。

关于各种模式之间的更多细节比较，请参考下图中的内容：

各升级模式特性比较

关于Secondary Slot的属性，既可以是片上flash，也可以是外部flash。FSP对外部的支持为QSPI Flash，可以映射到地址总线上的存储空间。假如利用外部flash如QSPI作为Secondary slot，则不支持Direct XIP模式。

另外，由于映像文件Image的传输途径可能具有潜在风险，又或者使用外部flash存储新Image担心被盗用，则推荐使用加密存储的方式。假如使用加密存储，则不支持Direct XIP模式。

前面提到了MCUboot可以实现安全boot，即判断目标Image的完整性和合法性，根据结果决定是否执行固件升级操作，这个过程也可以叫做安全校验。

安全校验的设计可谓丰俭由人，整体的原则是，安全级别越高，带来的代码量增加越大，启动时间越长。

MCUboot的安全校验意味着，待更新的Image文件需要增加一些标识，才能被bootloader识别，原始的文件无法通过安全校验。

下面的图展示了处理后的Application Image各部分信息。

利用Python脚本处理后的Application Image

MCUboot的安全校验的实现方式包括：

增加Header，位于更新后的Bootloader和Application实际起始地址中间。其中包含了丰富的信息，比较关键的部分如Image的版本及大小。

增加TLV (Type Length Value)，紧跟在Application之后。其中包含了Image文件对应的HASH哈希值和对Image文件生成的签名信息。

增加Trailer，位于Slot顶端，和TLV之间会填充固定数值。根据升级模式的不同，Trailer的格式和含义也不同，在此不展开。值得一提的是，对于Swap模式，Trailer中包含了Bootloader进行升级时的判断标志，更多细节请参考MCUboot官网对于此部分的说明。

由于Bootloader占用了flash空间0地址开始的部分且大小几乎不变，因此在设计的时候，需评估flash的空间划分，使得Bootloader尽量小以让出更多空间给Application利用。关于Bootloader优化，我们不在本章中展开说明。

决定Bootloader大小的关键要素有以下几个：

升级模式，Overwrite最小，Swap最大

安全校验的级别，级别越高代码量越大

对于Flash划分，需要遵循的基本原则是，每个区域（Bootloader，Primary Slot和Secondary Slot）均占据完整的Block size，具体到RA产品，请在硬件手册中确认Block size的值。

以RA6M4 1M Code Flash产品为例，共有38个Block，其中低8个Block大小为8KB，高地址上的Block大小均为32KB。

RA6M4 Flash Block地址信息

本章总结

本篇我们介绍了MCUboot的基本概念和设计的基本原则，后续的文章中，会针对每一种升级模式，做更详细的说明。