前面介紹了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大?。?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占據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的配置已經完成了。