ARMSoftbootLoader

Differences between revisions 32 and 33
Revision 32 as of 2009-06-02 18:52:33
Size: 10017
Editor: cpe-66-65-150-156
Comment:
Revision 33 as of 2009-06-02 18:53:38
Size: 10023
Editor: cpe-66-65-150-156
Comment:
Deletions are marked like this. Additions are marked like this.
Line 94: Line 94:
{{{
Line 164: Line 164:
}}}
  • Launchpad Entry: arm-softboot-loader

  • Created: January 13th, 2009

  • Contributors: Michael Casadevall, Emmet Hikory

  • Packages affected: kernel postinst, kboot-armel

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 or similar location.
  • 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.

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. As a short term solution, using a first-stage softbootloader is a quick and easy alternative. This first-stage bootloader can bring up whatever media necessary to find the main kernel and its initramfs, and then kexec() into said kernel, allowing normal system startup.

In the long term, we should be looking with ARM to create a standardized boot environment such as open firmware that can load a kernel directly from all sources and boot it, vs having deal with chainloading kernels.

Implementation

Existing Solutions

Several pre-existing solutions already exist to solve this problem, working by using the kexec() method in the kernel to do the chainloading.

  • kboot
    • http://kboot.sourceforge.net/

    • Original proof of concept soft bootloader created around kexec
    • Only supported on ia32, but written in shell script, so should work on ARM since its just a wrapper over kexec
    • Allows direct shell access in initramfs environment
    • Uses a kboot: prompt similar to lilo or silo
    • No longer developed upstream
  • petitboot
    • http://ozlabs.org/~jk/projects/petitboot/

    • Graphical bootloader for the PS3
    • Based around kboot+ps3, uses libtwin and the framebuffer to display the contents of menu files
    • Mixture of C and shell
    • Development stems to be dead
  • kexecboot
    • http://projects.linuxtogo.org/projects/kexecboot/

    • Graphical bootloader for Angstorm Linux (which is an ARM based distribution)
    • Written in C
    • Seems to support ext2-3, cramfs, reiser3, xfs, jfs, and lvm from looking at the source code
    • Graphical, works via /dev/fbX
    • Active upstream
    • Worked on ARM
    • Will need branding changes (based off screenshot, it clearly shows Angstrom Linux in the menu screen)

UI Changes

  • kboot and petitboot's out of the box UI should be acceptable
  • kexecboot's branding will have to be changed
  • Maybe nice to have a GRUB style countdown vs. a full graphical boot menu unless the later is pulled up in full

Code Changes

The installer will still have to have new subarchitectures handled as per usual due to the different kernels required per architecture (which the softboot loader does not resolve as of yet). The kernel will have to be setup to build both the boot kernel, and the standardized kernel, and the update-*bootloader* script will have to be created to handle management of whatever boot configuration file is used.

Test/Demo Plan

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

Unresolved issues

BoF/Discussion

== Current Situation ==
 * While there are a couple common boot loaders, commonly each SoC has a device-specific bootloader
 * In the case of kernel issues, the user often has to use low-level debugging tools
 * kernel must usually be place in specific media of limited size

== Objective ==
 * Create an interface between the SoC-installed kernel and the distribution-supplied kernel

== Boot loader mechanism ==
 * Start a tiny kernel and minimal ramdisk
 * Discover hardware and available kernels
 * kexec() into a selected kernel from alternate media

== Existing Solutions ==
 * Based on Linux
 * Start a tiny kernel and minimal ramdisk
 * Discover hardware and available kernels
 * kexec() into a selected kernel from alternate media
   * Angstrom
   * kboot
   * petitboot
 * OpenFirmware and DeviceTree
   * For the SoCs we currently target will only work by chainloading from
     RedBoot / U-Boot
 * Grub2?
 * UEFI?

== Requirements ==
 * Be able from the installed system to:
   * Maintain (add/remove/update) multiple kernels + initramfs
   * Change the default kernel cmdline
   * Select the kernel and change its cmdline for a single boot
     * Output list of kernels on the graphical outputs
     * Take input from mouse/keyboard

== Assumptions ==
 * Vendor boot solution is capable of loading separate kernel and initramfs
 * Users will be happy with a text-based interface
 * Boot speed is not a critical determinant in the solution selection

== Issues ==
 * kexec broken
 * Slower boot
 * Needs two kernels flavours (normal and lite-version) for each SoC
 * Some drivers have issues under kexec()

== Long term versus short term solutions ==
 * Need display output and mouse/keyboard input right now, which only the linux
   kernel provides for the SoC we target for karmic; short term we need linux in
   the stack
 * Might want to recommend OpenFirmware / DeviceTree as the long term solution

== Short Term Solution ==
 * Stripped minimal kernel
   * What about using the same kernel, and just trimming initramfs?
 * '''very''' small initramfs, only handling the limited activities desired (e.g.
    scanning USB can take 10 seconds); no udevadm settle
 * Stripped down initramfs without glibc?
 * Might write a C binary which does the scanning and all in the future, but
   should use our initramfs-tools infrastructure for now -- even if it's a bit
   slow
 * http://people.ubuntu.com/~ogra/arm/bootmenu has a (way to big) PoC script
 * Target 2M flash, with ~ 1.5 M available for kernel + initramfs

== Actions ==
 * Review current solutions (NCommander)
 * Investigate building initramfs without glibc (ogra)
 * Investigation of the state of OpenFirmware (cking)
 * Investigation of second-stage bootloaders (jerone)


CategorySpec

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