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 [email protected] *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 <[email protected]> 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 < > [email protected]> 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 >> [email protected] >> *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: [email protected] >> 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: >> [email protected]?subject=unsubscribe >> Searchable email archive available at >> https://www.mail-archive.com/[email protected]/ >> >>
_______________________________________________ Triangle, NC Embedded Interest Group mailing list To post message: [email protected] 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:[email protected]?subject=unsubscribe Searchable email archive available at https://www.mail-archive.com/[email protected]/
