[REGRESSION] Kernel reboots unexpectdely on i.MX8X when Cortex-M4 is running and it was started by U-Boot bootaux

[Hiago De Franco]

Hi Peng,

On Wed, Apr 16, 2025 at 08:19:27AM +0000, Peng Fan wrote:
> > Got it, I was able to make it work with the downstream pingpong
> > driver and the MCUXpresso demo. I can launch the firmware using the
> > remoteproc and exchange data between the two cores.
> >
> > There is something I noticed, when I start the pingpong demo with U-
> > Boot, it does not work. I run the pingpong modprobe on Linux but the
> > name service is never annouced. It only works if I start with the
> > remoteproc on Linux, not U-Boot. Is this because of Linux not being
> > able to control the M4?
>
> No. In you case, you could start using remoteproc, that means
> Linux could control M4.
>
> >
> > If I start the binary using U-Boot, the "state" always report as "offline"
> > by the remoteproc driver.
>
> In drivers/remoteproc/imx_rproc.c,  imx_rproc_detect_mode
> case IMX_RPROC_SCU_API is used for detect mode of M4 for i.MX8Q/X
> platform. Please give a look where it returns.
>
> For U-Boot start m4, linux should remote state: "attached"

Ok, in this case looks its does not work. I start the firmware with
U-Boot and state is always "offline". Inside the IMX_RPROC_SCU_API case,
the function returns at this point:

		...
		/*
		 * If Mcore resource is not owned by Acore partition, It is kicked by ROM,
		 * and Linux could only do IPC with Mcore and nothing else.
		 */
		if (imx_sc_rm_is_resource_owned(priv->ipc_handle, priv->rsrc_id)) {
			if (of_property_read_u32(dev->of_node, "fsl,entry-address", &priv->entry))
				return -EINVAL;

			return imx_rproc_attach_pd(priv); // <-- Returns here
		...

And this function, imx_rproc_attach_pd, returns 0 at the end:

	...
	return 0; // <-- Returns here at the end

detach_pd:
	while (--i >= 0) {
	...

So looks like in this case the partition is *not* owned by the A core,
it is still being owned by the Mcore and I can not attach.

For debugging purposes, I did the following patch, inverting the logic:

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 592a34cfa75e..2fcc9086e916 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -1072,7 +1072,7 @@ static int imx_rproc_detect_mode(struct imx_rproc *priv)
                 * If Mcore resource is not owned by Acore partition, It is kicked by ROM,
                 * and Linux could only do IPC with Mcore and nothing else.
                 */
-               if (imx_sc_rm_is_resource_owned(priv->ipc_handle, priv->rsrc_id)) {
+               if (!imx_sc_rm_is_resource_owned(priv->ipc_handle, priv->rsrc_id)) {
                        if (of_property_read_u32(dev->of_node, "fsl,entry-address", &priv->entry))
                                return -EINVAL;

And now the remoteproc driver attaches to the MCore succesfully, which
is exactly what I want. However less than one second later the kernel
reboot with the "SCFW fault reset" again.

Do you know what could be the issue in this case? Maybe the partitions are
not yet correct?

>
> Regards,
> Peng.

Cheers,
Hiago.