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

[Stefan Roese <sr@denx.de>]

Hi Sascha,

On Wednesday 04 July 2007, Sascha Hauer wrote:
> > 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.

You seem to never have dealt with a complex DDR2 setup with DIMM modules (and 
optionally with ECC support). Please take a look at 
cpu/ppc4xx/44x_spd_ddr2.c). It is pretty hard to come up with a common (cpu 
platform) code that can be used by several boards supporting a variety of 
DIMM modules. Here some debug printf's come in very handy.

> Usually this part is about 20 lines in my bdi config. Transfering this
> into some lines Assembler

I thought those days were over. I will never ever go back to having to setup a 
SDRAM controller in assembler.

> or C code is a piece of cake. 

Ah, ok. At least C.

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

No, you can't. Since the user might replace another DIMM module. Or even the 
board manufacturer.

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

That's good.

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

On the setup mentioned above, the printf's (or at least some serial output) is 
really a great benefit. It would be a pity to loose this in this new U-Boot 
version.

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

ACK.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================