ME05安全启动适配AB分区方案咨询

[White_Adam]

目前我的项目使用的是A/B分区的升级方式，而安全启动的逻辑是云途固化，之前我咨询过一次相关问题，但没有深入沟通，当时给出了一个物理隔离方案。 对于该方案我的疑惑点是：1、验签的地址范围以及验签成功后跳转的地址是静态配置在BVT中（（如BankA的App固定地址A，BankB的App固定地址B），如果我配置校验BankA，BankA的Secure Boot永远不会校验BankB的App，导致新写入B区的固件无法被校验。2、验签成功后，BankA的Secure Boot只能跳转到自身App的固定入口，无法跳转到BankB。当前方案的核心痛点该怎么解决？是否有其他更合适的方案？

[Diga]

Secure Boot 只有验签功能，没有 Bootloader 的职能，即 secure boot 不会去操作 Flash

理想的流程应该是，A 面的 secure boot 来保证 A 面的 Bootloader 完整性，A 面的 App 应由 A面的 bootloader 或 B 面的 bootloader 来保证完整性。

用户应该通过通信控制 A面 bootloader 跳转至A面的 app，或者直接boot swap，即 A B面交换，由 B面的bootloader 接管

[White_Adam]

Diga 1、当前我开发的项目中是没有Bootloader的，原则上不能因为安全启动就去动这个架构；2、按照您提供的这个思路A/B区出厂时就要固化BVT段，因为在后续升级的时候我并不清楚本次active的是A/B区，无法确定需要验签的地址范围。3、A/B区需要配置不同的BVT，分别放在不同的地址段。4、您的回复你表明secureboot不会操作Flash，那图中我划线的这个配置项的作用是什么？
5、是否能确认工具配置的安全启动依赖项全在BVT段？如验签地址范围这些关键数据，只刷写APP部分是否会影响到配置信息？

[Diga]

Secure Boot 不会操作 Flash，图中指示的是应用程序跳转地址。

如果你通过 OTA 方式修改了 App，但 Secure Boot 的加密内容中包含了 App，那就必须重新进行验签。建议 Secure Boot 去保证一段你不会修改的程序区域的完整性

[White_Adam]

Diga 你好，我按照图中方案 Secure Boot烧录起始地址0x80000，APP烧录起始地址为0x84000，无法正常执行启动；但是更改Secure Boot烧录起始地址到0x00却可以正常执行，这个问题有什么可能的原因吗？