ARMUBootFeatureAndPerformance

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. Finally, U-Boot boot time will be profiled to find areas of potential improvement and the top offenders will be addressed.

Release Note

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

Rationale

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 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. To facilitate this we will provide a specification and reference implementation of how a device tree blob is passed to an ARM device tree enabled kernel.

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. TI has contracted Steve Sakoman to add OMAP4 support to mainline.

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 and Implementation

Steve Sakoman has been contracted by TI to bring OMAP4 support to mainline. john.rigby@linaro.org will be helping with review and testing. Support for i.MX51 exists in mainline, however we do not know if the mainline version has all the features necessary to replace the current Freescale v2009.08 based version. Necessary features that are missing will be added using the Freescale version as reference.

The convention for passing the device tree to the kernel is being defined on the device tree discuss mailing list(http://lists.ozlabs.org/pipermail/devicetree-discuss/2010-May/002160.html). U-Boot already supports device trees on PowerPC, Sparc and 68K platforms. Device tree support for ARM will be based on these resources.

To address the requirement of improved boot performance, current U-Boot will be profiled to find what code paths are responsible for the majority of time spent in U-Boot. After these areas are identified, changes will be made to code and/or configuration to speed up boot time.

UI Changes

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

Code Changes

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. Changes to address performance will be determinded after profiling has been completed.

Migration

TBD

Test/Demo Plan

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

The new U-Boot should be measureably faster than the current one.

OMAP3, OMAP4 and i.MX51 U-Boot binaries should be buildable from the same source package.

Unresolved issues

This spec only addresses the version consolidation, device tree support and performance 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.

  • Recovery: 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 addresses the latter partially but ignores the former. The bootloader specification needs to be a separate effort.

  • Marvel Dove U-Boot is based on an older version of U-Boot. May want to help bring it up to latest in a future release.

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

Specs/M/ARMUBootFeatureAndPerformance (last edited 2010-06-08 04:22:24 by c-98-202-243-83)