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

[Sascha Hauer]

On Tue, Jul 03, 2007 at 10:48:06PM +0200, Wolfgang Denk wrote:
> 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 think you're talking about two different things here. The debug output
you want to see has nothing to do with the output in normal use. When
bringing up a green board I would not ask the environment for the
baudrate, because there is none.
We should create two entries to the console. One regular, with asking the
environment about baudrate and the like. The other one as simple as
possible. In this case I really only want to pass a base address and a
hardcoded baudrate.

Thinking about this U-Boot already has this. Only the way it is done
became very messy over the years. Not only this mailing list but also
the code looks like a struggling between the people who want early
debug output and the people who want to configure their console in the
environment, possibly disabling it completely. People with multiple
serial ports not to mention...
The console thing is symptomatic for other cases in U-Boot aswell. This
is why I think we need to start with a cleaner codebase where a driver
or board support only enters after it works with a to be defined API.

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

Add a Puthex(), then we're complete.

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

Sounds like calling the president for turning on the lights. Please do
not forget that there are also other people. None of our customers ever
asked for a even configurable console. 115200 port0 seems to fit everyone.
Instead we have to deal with Booting from small boot sectors.

Regards,
  Sascha

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