ARMUBootFeatureAndPerformance

Revision 7 as of 2010-06-01 15:57:30

Clear message

Summary

The version and feature set of U-Boot on the various supported ARM platforms varies widely. In Maverick we will begin to migrate to one U-Boot version. Also, with device tree support coming to the ARM kernel for Maverick, we will do a reference implementation of device tree passing in u-boot.

Release Note

With the addition of device tree support, the bootm command now takes an optional third argument. See TBD for details.

Rationale

Version Consolidation

Currently each ARM platform has a unique source archive and build process. For Maverick we want to begin to converge on one U-Boot version to make our lives simpler.

Device Tree

Device tree support for ARM is going into the kernel for Maverick. Booting a device tree kernel from old firmware is possible via a wrapper/prefix to the kernel. However, a better approach is to have device tree support in the boot loader. In order to help define the bootloader requirements for booting a device tree enabled kernel we need to provide a reference port.

User stories

Developer A wants to be able to boot both old ATAG kernels and new device tree kernels on her Beagle board. Without device tree support in u-boot she will need to add an additional step to her kernel build to wrap the kernel and device tree in a fit archive.

Developer B wants to add device tree support to his boot loader but there is no spec or the spec is a bit fuzzy. He can use the ubuntu reference device tree enabled u-boot source as a second reference.

Developer C needs to be able to switch between old and new kernels. The ubuntu reference u-boot will load both old and new kernels.

Assumptions

Current head of tree of git.denx.de has support for i.MX51 and OMAP3. OMAP4 support is beginning to arrive via patches on the u-boot mailing list. Marvell Dove has no support upstream.

The first device tree passing implementation will be for SD card boot only. The device tree will reside in a file on the VFAT partition. For NAND boot, repartitioning would be needed to reserve a place for device tree storage.

Design

Using existing u-boot source, add support to current upstream. Abandon the use of the HAL from the current implementation and do a more conventional port that will be easier to get accepted upstream.

The convention for passing the device tree to the kernel is being defined. See discussion on the device tree discuss mailing list. U-boot already supports device trees on PowerPC, Sparc and 68K platforms. The device tree support for ARM will be based on these two resources.

Implementation

The device tree support implementation will be based on existing device tree support already in u-boot.

Version consolidation will begin by adding Dove suppor to current upstream head. Our existing Dove U-Boot source will be used as reference but the new port will likely not use the "bolt on HAL" approach.

UI Changes

The main visible change from adding device tree support will be to the bootm command. It will now have 3 parameters kerneladdr, initrdaddr and devtreeaddr. This is already the case for PowerPC. This change is already documented in u-boot.

Code Changes

The Dove port will add/modify appropriate files/directories as does any port to a new SOC and board.

Most device tree changes will be in lib/arm/bootm.c in the u-boot source tree. There may be other changes, if for example there are byte endian bugs in the existing device tree code as there were in the kernel.

Migration

TBD

Test/Demo Plan

The new Dove port should be able to boot a kernel.

The device tree enabled u-boot should be able to boot both new device tree enabled kernels and old legacy kernels.

Unresolved issues

This spec only addresses the version consolidation and device tree stories and ignores the other possible features/improvements discussed at UDS-M. See the BoF notes below for details of all the possible efforts that could be persued. Here are the highlights along with why they are not included.

  • Performance: How to implement this will depend on how the ARM-Soft Boot Loader effort turns out. It is best to follow and participate in that effort then revisit u-boot later.
  • Recovery: Again the ARM-Soft Boot Loader effort will touch this eventually. If a kernel based soft boot becomes the suggested best practice then recovery will likely happen in Linux user land and not in the boot loader. Catastrophic failure recovery may still require bootloader support and that issue should be revisited in a later release.
  • Improved access to u-boot env settings via wrappers for fw_printenv and fw_setenv. This will need to be revisited later especially in terms of soft boot loader. Perhaps u-boot env settings will become less important.

  • BootLoader spec: One action item from the BoF was that Ubuntu should have a bootloader specification and a reference implementation. This spec address the later partially but ignores the former. The bootloader specification needs to be a separate effort.

BoF agenda and discussion

UDS-M 

=== UBoot Features and Performance ===

Discussion of improvements that can be made to UBoot,
including new features and performance improvements.

=== Features ===
 * framebuffer support with console parallel on screen as well as serial
 * tools to access, store/recover and modify uboot config easily from the runnig
   system (uboot-envtools exists, but could need a lot of enhancements)

==== Device tree support options ====

 * Wrap device tree and kernel in a blob
 and do nothing until ARM device tree convention
 is defined.
 * If Maverick gets device tree support for ARM
 then add support for ARM to U-Boot
 using PowerPC code already there as reference.
 There may well be endiness issues as reported in kernel.
 * The location of the device tree binary data is boot media dependent.
 It must not be embedded in u-boot (aka non updateable)
 * MAC address, console, 
 * Modifying device tree in u-boot is OK, but we probably need to constrain the
   amount of changes.  Risk "bricking" board with too many options in u-boot.

==== Recovery ====

How does one recover a "bricked" unit?
 * End user fix, not usually an engineering problem
 * Atmel AT91 boards use Atmel SAM-BA tool (Win/Linux)
 * ST-Ericsson NHK-15 uses Win32 tool
 * Beagle board - SD card
 * Marvell - Sheeva plug, recovers u-boot, rootfs, kernel, etc
   also supports downloading images to a USB
   * Marvell policy is to not touch u-boot once it's installed
 * Android fastboot - binary image to NAND via serial protocaol or USB
                      no filesystem - difficult for end users
 * More NAND with multiple partitions - makes a lot of sense, but expensive
   usually need to use in conjunction with internet images
 * Grandma approach is to hold a button and recover a minimal system that allows
 the download of a proper image/packages
 Note. Apt-get system requires valuable storage space to install << point worth
 exploring in a different session
 * u-boot should include a frame buffer driver to not display the "black screen"
  * however, development here is quite expensive - effort better spent in kernel
 * (Soft bootloader session scheduled for Friday)

==== SOC Vendor Specific Solution ====

Most(all?) ARM SOCs have recovery boot functionality
that use serial, USB (host or device) or SD/MMC,
however, each vendor is different.
 * i.MX has HAB toolkit
 * OMAP Beagle is easy to recover via SD and a custom
 boot command for u-boot (same with OMAP3 based BUG 2.0 which can be booted from 
 dead image just with SD card).
 * OMAP will also boot from USB or serial connected to a host running
 OMAP specific USB flashing utility.
 * Others?

All the solutions above need different support on host.
It might be possible to write a single utility with different back ends.
The back ends would likely require vendor proprietary bits.
A vendor neutral solution would be more desireable.

==== Vendor Neutral Recovery ====

Android Fastboot is an example of this.
Android Fastboot has nothing to do with booting fast.
It is really a protocol over usb plus a host daemon and
utility for making reflashing easy.

 * Works with USB
 * OMAP-Zoom Android U-Boot already has this

==== Redundant Partitions ====

If NAND is not a premium then the device can have
multiple copies of factory kernel and rootfs
including one that is read only and never used 
except for factory recovery.

=== Other Boot Modes ===

 * Low-power boot (100mA use case)
  * Start USB far enough to drive 500mA out port (allows enumeration of the USB)
  

=== Better U-Boot Userspace Config Support ===

martinbogo: Need tools to modify U-Boot env from userland.
ogra: The standard fw_setenv and fw_getenv are included in the omap image.
Could add wrappers to make them easier to use.
Need utility to extract ascii from u-boot boot.scr script image.
jcrigby: The strings command works for this.
 * tools in u-boot source tree can make this easier Loic has patches for whoever
   takes this task.
 * editing environment is quite dangerous.  Usually a cause of bricking board

=== Feature unification ===

U-Boot functionality depends on
 * U-Boot version
 * What features are turned on in board config.h
 * What board specific features have been added for a given platform
Each board has a different level of functionality
Do they need to be unified?
 * 2 configs: 1 for developer/1 for end user
  *  Ex - leaving SATA enabled wastes power
  * Hardware validation used in system test, but not for customer

Better upstream relationship between vendors and u-boot upstream would improve 
the situation a lot (often vendors develop behind closed doors here)


=== Performance ===
==== Fast-path ====
* Skip unnecessary initialization
  * Skip PHY negotiation
* Skip u-boot? With some work on NAND the secondary loader
(x-loader for OMAP, nand-spl loader for i.MX)
boot linux directly instead of loading u-boot?
  * Skip u-boot completely use x-loader (TI example) http://omappedia.org/wiki/Bootloader_Project
  * http://omappedia.org/wiki/E-MMC_boot#You_can_boot_omap3630_without_x-loadet
  * u-bootv2 (not related to u-boot)

=== Action Items ===
* Ubuntu should recommend boot architecture requirements - Loic
 * divergence is the result without this document
 * Vendors need to have input into this document
 * questions to be answeered: cost, objectives, required flash, device tree
   requirements, fast boot path
* Specification definition - instead of specifying a bootloader
 * reference design would be helpful but not required
 * Ubuntu can then define minimum requirements for a bootloader

CategorySpec