[coreboot] Trouble converting Truxton to CAR
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>
>> 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