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

[Marek Vasut]

On 11/13/25 11:46 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.