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

[Peng Fan]

> 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 at 90000000 {
> 			reg = <0 0x90000000 0 0x8000>;
> 			no-map;
> 		};
> 
> 		vdev0vring1: memory at 90008000 {
> 			reg = <0 0x90008000 0 0x8000>;
> 			no-map;
> 		};
> 
> 		vdev1vring0: memory at 90010000 {
> 			reg = <0 0x90010000 0 0x8000>;
> 			no-map;
> 		};
> 
> 		vdev1vring1: memory at 90018000 {
> 			reg = <0 0x90018000 0 0x8000>;
> 			no-map;
> 		};
> 
> 		rsc_table: memory at 900ff000 {
> 			reg = <0 0x900ff000 0 0x1000>;
> 			no-map;
> 		};
> 
> 		vdevbuffer: memory at 90400000 {
> 			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?

In your case, m4 is in same scu partition as a53, so m4
power domain is manageable(owned) by Linux.

However to m4 earlyboot(kicked by bootloader),
if you not wanna linux to handle m4, use scu_rm
to create a separate partition in u-boot.
If you wanna linux to handle m4, but not wanna linux
to shutdown the pd in kernel boot, imx_rproc.c
needs to be built in, and need to add a clock entry
or use clock optional api in imx_rproc.c .

Current imx_rproc.c needs a clock entry to probe pass.

I think in your case, this driver not probe pass, so the
M4 pd still get powered off.


Regards,
Peng.

> 
> >
> > 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.