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?
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
