[PATCH 2/5] boot: fit: decompress kernel when in SPL

Francesco Valla francesco at valla.it
Mon May 4 19:34:21 CEST 2026


Hi Simon,

On Mon, May 04, 2026 at 06:08:40AM -0600, Simon Glass wrote:
> Hi Francesco,
> 
> On 2026-04-28T20:24:41, Francesco Valla <francesco at valla.it> wrote:
> > boot: fit: decompress kernel when in SPL
> >
> > During the esecution of fit_image_load() in full U-Boot, the kernel is
> > not decompressed as this step is typically performed by the bootm
> > command logic afterward. This is not however true when doing a falcon
> > boot from SPL; enable the decompression in this case (i.e., if
> > CONFIG_SPL_OS_BOOT is set).
> >
> > Signed-off-by: Francesco Valla <francesco at valla.it>
> >
> > boot/image-fit.c | 7 ++++---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> > diff --git a/boot/image-fit.c b/boot/image-fit.c
> > @@ -2291,9 +2291,10 @@ int fit_image_load(struct bootm_headers *images, ulong addr,
> > +         image_type != IH_TYPE_RAMDISK &&
> > +         (CONFIG_IS_ENABLED(OS_BOOT) ||
> > +          image_type != IH_TYPE_KERNEL ||
> > +          image_type != IH_TYPE_KERNEL_NOLOAD)) {
> 
> Since image_type can never be both IH_TYPE_KERNEL and
> IH_TYPE_KERNEL_NOLOAD at the same time, (image_type != IH_TYPE_KERNEL
> || image_type != IH_TYPE_KERNEL_NOLOAD) is always true, the kernel is
> decompressed unconditionally, including in U-Boot proper, which is
> what the original code was trying to avoid.
> 
> I think you want:
> 
>     (CONFIG_IS_ENABLED(OS_BOOT) ||
>      (image_type != IH_TYPE_KERNEL &&
>       image_type != IH_TYPE_KERNEL_NOLOAD))
>

This was exactly the first version, then I tried to simplify the logic
and quite obviously failed. I'll fix it for v2.

> Can you see a way to add a test that exercises this path so the
> regression would be caught?
> 
> > During the esecution of fit_image_load() in full U-Boot, the kernel is
> 
> execution
> 
> It is worth mentioning mention in the commit message that you rely on
> CONFIG_IS_ENABLED(OS_BOOT) being false in U-Boot proper (since only
> CONFIG_SPL_OS_BOOT exists), so existing behaviour is preserved there.
> 

Ok

> Regards,
> Simon

Thank you

Regards,
Francesco


More information about the U-Boot mailing list