Message-ID: <20250411162328.y2kchvdb4v4xi2lj@hiago-nb>
Date: Fri, 11 Apr 2025 13:23:28 -0300
From: Hiago De Franco <hiagofranco@...il.com>
To: Peng Fan <peng.fan@....com>
Cc: "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
	Hiago De Franco <hiago.franco@...adex.com>
Subject: Re: [REGRESSION] Kernel reboots unexpectdely on i.MX8X when
 Cortex-M4 is running and it was started by U-Boot bootaux

Hi Peng,

On Fri, Apr 11, 2025 at 01:23:32PM +0000, Peng Fan wrote:
> Hi,
> 
> Sorry for late.
> > Subject: Re: [REGRESSION] Kernel reboots unexpectdely on i.MX8X
> > when Cortex-M4 is running and it was started by U-Boot bootaux
> > 
> > On Fri, Apr 04, 2025 at 11:17:13AM -0300, Hiago De Franco wrote:
> > > #regzbot introduced: 4f6c983261
> > >
> > > Hi Peng and all,
> > >
> > > Commit 4f6c9832613b ("genpd: imx: scu-pd: initialize is_off
> > according
> > > to HW state") introduced a regression where the Kernel reboots
> > > unexpectedly (without any warnings, crashes or errors) when the
> > > Cortex-M4 was loaded and running by U-Boot, using the bootaux
> > command:
> > >
> > > # load mmc 0:2 ${loadaddr} /home/root/hello_world.bin # bootaux
> > > ${loadaddr} 0 # boot
> > >
> > > This is a simple hello world binary that prints a message into the
> > > M40.UART0 pin (demo from NXP MCUXpresso).
> 
> Which release is this image from?

This is MCUXpresso SDK 2.9.0.

> 
> > >
> > > Before this commit, everything worked as expected, Linux boots fine
> > > and the HMP core keeps running and printing messages to the UART.
> > > After the commit, the kernel reboots at the beggining of the boot
> > > process. The only relevant message is printed by U-Boot after reset:
> > >
> > > "Reset cause: SCFW fault reset"
> > >
> > > This commit was bisectabled, the same device tree, u-boot version,
> > and
> > > SCFW versions were used. Reverting this commit fixes the issues.
> > >
> > > For testing purposes, I created the following patch which also fixes
> > > the
> > > issue:
> > >
> > > diff --git a/drivers/pmdomain/imx/scu-pd.c
> > > b/drivers/pmdomain/imx/scu-pd.c index
> > 38f3cdd21042..0477b3fb4991
> > > 100644
> > > --- a/drivers/pmdomain/imx/scu-pd.c
> > > +++ b/drivers/pmdomain/imx/scu-pd.c
> > > @@ -539,6 +539,9 @@ imx_scu_add_pm_domain(struct device
> > *dev, int idx,
> > >                 return NULL;
> > >         }
> > >
> > > +       if (strstr("cm40", sc_pd->name) != NULL)
> > > +               is_off = true;
> > > +
> > >         ret = pm_genpd_init(&sc_pd->pd, NULL, is_off);
> > >         if (ret) {
> > >                 dev_warn(dev, "failed to init pd %s rsrc id %d",
> > >
> > >
> > > Test Environment:
> > > - Hardware: Colibri iMX8DX 1GB with Colbiri Evaluation Board.
> > > - U-Boot Version: 2024.04
> > > - U-Boot Build info:
> > > 	SCFW 83624b99, SECO-FW c9de51c0, IMX-MKIMAGE
> > 4622115c, ATF 7c64d4e
> > >
> > > The issue is not present on: v6.5
> > >
> > > The real root cause is still unclear to me. Anybody has any ideas? I
> > > am happy to share more details if needed.
> 
> Have you tried pd_ignore_unused? 
> 
> I think it is linux power down M4 which M4 is running, then SCFW
> reports error. So please give a try pd_ignore_unused.

For debugging purposes, I tried it and it works, kernel boots fine with
M4 running and pd_ignore_unused parameter.

> 
> If this is the case, may I know do you have m4 nodes in dts and
> with power domain included?

This is the device tree overlay I am testing:

/dts-v1/;
/plugin/;

#include <dt-bindings/clock/imx8mm-clock.h>
#include <dt-bindings/firmware/imx/rsrc.h>

/ {
	compatible = "toradex,colibri-imx8x";
};

&{/} {
	imx8x-cm4 {
		compatible = "fsl,imx8qxp-cm4";
		mbox-names = "tx", "rx", "rxdb";
		mboxes = <&lsio_mu5 0 1
			  &lsio_mu5 1 1
			  &lsio_mu5 3 1>;
		memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
				<&vdev1vring0>, <&vdev1vring1>, <&rsc_table>;
		power-domains = <&pd IMX_SC_R_M4_0_PID0>,
				<&pd IMX_SC_R_M4_0_MU_1A>;
		fsl,entry-address = <0x34fe0000>;
		fsl,resource-id = <IMX_SC_R_M4_0_PID0>;
	};

	reserved-memory {
		#address-cells = <2>;
		#size-cells = <2>;
		ranges;

		vdev0vring0: memory@...00000 {
			reg = <0 0x90000000 0 0x8000>;
			no-map;
		};

		vdev0vring1: memory@...08000 {
			reg = <0 0x90008000 0 0x8000>;
			no-map;
		};

		vdev1vring0: memory@...10000 {
			reg = <0 0x90010000 0 0x8000>;
			no-map;
		};

		vdev1vring1: memory@...18000 {
			reg = <0 0x90018000 0 0x8000>;
			no-map;
		};

		rsc_table: memory@...ff000 {
			reg = <0 0x900ff000 0 0x1000>;
			no-map;
		};

		vdevbuffer: memory@...00000 {
			compatible = "shared-dma-pool";
			reg = <0 0x90400000 0 0x100000>;
			no-map;
		};
	};
};

&lsio_mu5 {
	status = "okay";
};

This was basically copied from
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts. Do you see anything
wrong? Should I also add the "clocks" property to imx8x-cm4 node?

> 
> Anyway, I will give a try on i.MX8QM EVK.

Great, thanks.

> 
> > 
> > Hello everyone, as this introduced a regression, should I send a revert
> > for 4f6c983261? 
> 
> Please wait a while, I think we need find root cause.
> 
> Thanks,
> Peng.
> 
> Or any ideas that might help fix this issue?
> > 
> > >
> > > Cheers,
> > > Hiago.
> > 
> > Cheers,
> > Hiago.

Cheers,
Hiago.

Powered by blists - more mailing lists