[meta-ti] BSP version selection forces initramfs integration

[meta-ti] BSP version selection forces initramfs integration

[Vitor Soares]

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.

Would this approach be welcome? We're happy to contribute patches.

Best regards,
Vitor Soares
Toradex

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

[PRC Automation]

meta-ti / na / 78ec394aae8a141ceb87a6b67f109665e7c96122.camel

PRC Results: FAIL

=========================================================
  check-yocto-patches: FAIL
=========================================================
Patches
----------------------------------------
FAIL - [meta-ti] BSP version selection forces initramfs integration
    WARN: Missing branches specifier [master/scarthgap/XXXXX]. (META-2)
        patch:55
            Subject: [meta-ti] BSP version selection forces initramfs integration
    
    WARN: Commit message does not include file/recipe name: BSP version selection forces initramfs integration. (COMMIT-MESSAGE-2)
        patch
    
    ERROR: Missing Signed-off-by in commit message. (SIGNED-OFF-BY-1)
        patch
    
    For details on the above errors/warnings visit: https://lists.yoctoproject.org/g/meta-ti/wiki/40887

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

[Ryan Eatmon]

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?


> 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 (#19472): https://lists.yoctoproject.org/g/meta-ti/message/19472
> Mute This Topic: https://lists.yoctoproject.org/mt/117717310/6551054
> Group Owner: meta-ti+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [reatmon@ti.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

-- 
Ryan Eatmon                reatmon@ti.com
-----------------------------------------
Texas Instruments, Inc.  -  LCPD  -  MGTS

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

[Vitor Soares]

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 (#19472):
> > https://lists.yoctoproject.org/g/meta-ti/message/19472
> > Mute This Topic: https://lists.yoctoproject.org/mt/117717310/6551054
> > Group Owner: meta-ti+owner@lists.yoctoproject.org
> > Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [reatmon@ti.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> > 
> 

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

[Moteen Shah]

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.

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 (#19475): https://lists.yoctoproject.org/g/meta-ti/message/19475
> Mute This Topic: https://lists.yoctoproject.org/mt/117717310/9997635
> Group Owner: meta-ti+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [m-shah@ti.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

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

[Vitor Soares]

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 (#19475):
> > https://lists.yoctoproject.org/g/meta-ti/message/19475
> > Mute This Topic: https://lists.yoctoproject.org/mt/117717310/9997635
> > Group Owner: meta-ti+owner@lists.yoctoproject.org
> > Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [m-shah@ti.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> > 

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

[Ryan Eatmon]

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).


> 
>>> 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/6551054
> Group Owner: meta-ti+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [reatmon@ti.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

-- 
Ryan Eatmon                reatmon@ti.com
-----------------------------------------
Texas Instruments, Inc.  -  LCPD  -  MGTS

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

[Vitor Soares]

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

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

[Francesco Dolcini]

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.

Thanks
Francesco

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

[Ryan Eatmon]

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.  And there are a 
number of cases where that interferes with someone trying to use that 
central file to support their own board.

Our position is that you can override the offending variable setting in 
your board specific file and turn off the initramfs feature if that is 
what you desire.  We added a lot of extra logic and control to enable 
you to turn it off.


> Thanks
> Francesco
> 

-- 
Ryan Eatmon                reatmon@ti.com
-----------------------------------------
Texas Instruments, Inc.  -  LCPD  -  MGTS

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

[Francesco Dolcini]

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