RE: [EXT] Re: [PATCH] arm64: dts: imx95-15x15-frdm: add boot phase properties

NXP Confidential
> -----Original Message-----
> From: [email protected] <[email protected]>
> Sent: Friday, August 14, 2026 2:45 PM
> To: Joseph Guo <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> Subject: [EXT] Re: [PATCH] arm64: dts: imx95-15x15-frdm: add boot phase
> properties
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report
> this email' button
>
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s)
> to consider:
> - [High] Missing device tree boot phase properties on provider dependencies
> (`&gpio3`, `&scmi_clk`) causes early boot (SPL) failure for UART and SD/eMMC.
> --
>
> --- Patch [1]: [PATCH] arm64: dts: imx95-15x15-frdm: add boot phase
> properties --- commit 9b9056eb20751b354934dfae8becee905da7d7b0
> Author: Joseph Guo <[email protected]>
>
> arm64: dts: imx95-15x15-frdm: add boot phase properties
>
> Add boot phase properties to essential resources during boot phase.
> FRDM-IMX95 need UART, SD-Card, eMMC access during boot process.
>
> > diff --git a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts
> > b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts
> > index 0f43e3be70589..ba17d87f197a3 100644
> > --- a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts
> > @@ -140,6 +140,7 @@ reg_usdhc2_vmmc: regulator-usdhc2 {
> >               regulator-name = "VDD_SD2_3V3";
> >               gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>;
> >               enable-active-high;
> > +             bootph-pre-ram;
> >       };
>
> [Severity: High]
> Will this regulator fail to probe during early boot (SPL)?
>
> It appears that while this regulator is marked for SPL, its provider &gpio3 lacks
> boot phase tags. U-Boot's SPL device tree minification tool (fdtgrep) drops any
> node lacking bootph-* tags unless it is an ancestor of a tagged node, and
> phandle dependencies are not automatically kept.
>
> If &gpio3 is excluded from the SPL DTB, could this fail to acquire the enable
> GPIO and break MMC power?
>
> [ ... ]
>
> > @@ -445,6 +446,7 @@ led_backlight1: led@1 {
> >  &lpuart1 {
> >       pinctrl-0 = <&pinctrl_uart1>;
> >       pinctrl-names = "default";
> > +     bootph-pre-ram;
> >       status = "okay";
> >  };
>
> [Severity: High]
> Is a boot phase tag also needed on the clock provider &scmi_clk for this UART?
>
> Since phandle dependencies are stripped if not explicitly tagged, this could
> cause clock acquisition to fail during SPL when &scmi_clk is missing from the
> minified device tree.
>
> [ ... ]
>
> > @@ -1014,6 +1026,7 @@ &usdhc2 {
> >       pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
> >       vmmc-supply = <&reg_usdhc2_vmmc>;
> >       fsl,tuning-step = <1>;
> > +     bootph-pre-ram;
> >       status = "okay";
> >  };
>
> [Severity: High]
> Could the missing provider tag on &gpio3 also cause a regression here for the
> card detect GPIO?
>
> Since this node is marked for early boot but relies on &gpio3 via cd-gpios, SPL
> might fail to acquire the GPIO if &gpio3 is excluded from the SPL DTB.
>

&scmi_clk,  &gpio3 both have the booth-all property in SoC u-boot dtsi already.
This won't be an issue if not adding the booth- property in board dts.


> --
> Sashiko AI
> review · https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
> 2Fsashiko.dev%2F%23%2Fpatchset%2F20260814-bootph-frdm-imx95-v1-
> 1-
> c0e3f1b9d2ed%40nxp.com%3Fpart%3D1&data=05%7C02%7Cqijian.guo%4
> 0nxp.com%7C0de91c85afe547e4e75408def9cf9c95%7C686ea1d3bc2b4c6f
> a92cd99c5c301635%7C0%7C0%7C639222867257619988%7CUnknown%7
> CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi
> JXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=
> elhbsnr6HqPz8KlXMZXnKx90oqd5iLF8CUBVDz6XfOo%3D&reserved=0