i.MX8MP OpenAMP Cortex-M7

[lbsobolewski]

Hi @alxlastur ,
Thanks a lot for your work on OpenAMP for the i.MX8MP platform in the PR #78585.
I'm encoutering some issues while trying to use it on another board powered by the exact same SoC.

Could you please explain your testing methods and environment?
I'm especially interested in which Linux kernel version you are using and which OpenAMP/RPmsg sample you ran for your tests?
Could you also provide some logs of these samples run (both Zephyr and Linux logs if possible)?

On my side, I'm currently stuck at rproc_virtio_get_status step (towards the end of lib/open-amp/open-amp/lib/remoteproc/remoteproc_virtio.c) where my Zephyr firmware is not able to read the VIRTIO_CONFIG_STATUS_DRIVER_OK flag; it keeps reading 0 so it never returns.
I have already verified that Linux was writing the relevant flag (it writes the value 7) but wasn't able to verify that both Linux and Zephyr are looking at it at the same register address.

Thank you for your help

[alxlastur]

Hi @lbsobolewski

We are working on an Application Note, possibly a Patch that should solve this.
I will post the link to the AN when is done.

[lbsobolewski]

Great news! Do you have an idea of when the note will be published?
And could you tell us which kernel versions it will support? We're using Linux 5.15 and we thought that an incompatibility between the drivers from this Linux release and the latest Zephyr version could occur.

[sebd71]

Hello @alxlastur ,
I'm working with @lbsobolewski and we're still struggling with this problem.
Does you Application Note available somewhere now ?
If not, is it possible to have a preview of that document and/or patches ?
Thanks in advance for your help.

[dbaluta]

@sebd71 @lbsobolewski

We are using linux kernel 6.6 kernel (we can have a look here: https://github.com/nxp-imx/linux-imx), branch lf-6.6.y.
With this patch applied: https://lore.kernel.org/imx/CAEnQRZDoYvK-YXLjqbXsRAWDkHrWNOoR1OCCWxs+AfNUDuPB_w@mail.gmail.com/T/

I guess this would work on your kernel also, you can just port it.

We also have this workaround applied:

--- a/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts
@@ -121,7 +121,7 @@ imx8mp-cm7 {
                mboxes = <&mu 0 1
                          &mu 1 1
                          &mu 3 1>;
-               memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>;
+               memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>;//, <&rsc_table>;
                status = "okay";
                fsl,startup-delay-ms = <500>;
        };

Then we also have some changes in ATF. I will let @alxlastur comment on that. He is also working on creating an App Note but that will take a while until it gets all necessary approvals to be published.

[alxlastur]

Hi,

For atf, on imx8mplus platform iti is important to know that Linux is using to start the Cortex M7 with remoteproc, it will do call to ATF to start the Cortex M7 in the gpc_common.c https://github.com/nxp-imx/imx-atf/blob/616a4588f333522d50a55bedd2b9a90a51474a75/plat/imx/imx8m/gpc_common.c#L382

Here at line 382-383 the ATF will configure the RDC module to restrict the access of Cortex A to TCM memory of Cortex M and because of this Cortex A won't be able to access the resource table that resides in TCM. So the user should take care of regaining the access of Cortex A to TCM memory. One quick way is to comment these 2 lines, butIn a real application the user should give access only to that specific address range in which the resource table is located.

Please let us know how the tests are working on your side.

Best regards,
Alex