[coreboot] Trouble converting Truxton to CAR

Dustin Harrison dustin.harrison at sutus.com
Tue Nov 2 18:43:08 CET 2010



On 02/11/2010 9:54 AM, Joseph Smith wrote:
>
> On Tue, 02 Nov 2010 08:43:50 +0100, Patrick Georgi<patrick at georgi-clan.de>
> wrote:
>> Am 02.11.2010 02:17, schrieb Dustin Harrison:
>>> valid for an Intel EP80579.  Is there a way I can validate that this CPU
>>> will work with the existing CAR code?
>>>
>>> I've gone so far as doing a code-n-pray conversion, but my linux boot
>>> hangs at "Jumping to Entry" and running memtest causes it to bork on
>>> Test #2 with an unhandled interrupt.
>> That's already _very_ far as much as CAR is concerned. Usually, if CAR
>> fails, you either see nothing but a couple of post codes, or have the
>> system fail when decompressing ramstage at the latest (because RAM init
>> failed for some reason).
>>
>>
> 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.




More information about the coreboot mailing list