RA Overwrite模式在FSP中的支持

前面介绍了MCUboot的基础知识，您可通过上方链接回顾，本章将着重介绍其中的Overwrite模式，以及在FSP中如何配置、如Flash怎样划分、安全校验的方式等。本文以RA6M4 1M Code Flash产品为例，使用Flat mode（不启用TrustZone）说明Overwrite模式进行升级时的注意事项。

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

MCUboot Overwrite模式解

从代码框架来看，整体划分为三部分，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中代码的版本（v2.0高于v1.0），检查其完整性等等，校验通过后，将Primary Slot擦除，并将Secondary Slot中的内容拷贝到Primary Slot中。之后跳转至Primary Slot中的新代码v2.0执行。比较升级操作的初始状态和终止状态，发现Primary Slot中运行的代码从低版本的v1.0变为高版本的v2.0。

在e? 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，可以在e? studio中新建并命名。在FSP的Stack选项卡下，点击New Stack → Bootloader → MCUboot，即可将该功能添加进来。

FSP中添加MCUboot

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

FSP中MCUboot

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

FSP中MCUboot General属性

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

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

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

Downgrade Prevention（Overwrite Only），假如设定为Disabled，则每次Secondary Slot中有新的Image，都会拷贝到Primary Slot中（安全校验通过的前提下）。假如设定为Enabled，则Bootloader会检查Secondary Slot中存储的Image版本，高于Primary Slot中Image版本的情况下才会拷贝。可根据实际需要选择。

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

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

接下来配置Flash Layout

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

由于Bootloader占据从0地址开始的空间，而RA6M4在低地址上的8个block大小均为8KB，因此我们将Bootloader大小设定为64KB，即0x10000。由于高地址上的Block大小为32KB，因此对于1MB code flash的RA6M4来说，可以将剩下的30个（37-8+1）Block等分，Primary Slot和Secondary Slot各占15 Blocks（0x78000字节）。

RA6M4线性模式下Code Flash地址空间

FSP中MCUboot Flash Layout设置

Bootloader Flash Area Size (Bytes)：

设定为0x10000即可

Image 1 Header Size (Bytes)：

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

Image 1 Flash Area Size (Bytes)：

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

由于Scratch Area仅针对Swap模式有效，因此在Overwrite模式下设定为0即可。

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

接下来我们需要在hal_entry.c中增加对函数mcuboot_quick_setup()的调用。在e? studio界面下，Project Explorer中找到Developer Assistance找到Call Quick Setup，鼠标左键点选，保持左键按下的状态，拖动到hal_entry.c文件的hal_entry()函数定义之前。

利用Developer Assistant向源码中增加mcuboot_quick_setup定义

然后在hal_entry()入口处增加对函数mcuboot_quick_setup的调用。

在hal_entry()入口处增加调用mcuboot_quick_setup

Build Project可以顺利完成，提示“0 errors, 0 warnings”。在Debug文件夹下确认包含同名的***.bld文件，用文本编辑器打开，检查内容。

Bootloader Project Build生成的.bld文件

.bld文件是XML格式的，主要包含两部分：

第一部分是symbol，主要包含Bootloader对Flash Layout的设定，FLASH_IMAGE_START值为0x00010200，即位于Primary Slot的Application Project实际Link（链接）地址。FLASH_IMAGE_LENGTH值为0x00077E00，即Primary Slot大小（0x78000）减掉Header Size（0x200）。

第二部分是对Application Image进行签名所用到的Python命令，对于该命令来说，输入是Application Project Build生成的原始Binary（二进制）文件，输出是同名的签名后的文件，后缀是.bin.signed。同时传入的参数还有文件版本，签名所用的密钥等。由于RA6M4搭载了支持TrustZone的Cortex-M33内核，因此文件的结构包含了对TrustZone的支持。对于不启用TrustZone的应用场景，我们仅需关注Python命令的第一部分。