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

Ulf Samuelsson
2007-07-03T17:18:45Z

tis 2007-07-03 klockan 10:52 -0600 skrev Grant Likely:
> On 7/3/07, Carsten Schlote <c.schlote@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