OTA升級中App切換痛點(diǎn)是什么

OTA升級設(shè)計(jì)幾乎是每個量產(chǎn)客戶都繞不開的話題，產(chǎn)品發(fā)布后免不了要做固件(App)升級以修復(fù)bug或者增加新特性。升級App是個麻煩事，因?yàn)樘幚聿缓?，App被破壞了導(dǎo)致啟動不了，產(chǎn)品就容易變磚，變了磚即使能救回來，也非常影響用戶體驗(yàn)。

如今基于i.MXRT的客戶量產(chǎn)產(chǎn)品越來越多，關(guān)于OTA安全升級的客戶支持也越來越多。早期的i.MXRT型號（比如i.MXRT1050/1020/1015）在做基于FlexSPI NOR Flash的OTA升級時，有一個最大痛點(diǎn)即App版本切換不便，因此后面的i.MXRT型號中（比如i.MXRT1064/1060/1010）新增了FlexSPI的Remap功能。今天就來介紹一下這個Remap功能是如何用于安全OTA的。

一、OTA設(shè)計(jì)中的痛點(diǎn)

1.1 OTA一般設(shè)計(jì)

在講App版本切換不便痛點(diǎn)前，先給大家簡單介紹一下OTA升級設(shè)計(jì)過程中處理App版本的一般套路。下面是一個典型的OTA設(shè)計(jì)中NOR Flash里內(nèi)容分布，最前面一般是L2 OTA Boot，負(fù)責(zé)更新升級或者啟動App；接下來是主App區(qū)，就是真正實(shí)現(xiàn)產(chǎn)品功能的App；然后是Temp區(qū)，一般用作App更新臨時緩沖區(qū)；最后是User Data區(qū)，存放一些固定不變的圖片資源（如果有GUI的話），或者放一些動態(tài)保存的系統(tǒng)關(guān)鍵數(shù)據(jù)。

 

這里面的Temp區(qū)設(shè)計(jì)是一個關(guān)鍵，如果沒有Temp區(qū)，在OTA升級時只能原地覆蓋主App區(qū)（App 1），升級過程中一旦發(fā)生意外（比如斷電），系統(tǒng)里就沒有完整App可用了，會導(dǎo)致產(chǎn)品變磚。而有了Temp區(qū)作緩存，升級過程就會可靠多了，如下圖所示，新版本App（App 2）首先會被放在Temp區(qū)，僅當(dāng)App 2完整性校驗(yàn)通過之后，才會從Temp區(qū)搬移到主App區(qū)，搬移完成之后再擦除Temp區(qū)。這樣的設(shè)計(jì)下，即使App 2下載到Temp區(qū)或者App 2往App 1搬移時發(fā)生意外，系統(tǒng)里都有完整App用于恢復(fù)。

 

上面介紹的處理App版本的典型設(shè)計(jì)在實(shí)際應(yīng)用中其實(shí)不算特別常用，因?yàn)橄到y(tǒng)中僅存在一份最新的App，其不支持版本回滾。有時候我們的新版本App因?yàn)橐恍┰颍ū热缧略龉δ苡衎ug）導(dǎo)致運(yùn)行并不穩(wěn)定，我們希望能夠回退到上一個已經(jīng)運(yùn)行穩(wěn)定的舊版本App，系統(tǒng)需要保留兩份不同版本App，所以就有了如下改進(jìn)的OTA設(shè)計(jì)NOR Flash內(nèi)容分布，在主App區(qū)（App 2）后面增加一個次App區(qū)（App 1）。

 

這時候升級過程稍微復(fù)雜一點(diǎn)，如下圖所示，多了一步主App區(qū)（App 2）搬移到次App區(qū)（App 1）的過程(Step 2)，這也是版本回滾的關(guān)鍵。不過萬事都是有代價的，版本回滾的代價就是增加了OTA升級的時間，以及將Flash中App區(qū)從兩段劃分成三段，導(dǎo)致App最大長度減少了1/3。

 

1.2 App版本切換痛點(diǎn)

前面介紹了OTA升級設(shè)計(jì)中管理App版本的兩種方法，注意這里的App都是指在FlexSPI NOR Flash中原地執(zhí)行(XIP)的App，代碼鏈接在芯片內(nèi)部SRAM或者外擴(kuò)RAM的App不在討論范疇（這種Non-XIP屬性的App升級不存在版本切換的痛點(diǎn)）。現(xiàn)在聊XIP App版本切換的痛點(diǎn)：

在上面的圖中你會發(fā)現(xiàn)，新版本App最終都會被搬到主App區(qū)（就是緊接著L2 OTA Boot后面的第一個App位置），為什么要這么做？這就涉及MCU中App鏈接相關(guān)知識了，因?yàn)镸CU不同于MPU，其沒有MMU組件，不支持虛擬內(nèi)存，所以App一般都是固定地址鏈接，App代碼體二進(jìn)制數(shù)據(jù)僅放在鏈接的位置才可以正常執(zhí)行，將App拷貝到非鏈接位置是不能運(yùn)行的。OTA升級中雖然App版本不同，但是這些App都有一個共同的鏈接地址，即都是鏈接在主App區(qū)的。

比如下圖OTA系統(tǒng)中使用了一塊8MB的Flash，在i.MXRT里的系統(tǒng)映射起始地址是0x60000000，L2 OTA Boot和User Data各占1MB，剩余6MB被均分成3段，那么App x/2/1都需要從0x60100000地址開始鏈接放中斷向量表。

 

可能你會說，我們也可以設(shè)計(jì)不同鏈接地址的App，這樣就不需要將新版本App都往主App區(qū)搬移了，是的，原理上可以這么做，但實(shí)踐中，需要管理不同鏈接地址的App，導(dǎo)致OTA升級上位機(jī)端操作比較復(fù)雜，容易出錯（當(dāng)前待升級的App必須與上一次升級的App鏈接地址不同），因此這種方法不推薦。

所以最大的痛點(diǎn)就是App總要往主App區(qū)搬移，既增加了OTA升級時間，也因?yàn)榘嵋撇僮鬟^多減小了Flash的壽命（總擦寫次數(shù)是一定的）。

二、詳解FlexSPI Remap功能

2.1 FlexSPI NOR系統(tǒng)映射地址

我們知道FlexSPI連接的NOR Flash能夠?qū)崿F(xiàn)XIP，最主要的原因是FlexSPI有對應(yīng)系統(tǒng)映射空間且NOR Flash自身可以按Byte地址訪問，這里的系統(tǒng)映射空間主要用于AHB方式讀。CPU去從系統(tǒng)映射空間里讀App指令碼，F(xiàn)lexSPI模塊會自動將AHB總線傳來的地址數(shù)據(jù)請求轉(zhuǎn)換成IPG命令方式去獲取NOR Flash里的對應(yīng)指令內(nèi)容。更多原理可參看 《在串行NOR Flash XIP調(diào)試原理》。

i.MXRT1060中分配給FlexSPI的系統(tǒng)映射空間如下，兩個FlexSPI一共分配了496MB。

 

i.MXRT1010中分配給FlexSPI的系統(tǒng)映射空間如下，一個FlexSPI分配了504MB。

 

2.2 FlexSPI Remap功能設(shè)計(jì)

i.MXRT中的Remap設(shè)計(jì)其實(shí)是系統(tǒng)架構(gòu)層面的，在AHB總線層面做一個地址重定向，并不是在FlexSPI模塊里實(shí)現(xiàn)的，這也是為什么Remap相關(guān)控制在IOMUXC_GPR寄存器里（設(shè)置后Remap立刻生效，但這些寄存器不是非易失性的，普通軟復(fù)位就會置位）。下面是Remap控制寄存器（對于含兩個FlexSPI的型號，Remap控制是同時作用的）：

Remap設(shè)計(jì)說起來其實(shí)特別簡單，就是地址（addr）落在[ADDR_START, ADDR_END]里的AHB訪問，其實(shí)際訪問到的是addr + ADDR_OFFSET位置處的數(shù)據(jù)。（注意ADDR_START, ADDR_END, ADDR_OFFSET都是4KB對齊的）

舉例來看，根據(jù)ADDR_OFFSET的大小不同，會有三種情況：第一種是ADDR_OFFSET = ADDR_END - ADDR_START，如下圖所示。這也是OTA中最常用的情況，ADDR_START可設(shè)為主App區(qū)起始地址，ADDR_END可設(shè)為次App區(qū)起始地址。

 

第二種是ADDR_OFFSET > ADDR_END - ADDR_START，如下圖所示：

 

第三種是ADDR_OFFSET < ADDR_END - ADDR_START，如下圖所示。不過這種情況在實(shí)際應(yīng)用中并不推薦。

 

2.3 Remap對擦寫Flash的影響

啟用了Remap功能后，很多人會對調(diào)用FlexSPI NOR驅(qū)動函數(shù)去擦寫Flash有點(diǎn)疑惑。其實(shí)完全不必要有這種疑惑，擦寫Flash操作走的是FlexSPI IPG命令方式，屬于FlexSPI模塊內(nèi)部的事情，完全不受上層系統(tǒng)Remap功能影響，你可以就當(dāng)Remap功能完全不存在，原來怎么做還是怎么做。

三、FlexSPI Remap解決OTA痛點(diǎn)

有了Remap功能，現(xiàn)在再回到OTA設(shè)計(jì)，此時我們只需要兩個App分區(qū)即可。新版本App（App 2）首先會被放在后Temp區(qū)，App 2更新完成且校驗(yàn)通過之后，直接使用Remap功能將App 2重映射到App 1位置，此舉既不增加額外物理搬移操作，也同時保留了新舊兩份App可以實(shí)現(xiàn)版本回滾，而且整個OTA過程僅有一次App擦寫耗時也最短，完美解決痛點(diǎn)。

當(dāng)Remap功能已被使能，再有新版本App（App 3）更新需求時，其需要被下載到前Temp區(qū)，注意Flash擦寫操作都是通過IPG方式實(shí)現(xiàn)，所以不受Remap功能干擾，僅需關(guān)注絕對物理地址偏移，App下載完成，取消Remap功能即可，如此往復(fù)。