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

[Sascha Hauer]

On Tue, Jul 03, 2007 at 10:52:23AM -0600, Grant Likely wrote:
> 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.

I think for most cases this is not needed. As long as you do not use
static pointers C code should run anywhere in address  space. Currently
I do this on the mpc5200 board. U-Boot is linked to 0x1000000, but can
be started from anywhere in RAM.

> 
> 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.

Do we really need console output before U-Boot has initialised SDRAM?
For debugging some simple PUTC() and PUTHEX() macros would be
sufficient. Of course they have to be disabled on systems designed to
have a quiet console.

Regards,
  Sascha
-- 
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord     http://www.pengutronix.de