public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marek.vasut@mailbox.org>
To: Tom Rini <trini@konsulko.com>, Anshul Dalal <anshuld@ti.com>
Cc: Beleswar Padhi <b-padhi@ti.com>,
	ilias.apalodimas@linaro.org, malysagreg@gmail.com,
	sughosh.ganu@linaro.org, philip.molloy@analog.com,
	marek.vasut+renesas@mailbox.org, james.hilliard1@gmail.com,
	afd@ti.com, nm@ti.com, vigneshr@ti.com, n-francis@ti.com,
	u-kumar1@ti.com, u-boot@lists.denx.de
Subject: Re: [PATCH v2 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB
Date: Mon, 12 Jan 2026 22:56:04 +0100	[thread overview]
Message-ID: <8eb4eeea-a755-4032-ab95-2b293f2d2289@mailbox.org> (raw)
In-Reply-To: <20260112164854.GQ3416603@bill-the-cat>

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 <anshuld@ti.com>
>>> Closes: https://lore.kernel.org/u-boot/DFJ950O0QM0D.380U0N16ZO19E@ti.com
>>> Fixes: 0535e46d55d7 ("scripts/dtc: Update to upstream version v1.7.2-35-g52f07dcca47c")
>>> Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
>>> ---
>>> 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/20260109190026.58464-3-b-padhi@ti.com/
>>>
>>>   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/87h65ihumb.fsf@bloch.sibelius.xs4all.nl/ 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.

  reply	other threads:[~2026-01-12 21:56 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-12 10:11 [PATCH v2 0/2] Fix TI DTB alignment issues with recent libfdt update Beleswar Padhi
2026-01-12 10:11 ` [PATCH v2 1/2] scripts/Makefile.xpl: Align filtered DTB to 8-byte within multidtb.fit Beleswar Padhi
2026-01-12 14:39   ` Marek Vasut
2026-01-12 17:25     ` Padhi, Beleswar
2026-01-12 21:57       ` Marek Vasut
2026-01-12 22:03         ` Tom Rini
2026-01-12 23:53           ` Marek Vasut
2026-01-13 10:25             ` Beleswar Prasad Padhi
2026-01-13 13:27               ` Marek Vasut
2026-01-13 15:00             ` Tom Rini
2026-01-13 16:38               ` Marek Vasut
2026-01-12 10:11 ` [PATCH v2 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB Beleswar Padhi
2026-01-12 13:08   ` Anshul Dalal
2026-01-12 16:48     ` Tom Rini
2026-01-12 21:56       ` Marek Vasut [this message]
2026-01-12 22:05         ` Tom Rini
2026-01-12 23:56           ` Marek Vasut
2026-01-13 15:00             ` Tom Rini
2026-01-13 16:34               ` Marek Vasut
2026-01-14 14:17                 ` Tom Rini
2026-01-15  0:02                   ` Marek Vasut
2026-01-15  8:00                     ` Ilias Apalodimas
2026-01-16  4:52                       ` Anshul Dalal
2026-01-13 19:45               ` Tom Rini
2026-01-12 14:40   ` Marek Vasut
2026-01-12 16:45     ` Tom Rini
2026-01-20 18:08 ` (subset) [PATCH v2 0/2] Fix TI DTB alignment issues with recent libfdt update Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8eb4eeea-a755-4032-ab95-2b293f2d2289@mailbox.org \
    --to=marek.vasut@mailbox.org \
    --cc=afd@ti.com \
    --cc=anshuld@ti.com \
    --cc=b-padhi@ti.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=james.hilliard1@gmail.com \
    --cc=malysagreg@gmail.com \
    --cc=marek.vasut+renesas@mailbox.org \
    --cc=n-francis@ti.com \
    --cc=nm@ti.com \
    --cc=philip.molloy@analog.com \
    --cc=sughosh.ganu@linaro.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=u-kumar1@ti.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox