• 状态 Resolved
  • 已锁定 已锁定
  • 个回复 4 个回复
  • 名订阅用户 0 名订阅用户
  • 次查看 73 次查看
  • 用户 0 名在线用户
选项
选项

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] AM6442：A53 CPU Linux 如何在 R5F CPU 和 R5F CPU 之间向 R5F CPU 发送 IPC 通知等信号？

admin
Guru**** 2035740 points
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1312504/am6442-how-does-a53-cpu-linux-send-a-signal-to-r5f-cpu-like-ipc-notify-between-r5f-cpu-and-r5f-cpu

器件型号：AM6442

您好：

在测试 Linux 系统和 R 内核之间的数据交互后、需要很长的时间才能使用 TI 提供的 RPMSG API 完成一个完整的读写周期。  数据交互耗时太长、因此 TI 官员提供的 API 无法满足我们的需求。

运行 Linux 的 A53内核和裸机 R5F CPU 能否相互发送中断？ 触发对等方将数据直接读写到商定的共享存储器区域的物理地址？ 具体包括以下内容：

1)。 A53 CPU Linux 如何 向 R5F CPU 发送信号 、例如 IPC 在 R5F CPU 和 R5F CPU 之间发出通知 ？ 能否    单独调用 A53 CPU 中 Linux OS 的 Mail Box 驱动程序和 R5F CPU 的 IPC Notify、并相互发送中断信号？

 如何实现？ 是否有任何相关的例子？

2)运行在 A53 CPU 和裸机 R5F CPU 上的 Linux 系统 不使用 RP 消息进行数据发送和接收。

Linux 系统和 R5F CPU 之间的共享 MSRAM 存储器区域 直接用于数据传输、并通过 Linux 系统的 memcpy 函数和 R5F CPU 将数据直接复制到 MSRAM 共享存储器区域 以进行读取和写入访问。

这种方法是否可行？  如何实现？ 是否有任何相关的例子？

  • 0
    TI__Guru**** 2035740 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    仔细检查您的测试

    1) 1)"需要很长时间才能完成完整的读写周期"是什么意思？

    2)你看到的延迟是什么? 您期望出现哪种延迟？

    3) 3)您是否在寻找特定的响应延迟、还是更关心数据吞吐率？ 如果您只关心吞吐量、您要寻找的吞吐量是多少？

    4)您使用的是 RT Linux 还是普通 Linux？  

    5) 5)您是否愿意与我分享您的测试方法以进行验证？ 如果您愿意、可以通过 Tony 将其离线发送。

    简单讨论您的其他问题  

    我希望我们首先着重回答上述问题。 但是、以下是对您的问题的快速答复：

    RPMSg IPC 是 TI 在 Linux 和远程内核之间支持的唯一 IPC 形式(尽管我们也有一个共享存储器示例，其中 RPMsg 在这里用作通知机制： https://git.ti.com/cgit/rpmsg/rpmsg_char_zerocopy/ )。

    理论上、您可以在 Linux 和远程内核之间实现自己的仅邮箱消息传递、但 TI 不能在这方面为您提供支持。 目前低级 Linux 邮箱驱动程序无法直接与 Linux 用户空间进行通信。

    是的、在 DDR 或 SRAM 上共享存储器是绝对可行的。 到 SRAM 的访问延迟将会较低、但 SRAM 上的可用空间也较少。 上面链接的零占空比示例是使用 DDR 实现的、但同样的概念也适用。

    此致、

    尼克

  • 0
    TI__Guru**** 2035740 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Nick、

    这个问题并不完全是我的责任,其他一些负责测试的同事。

    • 我问了他们的意见并作了简短的回答。

    • 1）>"需要很长时间才能完成完整的读写周期"是什么意思？
    • 我之前修改了 ipc_rpmsg_linux_echo 示例(R5F)和 ti_rpmsg_char 示例(Linux)以进行测试。

    • R5F 与 Linux 系统之间每次传输的数据大小为496个字节。 在 R5F 中定义一个 GPIO 以观察时间、程序处理流程如下：

    • GPIO_高电平- >R5F/RPMessage_send()(无块)->Linux /Read()(块)->Linux/write()(块)-> R5/RPMessage_recv ()(块)-> GPIO 低电平 。

    • 观察 GPIO 保持高电平的时间。 当时没有记录确切的时间。 如果我没记错的话,就会超过100us。 今天我没有时间进行测试。

    • 2).>您看到了哪种延迟？ 您期望出现哪种延迟？

    • 我们期望函数的执行时间。

      交互式数据的大小为496字节。 整个数据交互过程不超过40us。

    • Linux/writeToR5F ()–>R5F/RPMessage_recv ()(R 内核中的中断接收)–>R5F/RPMessage_send ()–>Linux/readFromR5F ()= T < 40us

    • 3)。 >您是否正在寻找特定的响应延迟，或者您是否更关心数据吞吐率？ 如果您只关心吞吐量、您要寻找的吞吐量是多少？

    • 因此我们需要更多地关注响应延迟， 延迟越小越好。

      我们希望优化400字节前提下的数据传输。 这两个指标之间存在一定的矛盾，应同时注意吞吐量和响应延迟。

      最小传输要求为300字节、Linux 和 R 内核之间的数据交换频率要求为8kHz、换句话说、执行将在125us 下完成。

    • 4)。 >您使用的是 RT Linux 还是普通 Linux？  

    • 常规 Linux μ，和 xenomai 实时补丁已针对 Linux 实现。

      该程序在实时域中运行。

    5). >我需要问我的同事,他们是否能提供。 问题1的答案是、我测试的时间有点长。 我不知道该示例是否仍然存在、我们需要找到它

    >理论上您可以在 Linux 和远程内核之间实现自己的仅邮箱消息传递，但 TI 不能在这方面为您提供支持。

    为何 TI 不能提供 Linux 邮箱驱动程序支持？

    此致、

    黄

  • 0
    TI__Guru**** 2035740 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    黄先生、您好！

    我将根据 Tony 离线分享的信息进行回复：

    用例  

    Linux 正在执行一项需要在125us 内完成的任务。 在这125us 内需要发生的事情包括：
    1) 1) Linux 将数据写入 R5F
    2) R5F 处理数据
    3) R5F 将数据写回 Linux
    4)(不清楚)也许 Linux 还必须执行一些任务，如从网络端口发送数据？

    设计反馈  

    好的、让我们退一步讲。 在我们尝试对 RPMsg 时序或 IPC 时序进行任何优化之前、我们应该讨论您的设计本身。

    RPMsg 不适合您具有125us 的硬周期时间。

    对于周期时间绝不能超过125us 的设计、即使是实时(RT) Linux 本身也可能不适合。 这是因为 RT Linux 实际上并不是一个实时操作系统。 有关更多详细信息、请参阅 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1085663/faq-sitara-multicore-system-design-how-to-ensure-computations-occur-within-a-set-cycle-time

    最坏情况的 Linux 中断响应延迟(也就是 Linux 响应中断信号和切换上下文的时间-不包括切换上下文后实际运行代码) 可能在50-100us 范围内、具体取决于您在 RT Linux 上运行的软件。 您需要运行自己的测试来查看您的软件系统的性能。 有关详细信息，请参阅 https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/09_01_00_08/exports/docs/devices/AM64X/linux/RT_Linux_Performance_Guide．html#stress-ng-and-cycluse-test 和 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1183526/faq-linux-how-do-i-test-the-real-time-performance-of-an-am3x-am4x-am6x-soc

    基于 Linux 计时器的轮询是一个选项、它将取出发送 RPMsg 时涉及的所有数据副本等。 但是、Linux 计时器中断仍将受到我们上面讨论的中断响应延迟的影响。 因此、对于极其紧张的周期时间、即使基于 Linux 计时器的轮询也可能所需的时间超出您的预期。

    另外还有几种方法是尝试解决中断响应延迟、但它们都有各自的折衷。 如需更多信息、请参阅 我在上面链接的"周期时间"常见问题解答的 Linux 内核部分。

    此致、

    尼克

  • 0
    TI__Guru**** 2035740 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Nick、

    非常感谢您的分析！

    我们的项目团队已阅读您的回复。 您在 Linux 上对 rpmsg 的性能分析也加深了我对 rpmsg 的理解。

    我们的项目团队也对您的回复进行了一些讨论。 新的数据交互方法也在测试中。

    此致、

    黄