工業(yè)產(chǎn)品設(shè)計里經(jīng)常會有冗余程序/備份程序設(shè)計的需求，因為在工業(yè)環(huán)境里要求設(shè)備能夠持續(xù)穩(wěn)定運行，不能輕易宕機，但現(xiàn)實環(huán)境中常常有各種意外發(fā)生，其中一個常見的意外就是設(shè)備主控MCU程序被破壞。

為了降低程序損壞這種意外帶來的影響，一個很典型的做法就是增加MCU程序的份數(shù)，第一份被破壞，就啟動第二份...，用程序數(shù)量的增加來降低啟動失敗率，這屬于概率學(xué)手段范疇。

我們知道恩智浦i.MX RT系列MCU內(nèi)部沒有非易失性存儲器，它需要搭配外部存儲器來工作，可選存儲器類型非常多：NOR Flash, NAND Flash, eMMC, SD卡都行。

其中對于NAND型存儲器，冗余程序設(shè)計是必備的，因為NAND本身允許壞塊現(xiàn)象存在，所以不得不做冗余設(shè)計。而對于NOR型存儲器，冗余設(shè)計則不是必需的，偏偏串行NOR Flash是i.MX RT最常用的搭檔，那該怎么辦？別急，今天痞子衡介紹的就是i.MX RT1010/1060上串行NOR Flash冗余程序設(shè)計，恩智浦已經(jīng)都給你考慮到了。

注：本文所涉及的串行NOR Flash冗余程序設(shè)計，不支持早期的i.MX RT1050/1020/1015型號。

一、初識冗余程序啟動

在i.MX RT上可以掛載串行NOR Flash去啟動程序的外設(shè)有兩個，分別是FlexSPI和 LPSPI，如下圖所示。

注：并不是所有 i.MXRT 型號都支持 LPSPI 外設(shè)掛載存儲器去啟動。

其中連接在FlexSPI 上的 Flash A 屬于主啟動設(shè)備，連接在LPSPI上的Flash B屬于備份啟動設(shè)備（關(guān)于備份設(shè)備啟動詳見痞子衡舊文《從Serial(1-bit SPI) EEPROM/NOR恢復(fù)啟動》）。

用兩片NOR Flash去完成冗余程序設(shè)計當(dāng)然是沒問題，但也相應(yīng)增加了硬件成本，而本文今天要討論得不是這種冗余程序設(shè)計，我們要聊的是在一片掛載在FlexSPI上的串行 NOR Flash里做冗余程序設(shè)計，就是圖中的image 0和image 1。

冗余程序啟動流程其實特別簡單，上電永遠(yuǎn)先啟動物理地址靠前的image 0，如果 image 0被破壞了，則啟動image 1。原則上image 0和image 1應(yīng)該是完全一樣的（鏈接地址也一樣，并且中途不需要搬移這兩份image數(shù)據(jù)，這個是靠芯片里的一個黑科技做到的，下文會細(xì)講），畢竟是冗余設(shè)計，不過你要執(zhí)意放兩份不完全一樣的image，倒也沒問題。

二、實測冗余程序啟動

我們知道i.MX RT芯片上電總是先運行廠商固化好的BootROM，所以冗余程序啟動設(shè)計是做在BootROM代碼里的。之前有一篇舊文《了解i.MXRT1060系列ROM中串行NOR Flash啟動初始化流程優(yōu)化點》中2.1 節(jié)其實已經(jīng)簡單地提到了冗余程序設(shè)計，其主要借助了芯片系統(tǒng)FlexSPI地址重映射(Remap)功能，這個功能是在恩智浦后期推出的 i.MX RT1060/1010 等型號上才有的，這也是上文所說的黑科技。關(guān)于這個黑科技，痞子衡也有舊文《利用i.MXRT1060,1010上新增的FlexSPI地址重映射(Remap)功能可安全OTA》。

有了FlexSPI Remap黑科技存在，我們就可以將同一份image binary放在Flash中兩個不同位置，并且不用做擦除編程操作來交換其位置，就可以實現(xiàn)各自的啟動執(zhí)行。如果沒有這個黑科技，我們只能老老實實做數(shù)據(jù)搬移，這會增加擦除次數(shù)從而影響Flash使用壽命。

原理搞清楚了，現(xiàn)在我們在板子上實測一下這個功能，看看如何正確地放兩份image進Flash，哪些情況會導(dǎo)致image 0啟動失敗從而去啟動image 1。

我們就以恩智浦官方MIMXRT1060-EVK開發(fā)板為例，這個板子FlexSPI1上掛了兩片 Flash，默認(rèn)連接的8MB QuadSPI Flash，還有一片64MB HyperFlash（需要做板子改動才能使能）：

2.1 使能冗余程序啟動

使能冗余程序啟動特性很簡單，就是將fuse 0x6E0[23:16] - FLEXSPI_NOR_SEC_IMAGE_OFFSET燒錄為非0值即可，根據(jù)下面定義，第二份image 偏移地址最大可以設(shè)到Flash中0x3FC0000（63.75MB）處：

Remap功能的ADDR_START寄存器固定設(shè)為Flash 起始映射地址。

fuse 0x6e0[15:13] - xSPI_FLASH_IMAGE_SIZE，App的最大長度，標(biāo)識了第一份App的結(jié)束地址，該值加上ADDR_START后被填入Remap功能的ADDR_END寄存器。

fuse 0x6e0[23:16] - FLEXSPI_NOR_SEC_IMAGE_OFFSET，標(biāo)識了第二份App的起始地址（在Flash中偏移位置），即填入Remap功能的ADDR_OFFSET寄存器的值。

本次測試，我們就將FLEXSPI_NOR_SEC_IMAGE_OFFSET燒錄為0x10，xSPI_FLASH_IMAGE_SIZE保持默認(rèn)0，即第二份image 偏移地址在Flash 0x400000（4MB）處，最大image長度也是4MB，可借助MCUBootUtility工具完成Fuse燒錄：

2.2 下載兩份無簽名image進Flash

現(xiàn)在開始準(zhǔn)備image，我們就直接用SDK_2.10.1_EVK-MIMXRT1060boardsevkmimxrt1060demo_appsled_blinky例程，簡單直觀。為了便于肉眼分辨效果，我們生成兩個稍微不一樣的image，閃燈間隔時間一個是200ms（image 0 - iled_blinky_delay200ms.bin），另一個是2s（image 1 - iled_blinky_delay2s.bin）：

然后還是借助MCUBootUtility工具，先使用All-In-One操作將image 0下載進Flash，因為是bin文件，所以我們要填入正確的鏈接起始地址（對于i.MX RT1060就是 0x60000000；對于i.MX RT1010應(yīng)該是0x60000400，具體查看工程鏈接文件便知）。

此外我們使用的是完整的可啟動鏡像文件（包含了全部所需啟動頭），也可以直接在軟件通用編程器界面做下載。

image0下載進Flash后，繼續(xù)下載image 1，這時候只能在軟件通用編程器界面操作。這里主要是設(shè)置好下載起始地址，前面我們使能冗余程序啟動時在Fuse里設(shè)置的偏移地址是0x400000，那么此時下載起始地址就應(yīng)該是0x400000（對于i.MX RT1060是0x400000；對于i.MX RT1010應(yīng)該是0x400400）。至此兩份image下載就完成了。

2.3 快速驗證兩份image正確性

現(xiàn)在Flash里有了兩份image，我們來做一個快速驗證，看看image是不是放得符合冗余程序啟動的要求。對于image 0，沒什么好說的，芯片啟動模式設(shè)為2'b10 后斷電復(fù)位應(yīng)該可以看到image 0在執(zhí)行，最重要的是驗證image 1是不是合法。

這里開始涉及到芯片冗余程序啟動流程核心了，當(dāng)image 0啟動失敗后，芯片BootROM不是立刻去執(zhí)行image 1的，它用了一個取巧的方式，在一個軟復(fù)位不置位的寄存器里（SRC_GPR10）標(biāo)記了當(dāng)前狀態(tài)，然后調(diào)用NVIC_SystemReset()重新進入BootROM執(zhí)行，第二次BootROM執(zhí)行時才會去啟動image 1。

所以這也給了我們快速驗證image 1執(zhí)行的可能性，我們在板子上掛上J-Link仿真器，然后打開J-Link Commander，直接將SRC_GPR10寄存器改寫為0x40000000，再依次執(zhí)行reset和go命令，這時你應(yīng)該可以看到image 1正在執(zhí)行了。

2.4 測試無簽名 image 0 損壞條件

痞子衡之前在《i.MXRT Bootable image格式》一文里介紹過一個可啟動image包含哪些組成部分，其中最簡單的無簽名image應(yīng)該至少包含F(xiàn)DCB, IVT, BD, App四部分，芯片BootROM也是按序讀取這四部分?jǐn)?shù)據(jù)完成程序啟動的。

現(xiàn)在我們嘗試分別破壞這幾個組成部分來看看何種程度的image 0損壞能被BootROM識別出從而去啟動image 1，下面是測試結(jié)果。從測試結(jié)果來看，除了Image 0 - App的損壞無法檢測外，image 0其余啟動頭的損壞都可以被BootROM識別到。

2.5 能檢測image 0 app損壞的方法

如果不能檢測image app部分的損壞，那這個冗余程序啟動功能就比較雞肋了，畢竟app部分的數(shù)據(jù)才是整個image核心所在。如果要加上app損壞檢測，需要使能i.MX RT 簽名啟動，還是可以借助MCUBootUtility工具完成全部流程，下載兩份含簽名的image進Flash的過程跟2.2節(jié)基本差不多，只是Secure Boot Type里需要選擇 "HAB Signed Image Boot"，含簽名的image 0下載沒什么好說的，All-In-One操作全搞定，含簽名的image 1數(shù)據(jù)可以通過在通用編程器界面里將含簽名的image 0數(shù)據(jù)全部讀回得到，這個具體操作就不詳細(xì)展開了。

含簽名image 0相比無簽名image 0多了HABdata(csf,cert,signature) 數(shù)據(jù)段，BootROM在跳轉(zhuǎn)image之前會根據(jù)HAB data數(shù)據(jù)對image進行驗簽，驗簽通過才做跳轉(zhuǎn)。

此時再做一次破壞實驗，結(jié)果如下，顯然加了簽名的image 0其完整性就有保證了，這時的冗余程序啟動設(shè)計才能發(fā)揮出最大效果。

來源：恩智浦MCU加油站（作者： 痞子衡）