1

I would like to load a few kernel modules, and activate framebuffer access prior to Plymouth launch. This is normally done using /etc/initramfs-tools directory provided with the initramfs-tools. However, when building an initramfs image with Yocto, no such directory is available. This means that whatever initramfs-tools does for loading modules and initializing framebuffer, has to be done manually in the initramfs image as far as I could understand.

The tasks I want to accomplish is very delicately explained by notro in https://github.com/notro/fbtft/wiki/Bootsplash . I'd like to do the equivalent of what's done below:

  • Access to /etc/initramfs-tools/scripts/init-top/spi and modprobe a module.
  • Access to /etc/initramfs-tools/modules and list further modules to be launched by modules daemon
  • Enable framebuffer which is done via echo "export FRAMEBUFFER=/dev/fb1" | sudo tee /etc/initramfs-tools/conf.d/fb1

With my research, I could find initramfs-framework-base package which features some scripts that initramfs boot uses. I think this might be a good starting point. However, I do not know how to explicitly tell initramfs to do what I want to accomplish (tasks above).

Note: Currently, my initramfs image is generated by the following recipe:

include recipes-core/images/rpi-basic-image.bb
BASEPACKS = " \
    base-passwd \
    busybox \
    initramfs-live-boot \
    initramfs-framework-base \
    udev \
    ${ROOTFS_BOOTSTRAP_INSTALL} \
"

IMAGE_INSTALL = " ${BASEPACKS} \
                  plymouth plymouth-set-default-theme  \
                "

# Do not pollute the initrd image with rootfs features
IMAGE_FEATURES = "splash"
SPLASH = "plymouth"

IMAGE_LINGUAS = ""
LICENSE = "MIT"

IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
IMAGE_ROOTFS_SIZE = "8192"
IMAGE_OVERHEAD_FACTOR = "1.0"
IMAGE_ROOTFS_EXTRA_SPACE = "0"
IMAGE_ROOTFS_MAXSIZE = "12288"

CMDLINE_append = " quiet splash nomodeset plymouth.ignore-serial-consoles consoleblank=0"

BAD_RECOMMENDATIONS += "busybox-syslog"

Also Note: I'm using an ARMv6-based machine with U-boot bootloader. Compiling the original initramfs-tools (that is originally developed for Debian) generates 0 byte images. I'm guessing this is an issue with its compatibility. So I'll have to resort to generating initramfs with yocto's internal tools.

Any help is appreciated. Thanks in advance.

mozcelikors
  • 2,582
  • 8
  • 43
  • 77
  • There's no such thing as an *"initramfs image"*. The kernel creates an empty ramfs filesystem, and then can populate it by unpacking a **cpio** archive linked with the kernel image. The memory address of another **cpio** archive can be passed to the kernel using the same register mechanism that initramd uses. BTW there are no size parameters for ramfs, which can use whatever free memory there is. Size parameters would be attributes for a ramdisk. IOW you're conflating ramfs with ramdisk. – sawdust May 23 '18 at 19:37
  • Well, your comment is not very helpful regarding my questions here. I know what initramfs is, it is a filesystem, but you are wrong. There is something called initramfs image which is a wrapped version of the archive you mentioned. Cpio.gz archive is wrapped to .img format for u-boot to understand it. The format I am using right now has .img extension, which means that it is an image. However, you can either bundle it with kernel, like what im doing in this particular example, or you can use it externally and configure your GRUB or UBOOT. Your choice. – mozcelikors May 23 '18 at 19:37
  • Perhaps you should read this first: https://developer.toradex.com/knowledge-base/initramfs-and-tmpfs This clearly states that there is an initramfs image, with its keyword built-into the entire Yocto Linux system even. Called INITRAMFS_IMAGE. Also this will help you understand how to generate an initramfs image. – mozcelikors May 23 '18 at 19:47
  • That link is interesting, because its inaccuracies are part of the problem. You can continue to follow its inaccuracies, or learn the truth. For instance you won't find *"INITRAMFS_IMAGE"* in Linux kernel source code or documentation; that's an OpenEmbedded contrivance. The U-Boot wrapper name extension of .img is yet another instance of misleading information due to misapplication of labels. Aside from the errors in that tutorial, it actually repeats what I wrote. So you claiming that I'm wrong while advocating it is a contradiction that you need to resolve. – sawdust May 23 '18 at 20:18
  • Thanks for the advice. I'm open to read more resources. In the Yocto world, I find that naming being used quite a lot. But Id prefer not to cross with the naming strictly and focus on the more important aspects. – mozcelikors May 23 '18 at 20:21

0 Answers0