[U-Boot-Users] U-Boot-NG ?

[Scott Wood]

On Tue, Jul 03, 2007 at 10:52:23AM -0600, Grant Likely wrote:
> I see a few approaches to handle this:
> 1. eliminate console output from the wrapper.  (by far the easiest,
> but provides no clues when RAM configuration fails).
> 2. cut down wrapper functionality in the wrapper (this is just early
> boot after all).  Eliminate printf() support in the wrapper and make
> due with puts().  Reduce the wrapper console driver to output only.
> The problem still remains that the env needs to be read to know how to
> configure the console.
> 3. Same as two; but don't read the environment.  Use a static console
> config instead.

4. Include full console functionality in the wrapper, but only for debug
builds.  A simple printf() really shouldn't be that big, anyway.  This
also eliminates the need to get console information from the environment,
since you can hardcode it for debugging purposes.

5. Export common code as a jump table for the second-stage code to call.

The three main advantages I can see with a two-stage approach are:

1. Devices with very small flash could ditch the second-stage u-boot
altogether and put something custom there.

2. Changes to code in the second-stage could be tested without needing to
use JTAG to reflash if it doesn't work, by using some software-readable
switch (or possibly warm-boot v. cold-boot) to tell the wrapper which
stage-2 to use.  I've seen several boards that have software switches but
no alternate-boot-location switch.

3. It enforces a certain amount of clean separation between the two
components, making it easier to alter the stage-2 layer.  For example,
stage-2 may be much easier to port to a new board than stage-1, and thus
it'd be easier to get improvements to things like device-tree handling on
a board that has been unmaintained for a while.

-Scott