v2023.07-rc5 regression: Image overlaps SPL

[Francesco Dolcini]

On Mon, Jul 03, 2023 at 04:01:15PM -0400, Tom Rini wrote:
> On Mon, Jul 03, 2023 at 09:54:40PM +0200, Francesco Dolcini wrote:
> > On Mon, Jul 03, 2023 at 09:40:51PM +0200, Marek Vasut wrote:
> > > On 7/3/23 18:49, Francesco Dolcini wrote:
> > > > Short update on this regression.
> > > > 
> > > > On Thu, Jun 29, 2023 at 04:19:22PM +0200, Francesco Dolcini wrote:
> > > > > I also noticed something weird on a colibri imx7s, this is not using SPL,
> > > > > likely something completly different, however given this is new also from rc5 I
> > > > > thought it's valuable to report:
> > > > > 
> > > > > ```
> > > > > U-Boot 2023.07-rc5-0.0.0-devel+git.580eb31199be (Jun 27 2023 - 13:39:58 +0000)
> > > > > CPU:   Freescale i.MX7S rev1.2 800 MHz (running at 792 MHz)
> > > > > CPU:   Extended Commercial temperature grade (-20C to 105C) at 30C
> > > > > Reset cause: POR
> > > > > DRAM:  initcall sequence 8786eafc failed at call 8781b351 (err=-3)
> > > 
> > > If you have the u-boot (elf file, unstripped), then check which initcall it
> > > is that failed . Just run arm-...-objdump -lSD on it and search for the
> > > 8781b350: address ; remember to clear the LSbit of the address in case this
> > > is thumb mode of the CPU.
> > 
> > 
> > U-Boot 2023.07-rc6 (Jul 03 2023 - 21:50:58 +0200)
> > 
> > CPU:   Freescale i.MX7S rev1.2 800 MHz (running at 792 MHz)
> > CPU:   Extended Commercial temperature grade (-20C to 105C) at 35C
> > Reset cause: POR
> > DRAM:  initcall sequence 8786fb00 failed at call 8781b715 (err=-3)
> > ### ERROR ### Please RESET the board ###
> > 
> > 
> > u-boot/common/board_f.c:523
> > }
> > 8781b710:       2000            movs    r0, #0
> > 8781b712:       bd08            pop     {r3, pc}
> > 
> > 8781b714 <fix_fdt>:
> > fix_fdt():
> > u-boot/common/board_f.c:729
> >         return board_fix_fdt((void *)gd->fdt_blob);
> > 8781b714:       f8d9 0068       ldr.w   r0, [r9, #104]  ; 0x68
> > 8781b718:       f7ea bafe       b.w     87805d18 <board_fix_fdt>
> 
> So, that's in your board code then:
> board/toradex/colibri_imx7/colibri_imx7.c:int board_fix_fdt(void *rw_fdt_blob)

Yep, this is the problematic code:

board/toradex/colibri_imx7/colibri_imx7.c:
int board_fix_fdt(void *rw_fdt_blob)
{
	/* i.MX 7Solo has only one single USB OTG1 but no USB host port */
	if (is_cpu_type(MXC_CPU_MX7S)) {
		int offset = fdt_path_offset(rw_fdt_blob, "/soc/bus at 30800000/usb at 30b20000");

		return fdt_status_disabled(rw_fdt_blob, offset);
	}

	return 0;
}

For what is worth in this node "/soc/bus at 30800000/usb at 30b20000" the
`status="ok"` property is already present.


Before 8c103c33fb14 ("dm: dts: Convert driver model tags to use new
schema") fdt_status_disabled() did return 0, so all good
no issue.

If I do this small partial revert

--- a/arch/arm/dts/imx7d-colibri-eval-v3-u-boot.dtsi
+++ b/arch/arm/dts/imx7d-colibri-eval-v3-u-boot.dtsi
@@ -15,7 +15,8 @@
        pinctrl-0 = <&pinctrl_lcdif_dat
                     &pinctrl_lcdif_ctrl>;
        display = <&display0>;
-       u-boot,dm-pre-reloc;
+       bootph-all;

fdt_status_disabled() returns 0 again.

With the current master, fdt_status_disabled() returns -3,
-FDT_ERR_NOSPACE, and I assume I could just change my code to call
fdt_increase_size() and call it done.

However, what the reason for this different behavior triggered by that
change in the *-u-boot.dtsi ? Is this expected?

>From a quick check multiple place in the code just disable/enable nodes
or set properties without taking care of this, are those going to be
affected by that commit that created the regression? Are those all
buggy?

$ git grep fdt_setprop |wc -l
461

We have some helper around, for example
arch/arm/mach-imx/imx8/fdt.c:disable_fdt_node(), but this is for example
just specific on that file.

Simon: any suggestion?

Thanks,
Francesco