MCUboot Swap模式升级流程及应用

程序员库森

转自 | 瑞萨嵌入式小百科
2 _- u. r6 a5 k. h* s5 r( o上周给大家分享了《MCUboot Overwrite模式升级流程及应用》，今天继续给大家分享另外一种Swap模式升级流程及应用.

本文以瑞萨RA4M2 512K Code Flash产品为例，使用Flat mode（不启用TrustZone）说明Swap模式进行升级时的注意事项。
9 K' m& m8 W& f/ t" K. K
; k" }+ D- X5 Y! G. i6 `首先回顾一下Swap模式升级的流程。

; T# A- r1 {" k9 @# R$ e

mpctg33n24t64063127839.png

8 i/ L+ g8 z! {: q7 P2 w5 ^MCUboot Swap模式图解

6 s4 n6 U, S  u- G# f- p& S从代码框架来看，整体划分为三部分，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。
6 t; _# P# h$ e# p7 L
: ]9 W& }; H( k, Z' \在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和加密算法等。
' `9 j6 |) |7 n
对于Bootloader Project，可以在e2 studio中新建并命名。在FSP的Stack选项卡下，点击New Stack → Bootloader → MCUboot，即可将该功能添加进来。

b4bx1imc4sf64063127939.png

/ Z* A. p! A4 ?5 ^0 `/ T4 ~: ?- lFSP中添加MCUboot

8 U: y" W0 d. K, r5 S* I; W6 j添加MCUboot之后，由于它依赖一些底层驱动，如Flash，Crypto等，因此会在初始界面提示错误，按照提示信息逐个修复即可，此处不详细展开。

uey013lr1r164063128039.png

: F* r8 D9 b& T0 z! P  vFSP中MCUboot
- m$ o. b- M' M2 c7 F
注意，如需使用示例密钥对Application Image进行处理，则需要添加MCUboot Example Keys。该Key仅供测试使用，量产时需进行替换。
+ a4 w! @6 }+ M! t) A' e/ @
% x3 G( w2 K6 y5 x5 m% ^

icio4mna22n64063128139.png

3 g% |- {5 J. E3 F6 K" V% ]FSP中MCUboot Example Keys配置

- ?4 w& o* Y" t3 @( ]5 z假如使用Crypto相关的driver，则参考下图的配置修复相关error。
6 W# @, C! W/ J% u

tf3bmqohaym64063128239.png

6 p3 T3 r* _# N+ E; I0 GFSP中MCUboot下MbedTLS (Crypto Only)配置参考

将所有的错误修正后，配置MCUboot的关键属性。
2 M# S% A$ L% ~0 T. q# a, L3 `5 k$ J
4 z( m% M! j1 T6 O/ |8 d; v

rqmmfmcjc0s64063128339.png

& Y! G$ l: Q- S) C, r4 X& |FSP中MCUboot General属性
0 l( r) S2 S& s# Z( K
展开Common选项下的General属性，对于几个可配置的关键选项，说明如下：
$ X- y* K# J9 [

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

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

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

o5dxzw1o4sy64063128439.png

FSP中MCUboot Signing and Encryption Options属性
: I9 H7 _9 f; J# ^) W+ L8 H
展开Common选项下的Signing and Encryption Options属性，对于几个可配置的关键选项，说明如下：
+ T4 Y# G% X) x) \' J( t3 `2 [, U
$ A' h# M! w- y2 G0 [

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

Custom可以从--confirm和--pad两者中任选其一
# Q" a/ N4 L7 w! G. O3 d* R- 默认选项为--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。这是实现代码回滚的一种方式，我们会在下一篇文章中做详细介绍。

& y1 u4 ]; r4 u

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

接下来配置Flash Layout
8 o  I8 J" u* Y) a" Z. B! g/ O
; x) ]! ~+ i, f! ^7 R/ D对于Flash Layout来说，由于升级模式已锁定Swap，在此基础上决定Bootloader的大小因素就只剩下校验算法的选择了。
& B; d6 X* O* y- `8 Z9 V
由于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）。

$ `& l/ I) ]& I9 G: g既然如此，我们索性把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。

xzkumerjehd64063128539.png

RA4M2 Code Flash地址空间

cdace1uzlzg64063128639.png

FSP中MCUboot Flash Layout设置
4 o* Z$ Q6 m+ n, q6 `& m- P! f4 B( z
Bootloader Flash Area Size (Bytes)：
设定为0x18000即可

Image 1 Header Size (Bytes)：
前面的划分Primary Slot和Secondary Slot包含Header，对于Cortex-M33内核的产品，有中断向量表对齐的要求，因此我们建议将Header size统一设定为0x200，以支持Application的所有中断。
2 X: M2 ^) y- ~/ X
3 ?8 A! M  v. r# ^9 {4 yImage 1 Flash Area Size (Bytes)：
6 p2 \; ?! z4 f# _根据前面的计算结果，填入0x30000（6个32K block）
1 \: _6 Q) m' y
Scratch Area用于暂存两个Slot内容交换时的最小单元，因此我们将Scratch Area大小设定为Block size 0x8000（32K）。
* M5 X9 R- a8 c: o9 D/ Q; X8 _
至此，对于Bootloader的配置已经完成了。

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

442drfn1fyj64063128739.png

利用Developer Assistant向源码中增加mcuboot_quick_setup定义
. ^3 Y: E2 K9 f( Q3 Q
然后在hal_entry()入口处增加对函数mcuboot_quick_setup的调用。
9 y! q5 v. {. C

baptur0ku3x64063128839.png

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

Build Project可以顺利完成，提示“0 errors, 0 warnings”。在Debug文件夹下确认包含同名的***.bld文件，用文本编辑器打开，检查内容。
# L6 d! {+ B/ }0 R
1 `* j4 K7 P  `

gxcl0pgbico64063128939.png

Bootloader Project Build生成的.bld文件
8 l' ^) ]# M+ k+ O: e* \" `
5 M% ]' z! G+ ~+ m- l.bld文件是XML格式的，主要包含两部分：

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

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

2
& B, S9 O2 J+ m& ?2 [- t4 x9 r6 H将Application Project和Bootloader关联起来
  x& E) k) e' r9 T" ]接下来，我们要利用该Bootloader调试目标Application Project，如何才能将Bootloader和Application关联起来呢？就需要借助刚才提到的Bootloader Project Build所生成的***.bld文件。

除了新建Project，也可以将任意一个现有的Project跟Bootloader关联起来，此时，该Project编译的地址为Primary Slot起始地址加上Header大小。

% b1 d/ B5 I& B- H" l* {1 i: TApplication Project会利用.bld中的内容替代原始的链接脚本文件（linker script file）。编译的起始地址来自标号FLASH_IMAGE_START，图中的值为0x00018200，可以看到，Header大小0x200已经包含进来。

另外，由于需要使用Python对Application Image进行处理，因此需要在本地安装Python以及相关插件的支持。该操作仅需执行一次。

3 w9 J. x" X* z% x3 l& S' V具体的步骤如下，在Project Tree界面下找到ra\mcu-tools\MCUboot\scripts，鼠标点击右键，Command Window，则会在打开命令行界面，并进入scripts文件夹。键入如下命令，安装Python所需的lib。
3 l4 N! N) p) g
) p) a4 V) F( S7 mpip3 install --user -r scripts/requirements.txt

: V! D) [# k% Y, U7 N

4wclgo1xesq64063129039.png

Python安装所需Lib的提示信息

/ r1 _: I! D/ E$ _; S4 M* k: z6 J9 B# wPython命令中包含e2 studio中的Placeholder，针对某个具体的Project，在执行的时候会解析为Workspace下的Project路径以及Project名称。

) _% e2 Q- @/ E5 j# E6 S/ Q通过环境变量将Application Project关联起来
' @/ P" Y0 l( g8 s/ s& B
* _) }3 p5 ?, K" t  x打开Application Project的属性界面，在C/C++ Build → Build Variables下添加.bld文件。

) i* T6 I3 w+ k+ W+ `7 q

gn4dhiddg0264063129140.png

添加.bld文件到Application Project的Build Variables

1 O. ?" y, K1 z4 h- L' e同时，对Application Project Image进行签名操作所需的公钥放在Bootloader中，因此也需要将该文件链接到Application Project中，具体的实现方式如下：
/ g% J- ^+ @! r1 G7 J) }5 }' i
% k: M- L9 U; J7 k" {

0fjpvww05bc64063129240.png

添加Public Key for Sign

注意，此时Public Key for Sign依然位于Bootloader Project所在路径，该配置只是引入该文件的地址，使得在Application Project中调用Python脚本对Image进行签名操作时找到该Public Key。

6 T* U6 g2 q* g8 M* o9 R另外，Image文件的版本信息可以通过添加Environment variable实现，配置方式如下：
. i" q) O1 I- K) P- @# o% h+ @

ajoeakxxxwi64063129340.png

" `# M6 [. s: g" m: F4 ^将Image版本号添加到Environment variable
# _; Z; \' |/ R6 R. p& w
最终生成的版本信息会以4字节添加到Header中。
) s; J) A1 Z8 i& s2 P2 Y/ W
0 q) N4 {) X! `' p7 m/ W7 Z为保证每次Environment variables有变化或者Bootloader生成的***.bld发生改变时，Application Project都可以重新编译，需在Pre-build中增加以下内容：

, X2 W" f6 z: N8 t7 u, O- Rrm -f ${ProjName}.elf

' c. L9 A& c7 a& G$ j. S' E# v% \

drzy4oah5wr64063129440.png

Pre-build step添加删除***.elf的操作

完成了以上的所有基础配置后，可以编译Application Project。在Console界面查看Build Log，可以发现编译完成后，增加了对Image文件的处理。

qxogyjhrumu64063129540.png

对Image签名操作对应的Python内容
" r) s3 T8 L5 e; h6 c
此时生成的***.bin.signed文件包含了Header，TLV和Trailer等内容，可以被Bootloader识别并运行。利用工具打开该文件，可以发现它不同于原始的Application Image文件：

f0ucxg142or64063129640.png

.bin.signed文件结构
! y6 g2 a2 x" a+ E9 M6 T
" ?) Y8 ~/ n- Z: @" ?; }开始的0x200字节是Header信息，在e2 studio中通过Environment variable传入的版本信息1.0.0在0x14地址偏移上。关于其他部分的细节，感兴趣的朋友可自行查阅。

Application Image开始的0x200处，第二个4字节即当前的中断向量表起始地址，可以看到是小端格式的0x00018ab9，在Primary Slot地址空间（0x00018000～0x87FFF）内。


3
调试Application Project
由于芯片上电后需要从0地址（具体地说是0004h地址处）的中断向量开始运行，因此，调试Application Project时需要下载Bootloader文件，我们在Application Project的Debug Configuration中添加相关部分。
8 w0 l3 S+ ]$ W9 ^, k) O2 |9 l" X
" w: o% B; \2 t' F8 a) L" ]& x) h

5twze11xilr64063129740.png

5 c; P$ h4 [5 _- S6 o: o# t& EApplication Project Debug Configuration Startup选项卡配置

) E, K, V) V7 l' g7 g' \( @$ j* B增加对于Bootloader的加载，类型选项设定为Image and Symbols，这样调试状态下可以跟踪Bootloader中代码运行的状态。
& b' `1 F! x+ l1 b; `: b
/ T, P' s( W/ q/ B1 s. z同时，将Application Project对应的***.elf → Load type设定为Symbols only，仅下载标号。由于加载了Application Project对应的symbol，因此我们可以调试时检查代码的运行状态。但实际下载到code flash的内容是经过了Python脚本处理，增加了Header，TLV和Trailer等信息的***.bin.signed文件，因此可以通过Bootloader的安全校验。
/ y) |1 ]! s! j& Y
$ N5 ~- j/ ~- Z6 T按下Debug按钮，启动调试，此时可以发现PC停在Bootloader的reset向量处。

  G* Y8 b  h% U& [5 f6 F  D: J
调试Application Project
$ ]- {( k" Y* s6 D8 E" z
* ?+ R- J. a$ g/ m  E点击Load Ancillary按钮
# I, ^4 ]: W# l5 m# e
，将Application Project Debug文件夹下的***.bin.signed下载到芯片上，注意选择地址为Primary Slot起始地址0x18000。


将1.0.0版本Image ***.bin.signed文件下载到Primary Slot的起始地址0x18000

& @* w& e0 i' P* ?$ z在memory窗口检查当前Primary Slot中的内容，可以看到Image版本为1.0.0。


PC Primary Slot中存储了1.0.0版本的Image

点击Resume，可以发现PC指针停在Primary Slot的Application Project Reset向量处，此时PC指针地址0x00018ab8位于Primary Slot地址空间范围（0x18000～0x37FFF）。如下图所示。

之后在任意时刻暂停，通过PC指针的地址空间范围和对应的代码标号可以发现PC已经运行在Application Project中了。
& [  p4 T2 P! D# L* F
1 N8 o" s5 D& U- i3 z; y
1 M& I. u' Y+ }8 a2 v0 j9 y) z3 UPC指针运行在Primary Slot中
# E/ T; {5 \# o' M$ G% E
7 b' ^6 c, T& {再次点击resume，则可以观察到代码运行在Primary Slot的Application Project中。
  U/ T3 N) p! d+ }
4
" Q" c8 k/ ?' j( Y* [( T升级并验证
7 f1 a- ]; r$ q6 {由于升级方式是基于应用层面的实现，因此依赖客户的设计。如果需要展示，则建议参考下方链接Application Note中的内容，对应的示例代码包含了遵循XModem协议利用UART传输Image。
( p1 {. ]9 v$ [, Rhttps://www.renesas.com/us/en/document/apn/ra6-mcu-advanced-secure-bootloader-design-using-mcuboot-and-code-flash-dualbank-mode
/ p; A" Z7 k7 n5 y' a7 t9 S
+ _3 p, i* l7 b6 o# J; Y% o在调试状态下，可以通过将待更新的Image文件下载到Secondary Slot中，重启即可使得升级生效。
* q- ~9 b- R/ D/ L
在Application Project上稍作修改，比如原始的Project在EK-RA4M3上使三个LED（红绿蓝）一起闪烁，而我们将代码更新为只有一个LED（蓝色）闪烁。同时，将Image Version从1.0.0更改为1.1.0，重新Build Project，确认Debug文件夹下的.bin.signed重新生成了。

' c* n: h6 L. I9 J. u" C5 h现在将1.1.0版本的Image烧录到Secondary Slot中，点击Load Ancillary，选中***.bin.signed，目标地址选择0x48000。
: h' Z5 d/ ?1 d! S+ I& |% A+ C. K% d

' o, v% @* v! ]! k, d将1.1.0版本Image下载到Secondary Slot中

1 k6 T% t1 Z2 _% ]下载成功后查看Memory中的内容，可以确认Secondary Slot存储了1.1.0版本的Image。
. N3 X5 K+ M% n! h
0 M6 a( t, A8 V: {& l; r
Secondary Slot保存了1.1.0版本的Image

按下Reset按钮

，使得Bootloader运行，启动代码升级。

0 H) |! P3 ]' T3 R  ]1 i可以看到EK-RA4M3从三颗LED闪烁变为仅有一颗蓝色LED闪烁，表明升级成功。
) b* d# U2 J1 M( Z8 y
升级完成后查看Primary Slot和Secondary Slot，发现两个Slot内容已经交换了。Primary Slot中保存了1.1.0版本的Image文件，而Secondary Slot中保存了1.0.0版本的Image文件，如下图所示。

5 W3 k! h" ^0 L/ ]4 }/ |3 [
Primary Slot保存了1.1.0版本的Image，Secondary Slot保存了1.0.0版本的Image


------------ END ------------
- }/ U; n; B# s, X7 U& t& [1 i. z
MCUboot Overwrite模式升级流程及应用
$ m! b4 U8 v9 a0 O4 c- D
% Z8 C& Z# o. g2 V7 p8 r
& |9 q, c4 R3 c, i单片机TCM相比DMA的优势

7 j, r! [! \! A! l) X; E9 p5 F; q
在MCU上实现AI将成为常态