先楫半导体 HPM6000 系列常见的两种二级Bootloader 方案介绍
作为高性能、低功耗的嵌入式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处。
（图10：工作示意图）
以下为boot里面的链接修改，供大家参考：
（图11：Boot链接脚本参考）
（图12：App ram link方式链接文件参考）
在方案二中，二级boot需要做的操作比flash boot的方式多了一个步骤，需要先将APP分区的代码拷贝至内存，然后再跳转至内存执行。
（图13：代码拷贝至内存）
（图14：代码跳转至内存执行）
注意跳转前，需要关闭各种中断。
（图15：运行效果示意图）
3
注意事项
选择链接脚本时，要注意看左侧的链接脚本是否正确，如下图所示：
（图16：链接脚本示意图）
如果链接脚本不能执行，请检查下图的设置。
（图17：勾选newlib-nano）
编译的时候，需要把nerlib-nano勾选上，否则当使用memcpy的时候，有可能会出现 “非法指令” 的错误。
4
资料分享
先楫半导体HPM6750系列技术资料分享
百度云网盘链接：
https://pan.baidu.com/s/1QSr7nkGgKCKeeTpED7I_RQ
提取码：13kr
阿里云网盘链接：
https://www.aliyundrive.com/s/aXgJujYknB5
提取码：90ok
5
文章参考
（源文链接——https://gitee.com/spunky_973/rt-fota）
大家注意上文提到的这几点操作，相信会减少在添加Bootloader过程当中遇到的不少问题。
如果大家在开发过程中还有其他的思路或建议，欢迎到官方网站的 “先楫社区”
（http://www.hpmicro.com/support/forumpark.html）发贴讨论，MCU生态建设需要各位的积极参与，感谢您的信任与支持！
“先楫半导体”（HPMicro）是一家致力于高性能嵌入式解决方案的半导体公司，产品覆盖微控制器、微处理器和周边芯片，以及配套的开发工具和生态系统。公司成立于2020年6月，总部坐落于上海市张江高科技园区，并在天津、深圳、苏州和杭州均设立分公司。核心团队来自世界知名半导体公司管理团队，具有15年以上，超过20个SoC的丰富的研发及管理经验。
先楫半导体以产品质量为本，所有产品均通过严格的可靠性测试。目前已经量产的高性能通用MCU产品系列HPM6700/6400、HPM6300及HPM6200，性能领先国际同类产品，并完成AEC-Q100认证，全力服务中国工业，汽车和消费市场。
