On Mon, 2026-02-09 at 09:11 -0600, Ryan Eatmon wrote: > > > On 2/9/2026 5:21 AM, Vitor Soares via lists.yoctoproject.org wrote: > > Hi meta-ti maintainers, > > > > We've hit an issue where selecting a BSP version (e.g. TI_PREFERRED_BSP = > > "mainline") also forces initramfs integration via ti-soc.inc (lines 32-49). > > The > > bsp-mainline, bsp-next, and bsp-ti_6_18 overrides all unconditionally set > > BUILD_CORE_INITRAMFS_IMAGE_STEP, TI_WKS_INITRAMFS, and IMAGE_BOOT_FILES. > > > > This means we can't use bsp-mainline without also pulling in ti-core- > > initramfs — > > even when our images don't need it. > > > > Since we can't use bsp-mainline, we also lose the correct override context > > for > > other components. For example, we end up having to manually override all the > > mesa-pvr.inc virtual providers in our machine config to use upstream mesa — > > something that bsp-mainline would handle naturally. > > > > The root issue is that initramfs integration (an image-level concern) is > > tied to > > BSP version selection (a machine-level concern) in ti-soc.inc. > > > > A possible fix would be to move the initramfs logic to an image class (e.g. > > ti- > > image.bbclass) that images explicitly opt into. This would be a breaking > > change > > for images relying on the current automatic behavior, but it would properly > > separate these concerns. > > I recognize what you are saying as an issue. > > We are in the process of moving to require an initramfs for all of our > platforms as we transition to using modules for kernel features that the > upstream kernel is unwilling to turn on by default (to keep the kernel > small). We have been turning these features on by default in our vendor > kernel, and we moving away from that. > > So there is a need to balance our need to make sure that everything is > in place at the BSP level, and the need for downstream customers in > distro layers to build upon that initramfs and include their own changes. > > As I see it, we have two options. > > 1) Provide a mechanism to extend the ti-core-initramfs recipe to allow > you to put more stuff in there. > > 2) Go the class route and make it so that your initramfs (using the > class) would make sure to include ALL of the needed modules into your > initramfs and still register your initramfs with the images. > > Can you point me at the recipe that your initramfs is using so that we > can get an example of usage so we can plan for the best solution? > >
Thanks for the quick response. For context: we don't plan to use initramfs (at least not currently) - our images boot directly to rootfs. The issue is that selecting bsp-mainline forces initramfs integration we don't need, and prevents us from benefiting from bsp- mainline's other configurations. Proposed solution: Move initramfs logic from ti-soc.inc to classes/ti-image.bbclass, and images that need initramfs explicitly inherit ti-image. This separates machine-level BSP selection from image-level features (standard Yocto pattern). Breaking change: your reference images need inherit ti-image added. Thoughts? > > Would this approach be welcome? We're happy to contribute patches. > > > > Best regards, > > Vitor Soares > > Toradex > > > > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19475): https://lists.yoctoproject.org/g/meta-ti/message/19475 Mute This Topic: https://lists.yoctoproject.org/mt/117717310/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
