[PATCH 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB
Padhi, Beleswar
b-padhi at ti.com
Fri Jan 9 20:21:39 CET 2026
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 <b-padhi at ti.com>
>> ---
>> 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!
Thanks,
Beleswar
More information about the U-Boot
mailing list