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.
