Re: [OE-core] [PATCH v2 1/3] kernel-uboot: move FIT_KERNEL_COMP_ALG to image-fitimage.conf

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2026-07-30 at 15:35 +0200, Nora Schiffer wrote:
> On Thu, 2026-07-30 at 14:09 +0100, Richard Purdie wrote:
> > On Thu, 2026-07-30 at 13:15 +0200, Nora Schiffer wrote:
> > > On Thu, 2026-07-30 at 11:43 +0100, Richard Purdie wrote:
> > > 
> > > Okay, new plan: Change uboot_prep_kimage to accept the compression algorithm as
> > > an argument, so we can use different variables when calling it from kernel-
> > > uimage.bbclass and kernel-fit-extra-artifacts.bbclass. kernel-uimage.bbclass
> > > could then use a separate variable UBOOT_MKIMAGE_KERNEL_COMP_ALG instead of
> > > reusing the FIT one.
> > > 
> > > A more radical approach would be to skip the deprecation of using a linux.bin
> > > generated by the kernel recipe as a FIT image's kernel and drop support
> > > immediately.
> > 
> > Can you see from the commit history who might have been using that? Do
> > you think there are many people relying upon it? If that functionality
> > doesn't make much sense and wouldn't or shouldn't be used by people,
> > I'm fine with actually removing it, as long as we're clear about why it
> > likely isn't needed or is inefficient (or whatever) and what the
> > alternative is.
> > 
> > A lot of the time I think we support too many code paths when we should
> > try and encourage people to do the "best" known things.
> 
> Right now using linux.bin is the only way to build a FIT image using kernel-fit-
> image.bbclass - my patch 2/3 introduces the option to use something different
> instead of linux.bin. As currently implemented, the patch results in a
> deprecation warning for *all* BSPs that build FIT images, but that seems
> preferable to breaking such BSPs.
> 
> Making FIT_KERNEL_FILENAME default to KERNEL_IMAGETYPE would keep the FIT image
> working where KERNEL_IMAGETYPE is the correct image to include in the FIT, but
> it would differ from the current generation of linux.bin in kernel-uboot.bbclass
> in most cases. As far as I can tell this should work as intended on platforms
> that set KERNEL_IMAGETYPE to "Image"; types like zImage and bzImage would result
> in double compression with the default settings, and most other types would just
> be unbootable. I don't think we should go with this solution.

Right, that does not sound like a good outcome. It also means that
linux.bin isn't really deprecated though as the commit messages hinted
at :/.

This is why I'm asking questions since I really haven't looked into
this in detail. I'm just very worried about the spaghetti nature of our
classes and really don't want to make it worse.

Cheers,

Richard