On Wednesday, November 26, 2025 15:56 CET, Tom Rini <[email protected]> wrote: > On Wed, Nov 26, 2025 at 11:41:14AM +0100, [email protected] > wrote: > > On Tuesday, November 25, 2025 17:35 CET, Tom Rini <[email protected]> > > wrote: > > > > > On Tue, Nov 25, 2025 at 05:14:12PM +0100, Alexander Feilke wrote: > > > > > > > From: Alexander Feilke <[email protected]> > > > > > > > > Description: U-Boot hangs silently during boot when enabling DEBUG in > > > > lib/fdtdec.c > > > > > > > > Not sure if its really a bug or rather a configuration issue on my side. > > > > > > > > Minimal steps to reproduce: <see patch> > > > > > > > > The hang is caused by `panic("FDT overlap");` later inside the if block. > > > > (see `lib/fdtdec.c:1279` in `fdt_find_separate(void)`) > > > > > > > > Additionally, no boot log can be seen because serial is initialized > > > > after > > > > loading the devicetree in this boot stage (see `common/board_r.c:665` in > > > > `initcall_run_r(void)`) > > > > > > > > Tested on i.MX6 with configs for tqma6d_mba6 and other tq boards that > > > > aren't, > > > > mainlined yet (tqma6ulx_mba6ul and tqma7d_mba7). > > > > > > > > Any idea what to look for to fix this on our side? > > > > > > > > Thanks in advance, > > > > Alexander > > > > > > For very early failures you might need to look at enabling DEBUG_UART > > > which wires in a more direct "just write this to serial port". > > > > > > -- > > > Tom > > > > Thanks for pointing that out. The debug log shows that the global data is > > still located in the SRAM after relocation. > > Printing all variables involved in the panic condition shows, that the stack > > pointer also overflowed, so there appear to be two separate issues. > > > > if (top > (void *)gd || top > (void *)&stack_ptr) { > > > > including top, sp and sys_init_sp_addr for completeness: > > > > <debug_uart> > > FDT 8789d3a0 gd 0091de40 > > top 878a7aa8 sp 878543e7 > > sys_init_sp_addr 0091ff20 > > FDT overlap > > resetting ... > > System reset not supported on this platform > > ### ERROR ### Please RESET the board ### > > > > > > Note: I don't use CUSTOM_SYS_INIT_SP_ADDR so the default is used. > > GENERATED_GBL_DATA_SIZE is 0xe0 > > > > #define SYS_INIT_SP_ADDR (CFG_SYS_INIT_RAM_ADDR + CFG_SYS_INIT_RAM_SIZE > > - GENERATED_GBL_DATA_SIZE) > > #define CFG_SYS_INIT_RAM_ADDR IRAM_BASE_ADDR > > #define CFG_SYS_INIT_RAM_SIZE IRAM_SIZE > > > > Do you have any idea how to address these two problems? > > Are there similar configs upstream? I know that imx6 is not generally > broken, I boot my mx6cuboxi on current next (and master recently) and > it's not failing like that, for example. Also, adding in one of the imx > custodians.. > > -- > Tom
I can reproduce this with a build from master with our upstream tqma6q_mba6_mmc_defconfig, after integrating debug uart: <debug_uart> FDT 4fc78990 gd 0093de20 top 4fc836c0 sp 4fc00000 sys_init_sp_addr 0093ff10 gbl_data_size 000000f0 FDT overlap resetting ... I also have a mx7dsabresd but I cannot bring it to boot with a master build unfortunately.
