Tim Bird: /* Description */

2009-12-22T00:55:38Z

‎Description

Tim Bird: add project proposal

2009-12-22T00:55:09Z

add project proposal

New page

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

; Proposer : Wolfgang Denk

== 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 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)

; Scope : 3...5 weeks

== Contractor Candidate ==
Interested and willing to work on this: DENX

== Comments ==

[[Category:Project proposals]]

@@ Line 49: / Line 49: @@
 U-Boot, and at least achieve the following goals:
-* enable relocation (reduce differences to other architectures; make
+* enable relocation (reduce differences to other architectures; make features available there also available on ARM)
-  features available there also available on ARM)
+* enable real cache support (significantly reduce boot times on many systems)
-* enable real cache support (significantly reduce boot times on many
+* improve support for systems with multi-stage boot (like booting from NAND, DataFlash, or using a ROM based bootstrap loader)
-  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

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

Tim Bird: /* Description */

Tim Bird: add project proposal