痞子衡嵌入式:利用i.MXRT1060,1010上新增的FlexSPI地址重映射(Remap)功能可安全OTA


  大家好,我是痞子衡,是正经搞技术的痞子。今天痞子衡给大家介绍的是i.MXRT部分型号上新增的FlexSPI Remap功能

  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功能 对应控制寄存器
i.MXRT106x i.MXRT1010
ADDR_START IOMUXC_GPR_GPR30 IOMUXC_GPR_GPR27
ADDR_END IOMUXC_GPR_GPR31 IOMUXC_GPR_GPR28
ADDR_OFFSET IOMUXC_GPR_GPR32 IOMUXC_GPR_GPR29

  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功能完全不存在,原来怎么做还是怎么做。

  下面这段测试代码是在MIMXRT1060-EVK上跑的,用ROM API驱动擦写0x60100000地址,擦写操作前加了一段Remap设置干扰,实测下来Remap设置对擦写没有任何影响,复位后去读Flash,操作的还是原0x60100000地址。其实从测试代码也能看出端倪,API里传入是0x100000,这是Flash绝对偏移地址,跟系统映射没关系。

flexspi_nor_config_t flashConfig;
serial_nor_config_option_t configOption;
configOption.option0.U = 0xc0000007;

uint32_t programBuffer[64];
for (uint32_t i = 0; i < sizeof(programBuffer); i++)
{
    *((uint8_t *)programBuffer + i) = (uint8_t)(i & 0xFF);
}

IOMUXC_GPR->GPR30 = 0x60100000;
IOMUXC_GPR->GPR31 = 0x60200000;
IOMUXC_GPR->GPR32 = 0x100000;

g_bootloaderTree->flexSpiNorDriver->get_config(0, &flashConfig, &configOption);
g_bootloaderTree->flexSpiNorDriver->init(0, &flashConfig);
g_bootloaderTree->flexSpiNorDriver->erase(0, &flashConfig, 0x100000, 0x100);
g_bootloaderTree->flexSpiNorDriver->program(0, &flashConfig, 0x100000, programBuffer);

三、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功能即可,如此往复。

  至此,i.MXRT部分型号上新增的FlexSPI Remap功能痞子衡便介绍完毕了,掌声在哪里~~~

欢迎订阅

文章会同时发布到我的 博客园主页CSDN主页知乎主页微信公众号 平台上。

微信搜索"痞子衡嵌入式"或者扫描下面二维码,就可以在手机上第一时间看了哦。

posted @ 2020-08-15 20:50  痞子衡  阅读(1603)  评论(2编辑  收藏  举报