前面介紹了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）。

初始狀態(tài)下，芯片中燒錄了Bootloader和Primary Slot，代碼從Bootloader處啟動，跳轉至Primary Slot中的User Application v1.0。在User Application v1.0運行過程中，接收來自外部的更高版本Firmware v2.0，并燒寫到Secondary Slot中，燒寫完成后，執(zhí)行軟件復位Software reset，代碼重新從Bootloader開始運行。此時Bootloader判斷Secondary Slot中有待更新的Image，檢查其完整性等，校驗通過后，將Secondary Slot中的內容和Primary Slot中的內容交換（利用Scratch area作為暫存區(qū)域）。然后跳轉到Primary Slot中執(zhí)行。比較升級操作的初始狀態(tài)和終止狀態(tài)，發(fā)現(xiàn)Primary Slot中運行的代碼從低版本的v1.0變?yōu)楦甙姹镜膙2.0。

在e2 studio中進行開發(fā)時，Bootloader和User Application為相互獨立的Project，但位于同一個Workspace中。先Build Bootloader Project，然后Build位于Primary Slot的User Application Project，由于Bootloader規(guī)定了對于整個存儲空間的劃分，同時包含了對User Application Image進行簽名/驗簽所用的密鑰，因此Application Project會依據(jù)Bootloader build輸出的Bootloader Data File代替原有的Linker Script File（鏈接腳本文件）進行l(wèi)ink，并利用Bootloader包含的密鑰進行Image映像文件的處理。

1新建Bootloader并配置MCUboot參數(shù)

由于Bootloader是整個系統(tǒng)的關鍵，因此我們第一步創(chuàng)建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，除非資源非常緊張，開啟這部分功能帶來的代碼量增加不過幾十字節(jié)而已。

Downgrade Prevention (Overwrite Only)，由于該選項僅在Overwrite模式可選，因此設定為Disabled。

FSP中MCUboot Signing and Encryption Options屬性

展開Common選項下的Signing and Encryption Options屬性，對于幾個可配置的關鍵選項，說明如下：

簽名類型Signature Type，規(guī)定了對于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得到一次執(zhí)行的機會。在執(zhí)行的過程中，假如調用了boot_set_confirmed()函數(shù)，則下次復位后，不執(zhí)行Swap。假如在執(zhí)行的過程中，并沒有調用boot_set_confirmed()函數(shù)，則下次復位后，繼續(xù)執(zhí)行Swap，代碼回到舊版本的Image。這是實現(xiàn)代碼回滾的一種方式，我們會在下一篇文章中做詳細介紹。

Encryption Scheme，根據(jù)對于Application Image是否加密進行設定。默認是Disabled，假如使能，則可以從ECIES-P256和RSA-OAEP (RSA 2048 only)中任選其一。Encryption Enabled情況下，Bootloader代碼量會明顯增加。

接下來配置Flash Layout

對于Flash Layout來說，由于升級模式已鎖定Swap，在此基礎上決定Bootloader的大小因素就只剩下校驗算法的選擇了。

由于Bootloader占據(jù)從0地址開始的空間，而RA4M2在低地址上的8個block大小均為8KB，因此我們先將Bootloader大小設定為64KB，即0x10000。Swap模式需要保留一個Block大?。?2K）的空間用于對兩個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占據(jù)6個Block （Block 9～14），Secondary Slot占據(jù)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統(tǒng)一設定為0x200，以支持Application的所有中斷。

Image 1 Flash Area Size (Bytes)：

根據(jù)前面的計算結果，填入0x30000（6個32K block）

Scratch Area用于暫存兩個Slot內容交換時的最小單元，因此我們將Scratch Area大小設定為Block size 0x8000（32K）。

至此，對于Bootloader的配置已經完成了。