[PATCH] boot: image-fit.c: check target, not source, for 8-byte alignment when loading FDT

[Rasmus Villemoes]

A number of our boards no longer boot with v2026.04, ironically as a
result of the effort to ensure 8-byte alignment of the dtb passed to
the kernel and getting rid of the fdt_high=0xffffffff.

The problem exists when the FIT image does specify a (properly
aligned) load address to use for the fdt. For example, we have

	fdt-am335x-boneblack.dtb {
		description = "Flattened Device Tree blob";
		data = /incbin/(...);
		...
		load = <0x88000000>;
	}

Now, with v2026.04 and depending on just exactly where that data ends
up, in a good case we see

     Loading fdt from 0x8a8c6e10 to 0x88000000
     Booting using the fdt blob at 0x88000000
  Working FDT set to 88000000
     Loading Kernel Image to 86008000
  WARNING:
  The 'fdt_high' environment variable is set to ~0. This is known to cause
  boot failures due to placement of DT at non-8-byte-aligned addresses.
  This system will likely fail to boot. Unset the 'fdt_high' environment
  variable and submit a fix upstream.
     Using Device Tree in place at 88000000, end 8801af2f
  Working FDT set to 88000000
  Starting kernel ...
  [    0.000000] Booting Linux on physical CPU 0x0

and the board boots (though with that ominous warning). However,
modifying the .its file a little, e.g. just removing the word "blob"
from the description, we end up with

     Loading fdt from 0x8a8c6e14 to 0x88000000
     Booting using the fdt blob at 0x9df94718
  Working FDT set to 9df94718
     Loading Kernel Image to 86008000
  WARNING:
  The 'fdt_high' environment variable is set to ~0. This is known to cause
  boot failures due to placement of DT at non-8-byte-aligned addresses.
  This system will likely fail to boot. Unset the 'fdt_high' environment
  variable and submit a fix upstream.
  Failed to reserve memory for fdt at 0x9df94718
  FDT creation failed!
  resetting ...

Notice how the "Loading fdt from" line still claims to load the fdt to
that 0x88000000 address, but since this "else if" clause looks at the
source address (buf) and comes before the "else if (load != data)"
clause, we end up doing the "allocate another buffer to use as target"
instead of actually copying to 0x88000000, but then the "fdt_high=~0"
logic in boot_relocate_fdt() obviously fails to do an lmb-reservation
of that area, and the boot fails.

When there's no load= property in the fdt node, this should not change
anything. But when there is, it is the alignment of that target which
is relevant, not the alignment of the fdt blob within the FIT
image. With this patch applied, we instead get the expected

     Loading fdt from 0x8a8c6e14 to 0x88000000
     Booting using the fdt blob at 0x88000000
  Working FDT set to 88000000
     Loading Kernel Image to 86008000
  WARNING:
  The 'fdt_high' environment variable is set to ~0. This is known to cause
  boot failures due to placement of DT at non-8-byte-aligned addresses.
  This system will likely fail to boot. Unset the 'fdt_high' environment
  variable and submit a fix upstream.
     Using Device Tree in place at 88000000, end 8801af2f
  Working FDT set to 88000000

  Starting kernel ...

Signed-off-by: Rasmus Villemoes <ravi at prevas.dk>
---

Note: We will change our boot flow and get rid of fdt_high=~0, if
nothing else then to get rid of the warning, even though it feels
slightly exaggerated given that we have in fact taken the 8-byte
alignment requirement into consideration in setting that load=
property. But this still seems like something that should be applied.

 boot/image-fit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/boot/image-fit.c b/boot/image-fit.c
index 067ad236081..db64a1ee46d 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -2311,7 +2311,7 @@ int fit_image_load(struct bootm_headers *images, ulong addr,
 		}
 		len = load_end - load;
 	} else if (load_op != FIT_LOAD_IGNORED && image_type == IH_TYPE_FLATDT &&
-		   ((uintptr_t)buf & 7)) {
+		   (load & 7)) {
 		loadbuf = aligned_alloc(8, len);
 		load = map_to_sysmem(loadbuf);
 		memcpy(loadbuf, buf, len);
-- 
2.53.0