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 !
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,
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:
Then you just need to repeat steps 10 -12 if you disconnect the debugger to load a new image.
Best regards,
Aldo.