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