• 状态 Resolved
  • 已锁定 已锁定
  • 回复 8 回复
  • 订户 0 订户
  • 视图 673 视图
  • 用户 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.

[参考译文] DRA712：在 IPU (SYS/BIOS)和 MPU (Linux)内核之间共享数据

admin
Guru**** 2540720 points


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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/974714/dra712-sharing-data-between-ipu-sys-bios-and-mpu-linux-cores

器件型号：DRA712

您好！

我们的配置：

  • IPU (SYS/BIOS)-由引导加载程序(MLO)在引导过程的早期阶段加载、然后由 Linux 内核(remoteproc)稍后连接
  • 运行 Linux 的 MPU

我们需要将消息(固定大小的数据)从 IPU (FW)传递到 MPU (用户空间应用)、同时记住 IPU 首先运行、需要等待 Linux 启动。

目前、我们将 MessageQ 用于此目的、其中 IPU 用作写入器、用户空间应用用作读取器。 根据 MessageQ API、只有读取器可以创建和拥有队列、以便应用程序处于用户空间。

IPU 正在引导的早期阶段收集消息、此时应用尚未运行、并且由于队列尚未创建、因此它必须在固件存储器中内部缓冲这些消息、这是我们想要避免的。

1.除 MessageQ 之外、我们的配置(BIOS -> Linux)是否有任何其他机制允许将数据放入共享存储器、以便在另一个部分(Linux)准备就绪时可以读取这些消息？

我发现只有具有 RPMB 传输的 MessageQ 才能执行此类 IPC 通信。 MessageQ 使用的所有其他组件、如 ListMP 或 HeapBuf/Mem、仅用于运行 SYS/BIOS 的内核之间的通信。

www.ti.com/.../sprugo6e.pdf

我还找到了 RingIO 机制、但我想它不支持 DRA7X、需要额外的内核驱动程序：

software-dl.ti.com/.../_ring_i_o_8h.html

 

2.除了轮询 MessageQ_open 外，是否还有其他选项可用于检查远程侧是否仍然存在消息队列？ 因此、IPU 需要检查 Linux 端是否仍然存在队列。

我们观察到以下情况：

  • IPU 首次打开队列并正在输入一些消息。
  • 用户空间应用程序可以接收消息、一切正常。
  • 用户空间应用程序突然崩溃。
  • IPU 仍然可以无任何错误地放置消息、即 MessageQ_Put 返回成功
  • 应用程序将恢复再次创建队列、但先前发送的所有消息都将丢失

BR、

Szymon

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

    您好、Szymon、

    感谢您的耐心等待。 我花了一段时间与我们的专家一起集体讨论您的第二个问题。

    1.根据 IPC 协议，发送器/接收器都准备好开始通信。 这是因为我们的 IPC 通信是通过邮箱进行的(FIFO 深度为4)、接收端必须使用 FIFO 才能发送方放置下一条消息。

    但是，如果要在接收端准备就绪之前缓冲发送器端的数据包或消息，则需要在应用层中加以注意。

    2.关于错误恢复方案：  

    答：可实施应用级心搏监控来检查远程内核的状态

    b. IPC 无法自行恢复丢失的数据包。 但是、一旦重新建立 IPC、就可以在应用层实现应用级握手和数据包重传方案。

    谢谢、此致、

    Sunita。

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

    您好、Sunita、

    我担心这不能回答我的问题/疑问。

    首先、MessageQ 不使用深度为4的任何邮箱、但正如我之前所写的、它使用共享存储器、ListMP、Notify 和 HeapBuf 机制。 使用 HeapBuf 可以声明具有一定大小的块数的空间(例如、大小为64字节的512个块)、并且这些块被分配并放置在列表上。

    我对该部分的问题是、我们的用例(SYS/BIOS <-> Linux)是否有任何其他机制可以使用、而不是 MessageQ、这似乎仅限于用例。 例如、共享存储器、在该存储器中、我们可以保留以环形缓冲区形式的消息+一些同步机制、以通知远程部分缓冲区中有一些新内容需要拉出。

    介绍第二部分。

    答：可实施应用级心搏监控来检查远程内核的状态

    但如何呢？ :)我提到了轮询 MessageQ_open，但它是一个弱解决方案。

    BR、

    Szymon

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

    您好、Szymon、

    感谢您对系统中 MessageQ/共享内存使用情况的澄清。

    因此、当 userpspace 应用程序崩溃时、消息将不再有 MessageQ 端点。 用于 rpmsg 发送/接收该 MessageQ 实例的消息的套接字将被关闭、并且消息将在 rpmsg 级别自身被丢弃。

    在这种情况下、我认为一个自定义协议(可能是一个带有自旋锁的共享状态变量)是监控远程存储器状态的唯一选项。

    谢谢、此致、

    Sunita。

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

    您好、Sunita、

    我们希望使用您的 SDK 提供的一些机制。 一些常用且经过测试的产品、不会浪费时间来实施定制解决方案。 我们可能并不了解您的 SDK 和组件提供的所有可能性、因此我的问题也就这样。

    您的答案过于笼统。 我可以假设 MessageQ 不提供任何方法来防止应用程序崩溃时消息丢失。

    我的第一个问题、关于我们的方案(SYS/BIOS <-> Linux)的 MessageQ 替代方案、该怎么办？ 再说一次、我们到底可以使用什么。 我们非常感谢这些示例。

    BR、

    Szymon

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

    您好、Szymon、

    您提到的方案是自定义方案或错误恢复方案。 虽然我们没有处理此类案例的示例、但我将继续调查并提供是否有任何方法仍然可以利用 TI SDK 组件。 我会花点时间回到这个问题上。

    谢谢、此致、

    Sunita。

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

    您好、Simon、

    根据与以下 IPC 专家的讨论、我们建议 Linux 和 IPU 应用程序可实施以处理 A15 Linux 应用程序故障/恢复情形。

    如果延迟和消息开销是可以接受的、则针对从 IPU 发送的每条消息实施从 Linux 应用程序到 IPU 应用程序的 ACK 消息。

    或

    2.在 IPU 上实施心跳监测任务，并实施从 Linux 应用程序到 IPU 应用程序的定期状态通知消息。

    在这种情况下、根据心跳消息的频率、仍然可能丢失一些 IPU 消息。

    为了解决该 IPU 应用程序的问题、它可以实施以前消息的本地队列、当检测到 Linux 应用程序崩溃和恢复时、可以重新发送这些队列。

    对于上述两个选项、无需进行任何更改即可使用标准 IPC 驱动程序消息发送/接收。 在应用层中构建智能。

    请告诉我 您是否正在查找其他详细信息、或者我们是否可以关闭该主题。

    谢谢、此致、

    Sunita。

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

    您好、Sunita、

    感谢您的更新。

    只需确认即可。 我理解：

    1.无法使用 MessageQ 机制来检查远程端是否确实收到了我们的消息、或者只检查队列状态？

    2.对于在 SYS/BIOS 和 Linux 之间交换消息、MessageQ 没有替代方法？

    BR、Szymon

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

    您好、Szymon、

    1.是的、IPC 没有针对消息发送的自动反馈。 远程应用程序必须发送明确的 ACK 消息才能使用此反馈机制。

    MessageQ 为 Linux 到 SYS/BIOS 的通信提供标准用户空间接口。  还有 mmrpc 接口、但它更适合与远程内核进行多媒体应用通信、这也依赖于相同的 rpmsg 内核层。

    或者 、使用共享存储器和自旋锁、应用程序可以直接共享缓冲区、而无需通过标准 IPC 模块。

    在这种情况下、  在两个应用程序上都要实现正确的同步、以避免数据损坏。

    谢谢、此致、

    Sunita。