[PATCH] boot: Assure FDT is always at 8-byte aligned address

[Simon Glass]

Hi Marek,

On Mon, 17 Nov 2025 at 19:25, Marek Vasut <marek.vasut at mailbox.org> wrote:
>
> On 11/17/25 6:04 PM, Simon Glass wrote:
>
> Hello Simon,
>
> >>>>> The problem should be fixed higher up, in its callers, etc. For one
> >>>>> thing, the caller knows whether it is a DT or not, so putting this
> >>>>> logic here is messy. See boot_get_fdt_fit()
> >>>>
> >>>> This is triggered by a fitImage with DT embedded in that fitImage as
> >>>> non-external-data. That DT is at 4-byte aligned address, so how can the
> >>>> caller deal with it ? The caller gets a fitImage, which itself is at
> >>>> 8-byte aligned address, but the DT in it is not at 8-byte aligned
> >>>> address, so that DT has to be relocated somehow and that happens here.
> >>>
> >>> OK, but don't put the code in here...see boot_get_fdt_fit(). But even
> >>> then, why does it matter where the FDT is?
> >>
> >> The FDT has to be at 8-byte aligned offset.
> >>
> >>> We are going to use
> >>> fdt_openinto() at some point and put it elsewhere, right, so we can do
> >>> pre-boot fixups?
> >>
> >> Look at the fit load code, cca. 10 lines below, it checks the FDT for
> >> validity using fdt_check_header() . At that point, the FDT must be at
> >> 8-byte aligned address already:
> >>
> >> 2294         } else if (load_op != FIT_LOAD_IGNORED && image_type ==
> >> IH_TYPE_FLATDT &&
> >> 2295                    ((uintptr_t)buf & 7)) {
> >> 2296                 loadbuf = memalign(8, len);
> >> 2297                 load = map_to_sysmem(loadbuf);
> >> 2298                 memcpy(loadbuf, buf, len);
> >>
> >> ...
> >>
> >> 2309         /* verify that image data is a proper FDT blob */
> >> 2310         if (load_op != FIT_LOAD_IGNORED && image_type ==
> >> IH_TYPE_FLATDT &&
> >> 2311             fdt_check_header(loadbuf)) { <----------------- this
> >> 2312                 puts("Subimage data is not a FDT\n");
> >> 2313                 return -ENOEXEC;
> >> 2314         }
> >>
> >>> Perhaps we should deprecate FITs with internal data, too?
> >> We cannot break compatibility and stop supporting old fitImage, so this
> >> is irrelevant here.
> >
> > OK, so please create a function which can detect an FDT header without
> > it being aligned, like the other code you wrote. Then it will be safe
> > to call that here, even if unaligned.
> But we actually do want to detect unaligned broken FDT header and either
> fix it up or stop processing, we don't want to perpetuate handling of
> broken FDTs and pretend that is OK, it shouldn't be I think. Hence this
> fixup.

The decision as to whether something is an FDT is made a lot earlier
than the actual processing of it. For the former there is no need to
allocate and copy. For the latter we need to.

Anyway, you are doing the patches, so do what you think is best. But
please create a function for this, rather than lots of little
hand-crafted checks around the place.

Regards,
Simon