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

Sascha Hauer
2007-07-04T09:32:42Z

On Tue, Jul 03, 2007 at 10:55:36PM +0200, Wolfgang Denk wrote:
> In message <20070703175856.GB8839@pengutronix.de> you wrote:
> >
> > Do we really need console output before U-Boot has initialised SDRAM?
>
> Yes, we do. This is one of the things I definitely want to keep as it
> saved me lots of hours before. I won't give this up lightly.

I don't understand what's so damn complicated about setting up SDRAM.
This is one of the most basic things during lowlevel development.
Usually this part is about 20 lines in my bdi config. Transfering this
into some lines Assembler or C code is a piece of cake. If you have to
read some i2c data to get initialization settings, you have to do some
bits more and I understand that one wants to have some putc/puthex to
check if sane values are read. But again, this is lowlevel work and once
it's running can forget about this.
Relocation is tricky, yes. But this is well reviewed code common for
each SoC, or maybe (with some common code merge) even common for PPC.
You won't have problems in this area on a production board.

All this has _nothing_ to do with production boards. Here the SDRAM
initialization and relocation just work. If not, you're doomed anyway.
After relocation everyone can begin to setup things as he likes. I
first print a hello world on the console, others might look in the
device tree first to get console information.

At the moment (PPC-)U-Boot does 90% of the whole initialization while
running from Flash. All these serial read functions for the environment
are just a pain. Do you really want to do the same thing for the device
tree? Setting up things in SRAM and then copy them to SDRAM, possibly
with relocation fixups is a pain. Setting up a preliminary environment
in flash and relocate this complex thing afterwards with all this
global_data handling is what I would call complicated and error prone.

Doing this is not a design criteria, it is one main design flaw in
U-Boot. If you insist on doing it, we don't need to talk about a
redesign, just leave everything like it is.

Note that in my tree there is one single entrypoint for all
architectures, and the only thing needed to enter it is working RAM.
This is straight forward: Everyone should be able to provide working
RAM. If not, again you're doomed.
If you need some debugging output to get to that point, well that's
fine, but these are putc/puthex and _not_ printf. They are not compiled
in in production code and therefore do not need quiet console checking.

Don't make things more complicated as they are. The earlier you enter a
common entry point in U-Boot the more you can actually trust the code,
since from there on it's common for _all_ architectures and the code
will be best reviewed.

Regards,
Sascha

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