[参考译文] DRA829V：如何从 Cortex-R5 中销毁/删除 RPMsg 通道

尊敬的 Anderson：

发生这种情况是因为 R5 应用程序在启动时创建并提示通道。

您正在从 R5F 端创建和发布多少个信道？ 是否重新启动相同的固件或不同的固件？

是否有办法在硬复位 R5 内核之前指示主机 MPU 删除/销毁通道？ 或任何避免错误循环的权变措施？

不可以、 Linux 无法自行清理、因为设备最初是通过远程固件端的通知创建的。  

应用程序必须先通知远程固件执行清理、然后才能从 Linux 端停止处理器。 有许多资源可能是由固件端获取的、Linux 对此一无所知。  

发生这种情况时、Linux 终端将无法使用。

不应该发生这种情况、它应该只是 Linux 内核端的错误跟踪。

此致

Suman

您好、感谢您的迅速回答。

您正在从 R5F 端创建和发布多少个信道？ 是否重新启动相同的固件或不同的固件？

仅一个通道 (rpmsg_crdev、ID 14)。 这是同一固件、是 R5F 内核上的硬复位。 可以通过本地命令或在置位时复位我们的应用程序。

不可以、 Linux 无法自行清理、因为设备最初是通过远程固件端的通知创建的。  

应用程序必须先通知远程固件执行清理、然后才能从 Linux 端停止处理器。 有许多资源可能是由固件端获取的、Linux 对此一无所知。  

对于此情景、您会有什么建议？

不应该发生这种情况、它应该只是 Linux 内核端的错误跟踪。

我们的定制板和 J721E 开发板上也会出现相同的行为。 迹线的打印速度非常快 、以至于无法再在串行终端上键入。 对于如何修复此情景有什么想法？


此致、

Anderson

尊敬的 Anderson：

只有一个通道 (rpmsg_crdev、ID 14)。

嗯、除非您的固件代码在循环中重复发布同一通道、否则这应该显示为单个故障轨迹、而不是重复的故障轨迹。

这是同一个固件、是 R5F 内核上的硬复位。 我们的应用程序可以通过本地命令或在断言时重置。

您将如何执行此操作？ 您是否正在使用 remoteproc sysfs “stop“命令或其他方法？

对于这种情况、您会有什么建议？

Remoteproc 驱动程序最近得到了增强、以执行“正常“关机、在此情况下、Remoteproc 驱动程序向固件发送一条消息、允许其自行清理。

请参阅 正常关断 和 AM62Px MCU+ SDK：从 Linux 部分正常关断远程内核中介绍的功能（在不同的 SoC 文档上，不过概念是相同的）。

我们的定制板和 J721E 开发板上也会出现相同的行为。 迹线的打印速度非常快 、以至于无法再在串行终端上键入。 是否有任何关于如何解决此场景的想法？

您使用什么固件进行测试？  您使用的是哪个 SDK？

请注意、正常关机需要在固件端执行适当的处理操作。  

此致

Suman

你好。

嗯、这应该显示为单个故障跟踪、而不是重复故障、除非您的固件代码在循环中重复发布相同通道。

这很奇怪、因为固件仅运行通知一次、不涉及循环。

您将如何执行此操作？ 您是否正在使用 remoteproc sysfs “stop“命令或其他方法？

我正在使用此 API 请求远程重置: Sciclient_pmSetModuleRst_flags()。

Remoteproc 驱动程序最近得到了增强、以执行“正常“关机、在此情况下、Remoteproc 驱动程序向固件发送一条消息、允许其自行清理。

请参阅 正常关断 和 AM62Px MCU+ SDK：从 Linux 部分正常关断远程内核中介绍的功能（在不同的 SoC 文档上，不过概念是相同的）。

正常关机已实现。 如果我在远程处理器上回显“stop“、则固件已正确关闭。 仅当使用上述 API 请求复位时、才会出现问题。

关于您的 问题、我正在运行我们自己的应用、它不是直接基于 SDK 示例（例如 RPMsg 除外）。 我使用的 PDK 版本为 11.01.00.17。

尊敬的 Anderson：

这很奇怪、因为固件仅运行通知一次、不涉及循环。

嗯,我想知道 virtio-vring 状态机是否处于不正确的状态,这最终试图反复处理相同的消息。

我正在使用此 API 请求远程重置： Sciclient_pmSetModuleRst_flags()。

您从哪个或哪个内核请求此复位？ 如何重新启动核心？

正常关机已实现。 如果我在远程处理器上回显“stop“、则固件已正确关闭。

那么、在这种模式下您不会遇到任何问题、对吧？

只有在使用上述 API 请求重置时才会出现问题。

好的、我想先了解您的远程复位序列、然后再对此进行进一步评论。

关于您的 问题、我正在运行我们自己的应用程序、它不是直接基于 SDK 示例（例如 RPMsg 除外）。 我使用的 PDK 版本为 11.01.00.17。

感谢您的确认。

此致

Suman

您好、

我可以通过调试来注意到,正是 RPMessage_announces() 才 会触发该问题。

关于复位、我的应用程序在 MCU2_0 上运行、我们通过 Sciclient 请求远程复位。 准确的片段：

/* Request remote reset to MCU1_0 */
Sciclient_pmSetModuleRst_flags(TISCI_DEV_R5FSS0_CORE0, 1, 0, SCICLIENT_SERVICE_WAIT_FOREVER);
Sciclient_pmSetModuleRst_flags(TISCI_DEV_R5FSS0_CORE0, 0, 0, SCICLIENT_SERVICE_WAIT_FOREVER);

此致、

Anderson

尊敬的 Anderson：

我可以通过调试来注意到、正是 RPMessage_announce_() 触发了这个问题。

rpmessage_announce() 是固件端的 API、它向 Linux 通告 rpmsg 端点、因此触发条件是可以预期的。

关于重置、我的应用程序在 MCU2_0 上运行、我们通过 Sciclient 请求远程重置。

我假设您将在 MCU2_0 上再次重新引导它。

Linux Remoteproc 和 rpmsg 驱动程序无法处理执行已引导内核重置的不同内核。 Linux Remoteproc 驱动程序只能在其控制的处理器（之前未引导或由另一个处理器引导）上执行启动和停止。

如果处理器的引导时间早于 Linux、则驱动程序会将自身配置为“仅 IPC“模式、Linux 甚至不允许您停止此类过程。

我认为这一问题的主要原因是 vring 控制结构不匹配。 Linux 负责设置和初始化 vring 结构并启动缓冲区。 远程固件在开始通信之前依赖于这个逻辑。 MCU2_0 复位会异步复位一个内核、而无需复位 virtio-vring 状态机。 因此、您正在从不匹配的 Linux 状态机引导内核。

TI 将无法支持这种混合引导场景。 如果您要重新启动并重新加载由 Linux 启动的远程处理器、建议使用 Linux 的“stop“方式。

此致

Suman

您好、

我假设您将在 MCU2_0 上再次重新引导它。

是、MCU2_0 重新启动。

我理解 过程、但在某些情况下、我们的应用需要 异步复位。 例如、当我们必须在代码中断言时。  将来的看门狗复位怎么样、不会导致相同的问题？

我在这里看到了两件事、我需要 TI 提供一些支持：

• 在重置之前、我们的应用程序可能会尝试正常地重置/撤消/停止当前虚拟化。 显然、除了正常关机之外、没有其他 API。 是这样吗？
• 当 R5 应用程序尝试再次创建相同的通道时、Linux 内核不应以这种方式中断。 我认为这是一个问题、那么如何避免这种情况呢？  

一个解决方案可能是在重置之间保留一个持久的内存、告诉我们的应用程序 vring 已启动、因此我们不会尝试重新创建。 这是否可以通过 R5 来完成？

好的、感谢您的反馈。 我将看到如何解决该问题并使用 remoteproc 从 Linux 重置内核。