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

在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

將所有的錯誤修正后，配置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()的調用。在e2 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命令的第一部分。