[U-Boot] ppc440 (440EPx sequoia) - inhibiting the cpu cache?
Hi,
I'm in the process of bringing up a custom board featuring AMCC's 440EPx processor. I'm using the uboot-2008-10 source tree and "sequoia" board for my starting configuration, also using ELDK v4.2. for cross-compiler tools and such.
Although my board initializes and completes its memory tests "relocate_code" fails. I've noted in the FAQ and mailing lists the sensitive nature of sdram timing and have spent considerable effort making sure the ddr_xx settings are correct. I thought my latest adjustment would save the day, I realized 'BSTLEN' should likely be changed from 4 words to 8 words because my memory configuration is x32 not x64. Unfortunately my latest u-boot.bin is still not happy.
To be really really certain my problem lies elsewhere, for the purposes of hardware bringup I was wondering if there was a relatively easy way to inhibit memory bursts, by turning off the CPU Cache. I searched many of the the .h files and didnt' notice anything along the lines of EN or DISABLE the cache, only size adjustments and associations to Chip Selects. If I overlooked something I'd would really appreciate a tip on strategy getting past relocate_code. This is what I have so far:
U-Boot 2008.10 (Jan 8 2009 - 14:05:28)
CPU: AMCC PowerPC 440EPx Rev. A at 264 MHz (PLB=88, OPB=44, EBC=22 MHz) Security/Kasumi support Bootstrap Option H - Boot ROM Location I2C (Addr 0x52) , PCI async ext clock used 32 kB I-Cache 32 kB D-Cache Board: Raptor1K - Avtec Systems PPC440EPx ACU, Rev. 0, PCI=33 MHz I2C: ready DRAM: 128 MB AB reloc addr_sp: 7ea9f18 id: 7ea9f30 addr: 7fac000
Sincerely, J.J. Barrow
Hi Jonathan,
On Thursday 08 January 2009, Jonathan Barrow wrote:
I'm in the process of bringing up a custom board featuring AMCC's 440EPx processor. I'm using the uboot-2008-10 source tree and "sequoia" board for my starting configuration, also using ELDK v4.2. for cross-compiler tools and such.
Although my board initializes and completes its memory tests "relocate_code" fails. I've noted in the FAQ and mailing lists the sensitive nature of sdram timing and have spent considerable effort making sure the ddr_xx settings are correct. I thought my latest adjustment would save the day, I realized 'BSTLEN' should likely be changed from 4 words to 8 words because my memory configuration is x32 not x64. Unfortunately my latest u-boot.bin is still not happy.
To be really really certain my problem lies elsewhere, for the purposes of hardware bringup I was wondering if there was a relatively easy way to inhibit memory bursts, by turning off the CPU Cache. I searched many of the the .h files and didnt' notice anything along the lines of EN or DISABLE the cache, only size adjustments and associations to Chip Selects.
Usually caches are disabled on 44x platforms in U-Boot. So you shouldn't see any burst access to SDRAM anyway.
If I overlooked something I'd would really appreciate a tip on strategy getting past relocate_code. This is what I have so far:
Most likely still an SDRAM configuration problem. Did you check if SDRAM is working after initialization either using a debugger or by using some simple memory test (write value to SDRAM and read it back and print the result)? This is what I would recommend to do. Only if this works you can continue to run U-Boot from RAM.
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 =====================================================================
participants (2)
-
Jonathan Barrow -
Stefan Roese