Multiple Cores Communication

[kmkorym]

I read the RPMSG part of documentation https://openamp.readthedocs.io/en/latest/protocol_details/rpmsg.html#rpmsg-messaging-protocol.

It metioned that
" This layer is the key part of the whole solution - thanks to this layer, there is no need for inter-core synchronization. This is achieved by a technique called single-writer single-reader circular buffering "

My system is 2 cores run SMP Linux and 2 cores run RTOS,
I want to know about OpenAMP can be used for multiple core read/write message to only one shared memory region simultaneously ?

[tnmysh]

So, Are you planning to achieve a communication between linux and two cores ? Assuming 2 cores running RTOS in AMP mode, where each core operated individually.

For example:

      Linux
     /     \
    /       \
Core-0 --- Core1
RTOS        RTOS

In this case, you would need three shared memory regions:

shmem1: Linux to/From Core0-RTOS

Shmem2: Linux to/From Core1-RTOS

shmem3: Core0-RTOS to/From Core1-RTOS

"multiple core read/write message to only one shared memory region" -> This may not be possibe as, if single shared memory region is available

for more than two cores, data corruption is possible. Probably virtio spec not designed for this case.

@arnopo, @edmooring

[kmkorym]

@tnmysh
Thanks for your reply, In my situaiton is a single RTOS with SMP runs on two cores, and a SMP Linux run on two cores. In this setting, is there some internal synchronization mechanism in OpenAMP libs which allows SMP RTOS/Linux write to a shared memory region? Or applications needs to explicitly apply locking mechanism when calling APIs to access shared memory to avoid data corruption?
For example, if there are two process in SMP Linux write to a shared memory at the same time or
two threads in a RTOS wirtes to a shared memory at the same time.

[tnmysh]

I believe in SMP use cases, application explicitly needs to apply spinlocks.
mutexes are used, but not sure if they can prevent data corruption due to race condition between two different cores

[edmooring]

To extend this explanation a bit more, on Linux the RMPSG subsystem in the kernel handles concurrency internally, so applications don't need to worry about it. For the RTOS, the libmetal implementation is going to have to implement the metal_mutex*() functions, and additional synchronization may be required at the application level.