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