[参考译文] AM62P：无法从 AM62px - SDK 11.02.08.02 上的 R5 CPU 复位主 (A53) CPU

您好、

您是否使用了 MCU R5 的任何主域外设？

是否在从 DDR 运行 MCU R5 应用程序？

此致、

会面。

您好：
感谢您的查询。 有关专家因** TI 印度**假期而离职。
请预计响应会延迟。 感谢您的耐心和理解。

此致、
TI E2E 支持团队
——
*这是一个自动通知。*

您好、
我是代表我正在处理某个项目的同事与您联系的。

在‑‑上、我们使用 CAN 外设与外部节点进行实时的 μ s 时间通信、并使用 RPMessage 作为 TI IPC 框架的一部分、用于 μ s 间的处理器消息传递。
我们使用 R5 上的 RPMessage 将处理后的 CAN 数据发送到 WKUP CPU。

在 WKUP R5 CPU 上、一个专用任务为 A53 Linux 系统实施监督/监测机制。  

此任务监测 A53 心跳、WKUP R5 和 A53 之间的通信基于 RFPMessage。  
在 Linux 端、A53 通过标准 rpmsg‑char 接口进行交互、而 R5 使用 TI IPC 库。

所有映像都放置在 eMMC 存储器中。

你好  ,见塔卡,

让我提供有关我们设置的更多背景信息。 我们在 WKUP R5 内核上运行一个主应用程序、负责监督两个从应用程序：一个在 MCU R5 内核上、另一个在 A53 内核上。

我们的要求是检测 A53 应用程序何时崩溃、并在 5 秒延迟后仅复位 A53 内核、同时保持系统的其余部分运行。

但是、根据 TRM、复位控制似乎仅在复位域级别（MCU 域和 MAIN 域）进行组织、而不是按每个内核进行组织。 由此、我了解隔离或复位将影响整个 MAIN 域、包括 A53 内核以及其他组件。

这是否意味着只能复位两个复位域 (MCU 或 MAIN) 中的一个、而不能独立复位 A53 内核、这是我们需要的内容？

如果是这种情况：

• 这是复位架构的硬件限制吗？
• 或者、是否可以通过软件配置复位粒度、以仅针对 A53 内核？
• 如果可以重新配置软件、应使用什么机制？

此致、
Mihailo

这是否意味着只能复位两个复位域 (MCU 或 MAIN) 中的一个、而不能独立复位 A53 内核、这是我们需要的内容？

如果您使用复位隔离并从 MCU 域触发 MAIN 域的复位、那么它将复位整个 MAIN 域（包括 A53 和 DM R5）、而不仅仅复位 A53 内核。如果您只希望复位单个 A53 内核、只需使用 Sciclient_pmSetModuleState 为单个 A53 内核供电并再次为其供电。

你好, 见塔卡  

感谢您的澄清—我们完全采用了您建议的方法 Sciclient_pmSetModuleState 对单个 A53 内核进行下电上电。

下面是我们使用的函数：

static int32_t resetA53Only(void)
{
    int32_t status;
    struct tisci_msg_proc_get_status_resp procStatus;
    struct tisci_msg_proc_set_config_req  procCfg;

    status = Sciclient_procBootRequestProcessor(SCICLIENT_PROC_ID_A53SS0_CORE_0,
                                                SystemP_WAIT_FOREVER);

    status = Sciclient_procBootGetProcessorState(SCICLIENT_PROC_ID_A53SS0_CORE_0,
                                                 &procStatus, SystemP_WAIT_FOREVER);

    procCfg.processor_id  = SCICLIENT_PROC_ID_A53SS0_CORE_0;
    procCfg.bootvector_lo = procStatus.bootvector_lo;
    procCfg.bootvector_hi = procStatus.bootvector_hi;

    Sciclient_procBootSetProcessorCfg(&procCfg, SystemP_WAIT_FOREVER);

    /* Power OFF */
    Sciclient_pmSetModuleState(TISCI_DEV_A53SS0_CORE_0,
                              TISCI_MSG_VALUE_DEVICE_SW_STATE_AUTO_OFF,
                              TISCI_MSG_FLAG_AOP,
                              SystemP_WAIT_FOREVER);

    /* Power ON */
    Sciclient_pmSetModuleState(TISCI_DEV_A53SS0_CORE_0,
                              TISCI_MSG_VALUE_DEVICE_SW_STATE_ON,
                              TISCI_MSG_FLAG_AOP,
                              SystemP_WAIT_FOREVER);

    Sciclient_procBootReleaseProcessor(SCICLIENT_PROC_ID_A53SS0_CORE_0,
                                       TISCI_MSG_FLAG_AOP,
                                       SystemP_WAIT_FOREVER);

    return status;
}

通过这种方法、我们能够仅复位 A53SS0_CORE_0 上运行的 Linux、而不会影响主域的其余部分、从而确认您的点。

但是、我们使用了 Falcon eMMC 引导、这一点很重要、需要强调一下。 复位后、引导流程重新启动、我们可以看到 再次执行 TF-A (BL31) 和 OP-TEE、但加载 Linux 内核时系统挂起。

在正常启动中、我们会看到：

NOTICE:  BL31: v2.13.0(release)
NOTICE:  BL31: Built : 07:01:36, Jul  1 2025
...
[    0.000000] Booting Linux on physical CPU...

但在 A53 复位通过后 Sciclient_pmSetModuleState、输出停止在：

NOTICE:  BL31: v2.13.0(release)
NOTICE:  BL31: Built : 07:01:36, Jul  1 2025

并且在 Linux 引导方面没有进一步的进展。

因此、虽然每内核复位机制本身正常工作、但在 Falcon 引导场景中、系统在复位后似乎无法正确地继续执行除 ATF/OP-TEE 之外的引导链。

在将 A53 内核下电上电与 Falcon eMMC 引导结合使用时、您是否有任何建议或已知限制？

您好再次 会见塔卡 ,
最新动态：

我们能够确认当从配置中完全删除 IPC (RPMessage)（未初始化 RPMessage 对象、未调用 RPMessage API）时、RESET 隔离是否正常工作。
此外、我们必须 从 example.syscfg 中注释掉 IPC（如果不执行此步骤，行为是相同的）。  

在这种情况下、MCU 域按预期保持不受影响。

然而、在我们的用例中 、IPC 通信是一项强制性要求、没有 IPC 通信、我们就无法运行系统。 因此、遗憾的是、移除 IPC 对我们来说并不可行。

您能否建议是否有办法在仍保持 IPC (RPMessage) 启用的同时实现适当的复位隔离？

此致、
Mihailo

您好：
感谢您的查询。 有关专家因** TI 印度**假期而离职。
请预计响应会延迟。 感谢您的耐心和理解。

此致、
TI E2E 支持团队
——
*这是一个自动通知。*

尊敬的 Mihalio：

为此、 pscMCU2MainDisable 必须设置为 0。 如果需要任何额外的帮助、您可以参阅 reset_isolation_ipc 示例、该示例适用于 am64x： https://github.com/TexasInstruments/mcupsdk-core/blob/next/examples/drivers/safety/reset_isolation_ipc/reset_isolation_ipc_mcu_domain.c 

此致、

会面。

你好  ,见塔卡,

我们决定继续使用 Sciclient 方法、而不是重置隔离。

我们已经分享了我们当前使用的代码以及在调用 Sciclient API 时观察到的日志。

您能否帮助我们推进这一实施、并帮助我们确定任何潜在问题或需要纠正的问题？

此致、
Mihailo

您好、 认识 Thakar、因为我们目前在 Sciclient 集成方面被阻止。 我们之前分享了代码和日志、有关可能出现问题的任何指导都会非常有帮助。 提前感谢。

尊敬的 Mihailo：

我会在我的 EVM 上尝试一次、您只在 A53 上执行 falcon 引导时看到这个问题吗？ 或者、即使在内核上执行正常的 Linux 引导、也会出现相同的问题？

此致、

会面。

你好  ,见塔卡,

我们尚未尝试正常的 Linux 启动、因为我们的目标用例是 Falcon 引导、因此我们只关注该路径。

您是在 EVM 上重现该问题、还是在方面取得了一些进展？

此致、

Mihailo

你好  ,见塔卡,

只是跟进我之前的消息。

您是否曾在 EVM 上查看过该器件、或者希望取得任何进展？ 任何更新对我们协调后续步骤都很有帮助。

期待您的反馈。

此致、
Mihailo

‑正在开发一个具有特定与安全 T Ü V S Ü D 相关用例的工程。
我们的目标是隔离复位功能、使 R5 安全应用程序只能在需要时复位 A53 域。

用例：
R5 运行安全（监控）应用。
它负责监督在 A53 上运行的 Linux 系统。
如果 Linux 无响应或崩溃、R5 应仅针对 A53 域触发复位、而不会复位自身或 MCU 域。

我们基于重置隔离 MCU 示例测试了重置 A53 的方法、但没有成功 ( https://software-dl.ti.com/mcu-plus-sdk/esd/AM62PX/11_02_00_23/exports/docs/api_guide_am62px/EXAMPLES_DRIVERS_RESET_ISOLATION.html )。
 我们使用 SOC_generateSwWarmResetMainDomainFromMcuDomain() API 来调用复位。

当 MCU 任务调用复位时、
  R5F 和 A53 都会复位、而不仅仅是 A53。
  2. MCU 卡住
这就打破了我们的隔离要求。

我们是否可以使用 SOC_generateSwarmResetMainDomainFromMcuDomain() API 从 MCU/WKU CPU 中只重置 A53？

您好 Branko、

为什么选择性 A53 内核重置不起作用？

处理 A53 崩溃的常见首次尝试是仅重置 A53 处理器内核、同时保持其他所有内容运行。

然而、这种方法有一些根本问题、使其不可靠。

仅重置 A53 内核时、会发生以下问题：

A53 内核本身会复位、但周围的基础设施不会复位。

DMA 控制器仍包含崩溃前的旧通道配置和描述符。

UART、SPI、I2C 和其他外设控制器保持其先前的状态。

互连结构仍有来自崩溃应用程序的待处理事务。 A53 L2 高速缓存仍保存着可能一致、也可能不一致的旧数据。

当您在选择性复位后尝试重新初始化外设时、您会遇到不可预测的行为。 如果您尝试分配新的 DMA 通道、硬件仍可能引用旧的描述符或配置。 器件驱动程序可能无法初始化、因为它们需要干净的复位状态、但会发现过时的寄存器值。 系统变得不一致、某些 IP 处于初始化状态、而其他 IP 处于未知状态。

基本问题是外设复位必须完成。 仅靠处理器内核复位是不够的、因为处理器通过共享的互连和控制寄存器与周围硬件进行交互。

AM62P 复位架构设计：

AM62P SoC 具有特定的架构设计原则：在启用复位隔离的情况下执行主域复位时、SoC 仅支持 MCU 域复位。

主域包含 A53 处理器、DM R5F（设备管理 R5F）和所有关联的外设、如 DMA、UART、以太网、USB 和互连结构。 所有这些元件都以电气方式连接在一起。 它们共享电源域、时钟域、MMR 寄存器和复位树。

MCU 域由其自身的电源和复位树进行隔离。 它包含 MCU R5F 内核（安全内核）和 MCU 本地外设、如 MCU GPIO、MCU UART 和 MCU 计时器。

SoC 架构确保当主域复位时、它作为一个单元完全复位。 主域中的所有 IP 同时返回复位状态。

这可防止出现困扰选择性核心重置的不一致状态。

同时、复位隔离功能可确保 MCU 域在主域复位期间保持不变。 在 MCU R5F 上运行的安全关键型应用可以不间断地继续运行。

推荐解决方案：具有 MCU 隔离的主域复位：

主域包括 A53 处理器、器件管理 R5F、DMA 控制器和所有主要外设。 可以将主域重置为一个完整单元。 复位后、此域中的所有 IP 都会恢复其复位状态并清除配置。

MCU 域包括 MCU R5F 安全内核和 MCU 本地外设。 MCU 域受到复位隔离的保护。 当 MAIN 域复位时、MCU 域完全不受影响并继续正常运行。

正常运行期间：

A53 处理器执行应用程序代码。 所有主域 IP 都处于活动状态并针对 A53 应用程序进行了配置。 MCU R5F 内核运行一个运行状况监测器、定期检查 A53 处理器的状态。

MCU R5F 接收来自 A53 的周期性心跳信号。 如果 A53 应用程序正常运行、则心跳信号会定期出现。 如果 A53 应用程序崩溃或挂起、心跳信号会停止。

发生 A53 崩溃时：

MCU R5F 上的运行状况监视器检测到 A53 检测信号已停止。 MCU R5F 通过复位整个 MAIN 域来启动恢复序列。

主域复位后、SoC 将启动新的引导序列 (RBL→SBL/SPL→Application)。

然后、主域启动并再次运行。 所有主域 IP 都恢复到其复位值、主应用程序全新初始化并启动主内核。 这是正确的方法。

此致、

Anil.