On Tue, Nov 03, 2026 at 11:09:31 +0100, Mattijs Korpershoek wrote:
> Hi Carlo,
>
> Thank you for the patch.
>
> > A U-Boot image may embed its device tree, but a FIT which explicitly
> > names an FDT must not boot after that FDT fails to load or verify.
> > External FDT data is copied to its load address before verification,
> > so ignoring the error can leave an unverified device tree for U-Boot.
> >
> > Keep support for U-Boot images without a separate FDT, but reject
> > failures for an explicitly requested FDT in both firmware and loadables.
> >
> > Fixes: d879616e9e64 ("spl: fit: simplify logic for FDT loading for non-OS
> > boots")
> > Signed-off-by: Carlo Caione <[email protected]>
> >
> > diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> > index 64e5f95546f1..a520db765065 100644
> > --- a/common/spl/spl_fit.c
> > +++ b/common/spl/spl_fit.c
> > @@ -491,11 +491,14 @@ static int spl_fit_append_fdt(struct spl_image_info
> > *spl_image,
> > image_info.load_addr = ALIGN(spl_image->load_addr + spl_image->size, 8);
> >
> > /* Figure out which device tree the board wants to use */
> > + spl_image->fdt_addr = NULL;
>
> What's the point of initializing fdt_addr to NULL here?
> It's assigned in both cases (whether node < 0 or not).
We actually have a way out if (node < 0) and (!gd->fdt_blob) and the
problematic path is that early return.
The problem starts in spl_load_simple_fit() where image_info is not
zero-initialized so ->fdt_addr is basically garbage.
When we return early this garbage is copied into spl_image->fdt_addr.
Even zero-initializing the passed struct doesn't fully solve the issue
because the helper also receives the main spl_image, which is reused
across boot attempts and can contain a stale FDT pointer.
So, setting fdt_addr to NULL is the quickest fix for all the cases.
--
Carlo Caione
