Hello,
After all the excitement of converting the i810 boards to CAR, I've been looking at converting the Truxton board to cache-as-RAM. However, I'm not sure how to validate that the cpu/intel/car/cache_as_ram.inc code is 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.
Cheers Dustin
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).
Patrick
On Tue, 02 Nov 2010 08:43:50 +0100, Patrick Georgi patrick@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.
On 02/11/2010 9:54 AM, Joseph Smith wrote:
On Tue, 02 Nov 2010 08:43:50 +0100, Patrick Georgipatrick@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.
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?
On Tue, Nov 02, 2010 at 10:43:08AM -0700, Dustin Harrison wrote:
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.
Maybe. Can you post your patch for review and if possible the URL for the CPU datasheet?
Thanks, Uwe.
On 02/11/2010 3:03 PM, Uwe Hermann wrote:
On Tue, Nov 02, 2010 at 10:43:08AM -0700, Dustin Harrison wrote:
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.
Maybe. Can you post your patch for review and if possible the URL for the CPU datasheet?
I'll see what I can do for a patch, but it will be a couple of days while I wait for my RDIMM to show up so I can resurrect the Truxton dev board.
In the meantime here is the link to the datasheet: http://download.intel.com/design/intarch/ep80579/320066.pdf
-
Dustin Harrison -
Joseph Smith -
Patrick Georgi -
Uwe Hermann