[TriEmbed] Any experience using the Remote Processor Messaging driver in embedded ARM Linux?

[Scott Hall]

Info on the Remote Processor Messaging driver can be found here:
https://docs.kernel.org/staging/rpmsg.html

ST ecosystem info can be found here:
https://wiki.st.com/stm32mpu/wiki/Linux_RPMsg_framework_overview

And the non-linux side in Analog Devices universe can be found here:
https://wiki.analog.com/resources/tools-software/linuxdsp/docs/internal-cores-communication/rpmsg-lite

But I am dealing with NXP's multicore chips and finding the interface to be
very finicky.   I did resolve a problem today where the Linux user-space
process would core-dump and I could not figure out why - I was using a
C-based function that relied on malloc() in a C++ program and crashed as
soon as I attempted to access the allocated memory. Turns out that the
rpmsg-lite code on the remote core (ie. the non-Linux core) was scribbling
on a shared memory area segment intended for the heap of the Linux process
rather than within the rpmsg driver on the Linux side.

Much more solid now (thank goodness for open-source and being able to fix
it), but there is still some instability in non-happypath instances. That
is why I asked my original question hoping that somebody else has worked
with the RPMsg driver for Linux talking to a non-linux core utilizing the
rpmsg-lite API that shares memory space for passing information between the
two, and could help me through some hurdles.


Background: I’m using a Cortex-M core running FreeRTOS to manage more
deterministic operations with GPIO, timers and thus I2C, SPI, PWM,
multiplexed I/O, CANbus and a single UART (modbus), while using
quad-Cortex-A cores running Linux to handle the decision logic, networking,
video, USB, multi-UART, user interface, and other typical Linux functions.
Confusing the issue is my non-expertese regarding the multitude of linker
memory segment assignments to code and data segments in an ARM
cross-compiler throughout my code (fast-code, slow-code, flash memory,
static memory, readonly, permutable, and so on) for the bare-bones (well,
FreeRTOS) m-core code.

-- 
Scott G. Hall
Raleigh, NC, USA
scottghall1 at gmail.com
*Although kindness is rarely a job, no matter what you do it's always an
option.*

On Tue, May 27, 2025, 11:01 AM Nick Edgington <nickedgington at gmail.com>
wrote:

> Not understanding your system clearly. I was a senior Linux cluster
> architect at IBM. I work on the installation of cold clusters. I would be
> willing to take a look at the problem.
>
>
>
>
> Nick
>
> On Mon, May 26, 2025 at 11:35 PM Scott Hall via TriEmbed <
> triembed at triembed.org> wrote:
>
>>
>> I would love to pick your brain about the API for the RPMsg driver as it
>> is implemented in Debian-based embedded Linux systems (such as Yockto).
>> I need to monitor its activity, like if it has established or lost
>> communications with the remote processor.
>>
>> Please contact me if you have any experience or knowledge.  My problem is
>> that I need to reset the remote processor if the communications link goes
>> down, and I need a definitive way to determine that communications break
>> other than creating a keepalive on the remote processor and a timeout on
>> the Linux system if it hasn't received a keepalive within a certain period
>> of time.
>>
>>
>> --
>> Scott G. Hall
>> Raleigh, NC, USA
>> scottghall1 at gmail.com
>> *Although kindness is rarely a job, no matter what you do it's always an
>> option.*
>> _______________________________________________
>> Triangle, NC Embedded Interest Group mailing list
>>
>> To post message: TriEmbed at triembed.org
>> List info:
>> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
>> TriEmbed web site: https://TriEmbed.org
>> To unsubscribe, click link and send a blank message: mailto:
>> unsubscribe-TriEmbed at bitser.net?subject=unsubscribe
>> Searchable email archive available at
>> https://www.mail-archive.com/triembed@triembed.org/
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20250527/819d6693/attachment.htm>