Reload m4 firmware for RPMSG without module reboot

Hello everyone,

I am in the development phase for a system in M4 that should (e.g.) receive signals via a UART interface, add a timestamp for the first and last byte and then pass the whole thing on to Linux via the RPMSG interface.

I transfer and start the M4 firmware via JLink or using the uboot method. This all works satisfactorily.

The RPMSG functionality must already be running in the M4 core so that the drivers on Linux can set up appropriate endpoints when starting and applying the device tree.
Does anyone know of a way to reload the entire RPMSG dependencies on Linux after rebooting only the M4 firmware?
Maybe by loading, including the Virtio driver as a reloadable module?

Best regards

Remoteproc (kernel CONFIG_IMX_REMOTEPROC) driver allows launching / stopping / relaunching Cortex-M FW via sysfs like mentioned here

remoteproc for M4 on i.MX8 MM - NXP Community


I suspect that doesn’t solve my problem.
Using the JLink I am already able to rewrite the m4 FW and restart the M4 (if the M4 does not fall into a state where it no longer responds at all).
I’m afraid that I would have to completely reload the entire Virtio ↔ Rpmsg construct as a kernel module to the Linux runtime.
But that requires a lot of work and testing. And does it then work reliably? I should know that beforehand.

Oh yes. Debugging is problematic, I know no decent recipe for it on NXP iMX forum. Just advertisements how great it is (when already working :-)) and no good suggestions how to debug it not spending hours rebooting and rebooting whole Linux.

Since rpmsg comms are kind of serial port comms, I mean not specific routine calls, which obviously are different, but it is still getting some data, then reacting to received data. Perhaps it could be debugged over M4 serial port. Of course I did my M4 coding wrong way, adding some silly debug tricks, rebooting, so spending a lot of time not very effectively.
Do you have rpmsg lite on your iMX8? Unlike old rpmsg stuff for iMX7 rpmsg lite supports multiple rpmsg channels and /dev/ttyRPMSG’s, so you could dedicate one or more such TTY’s for debug messages and perhaps control commands. Of course rebooting quickly over JTAG would be the best if RPMSG could keep working.
Does m4fwloader support MX8? It allowed to just kick MU channels, which could reanimate RPMSG after reload in some cases.

Good to know I’m not alone in this

I think it’s some kind of shared memory, accessed via kernel modules / drivers. For example, an interface (/dev/ttyRPMSG30 or 31) (you mentioned it yourself) can also be accessed.

In order to be able to work effectively with the RPMSG method, a deeper insight into this matter is required.
It would go beyond the scope of this article if I were to list all the problems I have encountered so far.
But as you already suggested: you feel extraordinarily good when something works. :grinning: