Home > Edison > Building

Building and installing the kernel

Historical reason to use a initrd

In the past we built a kernel with a built-in initramfs. The initramsfs is a cpio built into the kernel containing kernel modules that are needed to boot from SDHC.

We no longer build the initramfs into the kernel, we now use a separate cpio. The reason is that U-Boot seems not to support loading a kernel larger then 15MB.

Note: How does the initrd work?

U-Boot loads the kernel into RAM memory and the initrd into another part of the RAM memory. The initrd has a filesystem on it with the needed modules as well as an init script. The init script mounts the detected files systems on the eMMC and the SD Card and then switches root. This means the / on the initrd is replaced by the ‘/’ on the filesystem in the command line.

Since we have everything here needed to boot we add some disk repair tools, so the initrd can double as a rescue disk.

Even though we call the file initrd (as everybody seems to be doing), it is really an initramfs.

Historically there was another reason to use a initrd. According the Andy Shevchenko some kernel module does not enumerate well when built into the kernel:

Note: Basically either you need to use special initramfs / initrd where you have all necessary modules and you use pivot_root to switch rootfs, or you compile in all those modules. Since one bug(?) in the regulator framework when you built-in sdhci-pci it will prevent to WiFi be enumerated, you have to workaround it like

echo 0000:00:01.3 > /sys/bus/pci/drivers/sdhci-pci/unbind  
echo 0000:00:01.3 > /sys/bus/pci/drivers/sdhci-pci/bind  

Instead we chose to use the initramfs. This has the additional advantage that is has a debugshell with busybox which will allow you to boot and investigate if your external image is not found or has problems.

Installing the kernel quickly

You would normally not do this manually. It is far easier to create a complete image with kernel, initrd, the kernel modules and all the rest of the rootfs by following Building the image and Installing the image to eMMC. And of course, if you build a package repository you can use apt to update the kernel.

However, when you are just doing kernel development, or bisecting to find a bug the following procedure will save a lot of time

Warning: Since you would be copying kernel files manually apt may loose track of installed packages. But since you know what you are doing, you would just flash a new image when your done, right?

bitbake linux-yocto
scp initrd and bzImage-6.16.0-rc6-edison-acpi-preempt-rt (example) from out/linux64/build/tmp/work/edison-poky-linux/edison-image/1.0/rootfs/boot/ to /boot on Edison.
On Edison mv /boot/initrd to /boot/initrdNew-6.16.0-rc6-preempt-rt
scp 6.16.0-rc6-edison-acpi-preempt-rt (example) from out/linux64/build/tmp/work/edison-poky-linux/edison-image/1.0/rootfs/lib/modules/ to /lib/modules/ on Edison.
scp from altboot.sh from meta-intel-edison/utils/flash/ to /root on Edison.
On Edison run ./altboot.sh 6.16.0-rc6 preempt-rt, this will create links for the alternate kernel in the /boot directory.
On Edison run fw_setenv switch 1 ; reboot, this sets the environment variable for U-Boot to try to run the alternate kernel. If it fails it should automatically fallback to the default kernel. If it succeeds if will continue to run the alternate kernel on next reboot until you do 8.)
On Edison run fw_setenv boot_count 1 ; reboot.

The above could give a fairly fast debug cycle. For reference on my machine I can do about 1 bisect per 10 minutes.