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 [email protected]
-----------------------------------------
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19841):
https://lists.yoctoproject.org/g/meta-ti/message/19841
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]]
-=-=-=-=-=-=-=-=-=-=-=-
