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

[Sascha Hauer]

On Wed, Jul 04, 2007 at 12:06:18PM +0200, Stefan Roese wrote:
> 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). 

I just did. The information this file outputs can easily be transfered
to puts/puthex. I'm not against early consoles in general, they are a
good thing. But you have to decide: Either you can provide a serial port
suitable for this kind of output, or you can't because this port is
normally occupied by a modem or something, but putting the information
about this in such a complicated thing as the environment or even the
device tree is just the wrong way.

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

I understand that you don't want to do such complicated things as done
in spd_sdram.c in assembler (and I don't want other people to do it in
assembler, that would be sadistic ;) But there is the other end aswell:
On Arm it's really simple like that. You do not even have SRAM to use
as a stack pointer (at least not as a general feature).

If you want output before SDRAM init, lets do it in form of a _simple_
console. Reading device tree contents or environment before the general
entry point is just bloated and imho cannot be done in a way everybody
is happy. Even netconsole was already mentioned somewhere. This can
simply not be implemented on other architectures than powerpc because of
the lack of SRAM.

I once wondered why it takes _so_ long to get a prompt on my MPC5200
board. The solution was simple: U-Boot was busy reading the environment
from EEPROM several times. Once for the checksum, once again for std*
settings and then for the baudrate setting. I was unable to fix it
though because my only chance was to #ifdef all around the place and
completely change the startup prodedure for my $SPECIAL_BOARD

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

Board manufactures should be able to buy DIMM modules which are
compatible with the board or have some 'verbose early debug U-Boot' in
place which they can use when testing new DIMMs.
And when I buy new DIMMs for my PC the 'no memory' beep tells me that
this module is not compatible. I do not need more information (I could
not make use of it anyway).


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

Ack

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

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