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@30800000/usb@30b20000"); return fdt_status_disabled(rw_fdt_blob, offset); } return 0; } For what is worth in this node "/soc/bus@30800000/usb@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