[PATCH 1/2] boot: Fix dtbo application by ensuring overlay alignment

[Tom Rini]

On Tue, Jan 27, 2026 at 10:26:33AM +0000, Jamie.Gibbons at microchip.com wrote:
> Hi Tom,
> 
> On Fri, 2026-01-23 at 14:15 -0600, Tom Rini wrote:
> > On Tue, Jan 20, 2026 at 03:33:12PM +0000, Jamie Gibbons wrote:
> > 
> > > After U-Boot's DTC/libfdt update, device tree overlay application
> > > could
> > > fail with FDT_ERR_ALIGNMENT due to the overlay DTBO being loaded at
> > > a
> > > misaligned address. Change the FIT image loader option in image-
> > > fit.c
> > > from FIT_LOAD_IGNORED to FIT_LOAD_OPTIONAL_NON_ZERO, to ensure
> > > overlays
> > > are loaded at properly aligned addresses and any alignment errors
> > > are
> > > resolved.
> > > 
> > > Tested on: PolarFire SoC Icicle Kit
> > > 
> > > Fixes: 0535e46d55d ("scripts/dtc: Update to upstream version
> > > v1.7.2-35-g52f07dcca47c")
> > > Signed-off-by: Jamie Gibbons <jamie.gibbons at microchip.com>
> > > ---
> > >  boot/image-fit.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/boot/image-fit.c b/boot/image-fit.c
> > > index 2d040e38d97..3a327d07784 100644
> > > --- a/boot/image-fit.c
> > > +++ b/boot/image-fit.c
> > > @@ -2481,7 +2481,7 @@ int boot_get_fdt_fit(struct bootm_headers
> > > *images, ulong addr,
> > >  			addr, &uname, &uconfig,
> > >  			arch, IH_TYPE_FLATDT,
> > >  			BOOTSTAGE_ID_FIT_FDT_START,
> > > -			FIT_LOAD_IGNORED, &ovload, &ovlen);
> > > +			FIT_LOAD_OPTIONAL_NON_ZERO, &ovload,
> > > &ovlen);
> > >  		if (ov_noffset < 0) {
> > >  			printf("load of %s failed\n", uname);
> > >  			continue;
> > 
> > After talking with Marek about this more, we think this is the wrong
> > approach. Can you please try dropping the load_op test from
> > 8fbcc0e0e839
> > and seeing if that also fixes your problem? If so, please post a
> > patch
> > with that and a Fixes tag, thanks!
> > 
> Dropping the load_op test added in commit 8fbcc0e0e839 does not solve
> the issue - failed on fdt_open_into for DTO due to misalignment of ov.

Ugh, darn. Is there another load_op check that can be removed to fix
that case? If not, then we need to pass in a new flag that means that we
always relocate the data. That was Marek's other suggestion as we talked
this over.

-- 
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/20260127/da3b08ee/attachment.sig>