From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Wed, 4 Jul 2007 12:06:18 +0200 Subject: [U-Boot-Users] U-Boot-NG ? In-Reply-To: <20070704093242.GI3361@leda.ptxnet.pengutronix.de> References: <20070703175856.GB8839@pengutronix.de> <20070703205536.89F3E353AF8@atlas.denx.de> <20070704093242.GI3361@leda.ptxnet.pengutronix.de> Message-ID: <200707041206.18929.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 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). 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. > 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. > 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. > 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 at denx.de =====================================================================