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.
