[参考译文] AM6422：IPC 延迟

您好、Wanglili、

第一个问题-对 RPMsg 性能进行基准测试  

您正在运行哪个版本的 Linux？

如果您关心控制延迟、 则应使用 RT Linux、而不是"常规"Linux。 即便如此、请记住 RT Linux 并不是完全确定性的-您可以说 RT Linux 在统计上可能满足实时要求、但您永远不能保证 Linux 能够满足这一需求。 有关 Linux 与 RT Linux 的更多讨论、请参阅
AM64x Academy > Multicore > Operating systems
https://dev.ti.com/tirex/explore/node?node=A__AZmYmYcoWo.KGrq4wf-oPQ__AM64-ACADEMY__WI1KRXP__LATEST 

Linux 内核6.6是 Linux 的版本、我们最终在 RPMsg 下重写了低级邮箱驱动程序、以便赋予其更高的优先级。 这意味着在 RT Linux 中、从 Linux 内核6.6开始、您可以通过提高 RPMsg 通信的优先级、开始更好地控制 RPMsg 延迟。

我编写了一个专门的基准测试示例、该示例最终将在接下来的几周内的某个时间发布在 ti-rpmsg-char 上。 如果您感兴趣、我可以提供当前版本的源代码。 现在、我将附加二进制文件、供您使用以下工具运行测试：

e2e.ti.com/.../rpmsg_5F00_char_5F00_benchmark

使用指南：

rpmsg-char-benchmark
====================

rpmsg-char-benchmark can be used to calculate average and worst-case round-trip
latencies for RPMsg messages between Linux and a non-Linux core.

Usage:
  rpmsg_char_benchmark [-r <rproc_id>] [-n <num_msgs>] [-m <msg_length>] [-d <rpmsg_dev_name>] [-p <remote_endpt>] [-l <local_endpt>]

  Where:
    -r <rproc_id>        remote processor id to be used.
                         Valid values are 0 to RPROC_ID_MAX
    -n <num_msgs>        Number of messages to exchange (default 100)
    -m <msg_length>      Number of characters to send per message (default 100)
    -d <rpmsg_dev_name>  rpmsg device name
                         (defaults to NULL, translates to rpmsg_chrdev)
    -p <remote_endpt>    remote end-point address of the rpmsg device
                         (default 14 based on current example firmwares)
    -l <local_endpt>     local end-point address of the rpmsg device
                         (default RPMSG_ADDR_ANY)
                         (If manually set, must be greater than
                         RPMSG_RESERVED_ADDRESSES = 1024)

Examples:
  rpmsg_char_benchmark -r 4 -n 1000000 -m 1
     Runs the example using default rpmsg device "rpmsg_chrdev",
     remote port 14 with rproc_id value of 4 (R5F_MAIN1_0), exchanges
     1,000,000 messages that are 1 character long

  stress-ng --cpu-method=all -c 4 & rpmsg_char_benchmark -r 4 -n 1000000 -m 496 & chrt -f -p 80 $!
     Use with RT Linux
     Runs the example using default rpmsg device "rpmsg_chrdev",
     remote port 14 with rproc_id value of 4 (R5F_MAIN1_0), exchanges
     1,000,000 messages that are 496 characters long.
     Add a background load on Linux with stress-ng.
     Set the rpmsg_char_benchmark application priority to 80.

您可以在此处看到我使用早期版本的代码在 Linux 内核6.6上生成的测试结果：
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1410313/am6442-communication-latency-issues-between-a53-and-r5-in-a-linux-rt-system/5434861#5434861

第二个问题-我们是否可以将零复制共享存储器与"常规"RPMsg "一起使用？  

是这样。

根据您的问题、我假设您已经找到了 zerocopy 项目：
https://git.ti.com/cgit/rpmsg/rpmsg_char_zerocopy/

此工程使用 RPMsg 发送指向共享存储器区域的指针。 然后、每个处理器直接读取/写入共享存储器区域、而不需要通过一组完整的 RPMsg 消息发送该数据。

您可以设置多个 RPMsg 端点、并对不同的任务使用不同的端点(例如、端点14用于共享内存、端点15用于其他通信)。 您可以在此处找到一个将多个 RPMsg 端点添加到 AM64x Academy 中的 MCU+工程的示例：
多核> IPC >如何将多个 RPMsg 端点添加到 MCU+工程
https://dev.ti.com/tirex/explore/node?node=A__Ae7iN576eTKQcrPcBcMrog__AM64-ACADEMY__WI1KRXP__LATEST

您也可以只有一个端点、让您的代码处理 RPMsg 消息的内容、以便查看该消息是用于共享存储器信号还是用于某些其他类型的传输数据。

此致、

Nick

我使用的是 SDK 8.6、Linux 版本为5.10。 该版本无法满足您提到的设置优先级和低延迟、对吧？ 如果我不打算更改 Linux 版本、可以采取什么措施来减少延迟？

您好、Wanglili、

在 Linux 中控制延迟的最佳方法是使用 RT Linux、并提高您关心的代码的优先级。

在早期版本的 Linux 中、邮箱中断与其他所有内容在优先级方面被分组在一起。 因此、无法提高邮箱代码执行的优先级。

您可以尝试将邮箱代码更改反向移植到 Linux 内核5.10。 如果你想尝试,我可以指向内核提交,但我们不能支持您在反向移植过程,我不能保证代码将在内核5.10上同样工作,一旦它实际上是反向移植。

另请注意、如果您在 Linux 内核5.10上使用 zerocopy 工程、请使用 ti-linux-6.1分支而不是主分支：
https://git.ti.com/cgit/rpmsg/rpmsg_char_zerocopy/

此致、

Nick

您好、

  我计划将您提到的中断优先级处理移植到5.10、希望您能提供技术支持。 谢谢您！

您好：

我在核心间沟通过程中遇到了一些问题、希望您能提供以下技术援助：

1. 非实时内核(A53内核)发送数据问题 ：
   • 当非实时内核发送数据时、如果实时内核(RT 内核)未及时接收数据、则之后会发生错误  25或26成功发送 ：
     错误日志：
     [509.586118] rpmsg device ti.ipc4.ping-pong platform 78000000.r5f: failed to send mailbox message, status = -105
     来自日志的建议：
     omap-mailbox 29020000.mailbox: Try increasing MBOX_TX_QUEUE_LEN
   • 观察 ：
     • 该函数 send_msg 用于消息传输。
     • 预期行为 ：
       当邮箱队列已满时、该函数应返回错误(以防止数据丢失)。
     • 实际行为 ：
       没有返回错误、并且消息被静默丢弃(或者发件人不知道失败)。
2. 实时内核(R5F 内核)接收死锁问题 ：
   • 当 RT Core 未能及时读取消息时、以及  累积的消息超过16条  在接收队列中：
     • 程序会卡在内的无限循环中  RPMessage_notifyCallback 测量输出。
     • 系统级别影响 ：
       • RT Core 上的其他任务已耗尽、无法执行。
     • 已尝试解决方案 ：
       • 最低电流限制  寄存器0x29020010的位0改为1  (可能是硬件流控制或中断使能位) DID  未解决问题 。

您好、Wanglili、

邮箱数量？  

处理器上的邮箱硬件有一个硬件 FIFO、最多只能保存4条邮箱消息。 但是、Linux 邮箱驱动程序具有一个软件 FIFO、可存储邮箱消息、直到它们准备好发送。 此 Linux 驱动程序任意大小为20个邮箱。 如果你愿意,你可以把它增加到256个邮箱或更大,然后你会被限制在 virtio 缓冲区中的256个消息。 有关更多信息、请参阅
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1179393/am6442-problem-detecting-rpmsg-mailbox-full-when-communicating-to-r5-core/4618458#4618458

MCU+内核在接收队列已满后锁定？  

这是一个已知错误。 您可以在此主题中找到用于修复该错误的补丁(以及关于该错误的更多讨论)：
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1365362/processor-sdk-am62x-multicore-development-ipc-process-multiple-endpoints-reserved-memory-purpose/5532041#5532041

此致、
Nick

感谢您的答复。 我们目前使用的是 SDK 8.6。 是否可以 RPMessage将 R5F RTOS 相关问题(例如中的无限循环问题)的错误修复反向移植到 SDK 8.6？ 如果是、需要进行哪些修改？

对于当值超过20时在 Linux 中出现的警报消息"OMAP-MAILBOX 29020000.MAILBOX：尝试增加 MBOX_TX_QUEUE_LEN"、可以简单地将 MBOX_TX_QUEUE_LEN  /include/linux/mailbox_controller.h Linux 源目录中文件中的宏定义从20修改为256来解决该问题？

您好、Wanglili、

Linux 软件邮箱队列

是的、 MBOX_TX_QUEUE_LEN 是您要更新的变量。

MCU+ SDK TX 缓冲器锁定

我不能确定反向移植错误修复程序所涉及的内容。 我在链接的线程中提到了实际提交、但我不确定 SDK 8.6和 SDK 10.1之间是否需要应用这些提交的其他更改。 很遗憾、我不支持将代码反向移植到以前的软件版本。

此致、

Nick

您好、Wanglili、

我将您的最新问题拆分为一个单独的 e2e 主题：
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1510849/re-am6422-ipc-enabling-disabling-interrupts

此致、

Nick