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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#242360): https://lists.openembedded.org/g/openembedded-core/message/242360 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]] -=-=-=-=-=-=-=-=-=-=-=-
