[参考译文] AM6412：当同时与两个 PRU 通信时、PSSP 的 RPMsg 回波示例偶尔会发生干扰。

大家好、

嗯。 就我而言、我并没有看到任何明显的地方、在这些地方、一个 PRU 内核可能会意外丢失一条用于另一个 PRU 内核的消息...

假设您在使用 PRU_ICSSG0、PRU0和 PRU1。

一般来说、我会这样做  

我们将简单介绍一下代码的逻辑  

第1步：Linux 对于每个 PRU 内核预计会收到哪些中断？
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am64-main.dtsi?h=ti-linux-5.10.y-cicd#n1050

第2步：它是否与用于初始化 Msg_Echo_Interrupt 传输结构的 examples/am64x/pru_36248/main.c 中定义的 TO_ARM_HOST 匹配？
(看起来像这样)

步骤3：我们在物理内存的不同位置使用不同的资源表/ virtio 队列、对吗？
请参阅  examples/am64x/pru_384/am64x_prux_intc_rscTbl.cmd Msg_Echo_Interrupt
表位于 DMEM 的不同部分：
Core0：.resource_table：align (8)> PRU0_DMEM_0、page 1
Core1： .resource_table：align (8)> PRU1_DMEM_1、page 1

我们还可以看到、在 PRU_45200l Msg_Echo_Interrupt 文件夹中的 Makefile 中指定了单独的端口号(Makefile 中的 PORT_NUM、main.c 中的 CHAN_PORT)

第4步：固件看起来至少应该只有在收到消息时才会调用、对吗？
-等待 R31上的另一位
-仅为清除事件状态  

潜在测试-在固件的传输层中是否有东西变得混淆？ 也许在 PRU_rpmsg_receive 中？  

我预计 PRU_rpmsg_receive (&transfer...) 应仅调用为特定传输创建的特定接收 virio。

话虽如此、我们从消息本身中抓取源和目标、然后将消息回显到 RPMsg 中指定的源和目标。 因此、您可能会开始检查这些 src 和 dst 变量、以查看它们是否符合预期、或者它们是否混淆。

此致、

Nick

谢谢你、Nick。 感谢您的支持。

我也确认了我的发展中环境。

步骤1：设备树与链路相同。

步骤2：对于 PRU0、TO_ARM_HOST 为16、对于 PRU1为18。 在调用 PRU_rpmsg_init 时指定这些函数。

步骤3：在  AM64x_PRUx_INTC_rscTbl.cmd 文件中、 PRU0的 resource_table 部分为 PRU0_DMEM_0。   PRU1的 resource_table 部分为  PRU1_DMEM_1。  

在映射文件中、 PRU0_DMEM_0和 PRU1_DMEM_1 是相同的地址。 我认为它们实际上是不同的存储器、因为它是映射文件中的本地地址。

PRU0的 PROT_NUM 为30、 PRU1的 PROT_NUM 为31。 (ICSSG0)

第4步：PRU0使用 R31的位30。 PRU1使用 R31的位31。 (HOST_INT 和 INTC_MAP_x.h？)

我已使用 CCS 检查 PRU_rpmsg_receive 的 src 和 DST、如下所示。

src 始终1024 PRU0 和 PRU1。

PRU0的 dst 始终为30。

PRU1的 dst 始终为31。

 当发生干扰时、它们不会更改。

我不确定这是否符合预期。

PRU1的 src

PRU1的 dst

谢谢

您好！

嗯。 我们可以确定二者的源值是相同的、即1024？

我想知道这是否会导致 开箱即用演示中 Linux 端的混乱、或者 Linux 端代码是否会检查 src 条目以将 PRU 响应置于 rpmsg_pru30或 rpmsg_pru31中？

通常为每个 RPMsg 端点指定一个唯一的 ID。 在最终用例中、如果有两个不同的 Linux 应用程序、它们至少有2个不同的 RPMsg 端点。

我将为您提供 AM64x 上其他内核的一些 RPMSG 资源的链接。 这些信息可能不会直接适用于具有 PRU 内核的 RPMsg -目前我尚未进行过多的 PRU 测试  

在 MCU+代码中设置多个 RPMsg 端点(R5F、M4F)
AM64x Academy 多核模块： https://dev.ti.com/tirex/explore/node?a=7qm9DIS__LATEST&node=A__Ae7iN576eTKQcrPcBcMrog__AM64-ACADEMY__WI1KRXP__LATEST

在 Linux 端代码中设置 RPMsg 端点

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1369380/sk-am62a-lp-ipc-rp-message-related-queries-communication-between-a53-and-mcu-r5-core 

此致、

Nick

您好！

我再次使用 CCS 检查了 src、PRU0和 PRU1的值都明确为1024。

我看了看你提到的链接。 它们似乎是在单个 Remoteproc 内核中创建多个 RPMSG 通道的示例。

在下面链接的 rpmsg_client_sample 日志中、virtio0~virtio3 (不同的 RPMsg？) 使用相同的地址1024 (0x400)和0xd。

https://dev.ti.com/tirex/explore/content/am62ax_academy_9_01_00_00_v1/_build_am62ax_academy_9_01_00_00_v1/source/multicore/multicore-dev/ipc-rpmsg.html#running-the-rpmsg-kernel-space-example

我修改了 echo 示例的源代码(如下图所示)以缩小原因范围(添加了第106行、108~111)

如果 PRU0的有效载荷不是"test30"、则执行错误响应。 (同时将 PRU1源代码修改为 响应错误(如果它不是"test31")

并且在错误情况下有一个断点、命中了中断。
在 PRU0中、有效载荷应该是"test30"、但它是"test31"。
这意味着数据已在 ARM 到双向 PRU 方向的位置被覆盖

我看了 Linux RPMsg 器件驱动程序的源代码部分、该部分似乎会将数据发送到 PRU。
它是 drivers/rpmsg/rpmsg_pru.c 中的 rpmsg_pru_WRITE()函数  

我不熟悉 Linux 设备驱动程序、因此我让 ChatGPT 和 GitHub Copilot 对它们进行分析。
他们说静态变量(rpmsg_pru_buf)的问题(如下所示)似乎导致了当前问题的产生。

"static char rpmsg_PRU_buf[FIFO_MSG_SIZE]；会在函数内部声明、但由于 static 关键字、不会在每次调用函数时重新创建这个缓冲区。  而是在内存中分配一次、并且此代码仍然存在。
因此、该缓冲区在整个器件驱动程序中共享、并且可以由多个进程或线程同时访问。
如果多个进程同时对器件文件执行写操作、则 rpmsg_PRU_write 函数将同时执行。
在这种情况下、数据可能会同时写入共享的 rpmsg_pru_buf、导致数据争用和损坏。"

您能告诉我、这是导致此问题的原因吗？

谢谢

您好！

肠道检查一些细节

Linux 端点是1024即有道理- Linux 自动分配从1024开始的 RPMsg 端点号(除非您专门对端点号进行硬编码、如果应用程序需要远程内核来启动第一个 RPMsg 而不是 Linux、这一点很有用)。 在 rpmsg_client_sample 程序中、同一个应用与所有远程内核通信、这就是为什么所有4个 Virtio 缓冲区使用相同端点0x400的原因。

我还没有深入研究 PRU RPMSG echo 示例的后端代码、有趣的是、它似乎也使用单个 Linux 端点/程序与所有 PRU 内核进行通信。

RPMsg 驱动程序观察结果如何？  

很好的调试！

这很可能是 Linux 驱动程序代码中的错误。 我不是 Linux 开发人员、但如果多个不同线程同时使用完全相同的缓冲区、那么当一个线程覆盖另一个线程的数据时、我可以看到会发生竞争情况。

让我联系 Linux 开发人员进行讨论。 这可能需要几天时间,因为这是在印度的假期周。 如果我周一尚未回复、请 ping 该主题-我不想在我的收件箱中丢失您的主题。

此致、

Nick

您好！

感谢您的观点和回应。 我理解。 我等待您的讨论结果。

周末愉快！

您好、Shinichi：

我将在下周星期四与开发人员进行同步设置。 我将计划在下周的星期五之前向您提供最新消息-如果您在下周的星期五之前没有收到回复、可以随时通过 ping 通该主题。

此致、

Nick

您好、Nick。  

我从变量(rpmsg_pru_buf)中删除了"static"并重新运行测试。
因此、如下面所示、重复了很多次、但 从不发生干扰。
我相信这将会解决这个问题。

静态移除之前：
PRU0和 PRU1在总共828个 RPMsg  通信中有3次交换
(26秒内发生3次)

静态移除后：发生
pru0和 pru1在总共227279 RPMsg 通信中有0个交换
(122分钟内出现0次)

我知道您还有时间重写设备驱动程序。  我的开发用该补丁解决了。

感谢您的响应和错误报告。
此致。

您好、Shinichi：

再次感谢您报告此行为。 它看起来像是 PRU_rpmsg 驱动器是8年前编写的、从未上传到主线 Linux、因此实际上没有影响、因为：
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/log/drivers/rpmsg/rpmsg_pru.c?h=ti-linux-4.9.y <- 2017年, 杰森写了最初的驱动程序
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/log/drivers/rpmsg/rpmsg_pru.c?h=ti-linux-6.6.y <---forward-ported,但基本上在2024年没有变化
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/rpmsg?h=v6.12-rc6 <--尚未上溢

RPMSG 协议在过去的8年中已经成熟了很多、因此整个驱动程序是由于重写的。 我对此行为提出了一个错误。 一般而言、我们会尝试在代码"成熟"后将其上行、因此我还会与开发团队讨论是否需要在更新后将驱动程序上行。

话虽如此、我仍然愿意在您的产品中使用 PRU RPMSG (假设延迟 和数据吞吐量性能满足您的需求)。 一般来说、该驱动程序似乎仍能正常工作、因为我们已在 AM335x、AM437x、AM57x、AM62x、AM64x 上使用了至少8年 AM65x 和您是第一个报告此行为的人。

此致、

Nick