On Tue, Jan 13, 2026 at 12:56:23AM +0100, Marek Vasut wrote: > On 1/12/26 11:05 PM, Tom Rini wrote: > > 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 > > ? > $sym is at the end, which is not always 8 byte aligned . See lib/fdtdec.c > for the relevant code: > > 1243 static void *fdt_find_separate(void) > 1244 { > 1245 void *fdt_blob = NULL; > 1246 > 1247 if (IS_ENABLED(CONFIG_SANDBOX)) > 1248 return NULL; > 1249 > 1250 #ifdef CONFIG_XPL_BUILD > 1251 /* FDT is at end of BSS unless it is in a different memory > region */ > 1252 if (CONFIG_IS_ENABLED(SEPARATE_BSS)) > 1253 fdt_blob = (ulong *)_image_binary_end; > 1254 else > 1255 fdt_blob = (ulong *)__bss_end;
OK. And why can't we make that check at $sym rounded up, and ensure our build targets pad? Going back to the commit message here, it's easy to tell the linker to place $sym at the right spot, but it's hard to make sure the output is padded. So having typed all that, maybe we need to do: d) Update linker scripts to ALIGN(8) the above symbols and have the make targets use dd to ensure padding prior to concatenation ? -- Tom
signature.asc
Description: PGP signature
