<div dir="auto"><div dir="auto">Info on the Remote Processor Messaging driver can be found here: <a href="https://docs.kernel.org/staging/rpmsg.html">https://docs.kernel.org/staging/rpmsg.html</a></div><div dir="auto"><br></div><div dir="auto">ST ecosystem info can be found here: <a href="https://wiki.st.com/stm32mpu/wiki/Linux_RPMsg_framework_overview">https://wiki.st.com/stm32mpu/wiki/Linux_RPMsg_framework_overview</a></div><div dir="auto"><br></div><div dir="auto">And the non-linux side in Analog Devices universe can be found here: <a href="https://wiki.analog.com/resources/tools-software/linuxdsp/docs/internal-cores-communication/rpmsg-lite">https://wiki.analog.com/resources/tools-software/linuxdsp/docs/internal-cores-communication/rpmsg-lite</a></div><div dir="auto"><br></div><div dir="auto">But I am dealing with NXP&#39;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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Background: I\u2019m 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.</div><div dir="auto"><br></div><div dir="auto">-- </div><div data-smartmail="gmail_signature" dir="auto"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Scott G. Hall<br>Raleigh, NC, USA<br><a href="mailto:scottghall1@gmail.com" target="_blank">scottghall1@gmail.com</a></div><i>Although kindness is rarely a job, no matter what you do it&#39;s always an option.</i><br></div></div></div></div></div></div><br><div class="gmail_quote gmail_quote_container" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, May 27, 2025, 11:01\u202fAM Nick Edgington &lt;<a href="mailto:nickedgington@gmail.com">nickedgington@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Nick</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 26, 2025 at 11:35\u202fPM Scott Hall via TriEmbed &lt;<a href="mailto:triembed@triembed.org" target="_blank" rel="noreferrer">triembed@triembed.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><br>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).</div><div>I need to monitor its activity, like if it has established or lost communications with the remote processor.</div><div><br></div><div>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&#39;t received a keepalive within a certain period of time.</div><div><br></div><br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Scott G. Hall<br>Raleigh, NC, USA<br><a href="mailto:scottghall1@gmail.com" target="_blank" rel="noreferrer">scottghall1@gmail.com</a></div><i>Although kindness is rarely a job, no matter what you do it&#39;s always an option.</i><br></div></div></div></div></div></div></div>
_______________________________________________<br>
Triangle, NC Embedded Interest Group mailing list<br>
<br>
To post message: <a href="mailto:TriEmbed@triembed.org" target="_blank" rel="noreferrer">TriEmbed@triembed.org</a><br>
List info: <a href="http://mail.triembed.org/mailman/listinfo/triembed_triembed.org" rel="noreferrer noreferrer" target="_blank">http://mail.triembed.org/mailman/listinfo/triembed_triembed.org</a><br>
TriEmbed web site: <a href="https://TriEmbed.org" rel="noreferrer noreferrer" target="_blank">https://TriEmbed.org</a><br>
To unsubscribe, click link and send a blank message: mailto:<a href="mailto:unsubscribe-TriEmbed@bitser.net" target="_blank" rel="noreferrer">unsubscribe-TriEmbed@bitser.net</a>?subject=unsubscribe<br>
Searchable email archive available at <a href="https://www.mail-archive.com/triembed@triembed.org/" rel="noreferrer noreferrer" target="_blank">https://www.mail-archive.com/triembed@triembed.org/</a><br>
<br>
</blockquote></div></div>
</blockquote></div></div>