On Thu, 2026-07-30 at 14:50 +0100, Richard Purdie wrote: > 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 :/.
My goal is to deprecate it though - linux.bin generation has some weirdness that we should get rid of in my opinion, at least for FIT images (I don't have an opinion about uImage build). Thus patch 2 - implements an alternative approach that avoids the weirdness - warns users to switch to the new approach (to set KERNEL_IMAGETYPE(S) and FIT_KERNEL_FILENAME appropriately), without immediately breaking existing BSPs. I feel like implementing the new way without the deprecation warning would just result in users keeping the old solution longer, thus requiring us to preserve support for using linux.bin. 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 (#242364): https://lists.openembedded.org/g/openembedded-core/message/242364 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]] -=-=-=-=-=-=-=-=-=-=-=-
