你们好,我是痞子衡,是正经搞技术的痞子。今天痞子衡给你们分享的是系统时钟配置不当会致使i.MXRT1xxx系列下OTFAD加密启动失败问题。git
咱们知道,i.MXRT1xxx家族早期型号(RT1050/RT0160/RT1020)的硬件解密外设名字叫BEE,这个外设主要是配合FlexSPI外设去实现外接串行NOR Flash在线解密XIP执行用的。而到了最近的i.MXRT1xxx新型号(RT1010/RT1170)上,BEE外设被替换成了OTFAD外设,功能不变,解密效率获得了很大提高,但客户在使能OTFAD加密启动时经常遇到App没法正常运行问题,这其实跟OTFAD自身的一个时钟小限制有关(这个限制在BEE上不存在),今天痞子衡就来好好聊一聊OTFAD的这个小限制:github
咱们以i.MXRT1010为例,从恩智浦官网下载一个SDK包(痞子衡下的是v2.9.1),随便选择其中一个例程,就以最简单的 \SDK\boards\evkmimxrt1010\demo_apps\led_blinky 为例吧。编译这个 led_blinky 工程(选择 flexspi_nor_debug build,即XIP工程),获得可执行文件(实际bin文件大小为10KB左右),使用 NXP-MCUBootUtility 工具将可执行文件(led_blinky.out)下载进MIMXRT1010-EVK开发板中(下载时启动模式为2'b01,启动时切换到2'b10),能够看到板载绿色LED小灯(D25)会闪,例程是能够正常工做的。微信
如今让咱们尝试使能OTFAD加密,回到芯片下载模式依然借助 NXP-MCUBootUtility 工具,将工具 Secure boot type 选项切换为 OTFAD Encrypted Image Boot,其余设置均默认(此时加密范围是 0x60001000 - 0x60001fff,仅加密IVT等启动头,不含app),再次下载可执行文件(led_blinky.out),换到芯片启动模式复位板子,例程依旧是正常工做的,看起来OTFAD加密启动彷佛没有问题。app
让咱们再进一步,将加密范围设置为0x60002000 - 0x60004fff,这时加密区域覆盖到了整个app,从新按上述流程操做一遍,发现例程没能正常工做,这时候OTFAD加密启动出了问题,难道app区域不能被加密?那OTFAD加密还有啥意义?ide
app区域固然能够被加密,跟着痞子衡再作一次实验,在 led_blinky.c 文件的 main() 函数中,咱们将时钟配置函数 BOARD_BootClockRUN() 直接注释掉或者在连接文件里将其所有搞成 __ramfunc(即在芯片内部RAM里执行这部分时钟配置代码),这个例程仅是利用SysTick定时翻转GPIO,所以时钟配置代码去掉不影响正常运行,从新编译工程再按上面流程操做一遍,这时候例程又能正常工做了,说明加密后的app是能被OTFAD正常解密执行的。函数
如今的问题变成了为什么OTFAD加密启动时,BOARD_BootClockRUN() 函数不能在Flash里执行,这就是问题所在。工具
关于上述问题的缘由,痞子衡先直接给答案,这是OTFAD外设自己的时钟小限制,当OTFAD被使能时,若是被加密的app代码是XIP执行,app里作系统时钟配置时要始终保证Core时钟高于FlexSPI外设时钟。若是Core时钟低于FlexSPI时钟,此时Core去访问加密Flash区域,OTFAD没法正常解密,会致使指令错乱,发生系统故障。flex
咱们配合上面的i.MXRT1010系统时钟树来认真分析下OTFAD这个时钟限制问题。芯片上电老是从BootROM执行,BootROM会先将Core配置到396MHz,将FlexSPI时钟根据用户放置在Flash偏移0x400处的FDCB里的设定配到30MHz - 200MHz不等,再读取Flash偏移0地址处OTFAD DEK KeyBlob数据使能OTFAD,而后读取IVT等头信息去跳转到App。很显然只加密IVT部分根本不受OTFAD限制的影响,这部分解析是在BootROM里完成的,BootROM里时钟配置符合OTFAD时钟限制要求。ui
// BootROM里对Core时钟配置 CCM_ANALOG->PFD_528[PFD3_FRAC] = 24, PLL2 PFD3输出 (528MHz * 18) / 24 = 396MHz CCM->CBCMR[PRE_PERIPH_CLK_SEL] = 2, 时钟来自PLL2 PFD3 CCM->CBCDR[PERIPH_CLK_SEL] = 0, 内核时钟来自CCM->CBCMR[PRE_PERIPH_CLK_SEL] CCM->CBCDR[AHB_PODF] = 0, 内核时钟不分频 // BootROM里对FlexSPI时钟配置 CCM_ANALOG->PFD_480[PFD0_FRAC] = x, PLL3 PFD0输出 (480MHz * 18) / x CCM->CSCMR1[FLEXSPI_CLK_SEL] = 3, 时钟来自PLL3 PFD0 CCM->CSCMR1[FLEXSPI_CLK_SRC] = 0, FlexSPI时钟来自CCM->CSCMR1[FLEXSPI_CLK_SEL] CCM->CSCMR1[FLEXSPI_PODF] = y, FlexSPI时钟作(y+1)分频
当BootROM跳转到了App以后,咱们再来看看App里对时钟是怎么配置的,就是BOARD_BootClockRUN()函数,能够看到这个函数里将内核频率从BootROM设置的396MHz切换到外部OSC 24MHz。不管此时用户FDCB里对FlexSPI时钟是多少配置,至少也会大于30MHz,那么此时24MHz内核频率必定会低于FlexSPI时钟频率,此时只要发生内核对Flash加密区域的访问(时钟配置代码就在Flash里执行),就触发了OTFAD时钟限制问题,App就会跑飞。加密
知道了缘由,解决方案就简单了,在App时钟配置里,不要按照寻常套路去先将内核时钟源切换到外部OSC再切到PLL,而是直接切到PLL上。好比i.MXRT1010内部有个PLL6(也叫Audio PLL),固定500MHz,正好是App要的最终内核频率,咱们在BOARD_BootClockRUN()里将Audio(Enet) PLL初始化设置代码提到前面,删掉原来的切换OSC设置代码便可。
void BOARD_BootClockRUN(void) { // 此处略去... /* Set Oscillator ready counter value. */ CCM->CCR = (CCM->CCR & (~CCM_CCR_OSCNT_MASK)) | CCM_CCR_OSCNT(127); - /* Setting PeriphClk2Mux and PeriphMux to provide stable clock before PLLs are initialed */ - CLOCK_SetMux(kCLOCK_PeriphClk2Mux, 1); /* Set PERIPH_CLK2 MUX to OSC */ - CLOCK_SetMux(kCLOCK_PeriphMux, 1); /* Set PERIPH_CLK MUX to PERIPH_CLK2 */ // 此处略去... /* Set IPG_PODF. */ CLOCK_SetDiv(kCLOCK_IpgDiv, 3); + /* Init Enet PLL. */ + CLOCK_InitEnetPll(&enetPllConfig_BOARD_BootClockRUN); + /* Set preperiph clock source. */ + CLOCK_SetMux(kCLOCK_PrePeriphMux, 3); // 此处略去... /* Enable Audio PLL output. */ CCM_ANALOG->PLL_AUDIO |= CCM_ANALOG_PLL_AUDIO_ENABLE_MASK; - /* Init Enet PLL. */ - CLOCK_InitEnetPll(&enetPllConfig_BOARD_BootClockRUN); - /* Set preperiph clock source. */ - CLOCK_SetMux(kCLOCK_PrePeriphMux, 3); // 此处略去... /* Set SystemCoreClock variable. */ SystemCoreClock = BOARD_BOOTCLOCKRUN_CORE_CLOCK; }
最后再提一下,这个OTFAD时钟限制问题在i.MXRT1170上一样存在,解决思路与上面相似,痞子衡就再也不赘述了。
至此,系统时钟配置不当会致使i.MXRT1xxx系列下OTFAD加密启动失败问题痞子衡便介绍完毕了,掌声在哪里~~~
文章会同时发布到个人 博客园主页、CSDN主页、知乎主页、微信公众号 平台上。
微信搜索"痞子衡嵌入式"或者扫描下面二维码,就能够在手机上第一时间看了哦。