• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 1163 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: Sharing data between IPU (SYS/BIOS) and MPU (Linux) cores

Szymon Mielczarek
Prodigy 160 points

Part Number: DRA712

Hello,

Our configuration:

  • IPU (SYS/BIOS) - loaded by the bootloader (MLO) at the early stage of the booting process and then late attached by Linux kernel (remoteproc)
  • MPU running Linux

We need to pass messages (fixed size data) from IPU (FW) to MPU (user space app) keeping in mind that IPU is running first and needs to wait for Linux to boot.

Currently, we are using MessageQ for that purpose where IPU works as writer and User space app as reader. According to MessageQ API only reader can create and own the queue so the app in user space.

IPU is collecting messages at the very early stage of the booting when the app is not running yet and because the queue is not created yet it has to internally buffer these messages in FW memory, which is something that we want to avoid.

1. Is there any other mechanism than MessageQ for our configuration (BIOS -> Linux) that allows putting data to shared memory in the way that when the other part (Linux) is ready it can read those messages?

I found that only MessageQ with RPMB Transport is capable to perform such IPC communication. All other components that are used by MessageQ like ListMP or HeapBuf/Mem are only for communication between cores running SYS/BIOS.

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

I also found RingIO mechanism but I guess it does not support DRA7X and requires additional kernel driver:

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

 

2. Is there any other option than polling MessageQ_open, to check that a message queue still exists on the remote side? So for IPU to check if the queue still exists on the Linux side.

We observe the following scenario:

  • IPU opens the queue for the first time and is putting some messages.
  • User space app can receive messages and everything works fine.
  • User space app suddenly crashes.
  • IPU can still put messages without any error, i.e. MessageQ_put return success
  • The app recovers creating the queue once again but all previously sent messages are lost

BR,

Szymon

  • 0
    TI__Expert 5970 points

    Hi Szymon,

    Thanks for your patience. I took sometime to brainstorm you second query with our experts.

    1. As per the IPC protocol, both the sender/receiver to be ready for you to start communication. This is because our IPC communication is via mailBox (with fifo depth of 4) and receiving end has to consume the FIFO for sender to place next message.

    However, if you want to buffer the packets or messages on the sender end till receiving end is ready, it needs to be taken care in the application layer.

    2. Regarding error recovery scenario: 

    a. application level heart beat monitoring can be implemented to check the status of the remote core

    b. There is no way for IPC to resume the lost packets on its own. however once IPC is reestablished, application level handshaking and packet re-transmission scheme can be implemented at application layer.

    Thanks & Regards,

    Sunita.

  • 0 in reply to Sunita Nadampalli
    Prodigy 160 points

    Hi Sunita,

    I'm afraid that doesn't answer my questions/doubts.

    First of all, MessageQ does not use any mailbox with depth 4 but, as I wrote before, it uses shared memory, ListMP, Notify and HeapBuf mechanisms. Using HeapBuf you declare a space with a number of blocks of a fixed size (e.g. 512 block with a size of 64 bytes) and such chunks are allocated and placed on the list.

    My question to that part was if there is any other mechanism for our use case (SYS/BIOS <-> Linux) that can be used instead of MessageQ which seems to be limited for use case. E.g. a shared memory where we could keep messages in the form of a ring buffer + some synchronization mechanism to notify remote part that there is something new in the buffer to be pulled out.

    About the second part.

    a. application level heart beat monitoring can be implemented to check the status of the remote core

    But how? :) I mentioned about polling MessageQ_open but it's rather a weak solution.

    BR,

    Szymon

  • 0 in reply to Szymon Mielczarek
    TI__Expert 5970 points

    Hi Szymon,

    Thanks for the clarification on the messageQ/shared memory usage in your system.

    So, when userspace app crashes, then there will no longer be a MessageQ endpoint for the messages. The socket used for rpmsg to send/receive the message for that messageQ instance will be closed, and message will get dropped at rpmsg level itself.

    In this case I think a custom protocol (may be a shared state variable with spinlock) is the only option to monitor the remotecore status.

    Thanks & Regards,

    Sunita.

  • 0 in reply to Sunita Nadampalli
    Prodigy 160 points

    Hi Sunita,

    We would like to use some mechanisms provided by your SDK. Something that is commonly used and was tested to not waste time on implementing a custom solution. Maybe we are not aware of the all possibilities that your SDK and components provide, thus my questions.

    Your answer is too general. I can just assume that MessageQ does not provide any way to prevent messages loss in case of an app crash.

    What about my first question, about MessageQ alternatives for our scenario (SYS/BIOS <-> Linux)? Again, what exactly can we use. Examples will be much appreciated.

    BR,

    Szymon

  • 0 in reply to Szymon Mielczarek
    TI__Expert 5970 points

    Hi Szymon,

    The scenarios you mentioned are either custom or error recovery scenarios. While we dont have examples to handle such cases, I will continue to investigate and provide if there are any approaches that can still leverage TI SDK components. I will take sometime to get back on this.

    Thanks & Regards,

    Sunita.

  • 0 in reply to Sunita Nadampalli
    TI__Expert 5970 points

    Hi Simon,

    Based on the discussions with other IPC experts below are the suggestions that Linux and IPU app can implement to handle A15 Linux app failure/recovery scenario.

    1. If the latency and message overhead is acceptable, implement ack message from Linux app to IPU app for every message sent from IPU.

    Or

    2. Implement a heart beat monitoring task on IPU and implement periodic state notification message from Linux App to IPU app.

    In this scenario, there is still a possibility of missing some of the IPU messages depending on the frequency of the heartbeat message.

    To work around that IPU application can implement a local queue of previous messages which it can resend when it detects that Linux App crashed and recovered.

    For both the above options, the standard IPC driver message send/receive can be used without any changes. The intelligence to be built in application layer.

    Please let me know if there are any other details you are looking for or we can close the thread.

    Thanks & Regards,

    Sunita.

  • 0 in reply to Sunita Nadampalli
    Prodigy 160 points

    Hi Sunita,

    Thank you for update.

    Just to confirm. I understand that:

    1. There is no way with MessageQ mechanism to check if the remote side actually received our message or to just check the queue status?

    2. There is no alternative to MessageQ to exchange messages between SYS/BIOS and Linux?

    BR, Szymon

  • 0 in reply to Szymon Mielczarek
    TI__Expert 5970 points

    Hi Szymon,

    1. Yes, there is no automatic feedback from IPC for message dispatch. remote application has to send an explicit ACK message in order to have this feedback mechanism.

    2.  MessageQ provides standard user space interface for Linux to sys/BIOS communication. There is mmrpc interface as well, but it is more tuned for multimedia application communication with remote cores, and this also relies on the same rpmsg kernel layer.

    Alternatively,  using shared memory and spinlocks, applications can directly share buffers without going through the standard IPC module.

    In this case,  proper synchronization to be implemented on both the applications to avoid data corruptions.

    Thanks & Regards,

    Sunita.