2393077_zh-CN

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

2393077_zh-CN

2393077_zh-CN

S32K3引导加载程序和HSE - 最佳实践?

您好,NXP团队:

我们正在 S32K312 上实施一个强大的 OTA 更新架构,采用 HSE 全块 A/B 交换。

我们的目标架构是:

- S32K312,2 MB PFlash 分为两个 1 MB 物理块。
- HSE AB_SWAP 通过被动块激活服务使用。
- 通过 Modbus/串口接收 OTA 数据包。
- 引导加载程序将签名映像加载到被动 PFlash 块中。
- HSE 验证被动图像/SMR。
- 引导加载程序请求 AP_SWAP。
- RESET后,新更换的银行暂时启动。
- 确认命令可使交换永久生效;否则设备将回滚。

最初我们尝试将一个全局引导加载程序放在 DFlash 中,位于两个 PFlash 存储区之外。该引导加载程序将接收 OTA,对被动 PFlash 存储进行编程,请求 HSE AP_SWAP,然后继续管理确认/回滚。

我们采用这种方法遇到了架构和运行时复杂性方面的问题:

1. HSE AB_SWAP 似乎在完整的 PFlash 块边界上进行操作,而不是在任意应用程序分区上进行操作。
2. 单个 DFlash 引导加载程序位于已交换/已验证的银行映像之外。
3. 交换后,活动的 PFlash 存储体仍然需要有效的启动/IVT/RESET 结构。
4. 当 DFlash 也参与引导加载程序运行时/记录处理时,我们遇到了执行方面的困难。
5.目前还不清楚全局 DFlash 引导加载程序是否与干净的全库 HSE AB_SWAP 生产设计兼容。

因此,我们暂时改用复制的PFlash引导加载程序模式:

- 每个 1 MB PFlash 存储区包含自己的 IVT + 引导加载程序 + 应用程序。
- 引导加载程序在每个存储体的底部都有一个预留插槽。
应用程序在引导加载程序槽之后启动。
- 已签名的 OTA 镜像是一个完整的银行镜像,包含引导加载程序和应用程序。
- 在 HSE AB_SWAP 之后,新激活的银行是独立的,可以启动。

对于 HSE 全模块 A/B 更换来说,这似乎要干净得多,但我希望确认其预期/生产安全的方法。这样做并不理想,因为它在一定程度上违背了工厂引导加载程序的初衷。

问题:

1.对于 S32K312 HSE AB_SWAP,在交换后的 PFlash 存储体之外,单个全局 DFlash 驻留引导加载程序是否是一种受支持/推荐的架构?
2. 或者 HSE AB_SWAP 是否有效地要求/建议每个被交换的 PFlash 块都是可独立启动的,具有自己的 IVT/引导加载程序/RESET 路径?
3.如果可以使用 DFlash 引导加载程序,那么交换后的引导流程应该如何构建,才能仍然满足 SBAF/HSE 引导预期?
4. NXP 是否有任何参考示例展示了 DFlash 引导加载程序如何在 S32K3 上管理全块 HSE AB_SWAP?
5.对于具有回滚/确认语义的生产 OTA,重复的 PFlash 引导加载程序模型是否是更安全的预期设计?

我们已经看到,通过修改链接器脚本可以将代码和 IVT 链接到 DFlash 中(我们也尝试过),但我们的问题具体是,在使用 HSE 全块 A/B 交换和安全启动/SMR 验证时,这样做是否合适。

谢谢!

Re: S32K3 bootloader and HSE - best practice ?

@coratron

1.对于 S32K312 HSE AB_SWAP,在交换后的 PFlash 存储体之外,单个全局 DFlash 驻留引导加载程序是否是一种受支持/推荐的架构?

从硬件角度来看,没有任何限制。两种选择都是可行的。如果数据闪存的容量足够大,并且您不打算将其用于存储数据,则可以将引导加载程序放置在数据闪存中。如果您需要将数据闪存用于其他用途,那么在两个分区中分别保存两份引导加载程序副本是一种常见的做法。

2. 或者 HSE AB_SWAP 是否有效地要求/建议每个被交换的 PFlash 块都是可独立启动的,具有自己的 IVT/引导加载程序/RESET 路径?

不,没有这样的要求。只需在数据闪存(引导加载程序的 IVT)中具有有效的 IVT 即可。通常的做法是,RESET后总是启动引导加载程序,然后引导加载程序跳转到用户应用程序。

3. 如果可以使用 DFlash 引导加载程序,那么交换后的引导流程应该如何构建,才能仍然满足 SBAF/HSE 引导预期?

SBAF 或 HSE 没有提出任何具体要求。启动引导加载程序后,它可以决定是跳转到应用程序,还是下载新应用程序,或者执行回滚等操作,然后它应该重置设备(在回滚/交换的情况下)或跳转到应用程序。

4. NXP 是否有任何参考示例展示了 DFlash 引导加载程序如何在 S32K3 上管理全块 HSE AB_SWAP?

我们没有这样的例子。

5. 对于具有回滚/确认语义的生产 OTA,复制的 PFlash 引导加载程序模型是否是更安全的预期设计?

我不认为这两种方法在安全性方面有任何绝对优势。特定架构的适用性取决于整体系统设计、网络安全要求、OTA 工作流程和回滚策略。这两个概念都可以在稳健的生产解决方案中得到实现。

问候,
卢卡斯

Re: S32K3 bootloader and HSE - best practice ?

感谢你的及时回复@lukaszadrapa 。这澄清了问题,并提供了很大的帮助——我们已经能够重新评估 DFlash 中的引导加载程序实现,并且取得了成功。

该团队已经习惯了其他供应商的文档/可访问性,发现 NXP 虽然是汽车应用领域的领导者,但与它们相比,NXP 的文档却出奇地令人困惑。

您的及时反馈弥补了这些不足,再次感谢您的帮助——非常感激。我会将您的回复标记为解决方案,并向您的团队提供以下反馈:

- 如果能提供 Dflash 引导加载程序 + HSE 演示,就能节省时间(包括您的时间)。我相信这对于使用 AB_SWAP 的人来说是自然而然的设置。

- NXP 应该统一并整理文档和软件栈(长期来看) - 兼容性/版本分散,没有统一的信息来源,导致混乱。

问候

Tags (1)
No ratings
Version history
Last update:
‎07-13-2026 02:28 AM
Updated by: