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

[Tom Rini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260112/fe74b369/attachment.sig>