CELF Project Proposal/Rework ARM architecture support in U-Boot

From eLinux.org
Revision as of 00:55, 22 December 2009 by Tim Bird (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Fix some design issues in the U-Boot implementation for the ARM architecture
Wolfgang Denk


U-Boot is a pretty popular boot loader for embedded systems, including and especially for systems based on the ARM architecture. Unfortunately, the ARM implementation has some deficiencies:

On other architectures (like PowerPC), we normally use code to automatically determine the memory sizes on a board. One binary image of U-Boot can run unchanged on boards with different sizes of flash and RAM. U-Boot will always relocate itself to the end of the available RAM, thus leaving the maximum possible amount of RAM available for the user, for example to load Linux kernel and root file system.

If we need to reserve memory, like for protected RAM (pRAM), or for a frame buffer that will be shared between U-Boot and Linux (so you can have a splash screen right after power-on which does not even flicker when Linux boots), or for a shared log buffer (so you can for example process U-Boot's Power-On Self Test messages in Linux using standard syslog tools, or you can use U-Boot to dump the Linux kernel's crash messages post mortem in U-Boot or in Linux after rebooting the system), we just shift the relocation address for U-Boot down by the required amount.

If you need a different amount of pRAM, just "setenv" the "pram" environment variable, and U-Boot will auto-adjust at the next reboot.

On ARM, we don't do any such relocation, we link the image for a fixed address in RAM. So assume you have a board that can come with 32 MB or with 64 MB of RAM. You will have to link U-Boot close to the end of the 32 MB border - say to run at 31 MB. On a 64 MB board this means it sits right in the middle of available RAM - you have some 63+ MB of RAM free, but you cannot find more than 32 MB contiguous space. If you need pRAM or framebuffer or log buffer, you will have to configure sizes at compile time, and then you cannot change it at run time. Systems with variable RAM sizes will always suffer from the same restrictions like on the board with the smallest RAM configuration.

Also, the initialization sequence on ARM is sub-optimal; for example, on most systems caches are not effective, so booting (especially loading big images from storage like NAND etc.) is slow.

This project shall fix the problems in the ARM implementation of U-Boot, and at least achieve the following goals:

  • enable relocation (reduce differences to other architectures; make features available there also available on ARM)
  • enable real cache support (significantly reduce boot times on many systems)
  • improve support for systems with multi-stage boot (like booting from NAND, DataFlash, or using a ROM based bootstrap loader)
3...5 weeks

Contractor Candidate

Interested and willing to work on this: DENX