系統(tǒng)時(shí)鐘配置不當(dāng)導(dǎo)致OTFAD加密啟動(dòng)失敗的解決方案

今天痞子衡給大家分享的是系統(tǒng)時(shí)鐘配置不當(dāng)會(huì)導(dǎo)致i.MXRT1xxx系列下OTFAD加密啟動(dòng)失敗問題。

我們知道，i.MXRT1xxx家族早期型號(hào)（RT1050/RT0160/RT1020）的硬件解密外設(shè)名字叫BEE，這個(gè)外設(shè)主要是配合FlexSPI外設(shè)去實(shí)現(xiàn)外接串行NOR Flash在線解密XIP執(zhí)行用的。而到了最近的i.MXRT1xxx新型號(hào)（RT1010/RT1170）上，BEE外設(shè)被替換成了OTFAD外設(shè)，功能不變，解密效率得到了很大提升，但客戶在使能OTFAD加密啟動(dòng)時(shí)常常遇到App無法正常運(yùn)行問題，這其實(shí)跟OTFAD自身的一個(gè)時(shí)鐘小限制有關(guān)（這個(gè)限制在BEE上不存在），今天痞子衡就來好好聊一聊OTFAD的這個(gè)小限制：

一、問題描述

我們以i.MXRT1010為例，從恩智浦官網(wǎng)下載一個(gè)SDK包（痞子衡下的是v2.9.1），隨便選擇其中一個(gè)例程，就以最簡(jiǎn)單的 \SDK\boards\evkmimxrt1010\demo_apps\led_blinky 為例吧。編譯這個(gè) led_blinky 工程（選擇 flexspi_nor_debug build，即XIP工程），得到可執(zhí)行文件（實(shí)際bin文件大小為10KB左右），使用 NXP-MCUBootUtility 工具將可執(zhí)行文件(led_blinky.out)下載進(jìn)MIMXRT1010-EVK開發(fā)板中（下載時(shí)啟動(dòng)模式為2'b01，啟動(dòng)時(shí)切換到2'b10），可以看到板載綠色LED小燈（D25）會(huì)閃，例程是可以正常工作的。

現(xiàn)在讓我們嘗試使能OTFAD加密，回到芯片下載模式依然借助 NXP-MCUBootUtility 工具，將工具 Secure boot type 選項(xiàng)切換為 OTFAD Encrypted Image Boot，其他設(shè)置均默認(rèn)（此時(shí)加密范圍是 0x60001000 - 0x60001fff，僅加密IVT等啟動(dòng)頭，不含app），再次下載可執(zhí)行文件(led_blinky.out)，換到芯片啟動(dòng)模式復(fù)位板子，例程依舊是正常工作的，看起來OTFAD加密啟動(dòng)似乎沒有問題。

讓我們?cè)龠M(jìn)一步，將加密范圍設(shè)置為0x60002000 - 0x60004fff，這時(shí)加密區(qū)域覆蓋到了整個(gè)app，重新按上述流程操作一遍，發(fā)現(xiàn)例程沒能正常工作，這時(shí)候OTFAD加密啟動(dòng)出了問題，難道app區(qū)域不能被加密？那OTFAD加密還有啥意義？

app區(qū)域當(dāng)然可以被加密，跟著痞子衡再做一次實(shí)驗(yàn)，在 led_blinky.c 文件的 main() 函數(shù)中，我們將時(shí)鐘配置函數(shù) BOARD_BootClockRUN() 直接注釋掉或者在鏈接文件里將其全部搞成 __ramfunc（即在芯片內(nèi)部RAM里執(zhí)行這部分時(shí)鐘配置代碼），這個(gè)例程僅是利用SysTick定時(shí)翻轉(zhuǎn)GPIO，因此時(shí)鐘配置代碼去掉不影響正常運(yùn)行，重新編譯工程再按上面流程操作一遍，這時(shí)候例程又能正常工作了，說明加密后的app是能被OTFAD正常解密執(zhí)行的。

現(xiàn)在的問題變成了為何OTFAD加密啟動(dòng)時(shí)，BOARD_BootClockRUN() 函數(shù)不能在Flash里執(zhí)行，這就是問題所在。

二、原因分析

關(guān)于上述問題的原因，痞子衡先直接給答案，這是OTFAD外設(shè)本身的時(shí)鐘小限制，當(dāng)OTFAD被使能時(shí)，如果被加密的app代碼是XIP執(zhí)行，app里做系統(tǒng)時(shí)鐘配置時(shí)要始終保證Core時(shí)鐘高于FlexSPI外設(shè)時(shí)鐘。如果Core時(shí)鐘低于FlexSPI時(shí)鐘，此時(shí)Core去訪問加密Flash區(qū)域，OTFAD無法正常解密，會(huì)導(dǎo)致指令錯(cuò)亂，發(fā)生系統(tǒng)故障。

我們配合上面的i.MXRT1010系統(tǒng)時(shí)鐘樹來認(rèn)真分析下OTFAD這個(gè)時(shí)鐘限制問題。芯片上電總是從BootROM執(zhí)行，BootROM會(huì)先將Core配置到396MHz，將FlexSPI時(shí)鐘根據(jù)用戶放置在Flash偏移0x400處的FDCB里的設(shè)定配到30MHz - 200MHz不等，再讀取Flash偏移0地址處OTFAD DEK KeyBlob數(shù)據(jù)使能OTFAD，然后讀取IVT等頭信息去跳轉(zhuǎn)到App。很顯然只加密IVT部分根本不受OTFAD限制的影響，這部分解析是在BootROM里完成的，BootROM里時(shí)鐘配置符合OTFAD時(shí)鐘限制要求。

// BootROM里對(duì)Core時(shí)鐘配置
CCM_ANALOG->PFD_528[PFD3_FRAC] = 24,   PLL2 PFD3輸出 (528MHz * 18) / 24 = 396MHz
CCM->CBCMR[PRE_PERIPH_CLK_SEL] = 2,    時(shí)鐘來自PLL2 PFD3
CCM->CBCDR[PERIPH_CLK_SEL]     = 0，   內(nèi)核時(shí)鐘來自CCM->CBCMR[PRE_PERIPH_CLK_SEL]
CCM->CBCDR[AHB_PODF]           = 0，   內(nèi)核時(shí)鐘不分頻

// BootROM里對(duì)FlexSPI時(shí)鐘配置
CCM_ANALOG->PFD_480[PFD0_FRAC] = x,    PLL3 PFD0輸出 (480MHz * 18) / x
CCM->CSCMR1[FLEXSPI_CLK_SEL]   = 3,    時(shí)鐘來自PLL3 PFD0
CCM->CSCMR1[FLEXSPI_CLK_SRC]   = 0，   FlexSPI時(shí)鐘來自CCM->CSCMR1[FLEXSPI_CLK_SEL]
CCM->CSCMR1[FLEXSPI_PODF]      = y，   FlexSPI時(shí)鐘做(y+1)分頻

當(dāng)BootROM跳轉(zhuǎn)到了App之后，我們?cè)賮砜纯碅pp里對(duì)時(shí)鐘是怎么配置的，就是BOARD_BootClockRUN()函數(shù)，可以看到這個(gè)函數(shù)里將內(nèi)核頻率從BootROM設(shè)置的396MHz切換到外部OSC 24MHz。無論此時(shí)用戶FDCB里對(duì)FlexSPI時(shí)鐘是多少配置，至少也會(huì)大于30MHz，那么此時(shí)24MHz內(nèi)核頻率一定會(huì)低于FlexSPI時(shí)鐘頻率，此時(shí)只要發(fā)生內(nèi)核對(duì)Flash加密區(qū)域的訪問（時(shí)鐘配置代碼就在Flash里執(zhí)行），就觸發(fā)了OTFAD時(shí)鐘限制問題，App就會(huì)跑飛。

三、解決方案

知道了原因，解決方案就簡(jiǎn)單了，在App時(shí)鐘配置里，不要按照尋常套路去先將內(nèi)核時(shí)鐘源切換到外部OSC再切到PLL，而是直接切到PLL上。比如i.MXRT1010內(nèi)部有個(gè)PLL6（也叫Audio PLL），固定500MHz，正好是App要的最終內(nèi)核頻率，我們?cè)贐OARD_BootClockRUN()里將Audio(Enet) PLL初始化設(shè)置代碼提到前面，刪掉原來的切換OSC設(shè)置代碼即可。

voidBOARD_BootClockRUN(void)
{
//此處略去...
/*SetOscillatorreadycountervalue.*/
CCM->CCR=(CCM->CCR&(~CCM_CCR_OSCNT_MASK))|CCM_CCR_OSCNT(127);
-/*SettingPeriphClk2MuxandPeriphMuxtoprovidestableclockbeforePLLsareinitialed*/
-CLOCK_SetMux(kCLOCK_PeriphClk2Mux,1);/*SetPERIPH_CLK2MUXtoOSC*/
-CLOCK_SetMux(kCLOCK_PeriphMux,1);/*SetPERIPH_CLKMUXtoPERIPH_CLK2*/

//此處略去...
/*SetIPG_PODF.*/
CLOCK_SetDiv(kCLOCK_IpgDiv,3);
+/*InitEnetPLL.*/
+CLOCK_InitEnetPll(&enetPllConfig_BOARD_BootClockRUN);
+/*Setpreperiphclocksource.*/
+CLOCK_SetMux(kCLOCK_PrePeriphMux,3);

//此處略去...
/*EnableAudioPLLoutput.*/
CCM_ANALOG->PLL_AUDIO|=CCM_ANALOG_PLL_AUDIO_ENABLE_MASK;
-/*InitEnetPLL.*/
-CLOCK_InitEnetPll(&enetPllConfig_BOARD_BootClockRUN);
-/*Setpreperiphclocksource.*/
-CLOCK_SetMux(kCLOCK_PrePeriphMux,3);

//此處略去...
/*SetSystemCoreClockvariable.*/
SystemCoreClock=BOARD_BOOTCLOCKRUN_CORE_CLOCK;
}

最后再提一下，這個(gè)OTFAD時(shí)鐘限制問題在i.MXRT1170上同樣存在，解決思路與上面類似，痞子衡就不再贅述了。

至此，系統(tǒng)時(shí)鐘配置不當(dāng)會(huì)導(dǎo)致i.MXRT1xxx系列下OTFAD加密啟動(dòng)失敗問題便介紹完畢了
編輯：hfy