Build logic for creating standalone initramfs environments.
See the README files in the respective subdirs for more details.
Normally you wouldn't build in this directory directly. Instead, you would build the chromeos-initramfs package with the right USE flags. e.g.:
$ USE=recovery_ramfs emerge-$BOARD chromeos-initramfs
That will install the cpio initramfs files into the sysroot for you to build into a kernel directly. The various build scripts would then be used to make the right kernel/image using those (e.g. mod_image_for_recovery.sh).
You could build these by hand for quick testing. Inside the chroot:
$ make SYSROOT=/build/$BOARD BOARD=$BOARD <target>
That will create the cpio archives for you.
It is possible to debug few of the initramfs targets in QEMU. Read test/README.md for more information.
Also, here is a shortcut for developing/debugging graphical bits in initramfs, without having to create a full image for every iteration.
After emerge-$BOARD, find your initramfs package from chroot /build/$BOARD/var/lib/initramfs and copy to a running DUT, for example /tmp/recovery_ramfs.cpio, then do followings on DUT over SSH:
mkdir /usr/local/test/; cd /usr/local/testxzcat /tmp/XXXXXX_ramfs.cpio | toybox cpio -iv (Here we assume that the kernel is configured to use xz compression for its initramfs.)stop ui; kill $(pidof frecon)for d in dev proc sys tmp; do
mount --bind /${d} /usr/local/test/${d}
done
chroot /usr/local/test /initSince the initramfs is bundled into the kernel, and our read-only firmware loads the kernel, we cannot create kernel images that are too big for the firmware to load into memory. The current limit applies to the entire kernel+initramfs image and depends on the device. We cannot rely on the read-write firmware booting things as it might not be upgraded, might be corrupted, and might not even be loaded at all depending on the device.
Older devices had a 8 MiB or 16 MiB limit, but those are all EOL now, so we do not need to worry about them.
These devices have a 32 MiB limit and must be supported until they all go EOL (which is at least Jun 2025).
All other supported devices have a 512 MiB limit, although that limit is a little fuzzy. It's meant to be “nobody could ever possibly need this much, right?” rather than “you can def use all 512 MiB”. We could loosen our belts a bit from 32 MiB by going up to e.g. 128 MiB, but if we start getting anywhere close to 512 MiB, we should strongly reevaluate our choices, and make sure we finally have automated coverage to verify exact sizes for current devices.
In practice, for projects that are shared across devices (i.e. recovery), we need to stay within the smallest limit (32 MiB). For projects that are device specific (i.e. hypervisor), they may rely on that device-specific limit. For projects that are shared across devices but only launched on newer ones (i.e. miniOS), they may rely on the smallest limits those devices share.
The list of devices here is not 100% complete, but is meant for general guidance when making decisions. The device names are what depthcharge uses. Most map directly to $BOARD names, but some might be slightly different.