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

[Grant Likely]

On 7/3/07, Carsten Schlote <c.schlote at konzeptpark.de> wrote:
> The relocation issue:
>
> For the real targets U-Boot should be relocateable. Why? Simply because
> I might want to run something else than Linux on a target. U-Boot
> shouldn't occupy IRQ Vectors in RAM, nor should it be located in the
> middle of available RAM - simply because my 'OS' might want to use it as
> a single large block.

I actually think we should go a step farther.  I think we should split
u-boot into two linked images; a setup wrapper and u-boot proper (in
the same way that the linux kernel is wrapped by a zImage wrapper).
The sole purpose of the setup wrapper is to configure RAM and copy the
u-boot proper image to location at the end of RAM.  The u-boot proper
image starts with the assembler routines to setup the C environment
and fixup the relocation symbols before jumping into main.

The goal should be to get into the u-boot wrapper C environment as
soon as possible.  The wrapper shouldn't do anything other than
initialize RAM, copy code, and provide a little bit of debug output.
As much as possible should be deferred to u-boot proper.

The advantage of this approach is that it makes it easier to handle
weird booting arrangements.  As long as something sets up ram and
copies u-boot proper; then u-boot can run (which is very similar to
what some ARM and one of my Xilinx Virtex ports already does.  It also
allows a single u-boot image to be used for booting from both RAM and
ROM (which I think is helpful).  It would also make it trivial to turn
dynamic relocation into a configuration option.

The disadvantage is that the setup wrapper cannot use the full
facilities of u-boot proper.  Every routine used by both the setup
wrapper and u-boot proper will exist in both images.  If it weren't
for the desire to have console output before relocation, I think this
approach would be the clear winner.  However, the requirements as I
understand them are for the boot code to fetch the console
configuration out of the environment and spit out some boot info.
This of course complicates things because it means the wrapper needs
more functionality.

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.

Other approaches probably exist.

Regardless of the approach, the choice of which to use can be made
per-board, which is a suitable tradeoff between size and
functionality.  My gut feel is that for most boards, the boot wrapper
will be very small, but I need to do some experiments to know for
sure.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195