On 02/11/2010 10:43 AM, Dustin Harrison wrote:
On 02/11/2010 9:54 AM, Joseph Smith wrote:
Yes, sounds to me more like a raminit issue more than a CAR issue.
Indeed, I enabled the ramtest and see failures starting at 0xCFE14 which is inside the CAR space (DCACHE_RAM_SIZE is 0x8000 in my case which should make the CAR range 0xC8000-0xCFFFF). My (naive) ideas are that either writes are getting sent to the SDRAM which prevents the raminit code from working or that CAR is not being (successfully) disabled after raminit due to some unique feature of this CPU. The reason I was asking about a method for validating the CAR code for this CPU is because this CPU supports a feature to share memory (for DMA purposes) with an accelerated services unit (ASU). Thus I jumped to the conclusion that this may affect the CAR routines.
Ok, I didn't think that last test through: Of course I fail the ramtest when I run it inside romstage.c:main() because I'm writing to memory that is in use. Adjusting the test (hopefully this is valid!), I moved the ram_check into hardwaremain.c. The result is that when I check 0xc0000 to 0xd0000 everything passes except the CAR area. The result of reads from the CAR area are always zero, up to the 128 failures that ram_verify shows before stopping. I adjusted the CAR size to be 0x1000 instead of 0x8000 and the read failures indeed moved to 0xcf000 instead of 0xc8000.
I also realized I missed one difference which is that cache_lbmem(MTRR_TYPE_WRBACK) line should be skipped if CONFIG_CACHE_AS_RAM is enabled, but that didn't solve the issue.
What would make the CAR area always return 0x0 as a value?