Re: [meta-arago] [meta-ti][PATCH 1/1 v2] recipes-ti: initramfs: Make minimal initrd image

[Randolph Sapp <rs@ti.com>]

On Wed Sep 10, 2025 at 6:48 AM CDT, Bryan Brattlof wrote:
> On September  9, 2025 thus sayeth Randolph Sapp:
>> On Tue Sep 9, 2025 at 9:56 AM CDT, Bryan Brattlof via lists.yoctoproject.org wrote:
>> > On September  4, 2025 thus sayeth Moteen Shah:
>> >> Add recipes to make initramfs image based on systemd.
>> >> The image will package boot essential and other modules
>> >> which will be modprobed by initramfs udev once the inbuilt
>> >> drivers gets probed.
>> >> 
>> >> Signed-off-by: Moteen Shah <m-shah@ti.com>
>> >> ---
>> >>  .../initramfs/packagegroup-ti-initramfs.bb    |  5 ++
>> >>  .../recipes-ti/initramfs/ti-tiny-initramfs.bb | 49 +++++++++++++++++++
>> >>  2 files changed, 54 insertions(+)
>> >>  create mode 100644 meta-ti-bsp/recipes-ti/initramfs/packagegroup-ti-initramfs.bb
>> >>  create mode 100644 meta-ti-bsp/recipes-ti/initramfs/ti-tiny-initramfs.bb
>> >> 
>> >> diff --git a/meta-ti-bsp/recipes-ti/initramfs/packagegroup-ti-initramfs.bb b/meta-ti-bsp/recipes-ti/initramfs/packagegroup-ti-initramfs.bb
>> >> new file mode 100644
>> >> index 00000000..5d2ff390
>> >> --- /dev/null
>> >> +++ b/meta-ti-bsp/recipes-ti/initramfs/packagegroup-ti-initramfs.bb
>> >> @@ -0,0 +1,5 @@
>> >> +SUMMARY = "Minimal initramfs for boot requirements"
>> >> +
>> >> +require recipes-core/packagegroups/packagegroup-core-boot.bb
>> >> +
>> >> +RDEPENDS:${PN}:remove = "grub-efi kernel"
>> >> diff --git a/meta-ti-bsp/recipes-ti/initramfs/ti-tiny-initramfs.bb b/meta-ti-bsp/recipes-ti/initramfs/ti-tiny-initramfs.bb
>> >> new file mode 100644
>> >> index 00000000..4cebf595
>> >> --- /dev/null
>> >> +++ b/meta-ti-bsp/recipes-ti/initramfs/ti-tiny-initramfs.bb
>> >> @@ -0,0 +1,49 @@
>> >> +SUMMARY = "TI SDK super minimal base image for initramfs"
>> >> +
>> >> +DESCRIPTION = "Image meant for basic boot of linux kernel. Intended as\
>> >> + bare system, this image does not package the kernel in the\
>> >> + standard /boot folder in rootfs. Instead, it provides a base\
>> >> + rootfs allowing kernel to be deployed elsewhere\
>> >> + (tftp/separate boot partition/jtag log etc..) and boot\
>> >> + the image.\
>> >> +"
>> >> +
>> >> +LICENSE = "MIT"
>> >> +
>> >> +inherit core-image
>> >> +
>> >> +IMAGE_FEATURES:remove = "package-management"
>> >> +
>> >> +INITRAMFS_FSTYPES = "cpio cpio.xz"
>> >> +
>> >> +#INITRAMFS_MAXSIZE = "65536"
>> >> +#IMAGE_OVERHEAD_FACTOR = "1"
>> >> +
>> >> +IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
>> >> +
>> >> +INITRAMFS_SCRIPTS ?= "initramfs-framework-base initramfs-module-udev initramfs-module-nfsrootfs"
>> >> +
>> >> +MODULES = "\
>> >> +    kernel-module-cdns-pltfrm \
>> >> +    kernel-module-ti-j721e-ufs \
>> >> +    kernel-module-tps6594-i2c \
>> >> +"
>> >
>> > Are these all the modules we'll need? Is everything else build-in the 
>> > default defconfig? or are we expecting this list to expand as more 
>> > platforms start migrating to this?
>> >
>> > ~Bryan
>> 
>> Should this instead be defined per machine with
>> MACHINE_ESSENTIAL_EXTRA_RDEPENDS?
>> 
>> https://docs.yoctoproject.org/ref-manual/variables.html#term-MACHINE_ESSENTIAL_EXTRA_RDEPENDS
>
> Yeah, I guess what I'm slowly realizing is we're adding roughly a 140MB 
> binary to the critical path for the bootloaders (so long any boot KPI) 
> all so we can have a PMIC driver as a builtin.
>
> All the distributions I can think of all modify the ARM64 defconfig in 
> some way to better suit their distribution. Yocto even has the advantage 
> of knowing what target they are building for. Should we instead carry a 
> fragment, or use some other mechanism, to change the kernel's config so 
> the PMIC driver is a builtin if needed by the target?
>
> ~Bryan

Use of conditional configs is simply reverting back to the schemes we were using
3+ years ago. Initramfs is big and slow, but it's standard and can be leveraged
across other distros easily as it's already been a production solution for them
for quite some time.

That being said, Yocto is *unique*, and what it doesn't do weird itself, it
leaves for the implementer to make weird in their own way. I guess it doesn't
really matter if we don't care about having a uniform bootflow across distros,
but that sounds like hell.

- Randolph