On Wed, 2026-02-11 at 11:50 -0600, Ryan Eatmon wrote: > > > On 2/9/2026 10:31 AM, 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. > > > > 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? > > I'm not sure you are 100% understanding what I'm saying. > > Starting with 6.18 and forward (including mainline and next since they > are always "forward"), we are requiring the initramfs for some of the > platforms (am62a, j721e, j784s4). Without the initramfs providing the > needed kernel modules you will not boot to the rootfs. The board will > just not work. > > So even if right now you are not using an initramfs, then for those > platforms you will need to start unless you take extra steps to force > the required modules to be compiled into the kernel via config fragments. > > Those modules were previously turned on in our vendor kernel (and never > for mainline/next), and we are no longer going to do that. > > That all being said, I will send a patch soon (need to test things > first) that will do the following: > > 1) Limit creation/requirement for the ti-core-initramfs to just > platforms that require it. > > 2) Allow you to disable the ti-core-initramfs completely by setting a > variable. BUT... you will be required to provide the needed modules in > some way to get your image to boot either by adding a config fragment in > the kernel, or doing your own initramfs and including the needed modules > (which you can use the variable from the machine conf files to get that > list). > Thanks for the detailed explanation and apologies for not providing enough context upfront.
We're Toradex, maintaining meta-toradex-ti BSP layer for our TI-based SoMs, including Aquila AM69. We use our own kernel and bootloader recipes based on vanilla mainline with our own defconfigs. Since we control our own kernel config, we can build needed drivers as built-in if necessary. Currently we don't plan to use initramfs. The issue we're trying to solve: we want to use `TI_PREFERRED_BSP = "mainline"` to get the BSP override context without being forced into the initramfs workflow. Your proposed opt-out variable would work for our immediate need. We'd disable ti-core-initramfs and manage our own kernel configuration as needed. That said, I still think the class-based approach is cleaner long-term architecture - it properly separates BSP selection (machine-level) from initramfs integration (image-level). If you're open to exploring that direction, I'm happy to help. Thanks for working on this. Best regards, Vitor Soares Toradex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19485): https://lists.yoctoproject.org/g/meta-ti/message/19485 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]] -=-=-=-=-=-=-=-=-=-=-=-
