ARMSoftbootLoader
Launchpad Entry: arm-softboot-loader
Created: January 13th, 2009
Contributors: Michael Casadevall, Emmet Hikory
Packages affected: kernel postinst, d-i; anything that installs a kernel or initrd, or acts as a wrapper for updating it
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.
- Gamma's ARM device can't directly boot off the hard drive, which is the only connected storage large enough to support kernel updates.
- Delta wants to reinstall Ubuntu ARM, but since it is difficult to create CD images for each ARM platform, have the image use the softboot kernel to load up, as well as the ability to use this as a failsafe boot mechanism (i.e., if every other kernel on the system is hosed, boot from the IPL kernel).
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
Design
The ARM board will automatically load its on board bootloader, which can't load the root filesystem device, which will load the starter kernel. The starter kernel will mount all devices it can find, and look for a menu file, and display a boot menu ala to grub or something similar. Once a kernel is found, kexec() is used to execute it, and control passed from the starter kernel to the main kernel. By having a standardized soft bootloader in the initrd, we have one set of d-i/update-initrd/etc routines for ARM in general.
Implementation
The basis of any bootloader that is used as a soft boot loader depends on the kexec mechanism of the kernel. kexec loads a kernel into memory, and then when receiving a syscall from userland, loads a short relocation stub, and then passes execution to the second kernel. This allows us to load the kernel and initramfs, and rootfs anywhere from where the first kernel sees it.
The soft boot loader kexec 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; porting busybox to dietlibc should help keep the size to a bare minimum; a quick Google search reveals patches exist to already do this for various versions of busybox.
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.
I'd also like to be able to load a graphical boot menu as such as petitboot; since size is an issue, this graphical loader should be loadable from a root device if we can't get it down to under the 1.5MB range, but this is optional, having kboot work alone is acceptable.
UI Changes
I'd like to base the UI on grub or something similar. Perhaps do something graphical like petitboot. TBD
Code Changes
All tools which install or update kernel and initrds directly (i.e., not through update-initrd) would have to be modified to handle this arrangement, just like any new architecture or platform in ubuntu.
Test/Demo Plan
Create a basic kboot image, and then implement additional changes on top of it to meet our requirements.
Unresolved issues
- None, for the moment