On Sat, Jan 10, 2026 at 12:51:39AM +0530, Padhi, Beleswar wrote: > Hi Tom, > > On 1/10/2026 12:40 AM, Tom Rini wrote: > > On Sat, Jan 10, 2026 at 12:30:26AM +0530, Beleswar Padhi wrote: > > > > > The OMAP2 SPL linker script (also used for K3 platforms) currently uses > > > 4-byte alignment after the __u_boot_list section. Change this to 8-byte > > > alignment to meet the device tree specification requirement for DTB > > > alignment. > > > > > > However, 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 the aligned address (e.g., > > > 0x41c35a00). When the FIT image containing device trees is concatenated > > > to the above SPL binary, it gets appended at the unaligned file size, > > > causing libfdt validation failure. > > > > > > To fix this, add an alignment directive inside the __u_boot_list section > > > itself. 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. > > > > > > Signed-off-by: Beleswar Padhi <[email protected]> > > > --- > > > arch/arm/mach-omap2/u-boot-spl.lds | 3 ++- > > > 1 file changed, 2 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..081323e6599 100644 > > > --- a/arch/arm/mach-omap2/u-boot-spl.lds > > > +++ b/arch/arm/mach-omap2/u-boot-spl.lds > > > @@ -35,9 +35,10 @@ SECTIONS > > > . = ALIGN(4); > > > __u_boot_list : { > > > KEEP(*(SORT(__u_boot_list*))); > > > + . = ALIGN(8); > > > } >.sram > > > - . = ALIGN(4); > > > + . = ALIGN(8); > > > __image_copy_end = .; > > > _end = .; > > > _image_binary_end = .; > > Do we need both of these? Shouldn't we just need the one inside the sram > > section with a comment that this ensures the end of the SRAM portion is > > 8-byte aligned? > > > Yes, we need only the first directive. But second one is just defensive > programming, if someday someone changes the memory layout, this just hints > that __image_copy_end should always be 8-byte aligned... Doesn't hurt to > have > it? Let me know what you think!
I think a comment is better defensive programming than extra ALIGN statements. And with this discovery, we should also I think audit the rest of the linker scripts with a ". = ALIGN(4)" to see if they're likely in similar spots. -- Tom
signature.asc
Description: PGP signature
