On Mon, Jan 12, 2026 at 10:56:04PM +0100, Marek Vasut wrote: > On 1/12/26 5:48 PM, Tom Rini wrote: > > On Mon, Jan 12, 2026 at 06:38:19PM +0530, Anshul Dalal wrote: > > > On Mon Jan 12, 2026 at 3:41 PM IST, Beleswar Padhi wrote: > > > > The OMAP2 SPL linker script (also used for K3 platforms) currently uses > > > > a 4-byte alignment directive after the __u_boot_list section. This > > > > alignment directive only advances the location counter without padding > > > > the actual binary output. > > > > > > > > When objcopy extracts u-boot-spl-nodtb.bin, it includes only actual > > > > data, stopping at the last byte of __u_boot_list (e.g., 0x41c359fc), > > > > not an aligned address (e.g., 0x41c35a00). So, when the FIT image > > > > containing device trees is concatenated to the SPL binary, it gets > > > > appended at this unaligned file size, causing libfdt validation failure. > > > > > > > > To fix this, move the alignment directive into the __u_boot_list section > > > > itself and make it 8-byte aligned as per DT spec. This forces the linker > > > > to include padding as part of the section data, ensuring objcopy > > > > includes the padding bytes in the binary and the appended FIT image > > > > starts at an 8-byte aligned boundary. > > > > > > > > Reported-by: Anshul Dalal <[email protected]> > > > > Closes: https://lore.kernel.org/u-boot/[email protected] > > > > Fixes: 0535e46d55d7 ("scripts/dtc: Update to upstream version > > > > v1.7.2-35-g52f07dcca47c") > > > > Signed-off-by: Beleswar Padhi <[email protected]> > > > > --- > > > > v2: Changelog: > > > > 1. Get rid of extra ALIGN() directive, replace it with a comment > > > > 2. Carry Reported-by, Closes and Fixes tag. > > > > > > > > Link to v1: > > > > https://lore.kernel.org/all/[email protected]/ > > > > > > > > arch/arm/mach-omap2/u-boot-spl.lds | 6 +++++- > > > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/arch/arm/mach-omap2/u-boot-spl.lds > > > > b/arch/arm/mach-omap2/u-boot-spl.lds > > > > index 3bb759d8a1c..5ad169a37b7 100644 > > > > --- a/arch/arm/mach-omap2/u-boot-spl.lds > > > > +++ b/arch/arm/mach-omap2/u-boot-spl.lds > > > > @@ -35,9 +35,13 @@ SECTIONS > > > > . = ALIGN(4); > > > > __u_boot_list : { > > > > KEEP(*(SORT(__u_boot_list*))); > > > > + /* > > > > + * Ensure 8-byte alignment at the end of the last > > > > section before > > > > + * DTB is appended, to satisfy DT spec alignment > > > > requirements > > > > + */ > > > > + . = ALIGN(8); > > > > > > I wonder if there could be a better way to handle this constraint, > > > currently we have two major problems with this approach: > > > > > > 1. All platforms facing similar alignment issues would have to modify > > > their linker scripts. > > > > Yes, agreed. > > > > > 2. The FDT only gets appended directly to SPL binary in cases of > > > CONFIG_SPL_SEPARATE_BSS. Otherwise we do (SPL binary + BSS + FDT) as per > > > the $(obj)/$(SPL_BIN)-dtb.bin make target. Which means BSS would have to > > > be 8-byte aligned as well as the SPL binary. > > > > > > I wonder if we could have a new make target for say > > > u-boot-spl-nodtb-aligned.bin which is just (SPL binary + optionally BSS > > > + padding for alignment) and at runtime we modify the fdt addr in gd to > > > point to the correctly aligned address? > > > > Looking back at > > https://lore.kernel.org/all/[email protected]/ we > > can use dd as a portable way to ensure that a file ends with 8-byte > > alignmnent by doing: > > dd if=testfile bs=8 conv=sync of=testfile_pad > > and we get a zero-padded 8-byte aligned output file, and at the end of > > that we can concatenate our dtb. > You still need to make sure there is a symbol generated by the linker that > points at the END of the u-boot binary . dd happens too late, so you cannot > do that. The alignment has to be done by the linker, in the linker script I > think.
I guess the question is are we: a) Look at $sym for device tree, and so $sym must be 8-byte aligned. b) Look at end of self, rounded up to alignment, for device tree c) (a) on some platforms (b) on other platforms ? -- Tom
signature.asc
Description: PGP signature
