一、與i.MX RT11xx系列雙程序啟動細節差異

1.1 恢復啟動的接口外設不同

第一點不同其實與本文要討論的 FlexSPI 雙程序啟動特性無關，因為我們要聊的還是在一片掛載在 FlexSPI 上的串行 NOR Flash 里做雙程序設計，就是下圖中的 image 0 和 image 1，不涉及 Flexcomm SPI 接口 Flash B 里的 image 2（在 i.MX RT1170 上這個外設是 LPSPI）。

在介紹 i.MX RT1170 雙程序啟動一文里我們用了 image L/H 來表示 image 0/1，這里還是恢復使用 image 0/1 來表示，因為后面我們要看的i.MX RT500/600 參考手冊啟動流程圖里就是用 image 0/1來表達的，避免表達混亂。

1.2 可啟動 image 結構不同

i.MX RT1170上最簡易可啟動image結構比較復雜（包含 FDCB、img_ver、IVT、BD、App），而 i.MX RTxxx上就比較簡單了（僅需 FDCB、img_ver、App），但是好在兩者關于 image version 頭結構定義以及偏移位置是完全一致的（0x600）。

此外i.MX RT1170上第一個FlexSPI 的 AHB 映射地址是 0x3000_0000，而 i.MX RTxxx 上第一個 FlexSPI 的 AHB 映射地址是0x0800_0000，這是系統設計差異，需要注意。

注：下圖中示意地址均是 Flash 偏移地址，沒有包含 AHB 映射地址，另外這里假設第二份 image 偏移地址在 0x400000（具體是由 otp 配置值來決定的）。

1.3 使能雙程序啟動的otp配置地址不同

i.MX RTxxx 上關于使能雙程序啟動的 otp 配置定義與i.MX RT1170 上是一致的，只是因為兩者 otp 空間設計不同，所以具體配置地址不同。i.MX RTxxx 上具體配置在 otp BOOT_CFG2/3 上面：

Remap功能的ADDR_START寄存器固定設為Flash 起始映射地址。otp 0x188[31:28] - FlexSPI remap size， App的最大長度，標識了第一份App的結束地址，該值加上ADDR_START后被填入Remap功能的ADDR_END寄存器。otp 0x18C[31:22] - Second image offset，標識了第二份App的起始地址（在Flash中偏移位置），即填入Remap功能的ADDR_OFFSET寄存器的值。

這次我們要在 MIMXRT595-EVK 板卡上實測，這個板子 FlexSPI0 上掛了兩片 Flash，默認連接64MB OctalFlash，還有一片 8MB QuadSPI Flash（需要做板子改動才能使能）。為了跟之前測試保持一致，還是借助 MCUBootUtility 工具將 Second image offset 燒錄為 0x10，FlexSPI remap size 保持默認 0，即第二份 image 偏移地址在Flash 0x400000（4MB）處，最大 image 長度也是 4MB。

1.4 暫存狀態的非易失寄存器有差異

// Load redundant boot options stored in specific register
#define LOAD_REDUNDANT_BOOT_OPTIONS() (*(volatile uint32_t *)(SYSCTL0_BASE + 0x384))

// Store redundant boot options in specific register before system reset
#define SET_REDUNDANT_BOOT_OPTIONS(val) ((*(volatile uint32_t *)(SYSCTL0_BASE + 0x384)) = val

這個32bit寄存器功能原型如下，它不單純是用做雙程序啟動的狀態記錄了，還糅合了 ROM API 功能。具體用法可以在芯片參考手冊 ROM API 小節找到，這里不具體展開了，不是本文重點。

typedef struct _user_app_boot_invoke_option
{
    union
    {
        struct
        {
            uint32_t reserved : 8;
            uint32_t boot_image_index : 4;
            uint32_t instance : 4;
            uint32_t boot_interface : 4;
            uint32_t mode : 4;
            uint32_t tag : 8;
        } B;
        uint32_t U;
    } option;
} user_app_boot_invoke_option_t;

1.5 image 版本判斷邏輯不同

在 i.MX RT1170 上 image version 頭有效的條件一定是其高低16bit符合取反關系，而 i.MX RTxxx 上除了這個條件外，其認定 0xFFFFFFFF 也是一個有效版本（被定為最低版本）。

在MIMXRT595-EVK開發板上對 image 版本設置情況也做了比較全面的實測，測試結果如下：

二、測試CRC32校驗雙程序啟動

現在來到本文的重頭戲了，如何使能 image 的 CRC32 檢驗啟動？這個設計其實最早可追溯到 Kinetis 系列，我有一篇舊文 "Kinetis BOOT特性(完整性檢測)"，文章很詳細地介紹了 Kinetis 系列 BootROM 里是如何支持 CRC32 校驗的。

2.1 啟動頭CRC32參數存儲位置

i.MX RTxxx BootROM 關于 CRC32 校驗的設計與 Kinetis 非常類似，最大的區別就在于存儲 CRC32 三大參數（起始地址，校驗長度，校驗值）的位置。i.MX RTxxx 上也是放在了 App 默認中斷向量表里的保留空間里（offset 0x20, 0x28, 0x34），共 12 個字節。

offset 0x34 - imageLoadAddress: App加載后中斷向量表首地址，也決定CRC校驗起始地址

- 對于XIP image，一般固定為0x08001000（App無需加載）

- 對于Non-XIP image，App加載前存儲起始地址是0x08001000，加載后到指定鏈接的RAM 地址，CRC計算和校驗是發生在App加載后。

offset 0x20 - imageLength: 決定CRC校驗總長度，一般是App 的長度（從中斷向量表首地址開始到代碼體結束）

offset 0x28 - crcChecksum: CRC校驗值，[imageLoadAddress : imageLoadAddress + imageLength] 范圍內數據的正確CRC32 結果

2.2 使能CRC32校驗的條件

當App 默認中斷向量表里 offset 0x24 處的imageType[7:0] 類型為 0x02 或者 0x05，且 offset 0x20 處的 imageLength 不為 0 時，CRC32 校驗的功能就會被使能。BootROM 在做 CRC32 計算時主要有如下兩個注意事項：

2.3 具體CRC32算法選項

關于CRC32 算法的具體實現有很多分支，BootROM 中使用的比較主流的 MPEG2 分支，其在計算 image 具體 CRC 時主要借助了芯片內部的 CRC 模塊（這個模塊也常見于恩智浦 LPC 系列芯片上），這個 CRC 模塊支持三種固定的 CRC 算法多項式（多項式系數不是可自由配置的），BootROM 用得就是最后一個模式選項 CRC-32：

BootROM中對 CRC 模塊的配置代碼如下：

#include "fsl_crc.h"
void crc32_init(void)
{
    crc_config_t crcUserConfigPtr;
    CRC_GetDefaultConfig(&crcUserConfigPtr);
    crcUserConfigPtr.seed = 0xffffffffU;
    crcUserConfigPtr.polynomial = kCRC_Polynomial_CRC_32;
    crcUserConfigPtr.reverseIn = false;
    crcUserConfigPtr.reverseOut = false;
    crcUserConfigPtr.complementIn = false;
    crcUserConfigPtr.complementOut = false;
}

2.4 利用工具自動添加CRC校驗參數

對CRC32 校驗啟動的原理了解差不多了，我們現在在 MIMXRT595-EVK 開發板上實測一下，跟前面測試一樣，先使用SDK_2.10.1_EVK-MIMXRT595oardsevkmimxrt595driver_examplesgpioled_outputiarflash_debug例程生成兩個閃燈間隔時間不同的程序鏡像文件：image 0 -gpio_led_output_delay200ms.bin 和 image 1 -gpio_led_output_delay2s.bin。

然后借助MCUBootUtility 工具（需要 v3.5.0 版本及以上），在 Secure Boot Type 里選擇 Plain CRC ImageBoot，點擊 All-In-One 下載按鈕（兩個文件分別做兩次同樣的下載流程），工具會自動在 image 相應地方填充進所需的 CRC32 參數并下載進 Flash。

這時候在工具通用編程器模式（Boot Device Memory）里我們再讀回 image 保存就可以得到兩個含 CRC32 校驗的程序鏡像文件 image 0 -gpio_led_output_delay200ms_crc.bin 和 image 1 -gpio_led_output_delay2s_crc.bin。

以image 0 為例，根據 0x08001020 處的imageLength 信息顯示，image 0 App 本身長度為 0x36e8 字節，而 App 起始偏移是 0x1000，所以我們直接是從偏移 0 地址處開始讀回 0x46e8 字節作為gpio_led_output_delay200ms_crc.bin 文件數據。此外 image 0 的 CRC32 校驗值已經填好了，是 0x4d8957d8。

2.5 手動驗證CRC32校驗值的方法

在使用image 0 - gpio_led_output_delay200ms_crc.bin 和 image 1- gpio_led_output_delay2s_crc.bin 做雙程序啟動前，我們可以先手動地驗證下其中的 CRC32 校驗值是否正確，痞子衡找到一個在線計算 CRC 的網站：

CRC在線校驗網站：http://www.sunshine2k.de/coding/javascript/crc/crc_js.html

在這個網站里把模式選好，然后從 gpio_led_output_delay200ms_crc.bin 文件里僅拷貝出App 部分的數據放到網站 CRC Input Data 框（注意要手動刪除 crcChecksum 四個字節，另外還要檢查總數據字節長度是否按 4 對齊，如果不對齊，要在數據末尾按格式補上相應的 00），最后點擊網站上的 Calculate CRC!按鈕可以得到結果，這里我們看到兩個結果是一致的：

2.6 含CRC32校驗的雙程序啟動測試

現在可以利用 image 0 - gpio_led_output_delay200ms_crc.bin 和 image 1 - gpio_led_output_delay2s_crc.bin 測試雙程序啟動了，繼續借助 MCUBootUtility 工具的通用編程器模式將其分別下載進 0x0 和 0x400000 地址處，必要時還可以手動調整兩個 image 里的版本號，測試過程中也可以稍微修改一下 image 數據再下載或者下載后再擦除一些 image 區域（故意讓CRC32校驗失敗），最終測試結果如下：

三、一些關于image的注意事項

• Note1:雖然文中所有的測試均是針對 XIP image，但這個雙程序可交替啟動特性對于 Non-XIP image 也同樣適用。

• Note2:如果是 XIP image，其鏈接地址要求固定在 Flash 偏移 0x1000 處（如果 Flash 掛在第一個 FlexSPI 上，其 AHB 地址就是 0x08001000）。

• Note3:如果是 Non-XIP image，在 SDK 包里無法直接生成含啟動頭的 Non-XIP image binary，這時候可以先使用 MCUBootUtility 主界面的 All-In-One 操作下載一次 image，再通過通用編程器界面 Read 操作讀回來便是含啟動頭的 Non-XIP image binary。

• Note4:使能 CRC32 校驗的雙程序可交替啟動，也是同時支持 XIP image 和 Non-XIP image 的。