On Tue, Jan 13, 2026 at 09:00:24AM -0600, Tom Rini wrote: > 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 > ?
Now that I've got a target where this issue is cropping up, and I can easily iterate on testing things, I *think* I was going in the wrong direction with dd. My inclination right now is to take (very soon) Beleswar's patch since they figured out the hard part on how to get the linker to do what we want and follow-up with my own commit cleaning up the other 12 linker files or so that seem to need a similar change. -- Tom
signature.asc
Description: PGP signature
