Re: [meta-ti] BSP version selection forces initramfs integration

[Francesco Dolcini <francesco@dolcini.it>]

On Mon, Apr 13, 2026 at 09:15:42AM -0500, Ryan Eatmon wrote:
> 
> 
> On 4/13/2026 2:12 AM, Francesco Dolcini wrote:
> > Hello Ryan,
> > 
> > On Wed, Feb 11, 2026 at 06:48:16PM +0000, Vitor Soares wrote:
> > > 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.
> > 
> > 
> > Any update on this? Just a reminder that meta-ti is used both for your
> > EVK/SK, and just for the SoC support. Specifically you should not
> > enforce anything like an initramfs to users of your SoC.
> > 
> > Can you please prioritize this? This is creating issues to us since
> > weeks and I do not see any progress.
> 
> There are a number of cases where we do things in the SOC common include
> files to centralize things for the evm/sk boards.

The fact that you have something common with your EVM/SK boards does not
implies that you should put it in the SOC conf file.
The SoC configuration file, should be about the SoC.

If you have a need of something common, name it
"ti-sk-evm-common-${whatever}.${ext}" and include it in from the related
TI machine conf file. You should opt-in for this common part from the
boards file you need, not force every user of your SoC and OE layer to
opt-out from it.

Francesco