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

[Stefan Roese]

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

Yes, this could be done. I just wanted to make a point, that not all SDRAM 
configuration are "easy" and fit into a few lines of code.

> 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 ;)

Yep. ;-)

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

I'm still a little undecided, if a "simple" output mechanism is enough. Of 
course you can life with a hardwired baudrate on most systems, so that you 
don't have to read the environment. But there will be some systems where the 
user configured a different baudrate and the outputs from the DDR2 init 
routine will not be readable.

But you are right: Making this step hardcoded makes the overall design much 
more simple. So that would be a "Good Thing" (TM).

> Even netconsole was already mentioned somewhere. This can 
> simply not be implemented on other architectures than powerpc because of
> the lack of SRAM.

Yes, something like netconsole has to be initializes quite late in the bootup 
process.

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

Yes. That is one of the reasons, why it is strongly discouraged to use I2C 
EEPROM for environment storage.

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

That's the way it *should* be. But unfortunately this is not always the case. 
At least we have seen it happen before, that not supported modules were 
shipped. :-(

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

If no output on the serial console always means: "problem with memory", than 
this would be an easy indication for SDRAM problems. But I have seen lots of 
other errors, that lead to a hangup in the very early boot stage. Most of the 
time *before* SDRAM is initialized.

Don't get me wrong. I generally like this 2 stage approach. For example it 
fits the NAND booting support (see nand_spl/*) where a small (4k on 4xx) 
first stage loader is needed. I'm just a little hesitant about dropping the 
full featured printf in early boot stages.

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