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@denx.de =====================================================================