The following is a collection of issues currently discussed on the
u-boot-users mailing list - especially for the 2.x redesign.
I put them here to make it easier for everyone involved in U-Boot
development to get a more or less current list of requirements with
a simple web browser. Feel free to add or change requirement items
as needed to reflect the current status.
--
CarstenSchlote - 08 Jul 2007
Common Design Requirements / U-Boot 2.x considerations
- Support for very early debug output. This early output might be
implemented as simple macros using fixed baudrate output,
but whenever possible the standard interface (i. e. taking into
account user settings like console port, baud rate, etc.)
should be used.
- Relocation from ROM to the end of available DRAM
(auto-detected instead
of fixed link address).
- If memory (RAM, flash) consists of several banks,
then U-Boot shall normally map these as contiguous regions.
- Simplistic device model. Hardware is initialized just before and
used only for the time of operation. Hardware must be released and
reset to a defined post-reset state after operation.
- Shall operate in polling IO mode.
Interrupts may be used in few, carefully selected cases,
if possible as a configurable option.
- Shall initialize only such peripherals used by U-Boot itself,
and must deinitialize them after use.
Note that especially the deinitialization is mandatory!
- Shall use C language whenever possible. Reduce assembly sources
to the absolute minimum required (e.g. reset code, IRQ/Expt Shells)
- ... tbd ...