XO PRS 2006

This is my investigation into the PRS run that Mitch Bradley conducted. Where applicable, I am including comments from Tom Sylla (http://dev.laptop.org/attachment/ticket/109/prscheck.txt) If you wish to comment, make sure you append four tildes ~~~~ to sign it.

GX Graphics PCI Header Register

PCI Cache Line Size (R/W)

Expected 8 Got 0

IGNORE. The VSA should fill these out so that the headers are spec compliant. Its unlikely that any of the drivers use these fields, so its probably OK to ignore these.

GX CPU Core MSRs

Data Memory Configuration (MSR 0x1800)

Expected 200000000002 Got 200000000022

FIX PRS. This is correct. It makes an INVD command work exactly like WBINVD. Interestingly enough, Tom's PRS check was different (it expected 200000000022), so that should be looked into.

Default RCONF (MSR 0x1808)

Expected 25fff00210730000 Got 25fff0021077e000

FIX CODE. From Tom: This one doesn't matter too much at runtime (after BIOS boot) It may as well match our PRS, since that is how we run all the time. The flashrom utility that is used to flash will have to turn off write protect as necessary. There is an interesting tangent though, what settings is LinuxBIOS using when booting? It could be something faster than uncacheable. Even more tangential, is their memcpy for shadowing the fastest it can be on our hardware?

RCONF Bypass (MSR 0x180A)

Expected 11 Got 0

FIX PRS. This is correct. From Tom: LinuxBIOS is right here. It is wrong in the olpc.prs. The LinuxBIOS value matches both the sparrow and norwich PRSes. '0' is the highest performance setting.

C0000-DFFFF RCONF

Expected 2121212121210101 Got 212121212121212

POSSIBLE CODE FIX. From Tom: this one would take some looking into. these regions are usually set CD, WS because they are where PCI ROMs are usually located. Since the OLPC will have no PCI ROMs at these locations, These could be made cacheable, and added back to the memory map that linux uses.

I'm not sure if we can even use this space in kernel land. - JordanCrouse (Talk to me!) 13:59, 3 October 2006 (EDT)

E0000 - FFFFF RCONF

Expected 101010101010101 Got 2121212121212121

POSSIBLE CODE FIX. Same as above.

I'm not sure we can use this space even if the kernel gets it back - JordanCrouse (Talk to me!) 13:59, 3 October 2006 (EDT)

Region Configuration SMM

Expected 4043f00040400104 Got 4041f00040400104

FIX PRS. I think this is fine - this just indicates that our SMM area is smaller then it normally is with the full VSA.

GX GeodeLink Memory Controller MSRs

Refresh and SDRAM program (0x20000018)

Expected 1007401200002000 Got 1007401200002400

VERIFY & FIX PRS. This needs to be verified correct for the hardware, and the PRS updated for the right value.

GX Display Filter (DF) MSRs

GLD Master Configuration (MSR 0xc0002001)

Expected 40f00 Got 40f80

FIX PRS. This value is correct for a TFT attached board.