Ubuntu Wiki

• Launchpad Entry: arm-softboot-loader

• Created: January 13th, 2009

• Contributors: Michael Casadevall, Emmet Hikory

• Packages affected: kernel postinst, update-initramfs

Summary

Provide a softboot loader for ARM to address outstanding issues with the wide variety of methods used to boot ARM devices, in a similar manner to that does to support ps3. Such a softboot loader would be installed on system flash or trusted boot media, to sufficiently enable the system to boot from more common devices (USB sticks, optical drives, hard drives, etc.).

Release Note

To facilitate standardization of ARM use with that of other architectures, a new softboot loader is provided for porting to specific system boards, providing a standard boot interface for all ARM users.

Rationale

One of the major problems we have with the ARM architecture is that there is no standardized boot framework like EFI/BIOS on a PC, or OpenFirmware on a Mac, which makes supporting Ubuntu on ARM a rather difficult process since not only the kernel must be tweaked, we also must add support to d-i for each boot configuration we want to support. Additionally, some ARM hardware is designed for embedded solutions, and may not be capable of booting in an expected manner, or using existing procedures to allow for selection of updated kernels when upgrading. Having a bootloader shim will create a much more robust booting solution.

Debian does support the ARM platform despite the non-standardized boot environment, often times directly writing to the flash chip, without having a fallback mechanism in case of a bad flash. This is fine for developer systems, or other individuals who will know how to access the bootloader directly, but unacceptable for end-users who are unlikely to have a serial console, or be willing to try and telnet into RedBoot, and then type cryptic commands to download and flash a new kernel and ramdisk.

Use Cases

• Alpha buys a new ARM laptop, and is able to (re)install Ubuntu without having to worry about changing the bootloader or entering cryptic commands at a bootloader.
• Beta wants to go back to the previous kernel after the new one stopped his system from booting and doesn't need to access the internal bootloader to load a new image over a serial terminal or something equivalent.
• Gamma's ARM device can't directly boot off the hard drive, which is the only connected storage large enough to support kernel updates, the soft bootloader stored in flash however can, and allows him to have an up to date kernel.
• Delta wants to reinstall Ubuntu ARM, and uses the soft bootloader to load a kernel and inital image off the installation media.

Assumptions

• Devices for which such a softboot loader are required are capable of booting off persistent on-board flash.
• Vendor supplied bootloaders are able to automatically load a starter kernel and softboot environment
• A starter kernel can be constructed with support for all necessary drivers to mount target boot filesystems.
• Don't care if the on-flash kernel matches the system kernel, or has all the patches since under normal operating conditions, it will be running up to 30 seconds - 1 minute max
• There is no standardized ARM BIOS
• kexec() will work on all target ARM hardware
• We want to build the soft bootloader in the archive itself, even though its not something Ubuntu doesn't actually touch, or install

Design

The basis of any soft boot loader is to get a system to a point where it can load its main operating system. As most ARM bootloaders are unable to access IDE/USB/SCSI/etc. devices, it makes more sense from an engineering point of view to use the Linux kernel to load all the necessary devices, load the main kernel image, and the boot into it.

Most ARM boards, when powered up, load a simple bootloader such as RedBoot or uBoot. These bootloaders usually no concept of USB, SATA, or other storage devices aside from the flash chip that they were started from. Since we wish to keep and store our main kernel on a larger storage device such as an SATA hard drive, we need to bring the system up to a point where it can mount the root file system, via means of a starter kernel embedded in flash along with the initial bootloader. The starter kernel will load a small initramfs with busybox and kboot on it, with all the necessary modules to load the root filesystems. The /etc/rc script on the image will start kboot, which provides a lilo like interface allowing for automated booing, as well as the ability to specify kernel, initrd, and kernel command line options.

The kboot initrd is platform-independent; it can be shared across all boards based on the same architecture; the starter kernel however subarchitecture specific (i.e., one kernel, one board). The current plan is to have a package which builds the kboot initrd, which is shared, then grab the source from the linux-source package, provide the .config file, and then build a kernel with that .config, generating a binary blob which can be flashed.

Implementation

The soft boot loader kboot can be used for this purpose; it was created as a proof-of-concept for exactly this kind of use case. As kboot's upstream is fairly dead (no release in over two years, mailing lists overrun with spam and little signs of life), we'll have to take their last release, and then modify our code to our needs. Offhand, the stock kboot builds a uclibc/busybox based initrd, which is undesirable since building against uclibc requires an actual cross-compiler, as well as being fairly large; linking busybox against eiter

As we would want busybox tailored to our specific needs with an absolute bare bones basic config, we can simply build it as part of kboot source package. Once busybox is built, kboot will be installed with it into a folder and a initramfs will be created. Once that's created, we want a barebones kernel with kexec+initrd+whatever we need to find the root device support which is just enough to load said initrd. The kernel supports embedded the initramfs right into it directly, and as this would make us almost completely bootloader independent (although most bootloaders can handle an initrd, some such as Freescale's dBUG can't, and its important that we have options open for a large variety of platforms). The output file should be a binary blob suitable for flashing by an OEM vendor or end user.

Edit conflict - other version:

Edit conflict - your version:

End of edit conflict

Handling LVM/RAID/encryption booting

kboot can load and mount LVM/RAID/encrypted filesystems since it can load in theory any filesystem mountable by the starting kernel. That being said, such support maybe impossible since the necessary kernel modules + helper scripts may be too large to fit on a 1.75MB flash. The other option is that we'll have to have a decrypted /boot partition with the main kernel which has all the necessary boot bits (this is how LVM/RAID/etc. are supported on non-x86 architectures, so there is president for this method)

KBoot UI Changes

kboot itself is command line based, providing a kboot: prompt, similar to older versions of lilo. While this is acceptable, its not ideal. If possible, a graphical boot UI should be made available; petitboot is a kboot derivate which creates said graphical boot menu. Under normal circumstance, it should simply print a series of text messages such as "Booting Ubuntu in 3 ... 2 ... 1", and "Press ESC to access boot menu", similar to what GRUB currently does.

General UI Changes

No UI changes outside of kboot are expected.

Code Changes

All tools which install or update kernel and initrds directly (i.e., not through update-initramfs) would have to be modified to handle this arrangement, just like any new architecture or platform in ubuntu. For packages in main, this should simply be d-i, ubiquity, the kernel itself, and update-initrd. kboot has a fairly specific menu file format similar to the one used by grub and lilo (and many other bootloaders). The proposed update-kboot will manipulate this file similar to the update-grub/update-lilo/update-etc scripts. We can likely recycle whatever script the PlayStation 3 port uses.

dietlibc's last released version doesn't support the ARMv5 EABI instruction set. Its author has moved to stop doing point releases, and recommends to always use the CVS HEAD. Updating the package will be a requirement should we choose to use it over uclibc. In addition, as it stands, dietlibc CVS HEAD currently segfaults out of the box when with -Os optimization.

As for kboot itself, its build system is fairly hackly, depending on specific versions of packages, and hardcoding in things like architecture specific options. If we use dietlibc, this build system should be overhauled, but if we use uclibc, then we should simply add kboot to buildroot, and then deal with the unique issues of building a cross-compiler in the build environment. Using buildroot also handles kernel (cross)compilation, initramfs generation, and the source package can be made arch all, and all the initramfs/kernel combinations being successfully built in a single pass.

dietlibc vs. uclibc

=== dietlibc ====

• Pros:
  • Smaller than uclibc
  • Doesn't require a cross-compiler
• Cons:
  • Requires we update and fix dietlibc on ARM (CVS HEAD seems to work ok when no -O flag is set)
  • Have to roll our own infrastructure

uclibc

• Pros:
  • Can leverage buildroot for easy initramfs image generation, and customization
  • buildroot also handles (cross)compiling kernels, so we simply need to provide .config files for any architectures aside from ARM we wish to support
  • uclibc seems to be happier on EABI ARM than dietlibc
  • busybox and supported utilities already supported by buildroot
• Cons:
  • Need to build a cross-compiler in the build environment
  • uclibc is larger than glibc

Test/Demo Plan

Install the kboot image to flash. Boot the device from the HDD or other similar location, and make sure that Ubuntu properly starts.

Unresolved issues

• How do we put these images on flash chips from vendors? (this is relatively undocumented in most bootloaders).
• should we use uclibc or dietlibc? dietlibc is easier to work with since it doesn't require a cross-compiler, but uclibc is better supported with busybox.

CategorySpec