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.
With the addition of device tree support, the U-Boot bootm command now takes an optional third argument. See TBD for details.
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.
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.
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. email@example.com 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.
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.
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.
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.
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
=== 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