MCUboot Swap模式升级的流程和注意事项

前面介绍了MCUboot的基础知识（请查看上方“简介以及在RA FSP上的支持”文章），上次介绍了Overwrite模式（请查看上方“RA Overwrite模式在FSP中的支持”文章），本次着重介绍其中的Swap模式，以及在FSP中如何配置，如Flash怎样划分、安全校验的方式等。

本文以RA4M2 512K Code Flash产品为例，使用Flat mode（不启用TrustZone）说明Swap模式进行升级时的注意事项。

首先回顾一下Swap模式升级的流程。

MCUboot Swap模式图解

从代码框架来看，整体划分为三部分，Bootloader，Primary Slot（保存了低版本的User Application v1.0）和Secondary Slot（保存了待更新的高版本User Application v2.0）。

初始状态下，芯片中烧录了Bootloader和Primary Slot，代码从Bootloader处启动，跳转至Primary Slot中的User Application v1.0。在User Application v1.0运行过程中，接收来自外部的更高版本Firmware v2.0，并烧写到Secondary Slot中，烧写完成后，执行软件复位Software reset，代码重新从Bootloader开始运行。此时Bootloader判断Secondary Slot中有待更新的Image，检查其完整性等，校验通过后，将Secondary Slot中的内容和Primary Slot中的内容交换（利用Scratch area作为暂存区域）。然后跳转到Primary Slot中执行。比较升级操作的初始状态和终止状态，发现Primary Slot中运行的代码从低版本的v1.0变为高版本的v2.0。

在e2 studio中进行开发时，Bootloader和User Application为相互独立的Project，但位于同一个Workspace中。先Build Bootloader Project，然后Build位于Primary Slot的User Application Project，由于Bootloader规定了对于整个存储空间的划分，同时包含了对User Application Image进行签名/验签所用的密钥，因此Application Project会依据Bootloader build输出的Bootloader Data File代替原有的Linker Script File（链接脚本文件）进行link，并利用Bootloader包含的密钥进行Image映像文件的处理。

1新建Bootloader并配置MCUboot参数

由于Bootloader是整个系统的关键，因此我们第一步创建Bootloader Project并配置一些关键选项如Flash Layout和加密算法等。

对于Bootloader Project，可以在e2 studio中新建并命名。在FSP的Stack选项卡下，点击New Stack → Bootloader → MCUboot，即可将该功能添加进来。

FSP中添加MCUboot

添加MCUboot之后，由于它依赖一些底层驱动，如Flash，Crypto等，因此会在初始界面提示错误，按照提示信息逐个修复即可，此处不详细展开。

FSP中MCUboot

注意，如需使用示例密钥对Application Image进行处理，则需要添加MCUboot Example Keys。该Key仅供测试使用，量产时需进行替换。

FSP中MCUboot Example Keys配置

假如使用Crypto相关的driver，则参考下图的配置修复相关error。

FSP中MCUboot下MbedTLS (Crypto Only)配置参考

将所有的错误修正后，配置MCUboot的关键属性。

FSP中MCUboot General属性

展开Common选项下的General属性，对于几个可配置的关键选项，说明如下：

升级模式Upgrade Mode，可以从Overwrite，Swap和Direct XIP中选择，此次选择Swap。该选项是决定Bootloader大小的关键性因素，Overwrite模式最小，Swap模式最大。

Validate Primary Image，建议设定为Enabled，除非资源非常紧张，开启这部分功能带来的代码量增加不过几十字节而已。

Downgrade Prevention (Overwrite Only)，由于该选项仅在Overwrite模式可选，因此设定为Disabled。

FSP中MCUboot Signing and Encryption Options属性

展开Common选项下的Signing and Encryption Options属性，对于几个可配置的关键选项，说明如下：

签名类型Signature Type，规定了对于Application Image进行签名所用的方式，可从None，ECDSA P-256，RSA 2048，RSA 3072四项中任选其一。假如使能签名，则代码量最小的是ECDSA P-256

Custom可以从--confirm和--pad两者中任选其一

- 默认选项为--confirm，在对Image进行签名操作时，会将该Image做标记，Bootloader判断时会将Secondary Slot和Primary Slot交换。下次复位时，两个Slot不会交换。

- 设定为--pad时，签名操作会将Image的Trailer部分标记为“可考虑使用该Image升级”。将Image写入Secondary Slot之后，Bootloader会先将Secondary Slot和Primary Slot进行交换，使得Secondary Slot中的Image得到一次执行的机会。在执行的过程中，假如调用了boot_set_confirmed()函数，则下次复位后，不执行Swap。假如在执行的过程中，并没有调用boot_set_confirmed()函数，则下次复位后，继续执行Swap，代码回到旧版本的Image。这是实现代码回滚的一种方式，我们会在下一篇文章中做详细介绍。

Encryption Scheme，根据对于Application Image是否加密进行设定。默认是Disabled，假如使能，则可以从ECIES-P256和RSA-OAEP (RSA 2048 only)中任选其一。Encryption Enabled情况下，Bootloader代码量会明显增加。

接下来配置Flash Layout

对于Flash Layout来说，由于升级模式已锁定Swap，在此基础上决定Bootloader的大小因素就只剩下校验算法的选择了。

由于Bootloader占据从0地址开始的空间，而RA4M2在低地址上的8个block大小均为8KB，因此我们先将Bootloader大小设定为64KB，即0x10000。Swap模式需要保留一个Block大小（32K）的空间用于对两个Slot内容进行交换，因此还剩512 – 8*8 – 32 = 416KB。假如将这416KB等分，则208K无法被32K整除，因此只能等分Block 8～Block 19，Primary Slot和Secondary Slot各占6个Block （32KB）。

既然如此，我们索性把Bootloader设定为96KB（Block 0～8），即0x18000。Primary Slot占据6个Block （Block 9～14），Secondary Slot占据6个Block （Block 15～20），最高地址的Block 21作为Swap模式下的Scratch area。

RA4M2 Code Flash地址空间

FSP中MCUboot Flash Layout设置

Bootloader Flash Area Size (Bytes)：

设定为0x18000即可

Image 1 Header Size (Bytes)：

前面的划分Primary Slot和Secondary Slot包含Header，对于Cortex-M33内核的产品，有中断向量表对齐的要求，因此我们建议将Header size统一设定为0x200，以支持Application的所有中断。

Image 1 Flash Area Size (Bytes)：

根据前面的计算结果，填入0x30000（6个32K block）

Scratch Area用于暂存两个Slot内容交换时的最小单元，因此我们将Scratch Area大小设定为Block size 0x8000（32K）。

至此，对于Bootloader的配置已经完成了。