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

[Ulf Samuelsson]

tis 2007-07-03 klockan 10:52 -0600 skrev 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.


The AT91-Bootstrap used by AT91SAM926x is less than 4 kB,
and supports console output as well as loading u-Boot
from the precompiled flash memory into SDRAM.

You only support booting from a single flash type in each
binary, which is stored inside that memory.

There is no interactive communication with the user, so 
this starts when u-boot is loaded.

It does not read the environment, since it should be useable
to load any application into SDRAM, not just U-Boot.

It is GPL, so I guess that it can be used as a base for this.
-- 
Best Regards,
Ulf Samuelsson