Hi Marek, On Tue, 11 Nov 2025 at 18:17, Marek Vasut <[email protected]> wrote: > > Newer versions of libfdt strictly check whether the FDT blob > passed to them is at 8-byte aligned offset, if it is not, then > the library fails checks with -FDT_ERR_ALIGNMENT . Currently, > android_image_print_dtb_contents() passed FDT directly mapped > from abootimg to libfdt, and this FDT is not always aligned to > 8-byte offset. Specifically, the FDTs are somewhat packed in > the abootimg, therefore if the first FDT blob is e.g. 0xfd bytes > long, then the next FDT blob ends up at 0xfd offset, which is > not 8-byte aligned. > > Fix this by first extracting the header into 8-byte aligned buffer, > checking only the header for validity, and then by copying the > entire FDT into newly allocated 8-byte aligned buffer. While this > is not efficient, it is the correct way to handle DTs, which must > be at 8-byte aligned offsets. Mitigate the inefficiency for the > common case by checking whether the DT might be 8-byte aligned and > if it is, map it directly. > > Signed-off-by: Marek Vasut <[email protected]> > --- > Cc: Aaron Kling <[email protected]> > Cc: Eddie Kovsky <[email protected]> > Cc: George Chan <[email protected]> > Cc: Julien Masson <[email protected]> > Cc: Mattijs Korpershoek <[email protected]> > Cc: Nicolas Belin <[email protected]> > Cc: Sam Day <[email protected]> > Cc: Simon Glass <[email protected]> > Cc: Tom Rini <[email protected]> > Cc: [email protected] > --- > boot/image-android.c | 46 +++++++++++++++++++++++++++++++++----------- > 1 file changed, 35 insertions(+), 11 deletions(-) >
OK, we need to adjust mkimage etc. to handle this. Until then I think we should have a way to disable the 8-byte-alignment check as it seems to have an enormous blast radius :-) Regards, Simon
