From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Mon, 7 Sep 2009 16:23:22 +0200 Subject: [U-Boot] PPC440GX: DDR ECC init time. In-Reply-To: <4CD35CD1F8085945B597F80EEC8942130348D9E9@exc01.bk.prodrive.nl> References: <4CD35CD1F8085945B597F80EEC8942130348D9E7@exc01.bk.prodrive.nl> <200909041513.35148.sr@denx.de> <4CD35CD1F8085945B597F80EEC8942130348D9E9@exc01.bk.prodrive.nl> Message-ID: <200909071623.22541.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 Monday 07 September 2009 15:57:19 Wouter Eckhardt wrote: > Well, I've been trying to work this into my U-Boot. I haven't succeeded > so far. Basically, the cache stuff in 4xx_spd_ddr2.c consists of setting > up a TLB without the CACHE_INHIBITED bit and then using some cache > instructions to fill up memory. That's what I've been trying to do, but > my call to change_tlb() hangs because of the invalidate_dcache() call > (bad trap exceptions). What could be going on here? > > I'll try and set up the DDR TLB dynamically instead of statically (in > init.S) and see if I can get that working. Yes. That's what I would do as well. > By the way, I've also stumbled upon some other VERY strange behavior. If > I leave the ecc_init() in its original state and just add in a puts(" ") > call at the beginning of the function, ECC generation is finished VERY > quickly. What influence could adding the puts() call possibly have on > the speed of generating ECC values in DDR? That's strange indeed. I suspect a problem in the code then. Try looking at the generated assembler code and/or debug with an BDI2000/3000. Cheers, 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