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

[Sascha Hauer]

On Wed, Jul 04, 2007 at 01:56:31PM +0200, Stefan Roese wrote:
> 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.

Might be the case, but I can think of more cases where a user simply has
a broken environment and won't see anything because of this. What does a
user see when he configured a different baudrate but somehow his
environment got scratched? #f32#f23##fwfdas#f32#d

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

I know it is, and it was the customers decision to so, but I think using
an I2C eeprom _should_ be no problem. It's just like any other memory
device.

> 
> 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 have the boards where DIMMs can be changed some kind of beeper or
LED telling you about memory problems?

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

I think we have little choice if we want 4k boot block support, early
console output _and_ a maintainable tree.

Regards,
  Sascha

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