Re: [BUG] silent hangup when debugging lib/fdtdec.c

[alexander.feilke@ew.tq-group.com]

On Wednesday, November 26, 2025 15:56 CET, Tom Rini <trini at konsulko.com> wrote:
> On Wed, Nov 26, 2025 at 11:41:14AM +0100, alexander.feilke at ew.tq-group.com wrote:
> > On Tuesday, November 25, 2025 17:35 CET, Tom Rini <trini at konsulko.com> wrote:
> > 
> > > On Tue, Nov 25, 2025 at 05:14:12PM +0100, Alexander Feilke wrote:
> > > 
> > > > From: Alexander Feilke <alexander.feilke at ew.tq-group.com>
> > > > 
> > > > 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.