先楫半导体 HPM6000 系列常见的两种二级Bootloader 方案介绍

cathy 发布于：周四, 03/23/2023 - 10:46 ，关键词：

概述

作为高性能、低功耗的嵌入式MCU产品，先楫半导体的HPM6000 系列产品广泛应用于多个领域。在嵌入式系统的开发中，Bootloader 常常是开发者可能会遇到的第一个技术难点。应用程序运行环境能否正确构建，内核能否启动成功，都取决于Bootloader 能否正确工作。一个功能完善的嵌入式系统，还需要Bootloader 能够实现系统OTA更新升级的能力，即除了usb烧录、串口烧录等方式外，还预留给客户通过以太网等方式实现快捷固件升级的窗口。

本文以HPM6450为例，基于HPM6000 系列产品嵌入式系统的硬件平台和RT—thread 软件平台，描述系统引导程序Bootloader 的设计思路，阐述了设计时需要考量的因素和遇到的技术难点及操作，希望能给大家一些启发。

二级boot方案思路分析

（图1：整体思路分析）

如上图所示，整个方案涉及3个部分：

FLASH空间的分区
二级boot
APP固件

因本次我们讨论的重点是“二级boot”，所以下文内容仅涉及前两部分。

1、FLASH空间的分区

HPM6700/6400系列的单片机和我们常用的stm32、at32这类的单片机最大的不同是该系列MCU 是通过 xpi 总线外挂外部FLASH，即代码存储在外部FLASH。

查阅芯片用户手册可知，该系列MCU支持通过 XPI0 或XPI1外挂FLASH（FLASH外挂方式，如图2所示）。

其中xpi0映射的地址空间是0x80000000，xpi1映射的地址空间是 0x90000000, CPU可对这两块地址空间直接寻址并运行代码（如图3所示）。

（图2：外部FLASH挂载于xpi0原理图）

（图3：地址空间映射关系）

为实现固件升级，FLASH空间需要进行合理的划分，如Bootloader分区、用户程序分区、OTA升级分区、用户数据分区等。在RT-Thread上，FAL组件提供了方便的分区划分机制。

本文分享的两种方案均以W25Q256为例，该FLASH大小为32MB，挂载于XPI0外设上，首地址为0x80000000,通过FAL组件对FLASH的分区详情如下图所示：

（图4：Flash 分区表）

注意，其中：

boot分区表示二级boot，该分区预留了1MB的存储空间，为未来的功能升级留足了空间。
app 分区可根据实际需要来分配大小，本方案中预留了1MB的空间。
download分区用于下载固件，在APP执行过程中，新固件通过OTA下载于该分区，并在重启后由boot分区的bootloader完成合法性检验和新固件升级操作。
Filesystem 分区用于实现文件系统，在此分区上面可以挂载littelfs格式文件系统，可以避免因频繁掉电导致数据丢失的问题。
Easyflash 分区可用于存储一些简单的参数等。

2、二级boot

二级boot由芯片BootROM引导，从芯片的用户手册可知：HPM6700系列支持多种启动方式，可到先楫半导体官网上查看“HPM6700/6400用户手册”的19.1内容部分，如下：

（图5：官方代码启动描述）

由上可知当从串行nor flash启动的时候，可支持“原地代码执行”和“拷贝到内部RAM”执行。“启动方式一” 表示代码存储在外部flash，并由CPU直接在flash上执行代码；“启动方式二” 表示代码存在flash里面，然后通过BootROM复制代码到内存后再执行。

受BootROM支持的两类启动方式的启发，笔者经过分析以及与官方的技术支持讨论得出如下结论：

采用FLASH原地执行的方式，系统可支持更大尺寸的应用程序，如支持GUI的应用。在cache的加持下，该方式可实现成本和执行速度的平衡。（需要注意的是：由于FLASH固有属性的限制(多数FLASH不支持RWW)，在需要支持FLASH擦写的应用中，用户代码需要做一些防止产生RWW场景的保护。）
采用拷贝到RAM中执行的方式，可实现如下优势：

✔ 用户代码以更高的性能执行（RAM的随机访问性能优于FLASH）

✔ 规避了FLASH不支持RWW的限制，由于代码执行于RAM，在需要FLASH擦写的应用中逻辑会更简单。

考虑到HPM6700/HPM6400系列有高达2MB连续空间的RAM，若用户代码及代码所需要的RAM所占用的空间总和小于或等于2MB，“启动方式二” 是一种值得考虑的选择。

由于二级boot 同时支持以上两种启动方案，接下来，我们将针对每种方案分别进行讨论。

方案一：FLASH原地执行

在该方案下，app 在FLASH里执行。如上所述，app 存储于FLASH 1MB偏移处，需要将链接脚本中的FLASH首地址改为0x80100000。

需要注意的是，由于app是被二级 Bootloader 引导，因此应用程序中不应再携带用于 BootROM 引导识别的启动头(boot header)。

Boot 的 FLASH 脚本不改，最终跳转逻辑为：

Boot启动

检查download分区是否有新固件，如果有则拷贝到APP
关闭中断
跳转到0x80100000地址，就启动了APP。

这样就完成了二级boot的设计。

这里最关键的就是如何修改连接脚本。

（图6：启动地址修改）

修改好app的链接脚本后，需要在boot里面进行跳转，跳转代码参考如下：

（图7：Boot 里跳转）

其中app_addr 为跳转偏移地址，如下：

（图8：偏移地址计算）

二级boot完成App跳转后，App在FLASH中原地执行。该方案的优势是与复制到RAM相比，应用的尺寸可以大至数十MB。考虑到FLASH的固有限制（随机访问性能稍弱，不支持RWW等），当应用程序执行于FLASH上，开发者需要注意以下几点：

对于需要高频执行的、对性能有要求的代码，用户程序需要将其复制到RAM中执行，否则会影响程序的效率（若cache未命中）。

若需要执行FLASH擦写操作，需要保证在FLASH擦写期间，没有程序或者其他外设访问FLASH（具体的实现方式有：关全局中断、关调度器等）。

完成FLASH擦写操作后，用户代码需要保证cache 一致性，否则可能会导致未预期的后果（如读到错误代码/数据）。

方案二：内存执行

若用户代码加代码所需的RAM总和小于2M，基于HPM6700/HPM6400有高达2MB的连续RAM，为规避FLASH固有限制带来的不便，产品可采用方案二，即：App本身在RAM中执行。启动过程中，二级boot将App复制到RAM中并中转到APP的目标地址执行。

（图9：内存系统描述）

采用该方案时，需要注意以下三点：

二级boot所使用的RAM不应和用户App所在RAM区域重叠，否则在拷贝中会产生错误。
二级boot在跳转到用户App前需要恢复中断到默认状态（关闭中断）。
boot采用flash link的编译方式，APP要采用ram link的编译方式，即APP是通过内存方式的链接脚本，因此APP编译后无法通过下载到flash的方式调试，必须使用USB或者其他的方式下载固件到0x80100000处。