痞子衡嵌入式：揭秘i.MXRT1060,1010上串行NOR Flash冗余程序启动设计

　　大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家介绍的是i.MXRT1060,1010上串行NOR Flash冗余程序启动设计。

　　工业产品设计里经常会有冗余程序/备份程序设计的需求，因为在工业环境里要求设备能够持续稳定运行，不能轻易宕机，但现实环境中常常有各种意外发生，其中一个常见的意外就是设备主控 MCU 程序被破坏。为了降低程序损坏这种意外带来的影响，一个很典型的做法就是增加 MCU 程序的份数，第一份被破坏，就启动第二份...，用程序数量的增加来降低启动失败率，这属于概率学手段范畴。

　　我们知道恩智浦 i.MXRT 系列 MCU 内部没有非易失性存储器，它需要搭配外部存储器来工作，可选存储器类型非常多： NOR Flash, NAND Flash, eMMC, SD卡都行。其中对于 NAND 型存储器，冗余程序设计是必备的，因为 NAND 本身允许坏块现象存在，所以不得不做冗余设计。而对于 NOR 型存储器，冗余设计则不是必需的，偏偏串行 NOR Flash 是 i.MXRT 最常用的搭档，那该怎么办？别急，今天痞子衡介绍的就是 i.MXRT1010/1060 上串行 NOR Flash 冗余程序设计，恩智浦已经都给你考虑到了。

Note：本文所涉及的串行 NOR Flash 冗余程序设计在早期的 i.MXRT1050/1020/1015 型号上不被支持。

一、初识冗余程序启动

　　在 i.MXRT 上可以挂载串行 NOR Flash 去启动程序的外设有两个，分别是 FlexSPI 和 LPSPI，如下图所示。其中连接在 FlexSPI 上的 Flash A 属于主启动设备，连接在 LPSPI 上的 Flash B 属于备份启动设备（关于备份设备启动详见痞子衡旧文《从Serial(1-bit SPI) EEPROM/NOR恢复启动》）。

Note: 并不是所有 i.MXRT 型号都支持 LPSPI 外设挂载存储器去启动。

　　用两片 NOR Flash 去完成冗余程序设计当然是没问题，但也相应增加了硬件成本，而本文今天要讨论得不是这种冗余程序设计，我们要聊的是在一片挂载在 FlexSPI 上的串行 NOR Flash 里做冗余程序设计，就是图中的 image 0 和 image 1。

　　冗余程序启动流程其实特别简单，上电永远先启动物理地址靠前的 image 0，如果 image 0 被破坏了，则启动 image 1。原则上 image 0 和 image 1 应该是完全一样的（链接地址也一样，并且中途不需要搬移这两份 image 数据，这个是靠芯片里的一个黑科技做到的，下文会细讲），毕竟是冗余设计，不过你要执意放两份不完全一样的 image，倒也没问题。

二、实测冗余程序启动

　　我们知道 i.MXRT 芯片上电总是先运行厂商固化好的 BootROM，所以冗余程序启动设计是做在 BootROM 代码里的。痞子衡之前有一篇旧文《了解i.MXRT1060系列ROM中串行NOR Flash启动初始化流程优化点》中 2.1 节其实已经简单地提到了冗余程序设计，其主要借助了芯片系统 FlexSPI 地址重映射(Remap)功能，这个功能是在恩智浦后期推出的 i.MXRT1060/1010 等型号上才有的，这也是上文所说的黑科技。关于这个黑科技，痞子衡也有旧文《利用i.MXRT1060,1010上新增的FlexSPI地址重映射(Remap)功能可安全OTA》。

　　有了 FlexSPI Remap 黑科技存在，我们就可以将同一份 image binary 放在 Flash 中两个不同位置，并且不用做擦除编程操作来交换其位置，就可以实现各自的启动执行。如果没有这个黑科技，我们只能老老实实做数据搬移，这会增加擦除次数从而影响 Flash 使用寿命。

　　原理搞清楚了，现在我们在板子上实测一下这个功能，看看如何正确地放两份 image 进 Flash，哪些情况会导致 image 0 启动失败从而去启动 image 1。我们就以恩智浦官方 MIMXRT1060-EVK 开发板为例，这个板子 FlexSPI1 上挂了两片 Flash，默认连接的 8MB QuadSPI Flash，还有一片 64MB HyperFlash（需要做板子改动才能使能）：

2.1 使能冗余程序启动

　　使能冗余程序启动特性很简单，就是将 fuse 0x6E0[23:16] - FLEXSPI_NOR_SEC_IMAGE_OFFSET 烧录为非 0 值即可，根据下面定义，第二份 image 偏移地址最大可以设到 Flash 中 0x3FC0000（63.75MB）处：

                                                  Remap功能的ADDR_START寄存器固定设为 Flash 起始映射地址。
fuse 0x6e0[15:13] - xSPI_FLASH_IMAGE_SIZE，       App的最大长度，标识了第一份App的结束地址，该值加上ADDR_START后被填入Remap功能的ADDR_END寄存器。
fuse 0x6e0[23:16] - FLEXSPI_NOR_SEC_IMAGE_OFFSET，标识了第二份App的起始地址（在Flash中偏移位置），即填入Remap功能的ADDR_OFFSET寄存器的值。

　　本次测试，我们就将 FLEXSPI_NOR_SEC_IMAGE_OFFSET 烧录为 0x10，xSPI_FLASH_IMAGE_SIZE 保持默认 0，即第二份 image 偏移地址在 Flash 0x400000（4MB）处，最大 image 长度也是 4MB，可借助 MCUBootUtility 工具完成 Fuse 烧录：

2.2 下载两份无签名 image 进 Flash

　　现在开始准备 image，我们就直接用 \SDK_2.10.1_EVK-MIMXRT1060\boards\evkmimxrt1060\demo_apps\led_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.MXRT1060 就是 0x60000000；对于 i.MXRT1010 应该是 0x60000400，具体查看工程链接文件便知）。此外我们使用的是完整的可启动镜像文件（包含了全部所需启动头），也可以直接在软件通用编程器界面做下载。

　　image 0 下载进 Flash 后，继续下载 image 1，这时候只能在软件通用编程器界面操作。这里主要是设置好下载起始地址，前面我们使能冗余程序启动时在 Fuse 里设置的偏移地址是 0x400000，那么此时下载起始地址就应该是 0x400000（对于 i.MXRT1060 是 0x400000；对于 i.MXRT1010 应该是 0x400400）。至此两份 image 下载就完成了。

2.3 快速验证两份 image 正确性

　　现在 Flash 里有了两份 image，我们来做一个快速验证，看看 image 是不是放得符合冗余程序启动的要求。对于 image 0，没什么好说的，芯片启动模式设为 2'b10 后断电复位应该可以看到 image 0 在执行，最重要的是验证 image 1 是不是合法。

　　这里开始涉及到芯片冗余程序启动流程核心了，当 image 0 启动失败后，芯片 BootROM 不是立刻去执行 image 1 的，它用了一个取巧的方式，在一个软复位不置位的寄存器里（SRC_GPR10）标记了当前状态，然后调用 NVIC_SystemReset() 重新进入 BootROM 执行，第二次 BootROM 执行时才会去启动 image 1。

　　所以这也给了我们快速验证 image 1 执行的可能性，我们在板子上挂上 J-Link 仿真器，然后打开 J-Link Commander，直接将 SRC_GPR10 寄存器改写为 0x40000000，再依次执行 reset 和 go 命令，这时你应该可以看到 image 1 正在执行了。

2.4 测试无签名 image 0 损坏条件

　　痞子衡之前在《i.MXRT Bootable image格式》一文里介绍过一个可启动 image 包含哪些组成部分，其中最简单的无签名 image 应该至少包含 FDCB, IVT, BD, App 四部分，芯片 BootROM 也是按序读取这四部分数据完成程序启动的。

　　现在我们尝试分别破坏这几个组成部分来看看何种程度的 image 0 损坏能被 BootROM 识别出从而去启动 image 1，下面是测试结果。从测试结果来看，除了 Image 0 - App 的损坏无法检测外，image 0 其余启动头的损坏都可以被 BootROM 识别到。

测试项	损坏程度	测试结果	备注
Image 0 - FDCB	全无或关键配置丢失导致Flash无法访问	无签名image 0启动失败无签名image 1启动成功	如启用Auto Probe功能，则FDCB无所谓
Image 0 - IVT,BD	全无或关键配置丢失导致App信息无法找到	无签名image 0启动失败无签名image 1启动成功	N/A
Image 0 - App	任意破坏App区域	无签名image 0被启动，但执行情况视破坏程度而定无签名image 1未被启动	N/A

2.5 能检测 image 0 app 损坏的方法

　　如果不能检测 image app 部分的损坏，那这个冗余程序启动功能就比较鸡肋了，毕竟 app 部分的数据才是整个 image 核心所在。如果要加上 app 损坏检测，需要使能 i.MXRT 签名启动，还是可以借助 MCUBootUtility 工具完成全部流程，下载两份含签名的 image 进 Flash 的过程跟 2.2 节基本差不多，只是 Secure Boot Type 里需要选择 "HAB Signed Image Boot"，含签名的 image 0 下载没什么好说的，All-In-One 操作全搞定，含签名的 image 1 数据可以通过在通用编程器界面里将含签名的 image 0 数据全部读回得到，这个具体操作就不详细展开了。

　　含签名 image 0 相比无签名 image 0 多了 HAB data(csf,cert,signature) 数据段，BootROM 在跳转 image 之前会根据 HAB data 数据对 image 进行验签，验签通过才做跳转。

　　此时再做一次破坏实验，结果如下，显然加了签名的 image 0 其完整性就有保证了，这时的冗余程序启动设计才能发挥出最大效果。

测试项	损坏程度	测试结果	备注
Image 0 - FDCB	全无或关键配置丢失导致Flash无法访问	含签名image 0启动失败含签名image 1启动成功	如启用Auto Probe功能，则FDCB无所谓
Image 0 - IVT,BD	全无或关键配置丢失导致App信息无法找到	含签名image 0启动失败含签名image 1启动成功	N/A
Image 0 - App,HAB data	任意破坏App,HAB Data区域	含签名image 0启动失败含签名image 1启动成功	N/A