Hi, Stefan
Stefan Roese wrote:
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.
Not exactly related to the subject under discussion, but I thought I'd mention it.
I had problems with ecc_init() on a custom 460EX board with soldered DDR2. Right after ecc_init() u-boot was crashing on PLB access. I've modified the code to use program_ecc_addr() instead of ecc_init(), and problem was solved. I was wandering why use two different ECC initialization routines for SPD and soldered cases, when program_ecc_addr() can do the job in both cases, while ecc_init() apparently has issues ?
Thanks.
Felix.
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@denx.de _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot