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? -- Tom
signature.asc
Description: PGP signature
