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