Hey, @vic,
That post refers to an old version of the overlay. The current version actually enables both RPMsg and RemoteProc, the documentation still needs to be updated. Additionally, I tested it and managed to run the M4 firmware on the Colibri iMX8X using RemoteProc.
Can you tell me what are the exact steps you are following to try to use RemoteProc and what error is appearing?
Best regards,
Hi @leonardo.costa.tx ,
I followed the instructions here and everything seems to be work as expected until I try to start the firmware by echoing “start” to /sys/class/remoteproc/remoteproc0/state. See what I get in the image below.
Surely I am missing something…
V
Hi @vic
I was able to run the M4 firmware today using remoteproc. Specifically, I am on the 7.4.0+build.28 release of Torizon. I modified my overlays.txt file as follows:
root@colibri-imx8x-06748684:/boot# cat /boot/ostree/torizon-77368a704b4e45bd6dc2d3539f6687f7be15979fb3249f06d8a2785f573fd6ea/dtb/overlays.txt
fdt_overlays=colibri-imx8x_vga-640x480_overlay.dtbo colibri-imx8x_hmp_overlay.dtbo colibri-imx8x_disable-cm40-uart_overlay.dtbo
Your OSTreee ID will likely be different than mine. I started with an unmodified quarterly build and make the changes manually. Eventually this should go into your torizoncore-builder config.
Then once I rebooted with that setup, I was able to do the following:
# echo -n /boot > /sys/module/firmware_class/parameters/path
# echo hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware
# echo start > /sys/class/remoteproc/remoteproc0/state
My guess is that doing this with remoteproc, rather than using the older method of the bootaux command in u-boot will allow you to proceed. I’ve not looked in depth at your code yet so it’s possible that something in there is clashing with Linux but since you indicated it seemed to be an issue on boot, hopefully running this using remoteproc, but after Linux is booted will, at the very least, unblock you.
I don’t know why your test with remoteproc failed but if you can share the entire set of commands maybe we can spot something.
Drew
Hi,
Well, we missed our deadline, but the have been some financial manoeuvres I guess, and I was able to spend some more time on this.
By comparing the working echo example project with our non-working project I was able to narrow things down to 2 problems in fact.
First, comparing the .cproject settings I noticed that our project was not passing
-D__STARTUP_CLEAR_BSS -D__STARTUP_INITIALIZE_NONCACHEDATA to the assembler. This may be why our code was working only after the echo example had been run - reboot I suppose leaves the memory unchanged.
Second, our code was overflowing the .heap space. Since the heap space is defined to be the same in both of the linker scripts, it’s not clear why our code appeared to work fine with the previous Yocto image. Perhaps Torizon has some strict memory management ? Although the heap is located in one of the TCM regions, which is not assigned to the Linux image iiuc.
Anyway, this looks resolved now 
Many thanks for the input,
Tim