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

[Wolfgang Denk]

In message <fa686aa40707030952v27a9ac98of1c5c1d33f3b9ae4 at mail.gmail.com> you wrote:
>
> 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 started with such a design in PPCBoot a long, long  time  ago.  The
problem  is  that  memory setup is tricky, and you want to be able to
use C to implement it, and you want  to  have  debug  output  on  the
serial  console as well. Which means you will have to include a *lot*
of library functions in the "setup  wrapper",  which  in  some  cases
nearly doubles the flash memory footprint for U-Boot.

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

Yes, but "provide a little bit of debug output"  means  printf()  and
friends,  plus  console  drivers,  which  in  turn  means reading the
environment (for the console baudrate) and probably the  device  tree
(for the hardware configuration of the console port), etc.

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

No, please don't. Don't!

> 2. cut down wrapper functionality in the wrapper (this is just early
> boot after all).  Eliminate printf() support in the wrapper and make

Remember that U-Boot is not only a tool needed by the end users, it's
also a tool used by ourselfs in the board bring up.  Don't  make  our
own  lifes  even  more  miserable when you have to deal with the next
green board.

> due with puts().  Reduce the wrapper console driver to output only.

Puts() is not sufficient. I definitely want to be able to print
register contents and the like.

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

Assume something like a MPC8xx with console on SMC1 or SMC2, depending
on that the device tree says...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Der Irrtum wiederholt sich immerfort in der Tat.  Deshalb muß man das
Wahre unermüdlich in Worten wiederholen.                     - Goethe