[coreboot] Trouble converting Truxton to CAR

Dustin Harrison 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 
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?

More information about the coreboot mailing list