From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Wed, 4 Jul 2007 13:56:31 +0200 Subject: [U-Boot-Users] U-Boot-NG ? In-Reply-To: <20070704112842.GJ3361@leda.ptxnet.pengutronix.de> References: <20070703175856.GB8839@pengutronix.de> <200707041206.18929.sr@denx.de> <20070704112842.GJ3361@leda.ptxnet.pengutronix.de> Message-ID: <200707041356.32051.sr@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 =====================================================================