Proposer: Wolfgang Denk

Summary: Fix some design issues in the U-Boot implementation for the
ARM architecture

Description: 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 acchieve 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)

Scope: 3...5 weeks

Interested and willing to work on this: DENX



Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@...
Don't tell me how hard you work. Tell me how much you get done.
-- James J. Ling

Wolfgang Denk wrote:

Summary: Fix some design issues in the U-Boot implementation for the
ARM architecture

Thanks. Proposal page is at:
http://elinux.org/CELF_Project_Proposal/Rework_ARM_architecture_support_in_U-Boot

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================