介紹MCUboot支持的四種升級模式，分別是Overwrite、Swap、Direct XIP和加載到RAM中執行。由于FSP不支持第四種——加載到RAM中執行，因為我們重點介紹前三種。

Direct XIP（Execute In Place）模式

MCUboot Direct XIP模式流程圖

接下來我們看第三種升級模式，Direct XIP（Execute In Place），跟前兩種模式Overwrite和Swap最大的不同在于，代碼是就地執行的，即升級后的代碼直接在Secondary Slot中執行。

上電后芯片中燒錄的是Bootloader和Primary Slot中User Application v1.0，運行的過程中，芯片收到升級指令，接收新firmware并燒錄到Secondary Slot中，然后跳轉至Secondary Slot中執行。

如果查看升級操作的起始狀態和結束狀態會發現，芯片從運行Primary Slot中的低版本v1.0代碼變為運行Secondary Slot中的高版本v2.0代碼，因此完成了一次升級。

從Direct XIP模式的流程可以看出它的一些特點：

支持代碼回滾/回退/降級。由于升級完成后，低版本v1.0 Image依然存儲在芯片中，因此若在高版本v2.0 上發現bug需要修復，則有機會重新執行升級程序使得代碼回到v1.0。

升級過程中不涉及對flash的擦除和寫入操作，因此Boot時間較短，是三種模式中時間最短的。

關于各種模式之間的更多細節比較，請參考下圖中的內容：

各升級模式特性比較

關于Secondary Slot的屬性，既可以是片上flash，也可以是外部flash。FSP對外部的支持為QSPI Flash，可以映射到地址總線上的存儲空間。假如利用外部flash如QSPI作為Secondary slot，則不支持Direct XIP模式。

另外，由于映像文件Image的傳輸途徑可能具有潛在風險，又或者使用外部flash存儲新Image擔心被盜用，則推薦使用加密存儲的方式。假如使用加密存儲，則不支持Direct XIP模式。

前面提到了MCUboot可以實現安全boot，即判斷目標Image的完整性和合法性，根據結果決定是否執行固件升級操作，這個過程也可以叫做安全校驗。

安全校驗的設計可謂豐儉由人，整體的原則是，安全級別越高，帶來的代碼量增加越大，啟動時間越長。

MCUboot的安全校驗意味著，待更新的Image文件需要增加一些標識，才能被bootloader識別，原始的文件無法通過安全校驗。

下面的圖展示了處理后的Application Image各部分信息。

利用Python腳本處理后的Application Image

MCUboot的安全校驗的實現方式包括：

增加Header，位于更新后的Bootloader和Application實際起始地址中間。其中包含了豐富的信息，比較關鍵的部分如Image的版本及大小。

增加TLV (Type Length Value)，緊跟在Application之后。其中包含了Image文件對應的HASH哈希值和對Image文件生成的簽名信息。

增加Trailer，位于Slot頂端，和TLV之間會填充固定數值。根據升級模式的不同，Trailer的格式和含義也不同，在此不展開。值得一提的是，對于Swap模式，Trailer中包含了Bootloader進行升級時的判斷標志，更多細節請參考MCUboot官網對于此部分的說明。

由于Bootloader占用了flash空間0地址開始的部分且大小幾乎不變，因此在設計的時候，需評估flash的空間劃分，使得Bootloader盡量小以讓出更多空間給Application利用。關于Bootloader優化，我們不在本章中展開說明。

決定Bootloader大小的關鍵要素有以下幾個：

升級模式，Overwrite最小，Swap最大

安全校驗的級別，級別越高代碼量越大

對于Flash劃分，需要遵循的基本原則是，每個區域（Bootloader，Primary Slot和Secondary Slot）均占據完整的Block size，具體到RA產品，請在硬件手冊中確認Block size的值。

以RA6M4 1M Code Flash產品為例，共有38個Block，其中低8個Block大小為8KB，高地址上的Block大小均為32KB。

RA6M4 Flash Block地址信息

本章總結

本篇我們介紹了MCUboot的基本概念和設計的基本原則，后續的文章中，會針對每一種升級模式，做更詳細的說明。