OTA升级设计几乎是每个量产客户都绕不开的话题，产品发布后免不了要做固件(App)升级以修复bug或者增加新特性。升级App是个麻烦事，因为处理不好，App被破坏了导致启动不了，产品就容易变砖，变了砖即使能救回来，也非常影响用户体验。

如今基于i.MXRT的客户量产产品越来越多，关于OTA安全升级的客户支持也越来越多。早期的i.MXRT型号（比如i.MXRT1050/1020/1015）在做基于FlexSPI NOR Flash的OTA升级时，有一个最大痛点即App版本切换不便，因此后面的i.MXRT型号中（比如i.MXRT1064/1060/1010）新增了FlexSPI的Remap功能。今天就来介绍一下这个Remap功能是如何用于安全OTA的。

一、OTA设计中的痛点

1.1 OTA一般设计

在讲App版本切换不便痛点前，先给大家简单介绍一下OTA升级设计过程中处理App版本的一般套路。下面是一个典型的OTA设计中NOR Flash里内容分布，最前面一般是L2 OTA Boot，负责更新升级或者启动App；接下来是主App区，就是真正实现产品功能的App；然后是Temp区，一般用作App更新临时缓冲区；最后是User Data区，存放一些固定不变的图片资源（如果有GUI的话），或者放一些动态保存的系统关键数据。

 

这里面的Temp区设计是一个关键，如果没有Temp区，在OTA升级时只能原地覆盖主App区（App 1），升级过程中一旦发生意外（比如断电），系统里就没有完整App可用了，会导致产品变砖。而有了Temp区作缓存，升级过程就会可靠多了，如下图所示，新版本App（App 2）首先会被放在Temp区，仅当App 2完整性校验通过之后，才会从Temp区搬移到主App区，搬移完成之后再擦除Temp区。这样的设计下，即使App 2下载到Temp区或者App 2往App 1搬移时发生意外，系统里都有完整App用于恢复。

 

上面介绍的处理App版本的典型设计在实际应用中其实不算特别常用，因为系统中仅存在一份最新的App，其不支持版本回滚。有时候我们的新版本App因为一些原因（比如新增功能有bug）导致运行并不稳定，我们希望能够回退到上一个已经运行稳定的旧版本App，系统需要保留两份不同版本App，所以就有了如下改进的OTA设计NOR Flash内容分布，在主App区（App 2）后面增加一个次App区（App 1）。

 

这时候升级过程稍微复杂一点，如下图所示，多了一步主App区（App 2）搬移到次App区（App 1）的过程(Step 2)，这也是版本回滚的关键。不过万事都是有代价的，版本回滚的代价就是增加了OTA升级的时间，以及将Flash中App区从两段划分成三段，导致App最大长度减少了1/3。

 

1.2 App版本切换痛点

前面介绍了OTA升级设计中管理App版本的两种方法，注意这里的App都是指在FlexSPI NOR Flash中原地执行(XIP)的App，代码链接在芯片内部SRAM或者外扩RAM的App不在讨论范畴（这种Non-XIP属性的App升级不存在版本切换的痛点）。现在聊XIP App版本切换的痛点：

在上面的图中你会发现，新版本App最终都会被搬到主App区（就是紧接着L2 OTA Boot后面的第一个App位置），为什么要这么做？这就涉及MCU中App链接相关知识了，因为MCU不同于MPU，其没有MMU组件，不支持虚拟内存，所以App一般都是固定地址链接，App代码体二进制数据仅放在链接的位置才可以正常执行，将App拷贝到非链接位置是不能运行的。OTA升级中虽然App版本不同，但是这些App都有一个共同的链接地址，即都是链接在主App区的。

比如下图OTA系统中使用了一块8MB的Flash，在i.MXRT里的系统映射起始地址是0x60000000，L2 OTA Boot和User Data各占1MB，剩余6MB被均分成3段，那么App x/2/1都需要从0x60100000地址开始链接放中断向量表。

 

可能你会说，我们也可以设计不同链接地址的App，这样就不需要将新版本App都往主App区搬移了，是的，原理上可以这么做，但实践中，需要管理不同链接地址的App，导致OTA升级上位机端操作比较复杂，容易出错（当前待升级的App必须与上一次升级的App链接地址不同），因此这种方法不推荐。

所以最大的痛点就是App总要往主App区搬移，既增加了OTA升级时间，也因为搬移操作过多减小了Flash的寿命（总擦写次数是一定的）。

二、详解FlexSPI Remap功能

2.1 FlexSPI NOR系统映射地址

我们知道FlexSPI连接的NOR Flash能够实现XIP，最主要的原因是FlexSPI有对应系统映射空间且NOR Flash自身可以按Byte地址访问，这里的系统映射空间主要用于AHB方式读。CPU去从系统映射空间里读App指令码，FlexSPI模块会自动将AHB总线传来的地址数据请求转换成IPG命令方式去获取NOR Flash里的对应指令内容。更多原理可参看 《在串行NOR Flash XIP调试原理》。

i.MXRT1060中分配给FlexSPI的系统映射空间如下，两个FlexSPI一共分配了496MB。

 

i.MXRT1010中分配给FlexSPI的系统映射空间如下，一个FlexSPI分配了504MB。

 

2.2 FlexSPI Remap功能设计

i.MXRT中的Remap设计其实是系统架构层面的，在AHB总线层面做一个地址重定向，并不是在FlexSPI模块里实现的，这也是为什么Remap相关控制在IOMUXC_GPR寄存器里（设置后Remap立刻生效，但这些寄存器不是非易失性的，普通软复位就会置位）。下面是Remap控制寄存器（对于含两个FlexSPI的型号，Remap控制是同时作用的）：

Remap设计说起来其实特别简单，就是地址（addr）落在[ADDR_START, ADDR_END]里的AHB访问，其实际访问到的是addr + ADDR_OFFSET位置处的数据。（注意ADDR_START, ADDR_END, ADDR_OFFSET都是4KB对齐的）

举例来看，根据ADDR_OFFSET的大小不同，会有三种情况：第一种是ADDR_OFFSET = ADDR_END - ADDR_START，如下图所示。这也是OTA中最常用的情况，ADDR_START可设为主App区起始地址，ADDR_END可设为次App区起始地址。

 

第二种是ADDR_OFFSET > ADDR_END - ADDR_START，如下图所示：

 

第三种是ADDR_OFFSET < ADDR_END - ADDR_START，如下图所示。不过这种情况在实际应用中并不推荐。

 

2.3 Remap对擦写Flash的影响

启用了Remap功能后，很多人会对调用FlexSPI NOR驱动函数去擦写Flash有点疑惑。其实完全不必要有这种疑惑，擦写Flash操作走的是FlexSPI IPG命令方式，属于FlexSPI模块内部的事情，完全不受上层系统Remap功能影响，你可以就当Remap功能完全不存在，原来怎么做还是怎么做。

三、FlexSPI Remap解决OTA痛点

有了Remap功能，现在再回到OTA设计，此时我们只需要两个App分区即可。新版本App（App 2）首先会被放在后Temp区，App 2更新完成且校验通过之后，直接使用Remap功能将App 2重映射到App 1位置，此举既不增加额外物理搬移操作，也同时保留了新旧两份App可以实现版本回滚，而且整个OTA过程仅有一次App擦写耗时也最短，完美解决痛点。

当Remap功能已被使能，再有新版本App（App 3）更新需求时，其需要被下载到前Temp区，注意Flash擦写操作都是通过IPG方式实现，所以不受Remap功能干扰，仅需关注绝对物理地址偏移，App下载完成，取消Remap功能即可，如此往复。