[参考译文] AM263P4：与通过 AM263P4 上的 Hsmclient_loadHSMRtFirmware 加载 HSM 固件相关的问题。

感谢您的回复、我还有几个问题：

问题 1：
基于您的首次回复和之前回复（__LW_AT__AM263P4：与 AM263P4 的 IPC 和 SIPC 相关的问题 — 基于 Arm 的微控制器论坛 — 基于 Arm 的微控制器 — TI E2E 支持论坛）

IPC 中断流程为：
-发送内核写入 write_done→触发中断→接收内核读取 READ_REQ。

SIPC 中断流程为：
-发送内核写入 READ_DONE_ACK→触发中断→接收内核读取 READ_DONE。

为什么在我所述流程的第 3 步中写入 write_done 会触发 SIPC 中断？ 同样、为什么在步骤 6 中需要清除 READ_REQ 和 READ_DONE 寄存器才能清除中断？ 我的理解是、对于 SIPC 中断、主内核只需要写入 READ_DONE_ACK 即可触发 SIPC 中断、主内核从 HSM 内核接收到 SIPC 中断后、应将 READ_DONE 设置为 1 以清除中断。

问题 2：
根据您的第二个响应、 HSM RBL 仅在*主内核已通过 SIPC 将 HSMRT 固件发送到 HSM RBL 之后才开始签名验证和解密是否正确？

问题 3：
根据您的第三个回答：
-分析 HSMRT 代码,`HsmServer_sendBootNotify(SystemP_WAIT_FOREVER)`–虽然参数是` ystemP_WAIT_FOREVER `S,但该函数实际上并不是阻塞的;它只是发送一条 SIPC 消息。 如果发送失败、HSMRT 会关闭所有驱动器、然后进入 WFI (`ASM_wfi`)。 这是什么状态？

-分析主内核代码,在`mcu_plus_sdk_am263px_11_00_00_19`中,`Hsmclient_loadHSMRtFirmware` function 默认配置为`HsmClient_waitForBootNotify(NotifyClient, SystemP_WAIT_FOREVER)`。 这意味着、如果 HSMRT 成功进行了签名验证和解密（即 HSMRT 未被篡改）但无法运行、HSM 内核将进入 WFI 状态、主内核将永远阻止。 该设计是否合理？ 设计意图是确保在主内核判定 HSM 固件已加载后、它可以 100%接收 HSM 通过`HsmClient_waitForBootNotify`发送的 BootNotify、从而避免 HSM 已加载并执行`HsmServer_sendBootNotify`在主内核达到`HsmClient_waitForBootNotify`之前发生的情况、导致 BootNotify 丢失？

问题 4：
AM263P4 HSM RBL 是否具有 25ms 的默认内部 WDT 超时？ 是否仅在 HSM RBL 无法正确加载的情况下才会发生此超时？ 加载用户的 HSMRT 后、该超时是否无效？

2. 以下说明是否意味着 180s 是指 R5 RBL 复位超时、即如果 RBL 无法正确加载 SBL、它将在超时后复位？

3. 如何配置 HSMRT 的内部看门狗? 因为 syscfg 中没有 WDT 配置。

你（们）好

为什么在我描述的流程的第 3 步中写入 write_done 会触发 SIPC 中断？ 同样、为什么在步骤 6 中需要清除 READ_REQ 和 READ_DONE 寄存器才能清除中断？ 我的理解是、对于 SIPC 中断、主内核只需写入 READ_DONE_ACK 即可触发 SIPC 中断、主内核从 HSM 内核接收到 SIPC 中断后、应将 READ_DONE 设置为 1 以清除中断。

Hsmclient_mboxRxISR 不是 SIPC ISR。 这是 R5 和 HSM ROM 之间的 IPC。 这使用 write_done 和 READ_REQ。

SIPC 位于 R5 和 HSM (HSMRT) 之间、这会使用 READ_DONE_ACK 和 READ_DONE。

根据您的第二个回答、 HSM RBL 仅在*主内核通过 SIPC 将 HSMRT 固件发送到 HSM RBL 之后才启动签名验证和解密是否正确？

主内核不通过 IPC 发送固件。  
L2OCRAM 上 HSMRT 的地址被发送到 HSM ROM、其中 HSM ROM 可以访问此 L2OCRAM 地址、从中选择用于签名验证和解密的内容。

如果发送失败、HSMRT 会关闭所有驱动程序、然后进入 WFI (`asm_wfi`)。 这是什么状态？

这可能意味着 SIPC 注册可能不正确、或者 HSM 将命令传回 R5 时出现问题、从而导致 HSM 处于此状态、即取消初始化仅在 HSM 内核上注册的驱动程序。

此设计是否合理？ 设计意图是为了确保在主内核判断 HSM 固件已加载后、它可以 100%接收 HSM 通过`HsmClient_waitForBootNotify`发送的 BootNotify、从而避免 HSM 已加载并执行`HsmServer_sendBootNotify`在主内核达到`HsmClient_waitForBootNotify`之前发生、导致 BootNotify/Quote 丢失的情况？

是的、我看不到 HSM 完成 BootNotify 且 R5 缺少相同内容的情况、因为这里使用了 SemaphoreP_pend、这可以在 HsmClient_register () 期间注册的 R5 端捕获此更新。

AM263P4 HSM RBL 是否具有 25ms 的默认内部 WDT 超时？ 是否仅在 HSM RBL 无法正确加载的情况下才会发生此超时？ 加载用户的 HSMRT 后、该超时是否无效

抱歉、此时间应为 180 秒 HSM ROM 支持看门狗、超时为 180 秒。 我将在下一版本的 HSM 附录中对此进行更正。 TRM 当前会调用正确的超时值

以下说明是否意味着 180s 指的是 R5 RBL 复位超时、即如果 RBL 无法正确加载 SBL、RBL 将在超时后复位？

这是 HSM ROM 中的 HSM WDT 超时。 如果 SBL 加载失败或 HSMRT 加载失败、则将进行看门狗复位（即每 180 秒系统热复位一次）

如何配置 HSMRT 的内部看门狗？ 因为 syscfg 中没有 WDT 配置。

HSMRT 目前没有将看门狗集成到 TIFS SDK 中。 HSM ROM 目前正在使用该看门狗。 如果您对 HSMRT 中的 HSM 看门狗有要求、则可以通过将 MCU_PLUS_SDK 看门狗驱动程序移植到 HSM 来将其作为新模块从末端添加到 HSMRT 中。

谢谢。此致、

Nikhil Dasan

[/quote]

感谢您的答复。

问题 1：
因此、据我所知、HSM RBL 中的 180 秒 WDT 仅在 R5 RBL 无法加载 SBL（即 SBL 不运行）或 HSM RBL 无法加载 HSMRT（即 HSMRT 不运行）时生效。 只要 SBL 和 HSMRT 成功运行、并且系统没有卡在 R5 SBL 或 HSM RBL 中、HSM RBL WDT 就不会处于活动状态。 是这样吗？

问题 2：
如果 SBL 无法加载 HSMRT（例如,由于它没有接收到而卡住） HsmServer_sendBootNotify,我们可以使用 SBL 中的内部看门狗触发超时复位。 现在、如果 HSMRT 遇到异常并在运行时卡住、则默认 TIFS SDK 不支持 WDT。 用户需要本身移植 WDT 功能、是否正确？但是、我认为 TI 应该默认集成了此功能、因为如果没有此功能、就无法从 HSM 运行但卡住的情况中恢复。 还是有另一种机制来避免这种情况？