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.

CS5536 MFGPT

MFGPT 3 Setup

Expected 10da Got 30da

INVESTIGATE. Bit 13 indicates that the Comparator 1 output status is high. The clock isn't being actively used, so this is harmless in and of itself, but we need to investigate why VSA is setting up this clock.

(Note - same goes for MFGPT 4 and MFGPT 5 setup).

MFGPT 5 CMP1

Expected 1b83 Got ffff

FIX PRS. The clock isn't being actively used, so the comparator value is harmless.

CS5536 SMB IO

SMBCTL2

Expected ff Got 41

FIX LB. SMBCTL[7:1] sets up the lower 7 bits of the SMB_CLOCK frequency. The kernel writes a 71 - Not sure where they got 41 from, but 71 has been verified to be a good value. Use that.

CS5536 EHC Native

USB_HCCPARAMS

Expected 5012 Got 12

FIX PRS. The 50 is used to point to an "extended capabilities" region in the config space.. Right now, that is only used to hand over control from the BIOS to the kernel. This isn't

a problem for us, and we have no reason even to wander down this code in the first place, so keep the offset at 0, and fix the PRS.

IPGREG04

Expected 2 Got 0

FIX PRS. Undocumented bits - 0 is correct for OLPC. Update the PRS.