On Mon, 2026-02-09 at 23:40 +0530, Moteen Shah wrote: > Hey Vitor, > > On 09/02/26 22:01, Vitor Soares via lists.yoctoproject.org wrote: > > 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. > > Can you please explain more on the part of how initramfs integration is > hampering other configs to get in. Also, what are those configurations. > >
The issue is with override precedence and future maintenanc. In ti-bsp.inc, BSP selection controls kernel, bootloader, and GPU driver versions through overrides like :bsp-mainline, :bsp-ti-6_12, etc. For bsp-mainline and bsp-next, the GPU driver variables are intentionally left empty because mesa-pvr doesn't support mainline kernels yet: BSP_ROGUE_DRIVER_PROVIDER:bsp-mainline = "" BSP_MESA_PVR_VERSION:bsp-mainline = "" This falls back to software rendering, which is what we need. Our problem is that we're running mainline-based kernels, so we should use TI_PREFERRED_BSP = "mainline". However, we can't because bsp-mainline, bsp-next, and bsp-ti_6_18 all force initramfs integration in ti-soc.inc. Instead, we have to manually override mesa providers in our machine conf to replicate what bsp-mainline already provides. The real issue is future maintenance. When you add mesa-pvr support for mainline kernels and updates bsp-mainline accordingly, we won't automatically inherit those changes. We'll have to keep tracking and duplicating BSP updates manually. The class approach actually works well for your modularization plan too. As you add modules to ti-core-initramfs, downstream users can extend it, create their own, or skip it entirely. BSP selection stays at machine-level, initramfs at image-level. Thoughts? Best regards, Vitor Soares > Regards, > Moteen > > > 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 (#19477): https://lists.yoctoproject.org/g/meta-ti/message/19477 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]] -=-=-=-=-=-=-=-=-=-=-=-
