[coreboot] Trouble converting Truxton to CAR
dustin.harrison at sutus.com
Tue Nov 2 22:28:36 CET 2010
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
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?
More information about the coreboot