[PATCH v2 0/2] Fix TI DTB alignment issues with recent libfdt update

[PATCH v2 0/2] Fix TI DTB alignment issues with recent libfdt update

[Beleswar Padhi]

Recent libfdt updates (commit 0535e46d55d7 "scripts/dtc: Update to
upstream version v1.7.2-35-g52f07dcca47c") enforce strict 8-byte
alignment for device tree blobs, as required by the device tree
specification. This causes failures on platforms using
CONFIG_SPL_MULTI_DTB_FIT, where DTBs were not properly aligned.

The alignment issue occurs at two levels:

1. DTBs embedded within the multidtb.fit FIT image may not be 8-byte
   aligned, even though the FIT image itself starts at an aligned
   address. This causes -FDT_ERR_ALIGNMENT failures when
   setup_multi_dtb_fit() tries to locate and use these DTBs.

2. The FIT image is concatenated to u-boot-spl-nodtb.bin at a boundary
   determined by the OMAP2 linker script. Currently, the linker only
   advances the location counter for alignment without padding the
   binary, causing the FIT image to be appended an unaligned offset.

This series addresses both issues:

Patch 1 adds the -B 0x8 flag to mkimage, ensuring all DTB entries
within the FIT image are 8-byte aligned.

Patch 2 fixes the linker script to include padding in the binary
by placing an alignment directive inside the __u_boot_list section,
ensuring the FIT image is appended at an 8-byte aligned boundary.

v2: Changelog:
1. Remove extra ALIGN() directive, add a comment instead.
2. Add R/B, Reported-by and Fixes: tags.

Link to v1:
https://lore.kernel.org/all/20260109190026.58464-1-b-padhi@ti.com/

Testing done:
1. Boot tested on all TI K3 platforms.

Beleswar Padhi (2):
  scripts/Makefile.xpl: Align filtered DTB to 8-byte within multidtb.fit
  ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB

 arch/arm/mach-omap2/u-boot-spl.lds | 6 +++++-
 scripts/Makefile.xpl               | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

-- 
2.34.1

[PATCH v2 1/2] scripts/Makefile.xpl: Align filtered DTB to 8-byte within multidtb.fit

[Beleswar Padhi]

When CONFIG_SPL_MULTI_DTB_FIT is enabled, multiple device trees are
packed inside the multidtb.fit FIT image. While the individual DTBs
and the FIT image start address are 8-byte aligned, the DTBs embedded
within the FIT image are not guaranteed to maintain 8-byte alignment.

This misalignment causes -FDT_ERR_ALIGNMENT failure in
setup_multi_dtb_fit() when locating the next available DTB within the
FIT blob and setting gd->fdt_blob, because of the recent libfdt
hardening since commit 0535e46d55d7 ("scripts/dtc: Update to upstream
version v1.7.2-35-g52f07dcca47c")

Add the -B 0x8 flag to mkimage to enforce 8-byte alignment for all DTB
entries within the multidtb FIT image.

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>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Anshul Dalal <anshuld@ti.com>
---
v2: Changelog:
1. Carry R/B, Reported-by, Closes and Fixes tag.

Link to v1:
https://lore.kernel.org/all/20260109190026.58464-2-b-padhi@ti.com/

 scripts/Makefile.xpl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/Makefile.xpl b/scripts/Makefile.xpl
index 5e65d7b2498..1183f5180ba 100644
--- a/scripts/Makefile.xpl
+++ b/scripts/Makefile.xpl
@@ -602,7 +602,7 @@ $(SHRUNK_ARCH_DTB): $$(patsubst $(obj)/dts/%, $(dt_dir)/%, $$@) $(dir $(SHRUNK_A
 targets += $(SPL_OF_LIST_TARGETS)
 
 MKIMAGEFLAGS_$(SPL_BIN).multidtb.fit = -f auto -A $(ARCH) -T firmware -C none -O u-boot \
-	-n "Multi DTB fit image for $(SPL_BIN)" -E \
+	-n "Multi DTB fit image for $(SPL_BIN)" -B 0x8 -E \
 	$(patsubst %,-b %,$(SHRUNK_ARCH_DTB))
 
 $(obj)/$(SPL_BIN).multidtb.fit: /dev/null $(SHRUNK_ARCH_DTB) FORCE
-- 
2.34.1

Re: [PATCH v2 1/2] scripts/Makefile.xpl: Align filtered DTB to 8-byte within multidtb.fit

[Marek Vasut]

On 1/12/26 11:11 AM, Beleswar Padhi wrote:
> When CONFIG_SPL_MULTI_DTB_FIT is enabled, multiple device trees are
> packed inside the multidtb.fit FIT image. While the individual DTBs
> and the FIT image start address are 8-byte aligned, the DTBs embedded
> within the FIT image are not guaranteed to maintain 8-byte alignment.

Because DT properties are 4-byte aligned, and fitImage is a DT with long 
binary strings encoded in them. But that is not the case here, because 
the invocation does use mkimage -E .

Therefore I see two issues:
- Should the code which handles LEGACY fitImages with 4-byte alignment 
be fixed to relocate the blobs ? I think yes.
- Should mkimage -E align blobs to 8 bytes by default ? I think yes, and 
frankly, I thought it does so already, but apparently not.

Re: [PATCH v2 1/2] scripts/Makefile.xpl: Align filtered DTB to 8-byte within multidtb.fit

[Padhi, Beleswar]

On 1/12/2026 8:09 PM, Marek Vasut wrote:
> On 1/12/26 11:11 AM, Beleswar Padhi wrote:
>> When CONFIG_SPL_MULTI_DTB_FIT is enabled, multiple device trees are
>> packed inside the multidtb.fit FIT image. While the individual DTBs
>> and the FIT image start address are 8-byte aligned, the DTBs embedded
>> within the FIT image are not guaranteed to maintain 8-byte alignment.
>
> Because DT properties are 4-byte aligned, and fitImage is a DT with 
> long binary strings encoded in them. But that is not the case here, 
> because the invocation does use mkimage -E .
>
> Therefore I see two issues:
> - Should the code which handles LEGACY fitImages with 4-byte alignment 
> be fixed to relocate the blobs ? I think yes.


This we can fix in the Makefile via the dd command as suggested by Tom.

> - Should mkimage -E align blobs to 8 bytes by default ? I think yes, 
> and frankly, I thought it does so already, but apparently not.


This can be done, but should it be? Not all FITs demand an 8-byte
alignment right? It is only the FDT which requires this.

Re: [PATCH v2 1/2] scripts/Makefile.xpl: Align filtered DTB to 8-byte within multidtb.fit

[Marek Vasut]

On 1/12/26 6:25 PM, Padhi, Beleswar wrote:
> 
> On 1/12/2026 8:09 PM, Marek Vasut wrote:
>> On 1/12/26 11:11 AM, Beleswar Padhi wrote:
>>> When CONFIG_SPL_MULTI_DTB_FIT is enabled, multiple device trees are
>>> packed inside the multidtb.fit FIT image. While the individual DTBs
>>> and the FIT image start address are 8-byte aligned, the DTBs embedded
>>> within the FIT image are not guaranteed to maintain 8-byte alignment.
>>
>> Because DT properties are 4-byte aligned, and fitImage is a DT with 
>> long binary strings encoded in them. But that is not the case here, 
>> because the invocation does use mkimage -E .
>>
>> Therefore I see two issues:
>> - Should the code which handles LEGACY fitImages with 4-byte alignment 
>> be fixed to relocate the blobs ? I think yes.
> 
> 
> This we can fix in the Makefile via the dd command as suggested by Tom.

My concern is about LEGACY fitImages (means already generated ones), not 
newly generated ones.

>> - Should mkimage -E align blobs to 8 bytes by default ? I think yes, 
>> and frankly, I thought it does so already, but apparently not.
> 
> 
> This can be done, but should it be? Not all FITs demand an 8-byte
> alignment right? It is only the FDT which requires this.
Maybe if image type is flat_dt, it should be implicitly 8-byte aligned 
then ?

Re: [PATCH v2 1/2] scripts/Makefile.xpl: Align filtered DTB to 8-byte within multidtb.fit

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]

On Mon, Jan 12, 2026 at 10:57:46PM +0100, Marek Vasut wrote:
> On 1/12/26 6:25 PM, Padhi, Beleswar wrote:
> > 
> > On 1/12/2026 8:09 PM, Marek Vasut wrote:
> > > On 1/12/26 11:11 AM, Beleswar Padhi wrote:
> > > > When CONFIG_SPL_MULTI_DTB_FIT is enabled, multiple device trees are
> > > > packed inside the multidtb.fit FIT image. While the individual DTBs
> > > > and the FIT image start address are 8-byte aligned, the DTBs embedded
> > > > within the FIT image are not guaranteed to maintain 8-byte alignment.
> > > 
> > > Because DT properties are 4-byte aligned, and fitImage is a DT with
> > > long binary strings encoded in them. But that is not the case here,
> > > because the invocation does use mkimage -E .
> > > 
> > > Therefore I see two issues:
> > > - Should the code which handles LEGACY fitImages with 4-byte
> > > alignment be fixed to relocate the blobs ? I think yes.
> > 
> > 
> > This we can fix in the Makefile via the dd command as suggested by Tom.
> 
> My concern is about LEGACY fitImages (means already generated ones), not
> newly generated ones.

Why is that a concern? If it's a legacy fitImage for the OS, we relocate
the device tree already normally to be aligned. If it's a legacy
fitImage of U-Boot, it's an old U-Boot?

> > > - Should mkimage -E align blobs to 8 bytes by default ? I think yes,
> > > and frankly, I thought it does so already, but apparently not.
> > 
> > 
> > This can be done, but should it be? Not all FITs demand an 8-byte
> > alignment right? It is only the FDT which requires this.
> Maybe if image type is flat_dt, it should be implicitly 8-byte aligned then
> ?

Well, the device tree spec says 8-byte alignment. It's not "FDT for OS"
that's 8-byte, it's any device tree should start out 8 byte aligned, and
everything else should then be naturally aligned. If we're looking in a
device tree for another device tree to use in place and not relocate
then that second tree must be aligned.

Or am I missing something?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 1/2] scripts/Makefile.xpl: Align filtered DTB to 8-byte within multidtb.fit

[Marek Vasut]

On 1/12/26 11:03 PM, Tom Rini wrote:

>>> This we can fix in the Makefile via the dd command as suggested by Tom.
>>
>> My concern is about LEGACY fitImages (means already generated ones), not
>> newly generated ones.
> 
> Why is that a concern? If it's a legacy fitImage for the OS, we relocate
> the device tree already normally to be aligned. If it's a legacy
> fitImage of U-Boot, it's an old U-Boot?

Not necessarily, it could be new U-Boot using old fitImage, for whatever 
reason (falcon boot maybe ?). We should not break that.

>>>> - Should mkimage -E align blobs to 8 bytes by default ? I think yes,
>>>> and frankly, I thought it does so already, but apparently not.
>>>
>>>
>>> This can be done, but should it be? Not all FITs demand an 8-byte
>>> alignment right? It is only the FDT which requires this.
>> Maybe if image type is flat_dt, it should be implicitly 8-byte aligned then
>> ?
> 
> Well, the device tree spec says 8-byte alignment.

8 byte alignment of what, start of DT, right ?

> It's not "FDT for OS"
> that's 8-byte, it's any device tree should start out 8 byte aligned, and
> everything else should then be naturally aligned. If we're looking in a
> device tree for another device tree to use in place and not relocate
> then that second tree must be aligned.
> 
> Or am I missing something?
The discussion is about mkimage -E which generates DTs for U-Boot SPL 
use. The DTs in those external data should likely be aligned to 8 bytes 
by default, i.e. implicitly set -B 8 (they don't seem to be right now).

Re: [PATCH v2 1/2] scripts/Makefile.xpl: Align filtered DTB to 8-byte within multidtb.fit

[Beleswar Prasad Padhi]

On 13/01/26 05:23, Marek Vasut wrote:
> On 1/12/26 11:03 PM, Tom Rini wrote:
>
>>>> This we can fix in the Makefile via the dd command as suggested by Tom.
>>>
>>> My concern is about LEGACY fitImages (means already generated ones), not
>>> newly generated ones.
>>
>> Why is that a concern? If it's a legacy fitImage for the OS, we relocate
>> the device tree already normally to be aligned. If it's a legacy
>> fitImage of U-Boot, it's an old U-Boot?
>
> Not necessarily, it could be new U-Boot using old fitImage, for whatever reason (falcon boot maybe ?). We should not break that.
>
>>>>> - Should mkimage -E align blobs to 8 bytes by default ? I think yes,
>>>>> and frankly, I thought it does so already, but apparently not.
>>>>
>>>>
>>>> This can be done, but should it be? Not all FITs demand an 8-byte
>>>> alignment right? It is only the FDT which requires this.
>>> Maybe if image type is flat_dt, it should be implicitly 8-byte aligned then
>>> ?
>>
>> Well, the device tree spec says 8-byte alignment.
>
> 8 byte alignment of what, start of DT, right ?


Yeah from start... In this case, the FDT for OS is aligned, but the sub DT
from the FIT is not aligned by 8-bytes.

>
>> It's not "FDT for OS"
>> that's 8-byte, it's any device tree should start out 8 byte aligned, and
>> everything else should then be naturally aligned. If we're looking in a
>> device tree for another device tree to use in place and not relocate
>> then that second tree must be aligned.
>>
>> Or am I missing something?
> The discussion is about mkimage -E which generates DTs for U-Boot SPL use. The DTs in those external data should likely be aligned to 8 bytes by default, i.e. implicitly set -B 8 (they don't seem to be right now).

Instead of -E, we can use '-b' which always takes DT and make sure that is 8-byte aligned by default:

Usage: mkimage [-D dtc_options] [-f fit-image.its|-f auto|-f auto-conf|-F] [-b <dtb> [-b <dtb>]] [-E] [-B size] [-i <ramdisk.cpio.gz>] fit-image
-b => append the device tree binary to the FIT

Thanks,
Beleswar

Re: [PATCH v2 1/2] scripts/Makefile.xpl: Align filtered DTB to 8-byte within multidtb.fit

[Marek Vasut]

On 1/13/26 11:25 AM, Beleswar Prasad Padhi wrote:

>>>>>> - Should mkimage -E align blobs to 8 bytes by default ? I think yes,
>>>>>> and frankly, I thought it does so already, but apparently not.
>>>>>
>>>>>
>>>>> This can be done, but should it be? Not all FITs demand an 8-byte
>>>>> alignment right? It is only the FDT which requires this.
>>>> Maybe if image type is flat_dt, it should be implicitly 8-byte aligned then
>>>> ?
>>>
>>> Well, the device tree spec says 8-byte alignment.
>>
>> 8 byte alignment of what, start of DT, right ?
> 
> 
> Yeah from start... In this case, the FDT for OS is aligned, but the sub DT
> from the FIT is not aligned by 8-bytes.

For mkimage -E (fit with trailing external data) , enforcing that 
alignment should be easily doable.

>>> It's not "FDT for OS"
>>> that's 8-byte, it's any device tree should start out 8 byte aligned, and
>>> everything else should then be naturally aligned. If we're looking in a
>>> device tree for another device tree to use in place and not relocate
>>> then that second tree must be aligned.
>>>
>>> Or am I missing something?
>> The discussion is about mkimage -E which generates DTs for U-Boot SPL use. The DTs in those external data should likely be aligned to 8 bytes by default, i.e. implicitly set -B 8 (they don't seem to be right now).
> 
> Instead of -E, we can use '-b' which always takes DT and make sure that is 8-byte aligned by default:
> 
> Usage: mkimage [-D dtc_options] [-f fit-image.its|-f auto|-f auto-conf|-F] [-b <dtb> [-b <dtb>]] [-E] [-B size] [-i <ramdisk.cpio.gz>] fit-image
> -b => append the device tree binary to the FIT

The type flat_dt should likely always be implicitly aligned at minimum 
to 8 bytes , without -b or -B or -whatever flags.

-- 
Best regards,
Marek Vasut

Re: [PATCH v2 1/2] scripts/Makefile.xpl: Align filtered DTB to 8-byte within multidtb.fit

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]

On Tue, Jan 13, 2026 at 12:53:39AM +0100, Marek Vasut wrote:
> On 1/12/26 11:03 PM, Tom Rini wrote:
> 
> > > > This we can fix in the Makefile via the dd command as suggested by Tom.
> > > 
> > > My concern is about LEGACY fitImages (means already generated ones), not
> > > newly generated ones.
> > 
> > Why is that a concern? If it's a legacy fitImage for the OS, we relocate
> > the device tree already normally to be aligned. If it's a legacy
> > fitImage of U-Boot, it's an old U-Boot?
> 
> Not necessarily, it could be new U-Boot using old fitImage, for whatever
> reason (falcon boot maybe ?). We should not break that.

If it's falcon boot then it's the OS case and we relocate it before
passing on, that's not changed. That's why I'm saying I'm not sure
there's a legacy case to worry about, since the big change now is that
U-Boot also demands correctly aligned device trees. The Linux Kernel
essentially always has, and other OSes probably as well. We were just
bad and let 4-byte work for so long.

> > > > > - Should mkimage -E align blobs to 8 bytes by default ? I think yes,
> > > > > and frankly, I thought it does so already, but apparently not.
> > > > 
> > > > 
> > > > This can be done, but should it be? Not all FITs demand an 8-byte
> > > > alignment right? It is only the FDT which requires this.
> > > Maybe if image type is flat_dt, it should be implicitly 8-byte aligned then
> > > ?
> > 
> > Well, the device tree spec says 8-byte alignment.
> 
> 8 byte alignment of what, start of DT, right ?
> 
> > It's not "FDT for OS"
> > that's 8-byte, it's any device tree should start out 8 byte aligned, and
> > everything else should then be naturally aligned. If we're looking in a
> > device tree for another device tree to use in place and not relocate
> > then that second tree must be aligned.
> > 
> > Or am I missing something?
> The discussion is about mkimage -E which generates DTs for U-Boot SPL use.
> The DTs in those external data should likely be aligned to 8 bytes by
> default, i.e. implicitly set -B 8 (they don't seem to be right now).

Right. So the only legacy case I can see would be using an old mkimage
to generate a current U-Boot image. And I'm not super sure that can
happen, outside of some sort of external to us tooling being wrapped
around things, and at that point we have little control.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 1/2] scripts/Makefile.xpl: Align filtered DTB to 8-byte within multidtb.fit

[Marek Vasut]

On 1/13/26 4:00 PM, Tom Rini wrote:
> On Tue, Jan 13, 2026 at 12:53:39AM +0100, Marek Vasut wrote:
>> On 1/12/26 11:03 PM, Tom Rini wrote:
>>
>>>>> This we can fix in the Makefile via the dd command as suggested by Tom.
>>>>
>>>> My concern is about LEGACY fitImages (means already generated ones), not
>>>> newly generated ones.
>>>
>>> Why is that a concern? If it's a legacy fitImage for the OS, we relocate
>>> the device tree already normally to be aligned. If it's a legacy
>>> fitImage of U-Boot, it's an old U-Boot?
>>
>> Not necessarily, it could be new U-Boot using old fitImage, for whatever
>> reason (falcon boot maybe ?). We should not break that.
> 
> If it's falcon boot then it's the OS case and we relocate it before
> passing on, that's not changed.

Not always, cf the whole fdt_high=-1 bag of issues.

What I would like to see is something like

8fbcc0e0e839 ("boot: Assure FDT is always at 8-byte aligned address")

then we are safe against all obscure 4-byte-alignment cases.

> That's why I'm saying I'm not sure
> there's a legacy case to worry about, since the big change now is that
> U-Boot also demands correctly aligned device trees. The Linux Kernel
> essentially always has, and other OSes probably as well. We were just
> bad and let 4-byte work for so long.
> 
>>>>>> - Should mkimage -E align blobs to 8 bytes by default ? I think yes,
>>>>>> and frankly, I thought it does so already, but apparently not.
>>>>>
>>>>>
>>>>> This can be done, but should it be? Not all FITs demand an 8-byte
>>>>> alignment right? It is only the FDT which requires this.
>>>> Maybe if image type is flat_dt, it should be implicitly 8-byte aligned then
>>>> ?
>>>
>>> Well, the device tree spec says 8-byte alignment.
>>
>> 8 byte alignment of what, start of DT, right ?
>>
>>> It's not "FDT for OS"
>>> that's 8-byte, it's any device tree should start out 8 byte aligned, and
>>> everything else should then be naturally aligned. If we're looking in a
>>> device tree for another device tree to use in place and not relocate
>>> then that second tree must be aligned.
>>>
>>> Or am I missing something?
>> The discussion is about mkimage -E which generates DTs for U-Boot SPL use.
>> The DTs in those external data should likely be aligned to 8 bytes by
>> default, i.e. implicitly set -B 8 (they don't seem to be right now).
> 
> Right. So the only legacy case I can see would be using an old mkimage
> to generate a current U-Boot image. And I'm not super sure that can
> happen, outside of some sort of external to us tooling being wrapped
> around things, and at that point we have little control.
For that case, see above.

[PATCH v2 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB

[Beleswar Padhi]

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);
 	} >.sram
 
-	. = ALIGN(4);
 	__image_copy_end = .;
 	_end = .;
 	_image_binary_end = .;
-- 
2.34.1

Re: [PATCH v2 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB

[Anshul Dalal]

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.

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?

>  	} >.sram
>  
> -	. = ALIGN(4);
>  	__image_copy_end = .;
>  	_end = .;
>  	_image_binary_end = .;

Re: [PATCH v2 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3487 bytes --]

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.

That would just leave the FIT images as the issue, which Marek provided
feedback on in 1/2, yes?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB

[Marek Vasut]

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.

Re: [PATCH v2 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4259 bytes --]

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 <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.

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
?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB

[Marek Vasut]

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 <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.
> 
> 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;

Re: [PATCH v2 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5749 bytes --]

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 <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.
> > 
> > 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
?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB

[Marek Vasut]

On 1/13/26 4:00 PM, 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 <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.
>>>
>>> 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
> ?
d) looks like what we should do, yes

Re: [PATCH v2 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 6610 bytes --]

On Tue, Jan 13, 2026 at 05:34:46PM +0100, Marek Vasut wrote:
> On 1/13/26 4:00 PM, 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 <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.
> > > > 
> > > > 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
> > ?
> d) looks like what we should do, yes

Poking at this harder, I'm not actually sure we need to use dd at all,
but we do need to fix our linker scripts, and then going back to when
Ilias reworked and cleaned up a bunch of them, get the changes reviewed
by the toolchain experts he got ahold of :)

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB

[Marek Vasut]

On 1/14/26 3:17 PM, Tom Rini wrote:

Hello Tom,

>>> 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
>>> ?
>> d) looks like what we should do, yes
> 
> Poking at this harder, I'm not actually sure we need to use dd at all,
> but we do need to fix our linker scripts, and then going back to when
> Ilias reworked and cleaned up a bunch of them, get the changes reviewed
> by the toolchain experts he got ahold of :)

I wonder if LD can always guarantee trailing alignment of the binary. If 
it can, then yes, dd would only be obscuring alignment problems and 
trailing DT look up failures which are hard to debug. It would be nice 
to drop the dd part, but I am not sure if we are able to do it reliably.

Re: [PATCH v2 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB

[Ilias Apalodimas]

Hi Marek,


On Thu, 15 Jan 2026 at 02:02, Marek Vasut <marek.vasut@mailbox.org> wrote:
>
> On 1/14/26 3:17 PM, Tom Rini wrote:
>
> Hello Tom,
>
> >>> 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
> >>> ?
> >> d) looks like what we should do, yes
> >
> > Poking at this harder, I'm not actually sure we need to use dd at all,
> > but we do need to fix our linker scripts, and then going back to when
> > Ilias reworked and cleaned up a bunch of them, get the changes reviewed
> > by the toolchain experts he got ahold of :)
>
> I wonder if LD can always guarantee trailing alignment of the binary. If
> it can, then yes, dd would only be obscuring alignment problems and
> trailing DT look up failures which are hard to debug. It would be nice
> to drop the dd part, but I am not sure if we are able to do it reliably.

LD won't pad align anything that doesn't have code afterwards. IOW
inserting an . = ALIGN(8); just before the .end symbol won't guarantee
alignement unless there's a section/code following.
What you can do is add an ALIGN(8) inside the last section. That will
guarantee that the last symbol is aligned. There's also the SUBALIGN
command which messes around with the input section alignment -- that
normally is automatically calculated, but Tom tested it yesterday
without success.

I'll have a closer look to the linker script in case I can come up
with something more elegant. Which defconfig should I use to reproduce
the issue?

Cheers
/Ilias

Re: [PATCH v2 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB

[Anshul Dalal]

On Thu Jan 15, 2026 at 1:30 PM IST, Ilias Apalodimas wrote:
> Hi Marek,
>
>
> On Thu, 15 Jan 2026 at 02:02, Marek Vasut <marek.vasut@mailbox.org> wrote:
>>
>> On 1/14/26 3:17 PM, Tom Rini wrote:
>>
>> Hello Tom,
>>
>> >>> 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
>> >>> ?
>> >> d) looks like what we should do, yes
>> >
>> > Poking at this harder, I'm not actually sure we need to use dd at all,
>> > but we do need to fix our linker scripts, and then going back to when
>> > Ilias reworked and cleaned up a bunch of them, get the changes reviewed
>> > by the toolchain experts he got ahold of :)
>>
>> I wonder if LD can always guarantee trailing alignment of the binary. If
>> it can, then yes, dd would only be obscuring alignment problems and
>> trailing DT look up failures which are hard to debug. It would be nice
>> to drop the dd part, but I am not sure if we are able to do it reliably.
>
> LD won't pad align anything that doesn't have code afterwards. IOW
> inserting an . = ALIGN(8); just before the .end symbol won't guarantee
> alignement unless there's a section/code following.
> What you can do is add an ALIGN(8) inside the last section. That will
> guarantee that the last symbol is aligned. There's also the SUBALIGN
> command which messes around with the input section alignment -- that
> normally is automatically calculated, but Tom tested it yesterday
> without success.
>
> I'll have a closer look to the linker script in case I can come up
> with something more elegant. Which defconfig should I use to reproduce
> the issue?

We have reproduced the issue on multiple K3 SoCs, to start with you can
make use of the am62px_evm_r5_defconfig with arm-none-eabi toolchain
from ARM[1] with version 13.3.rel1.

[1]: https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads

>
> Cheers
> /Ilias

Re: [PATCH v2 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 6459 bytes --]

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 <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.
> > > 
> > > 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB

[Marek Vasut]

On 1/12/26 11:11 AM, 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);
>   	} >.sram
Does this work even if the __u_boot_list section is empty ?

I think what you need is unconditional alignment of the end of the 
binary, that has to be 8 bytes aligned.

Re: [PATCH v2 2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2639 bytes --]

On Mon, Jan 12, 2026 at 03:40:57PM +0100, Marek Vasut wrote:
> On 1/12/26 11:11 AM, 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);
> >   	} >.sram
> Does this work even if the __u_boot_list section is empty ?

I'm not sure it can be empty, but it should still work.

> I think what you need is unconditional alignment of the end of the binary,
> that has to be 8 bytes aligned.

We might need to look harder at what Anshul was suggesting in his reply,
yeah. I'll chime in over there next.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: (subset) [PATCH v2 0/2] Fix TI DTB alignment issues with recent libfdt update

[Tom Rini]

On Mon, 12 Jan 2026 15:41:00 +0530, Beleswar Padhi wrote:

> Recent libfdt updates (commit 0535e46d55d7 "scripts/dtc: Update to
> upstream version v1.7.2-35-g52f07dcca47c") enforce strict 8-byte
> alignment for device tree blobs, as required by the device tree
> specification. This causes failures on platforms using
> CONFIG_SPL_MULTI_DTB_FIT, where DTBs were not properly aligned.
> 
> The alignment issue occurs at two levels:
> 
> [...]

Applied to u-boot/master, thanks!

[2/2] ARM: OMAP2+: Pad SPL binary to 8-byte alignment before DTB
      commit: 85f586035d75132b2b60d5e593e1c0049f5d126a
-- 
Tom