[PATCH] boot: Warn users about fdt_high=~0 usage

[Tom Rini]

On Sat, Nov 15, 2025 at 06:34:24PM +0100, Marek Vasut wrote:
> On 11/13/25 4:49 PM, Tom Rini wrote:
> 
> Hello Tom,
> 
> > > diff --git a/boot/image-fdt.c b/boot/image-fdt.c
> > > index 3f0ac54f76f..e88525a3846 100644
> > > --- a/boot/image-fdt.c
> > > +++ b/boot/image-fdt.c
> > > @@ -189,6 +189,10 @@ int boot_relocate_fdt(char **of_flat_tree, ulong *of_size)
> > >   			/* All ones means use fdt in place */
> > >   			of_start = fdt_blob;
> > >   			addr = map_to_sysmem(fdt_blob);
> > > +			if (addr & 7) {
> > > +				printf("WARNING: The 'fdt_high' environment variable is set to ~0 and DT is at non-8-byte aligned address.\nWARNING: This system will likely fail to boot. Unset 'fdt_high' environment variable and submit fix upstream.\n");
> > > +			}
> > > +
> > >   			err = lmb_alloc_mem(LMB_MEM_ALLOC_ADDR, 0, &addr,
> > >   					    of_len, LMB_NONE);
> > >   			if (err) {
> > 
> > I think we need to yell about it sooner.
> 
> I don't think so, for two reasons:
> 
> - If the user uses e.g. bootz to boot their kernel, which on arm32 is still
> sadly happening, they wouldn't trigger this problem at all and they wouldn't
> care about whichever way their fdt_high is set.

Which part of the problem? If the dtb is not 8-byte aligned the kernel
will fail. All the accessors require 8 byte alignment.

> - If the user sets 'fdt_high' as part of their boot command, they would not
> get any warning print if we warn earlier, but they would get one when they
> boot and trigger this affected code path.
> 
> Maybe we need warnings in two locations ?

Maybe? I was thinking it should be around this in boot/image-fdt.c:
        /* If fdt_high is set use it to select the relocation address */
        fdt_high = env_get("fdt_high");
        if (fdt_high) {
                ulong high_addr = hextoul(fdt_high, NULL);

                if (high_addr == ~0UL) {
                        /* All ones means use fdt in place */


As that's where all of the code paths end up calling, I think. But if
it's multiple paths, yes, multiple warnings if we can't abstract it out
to a common path.

> > Today (and for quite some
> > years) if you pass a 4 byte and not 8 byte aligned DT to Linux, it fails
> > to boot or breaks in loud
> 
> Worse, not loud, but silent.

Also true, yes.

> > and odd ways. This has in turn lead to much
> > time spent and some of our older threads with the libfdt folks years
> > ago. So I think we need something earlier in code where we're seeing
> > that fdt_high is set to ~0 and that's where we say "Stop doing this, it
> > will be removed soon".
> 
> We cannot remove this functionality, someone might actually depend on it for
> whatever reason. It is part of the command line ABI now.

The valid use case is boot time optimization. It's also a
micro-optimization (as actually megabyte sized device trees like when
people wanted to pass FPGA bitstreams in 15+ years ago are not allowed)
I think really. I am loath to break ABI like this but I'm not entirely
sure we have a choice. Maybe we detect disabled relocation and
misaligned device tree and fall back to prompt? Or if it's too late,
panic with an explanation? Or maybe we just move it 4 bytes higher. The
device is in a going to fail state anyhow, so trying to recover it might
be OK, and since the device tree needs to be modified by us it has to be
in writable memory.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20251116/2d281426/attachment.sig>