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. Best, Nora -- TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany Amtsgericht München, HRB 105018 Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider https://www.tq-group.com/
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#242357): https://lists.openembedded.org/g/openembedded-core/message/242357 Mute This Topic: https://lists.openembedded.org/mt/120464164/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
