cancel
Showing results for 
Search instead for 
Did you mean: 

User space applications and OpenAMP

debugging
Senior III

STM32MP1.

Working on an solution that will use OpenAMP between M4 and A7 and then to user space. The M4 will run real time critical code that will send a message to the A7 when data is available,  Got the raw and USART samples compiled nder CubeIDE and it''s working as loading the M4 code works.

However wish to use a callback (interrupted) solution in a Linux user space application instead of this user space application polling a device or channel endpoint in a thread to check for data , thus to save CPU load. Even better is avoiding to have to use kernel modules for this A7/M4 brigde.  I could not find much use cases of OpenAMP even it's quite an established technology. Any guidance would be helpful.

1 ACCEPTED SOLUTION

Accepted Solutions

Hi @debugging​ 

>> However how to end the thread when it is in a blocked read and assure graceful exit with all allocated resources in the thread are correctly cleaned up

It exist standard linux solution using SIG (https://man7.org/linux/man-pages/man7/signal.7.html)

>> One idea perhaps is to send a special message to the M4 to let it send a special message to the A7 to terminate

yes it's a solution. Calling VIRT_UART_DeInit on M4 side will destroy endpoint rpmsg, and consequently delete /dev/ttyRPMGx

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

View solution in original post

4 REPLIES 4
Olivier GALLIEN
ST Employee

Hi @debugging​ ,

Could details your use case? If I well understood you want to have a Linux userland application that waits for m4 messages but does not consume CPU during this time?

Managing an interrupt callback in the userland is not possible, you have to manage events ( such as udev).

But you probably don’t need to do that.  For instance if you have a look to the OpenAMp TTY echo sample, a /dev/ttyRPMSG0 ABI is created.

An application thread reading this file be blocked (until the Cortex-M4 sent a message) without any CPU consumption.

You can do the test by yourself:

  • Start the OpenAMP_TTY_echo firmware.
  • When started you should have a /dev/ttyRPMSG0 file created
  • Run following command : “ cat /dev/ttyRPMSG0 &�?
  • This cat application is running in background waiting for data on /dev/ttyRPMSG0
  • Run “top�? command to observe the CPU load, the CPU associated to the cat command is 0.

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
debugging
Senior III

Many thanks. That understanding is correct. The TTY solution should work in in that way if it runs forever. the virtual UART TTY solution runs fine. However how to end the thread when it is in a blocked read and assure graceful exit with all allocated resources in the thread are correctly cleaned up. One idea perhaps is to send a special message to the M4 to let it send a special message to the A7 to terminate . Not sure if there are any other real world solutions so I was looking for something that could be done with the CM4/CA7.

Hi @debugging​ 

>> However how to end the thread when it is in a blocked read and assure graceful exit with all allocated resources in the thread are correctly cleaned up

It exist standard linux solution using SIG (https://man7.org/linux/man-pages/man7/signal.7.html)

>> One idea perhaps is to send a special message to the M4 to let it send a special message to the A7 to terminate

yes it's a solution. Calling VIRT_UART_DeInit on M4 side will destroy endpoint rpmsg, and consequently delete /dev/ttyRPMGx

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
debugging
Senior III

Thanks, it gets a bit in tricky territory, https://man7.org/linux/man-pages/man7/signal-safety.7.html. the UART option seem the be most safe and clean. The signal may cause to leave the system in unstable state, specially when the main thread needs to continue. Thanks, can close this one.