ARMSoftbootLoader

Differences between revisions 10 and 11
Revision 10 as of 2009-01-19 06:24:41
Size: 7890
Editor: cpe-67-242-211-173
Comment:
Revision 11 as of 2009-01-19 06:41:11
Size: 8077
Editor: cpe-67-242-211-173
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
 * '''Packages affected''': kernel postinst, d-i; anything that installs a kernel or initrd, or acts as a wrapper for updating it  * '''Packages affected''': kernel postinst, debian-installer, update-initramfs, ubiquity
Line 55: Line 55:
=== UI Changes === === KBoot UI Changes ===
Line 59: Line 59:
=== General UI Changes ===

No UI changes outside of kboot are expected.
Line 61: Line 65:
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. 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. 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.
Line 65: Line 69:
Install the kboot image to flash. Boot the device from the HDD or other similar location. Install the kboot image to flash. Boot the device from the HDD or other similar location, and make sure that Ubuntu properly starts.
  • Launchpad Entry: arm-softboot-loader

  • Created: January 13th, 2009

  • Contributors: Michael Casadevall, Emmet Hikory

  • Packages affected: kernel postinst, debian-installer, update-initramfs, ubiquity

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

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.

The ARM board will automatically load its on board bootloader, which can't load the root filesystem device, it will be able to load the starter kernel. 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 not platform-specific; it can be shared across all boards based on the same architecture; the starter kernel however is. 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; 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.

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 greatly 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.

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).


CategorySpec

Specs/ARMSoftbootLoader (last edited 2010-05-25 13:20:08 by 5ac8847a)