topic Re: i.MX8 Cortex-M4 RPMSG-lite best practice in i.MX Processors

i.MX8 Cortex-M4 RPMSG-lite best practice

romainmoura — Thu, 05 Aug 2021 09:24:59 GMT

Hello,

We are starting a new project based on an i.MX8mm board running a Yocto Linux.

We plan to put most parts of the hardware access on the Cortex-m4 coprocessor. For this propose we will need a lot of interprocessor communication, a certain amount of data will transit between the Linux A53 cores and the M4 core.

RPMSG-lite seems to be designed for this, but, I'm wondering what the best practice during the development process of the M4 firmware. From what I have tested, things are OK for "production", the process is :

-Halt in u-boot

-Load the cortex-M4 firmware (the .bin file or, in my case, with a j-link probe)

-boot Linux

-During the Linux boot, the M4 can see the rpmsg link going up

-Once started, load the rpmsg kernel module (modprobe imx_rpmsg_tty)

-start talking between A53 and M4 cores

Good, but during the development process, we need to "live test" our firmware, but, once this previous "hand check" process had been executed at boot, if I load a new firmware (via j-link probe), the rpmsg behaviour became unstable, sometimes it works, sometimes it seems that the queue had kept all the data from the beginning and sometime the Linux hang....

The only way is to reboot the Linux each time to correctly execute the initialisation process, but, this is not a suitable option for a heavy M4 firmware development.

So my question, is there a better way to develop on the M4 ?

Thanks for your help !

Re: i.MX8 Cortex-M4 RPMSG-lite best practice

AldoG — Sat, 07 Aug 2021 00:04:22 GMT

Hello,

You could try using remoteproc which can be used at Linux user space for stop, restart and reload Cortex-M, you may refer to the kernel documentation for more information:
https://www.kernel.org/doc/Documentation/remoteproc.txt

Also, you could refer to the following example:

u-boot=> setenv fdt_file imx8mm-evk-rpmsg.dtb
Boot Linux & Login.
modprobe imx_rpmsg_tty
cd /sys/class/remoteproc/remoteproc0
echo /run/media/mmcblk1p1/ >/sys/module/firmware_class/parameters/path
echo imx8mm_m4_TCM_rpmsg_lite_str_echo_rtos.elf >firmware #Note: *.elf, not *.bin.
cat state #It should report offline
Load C-M program via JTAG
echo start >state
Load a new C-M program via JTAG
echo stop >state
echo start >state

Then you just need to repeat steps 10 -12 if you disconnect the debugger to load a new image.

Best regards,
Aldo.

Re: i.MX8 Cortex-M4 RPMSG-lite best practice

romainmoura — Mon, 09 Aug 2021 13:05:08 GMT

Hello,

Thanks for your help !

I have already seen this example, but there is no remoteproc0 on my device... I don't know why because the option is enabled in the Kernel source. I will investigate further.

Best regards,