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

Wolfgang Denk
2007-07-03T20:48:06Z

In message <fa686aa40707030952v27a9ac98of1c5c1d33f3b9ae4@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