• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 3 answers
  • Subscribers 98 subscribers
  • Views 1826 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.

Linux/AM5706: IPC questions

Jose Carlos Billalabeitia
Expert 2490 points
Part Number: AM5706


Tool/software: Linux

Hi:

    I have an AM5706 evm with Linux in A15 and TI-RTOS in DSP/M4. For IPC communication:

The hardware resources are :

- spinlock, mailbox, interrupts and RAM memory.

Some of Linux services & functions:

- GateMP, MessageQ, RPMsg (remoteproc, rpmsg) ...

I am trying to understand how the Linux IPC services are implemented at low level based on the hardware resources,

so I have read some documentation, E2E questions and so on. It is not very clear for me, so here are some

of my interpretations and I would like to confirm them:

GateMP: I want to work with "GateMP_RemoteProtect_SYSTEM".  Can I assume that

- it makes use of hardware spinlock?

- it has at low level the "spin_lock_irqsave()" function?

- I can use it from user space? I need to disable interrupts that cannot be done at user space.

- there is any function at user space that wraps a hardware spinlock? Or I need to work at kernel space?

MessageQ: can I assume that

- it has "remoteproc" and "rpmsg" as a mechanism to transport the messages and vring buffers? Or it is based on hardware mailboxes?

- it triggers a hardware interrupt to the receiving core?

- then it triggers a software interrupt at user space?

- it can only be used at user space?

RPMsg: can I assume that

- it has a similar implementation as the MessageQ?

-  it has "remoteproc" and "rpmsg" as a mechanism to transport the messages and vring buffers?

- it triggers a hardware interrupt to the receiving core?

- it only works at kernel space?

- Where can I find some user´s guied documentation?

"spin_lock_irqsave()": can I assume that

- it makes use of hardware spinlock?

- I can only use it at kernel space?

Hardware mailbox: 

- what Linux user service makes use of it?

- I can only use it at kernel space?

Triggering a hardware interrupt from one core to other: 

- is there any mechanism in Linux to achieve it?

- does it work only at kernel space?

- is there any mechanism other than a maibox in TI-RTOS to achieve it?

Sorry for the question being so long.

Regards

Billa

  • 0
    TI__Guru 50170 points
    Hi, Billa,

    On AM57x, the hardware spinlock is supported, and yes, Linux and RTOS both use it. In term of share memory protection using spinlock, for ARM/Linux and DSP/RTOS communication, it is through virtio which uses different areas for read and write. That will not cause any contention issue.

    GateMP uses spinlock underneath it. So, if you need to use spinlock, would GateMP API be sufficient?

    Remoteproc is the mechanism to download image to DSP which should not be confused with rpmsg. MessageQ sends messages between Linux and RTOS application. MessageQ uses RPMsg which sits on top of Virtio for data transfer. Once the message is copied to the buffer, mailbox is used to trigger an interrupt to notify the other side.

    IPC provides an abstraction layer to the lower layer hardware through APIs which should be used. Some modules have user space APIs which can be found in ipc_x_xx_xx_xx/package/ti/ipc/*.h. If TI IPC APIs are not used, but going down the route of customized access in user space, it can be done through mm device map, but what is the purpose of having user space APIs or what are missing in IPC APIs which can't be used in the project?

    Rex
  • 0 in reply to Rex Chang
    Expert 2490 points

    Hi Rex:

         My understanding is that you cannot disable interrupts in user space. I guess that GateMP disables interrupts somewhere in kernel space before getting the spinlock, right?

    I guess that the process of protecting a shared resource with GateMP in user space implies that this function call switches to kernel space, disable interrupts an tries for some time to get the spinlock.

    Then it makes the way back to user space for application to acces the protected shared resource. And finally it has to release the spinlock trhough the same path as getting the spinlock.

    What I mean is that it can take long time to access the shared resource and the spinlock will be locked. That is something to avoid.

    So it is not clear to me the use of GateMP from user space. More over if you are having many accesses to a shared memory that is being changd every 1 msec by other core, this mechanism canno be very efficient.

    Regards

    Billa

  • 0 in reply to Jose Carlos Billalabeitia
    Expert 2490 points
    Hi Rex:

    Can I assume that the only difference between MessageQ and the RPMsg API is that MessageQ is used in user space and RPMsg in kernel space?
    According to your answer my understanding is that both use hardware mailboxes and hw interrupts underneth.
    Where can I find RPMsg API documentation?

    Regards
    Billa
  • 0 in reply to Jose Carlos Billalabeitia
    TI__Guru 50170 points
    Jose,

    The correct way of accessing hardware including spinlock is through kernel. It does involve overhead, but it provides the necessary protection. Exposing the access in user space, you lose all those protections in kernel.

    RPMsg is a kernel device driver. The documentation is in Documentation/rpmsg.txt, the source code in drivers/rpmsg.

    Rex
  • 0 in reply to Rex Chang
    Expert 2490 points

    Hi Rex:

         So as a summary, you cannot use hardware spinlock protection from user space.

    Or if you use it, the user application will make use of the kernel driver to protect-unprotect

    the shared resource. The latter may imply to leave the spinlock and interrupts locked and

    disabled for long time.

    Regards

    Billa

  • 0 in reply to Jose Carlos Billalabeitia
    TI__Guru 50170 points

    Hi, Billa,

    Bypassing kernel is not recommended. There are other ways which you may want to explore. UIO may be an option, or other means from user space which is not in our support scope.

    Rex

  • 0 in reply to Rex Chang
    Expert 2490 points
    Hi Rex:

    I have read someting about UIO and will try to deal with it, and check if it is suitable for me.

    Thanks a lot !!