Jump to content

DSDT for Asus P8P67-M PRO

Time2Retire

By Time2Retire,
in Patches

 Share
834 posts in this topic

Recommended Posts

Time2Retire
Time2Retire
Posted
  • Author
Posted

Sorry no. The IORegistryExplorer dumps from post #205 I have one, but there appears to be two so I missed one. Now I cannot find it again.

 

I now also checked: MSR_PKGC3_IRTL, MSR_PKGC6_IRTL and MSR_PKGC7_IRTL against the Intel datasheet and the values we get appear to be fine:

0x8850
0x8868
0x886d

But they are a little different to what biosbits.org is using:

0x8C02
0x885B
0x885B

Note: The 5B is 54 for processors with less/more cores.

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted

Ah there it is. Thanks.

 

Oh but those are set to MacBookPro8,1 and iMac11,1 Too bad. Nothing new here. Thanks anyway.

 

What is the trick for this value? I have almost all the values that the real MacBookPro5,5 has but I couldn't manage to get this value appear. I have both AGPMEnabler &AGPM loaded in ioreg.

 

What else is needed? Do I have to inject this?

Sorry. I have no idea. Maybe it is a simple matter of renaming devices, but that's just a wild guess.

Link to comment
Share on other sites
flAked
flAked
Posted
Posted

We should try and fix this reboot business on writing to our MSR. Either we have a serious bug on ASUS side or we are not setting up things correctly.

 

Did you stumble across MSR_POWER_CTL yet?

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted
We should try and fix this reboot business on writing to our MSR. Either we have a serious bug on ASUS side or we are not setting up things correctly.

Whatever it is we have to get to the bottom of it. And when this is some weird Asus bug, we have to get them aboard.

 

Did you stumble across MSR_POWER_CTL yet?

Yeah but only for two bits of it:

 

Bit-1: C1E Enable. (R/W)

When set to ‘1’, will enable the CPU to switch to the Minimum Enhanced Intel SpeedStep Technology operating point when all execution cores enter MWAIT (C1).

 

Bit-4: FAST_Brk_Int_En.

When set to 1, enables the voltage regulator for fast slope for PCI-E interrupt wakeup events.

 

Bit-18: Appears to be related to the 'Energy Performance Bias MSR' because I found this note:

"If setting MSR_POWER_CTL bit 18 causes a GPF then Energy Performance Bias MSR cannot be made visible and is not supported" in ppmstart.c (property of biosbits.org).

 

No problem with: wrmsr64(MSR_POWER_CTL, (1 << 18)) here. Will try to clear the bit and see what happens.

 

The rest is "reserved".

 

Update: MSR_POWER_CTL = 0x4005F with C1E enabled and 0x4005D with C1E disabled in the BIOS.

Link to comment
Share on other sites
flAked
flAked
Posted
Posted

Can you write to 0x2E with reggie_se? I don't have the current version (wasn't in the update).

 

Update: MSR_POWER_CTL = 0x4005F with C1E enabled and 0x4005D with C1E disabled in the BIOS.

Cool. So they actually set registers once in a while :lol:

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted
Can you write to 0x2E with reggie_se? I don't have the current version (wasn't in the update).

reggie_se is an optional installation, which I apparently forgot to check when I installed Xcode 4. Oh well. It is a bit late now to start all over. Will do it when I (have to) install it again.

 

I am going to hunt for 0xE2 related material for a short while, and then I need to get some well deserved sleep.

 

A few more observations before going to bed:

 

1.) My data is incomplete. Only have the first table of this table (from the new MBP/iMac's):

		Name (SSDT, Package (0x0C)
	{
		"CPU0IST ", 
		0x8ADE7718, 
		0x00000671, 
		"APIST   ", 
		0x8ADE6C18, 
		0x000003A4, 
		"CPU0CST ", 
		0x8ADE5818, 
		0x00000781, 
		"APCST   ", 
		0x8ADE4D98, 
		0x00000119
	})

Need a way to extract them.

 

2.) MSR MSR_PMG_IO_CAPTURE_BASE (0xE4) is 0x10414 and the 414 here is the register used for MWAIT redirection. Now look at this code snippet from a GigaByte board:

        Method (_CST, 0, NotSerialized)
       {
           If (CSEN) // True because of Name (CSEN, 0x00000001)
           {
               If (LAnd (MWOS, And (TYPE, 0x0200)))
               {
                   Return (Package (0x04)
                   {
                       0x03, 
                       Package (0x04)
                       {
                           ResourceTemplate ()
                           {
                               Register (FFixedHW, 
                                   0x01,               // Bit Width
                                   0x02,               // Bit Offset
                                   0x0000000000000000, // Address
                                   0x01,               // Access Size
                                   )
                           }, 

                           0x01, 
                           0x0001, 
                           0x000003E8
                       }, 

                       Package (0x04)
                       {
                           ResourceTemplate ()
                           {
                               Register (FFixedHW, 
                                   0x01,               // Bit Width
                                   0x02,               // Bit Offset
                                   [color="#FF0000"]0x0000000000000010[/color], // Address
                                   0x01,               // Access Size
                                   )
                           }, 

                           0x02, 
                           0x0040, 
                           0x000001F4
                       }, 

                       Package (0x04)
                       {
                           ResourceTemplate ()
                           {
                               Register (FFixedHW, 
                                   0x01,               // Bit Width
                                   0x02,               // Bit Offset
                                   0x0000000000000020, // Address
                                   0x01,               // Access Size
                                   )
                           }, 

                           0x03, 
                           0x0060, 
                           0x0000015E
                       }
                   })
               }

So does this mean that we have the wrong value or what?

 

p.s. He OC'ed his rig so that might explain why AICPMVers is missing. In which case C-States are not used. Correct?

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
p.s. He OC'ed his rig so that might explain why AICPMVers is missing. In which case C-States are not used. Correct?

On ASUS P67x you can actually OC and have C-States enabled. But only if you define it manually, AutoTune or how it's called will disable them. Don't know how this is handled on GB.

 

 

2.) MSR MSR_PMG_IO_CAPTURE_BASE (0xE4) is 0x10414 and the 414 here is the register used for MWAIT redirection. Now look at this code snippet from a GigaByte board:

 

So does this mean that we have the wrong value or what?

Need to do more reading. But I tested their _CST already with no success.

 

 

PCT - Performance Control

 

Interface for performance state transition

 

ASUS & GB

Name (_PCT, Package (0x02)
{
  ResourceTemplate () { Register (FFixedHW, 0x40, 0x00, 0x0000000000000199,,) }, 
  ResourceTemplate () { Register (FFixedHW, 0x10, 0x00, 0x0000000000000198,,) }
})

 

MBP81

Name (_PCT, Package (0x02)
{
  ResourceTemplate () { Register (FFixedHW, 0x00, 0x00, 0x0000000000000000,,) }, 
  ResourceTemplate () { Register (FFixedHW, 0x00, 0x00, 0x0000000000000000,,) }
})

 

PSS - Performance Supported States

 

Defines P-States

 

Crafted for i5-2500K, note that MBP8,1 has APSS with all states defined and legacy _PSS with a meta state for TurboMode. For now we just alias the two. We might need to add _PSS later on. 

Name (APSS, Package (0x13) // Performance Supported States, used by SMC_PlatformPlugin
{
/*  Core Frequency (MHz), Power (milliwats), Latency (ms), Bus Latency (ms), Control, Status */
            Package (0x06) { /* 3700 MHz */ 0xE74, 0x17318, 10, 10, /* 37 */ 0x2500, 0x2500 },
	    Package (0x06) { /* 3600 MHz */ 0xE10, 0x17318, 10, 10, /* 36 */ 0x2400, 0x2400 }, 
	    Package (0x06) { /* 3500 MHz */ 0xDAC, 0x17318, 10, 10, /* 35 */ 0x2300, 0x2300 }, 
	    Package (0x06) { /* 3400 MHz */ 0xD48, 0x17318, 10, 10, /* 34 */ 0x2200, 0x2200 }, 
            Package (0x06) { /* 3300 MHz */ 0xCE4, 0x17318, 10, 10, /* 33 */ 0x2100, 0x2100 }, 
            Package (0x06) { /* 3200 MHz */ 0xC80, 0x163c6, 10, 10, /* 32 */ 0x2000, 0x2000 }, 
            Package (0x06) { /* 3100 MHz */ 0xC1C, 0x154ba, 10, 10, /* 31 */ 0x1F00, 0x1F00 }, 
            Package (0x06) { /* 3000 MHz */ 0xBB8, 0x145f5, 10, 10, /* 30 */ 0x1E00, 0x1E00 }, 
            Package (0x06) { /* 2900 MHz */ 0xB54, 0x13776, 10, 10, /* 29 */ 0x1D00, 0x1D00 }, 
            Package (0x06) { /* 2800 MHz */ 0xAF0, 0x1293c, 10, 10, /* 28 */ 0x1C00, 0x1C00 }, 
            Package (0x06) { /* 2700 MHz */ 0xA8C, 0x11b47, 10, 10, /* 27 */ 0x1B00, 0x1B00 }, 
            Package (0x06) { /* 2600 MHz */ 0xA28, 0x10d96, 10, 10, /* 26 */ 0x1A00, 0x1A00 }, 
            Package (0x06) { /* 2500 MHz */ 0x9C4, 0x10028, 10, 10, /* 25 */ 0x1900, 0x1900 }, 
            Package (0x06) { /* 2400 MHz */ 0x960, 0xf2fe, 10, 10, /* 24 */ 0x1800, 0x1800 }, 
            Package (0x06) { /* 2300 MHz */ 0x8FC, 0xe616, 10, 10, /* 23 */ 0x1700, 0x1700 },
            Package (0x06) { /* 2200 MHz */ 0x898, 0xd971, 10, 10, /* 22 */ 0x1600, 0x1600 }, 
            Package (0x06) { /* 2100 MHz */ 0x834, 0xcd0c, 10, 10, /* 21 */ 0x1500, 0x1500 }, 
            Package (0x06) { /* 2000 MHz */ 0x7D0, 0xc0e9, 10, 10, /* 20 */ 0x1400, 0x1400 }, 
            Package (0x06) { /* 1600 MHz */ 0x640, 0x92d9, 10, 10, /* 16 */ 0x1000, 0x1000 }
})
Alias(APSS, _PSS)

 

 

TSS - Throttling Supported States

 

Defines T-States

 

ASUS defines two tables, one with 8 states (below) and one with 1 state at 100%. Note the first field is a percentage, the second is a power value in mW. It is arbitrary high and will be ignored if P-States are available. 

Name (_TSS, Package(0x08)
{
	    Package (0x05) {0x64, 0x03E8, Zero, Zero, Zero }, 
            Package (0x05) {0x58, 0x036B, Zero, 0x1E, Zero }, 
            Package (0x05) {0x4B, 0x02EE, Zero, 0x1C, Zero }, 
            Package (0x05) {0x3F, 0x0271, Zero, 0x1A, Zero }, 
            Package (0x05) {0x32, 0x01F4, Zero, 0x18, Zero }, 
            Package (0x05) {0x26, 0x0177, Zero, 0x16, Zero }, 
 	            Package (0x05) {0x19, 0xFA, Zero, 0x14, Zero },
            Package (0x05) {0x0D, 0x7D, Zero, 0x12, Zero }
})

 

GB either returns the same 8 states as above or Zero. Power value starts from 0x960 downwards.

 

MBP8,1 has the same table as above (TSMC) but an additional table (TSMF) with more granularity of 15 states. Apple copies the power values of APSS into both tables, exact formula not yet understood. We need to craft this as well.

 

 

PSD - P-State Dependency

 

ASUS defines

Name (_PSD, Package (0x01) { Package (0x05) { 0x05, Zero, Zero, 0xFE, 0x04 } })

GB returns the same or Zero depending on P-State availability.

 

MBP8,1 defines two different PSD based on PDC0

Name (_PSD, Package (0x01) { Package (0x05) { 0x05, Zero, Zero, 0xFE, 0x80 } }) // 0xFE = HW_ALL
Name (_PSD, Package (0x01) { Package (0x05) { 0x05, Zero, Zero, 0xFC, 0x80 } }) // 0xFC = SW_ALL

Note that Apple doesn't define NumProcessors explicitly (0x80).

Based on the fact that APSS is directly accessed by SMC_PlatformPlugin we can speculate that P-State coordination is in fact done in software (0xFC).

 

 

TSD - T-State Dependency

 

MBP8,1 defines two TSD based on PDC0 again

Name (_TSD, Package (0x01) { Package (0x05) { 0x05, Zero, Zero, 0xFD, 0x04 } }) // 0xFD = SW_ANY
Name (_TSD, Package (0x01) { Package (0x05) { 0x05, Zero, Zero, 0xFC, 0x04 } }) // 0xFC = SW_ALL

 

GB has a slightly different definition for every CPU or returns Zero

Name (_TSD, Package (0x01) { Package (0x05) { 0x05, Zero, 0x00, 0xFD, 0x01 } }) //CPU0
Name (_TSD, Package (0x01) { Package (0x05) { 0x05, Zero, 0x02, 0xFD, 0x01 } }) //CPU1
Name (_TSD, Package (0x01) { Package (0x05) { 0x05, Zero, 0x04, 0xFD, 0x01 } }) //CPU2
Name (_TSD, Package (0x01) { Package (0x05) { 0x05, Zero, 0x06, 0xFD, 0x01 } }) //CPU3

Note that the 3rd field defines the operation domain.

 

Also note that ASUS is missing TSD completely.

 

 

PPC - Performance Present Capabilities

 

Indicates number of available P-States

 

ASUS & GB always return Zero

Method (_PPC, 0, NotSerialized) { Return (Zero) } // all p-states available

 

MBP8,1 reads this value directly from field CPLT.

 

 

TPC - Throttling Present Capabilities

 

Indicates number of available T-States

 

ASUS & GB & MBP8,1 always return Zero

Method (_TPC, 0, NotSerialized) { Return (Zero) } // all t-states available

 

 

PTC - Processor Throttling Control

 

Interface for throttling state transition

 

ASUS returns PTC based on PDCV (either _PTC or PTCI). GB always returns _PTC below.

Method (_PTC, 0, NotSerialized)
{
            Return (Package (0x02)
            {
		    ResourceTemplate () { Register (FFixedHW, 0x00, 0x00, 0x0000000000000000,,) }, 
	            ResourceTemplate () { Register (FFixedHW, 0x00, 0x00, 0x0000000000000000,,) }
            })
}

Method (PTCI, 0, NotSerialized)
{
            Return (Package (0x02)
            {
		    ResourceTemplate () { Register (SystemIO, 0x04, 0x01, 0x0000000000000410,,) }, 
	            ResourceTemplate () { Register (SystemIO, 0x04, 0x01, 0x0000000000000410,,) }
            })
}

 

Based on PDC0, MBP8,1 either returns _PTC as well or a SystemIO definition (which of course is different for every system)

Method (_PTC, 0, NotSerialized)
{
            Return (Package (0x02)
            {
		    ResourceTemplate () { Register (SystemIO, 0x05, 0x00, 0x0000000000000410,,) }, 
	            ResourceTemplate () { Register (SystemIO, 0x05, 0x00, 0x0000000000000410,,) }
            })
}

 

 

CST - C States

 

*still investigating*

 

 

 

Source: http://www.acpi.info/

 

 

Cookies anyone? :(

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted

Lots of great investigating done/going on here, but I think that it is time for us to wake up the Asus BIOS guru over at that forum (link was given earlier) because I cannot write to MSR 0xE2 but I can on a P67 GigaByte board!!!

 

Note: I was only able to boot from a USB-stick (with RevoBoot on it) in a shop, up until a certain point, but that was way beyond the usual KP!!!!!!

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted
Agreed. I posted over there at page #125. Please don't link directly. Here is the reply, very promising indeed!

Great. Thanks for that.

 

I hope that this is it. A simple MSR write, or that we need to re-configure something – like the PCI configuration space maybe? Whatever it is. Let them be quick :)

Link to comment
Share on other sites
flAked
flAked
Posted
Posted

I couldn't resist and asked him if he knew the MSR. He said it was listed in an older Intel tech document 2.

 

Could it be:

15: CFG Lock. (R/WO)

When set, lock bits 15:0 of this register until next reset

 

My MSR_PMG_CST_CONFIG_CONTROL shows 0x1e008407 -> bit 15 = 1

 

So. Lock is active but AICPUPM is trying to set C-States -> KP ?

 

 

Nope. Reboots as well.

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted
...

Nope. Reboots as well.

LOL I was about to say: "That can't be as we cannot write to it".

 

Is this document about the CPU or the Chipset?

 

p.s. I cannot sign up there as my ISP blocks certain parts of that website (:

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
Is this document about the CPU or the Chipset?

Rather cryptic:

It might be shown in the Intel white papers - check tech document number two (on older platforms it was listed, but I'm not sure if they have listed for SNB).

 

Another thought: is RevoBoot actually running in ring-0?

Link to comment
Share on other sites
flAked
flAked
Posted
Posted

I made a quick kext to write to 0x2E and was able to reproduce the exact KP we are seeing on AICPUPM.

 

It's a bit redundant, but good to know that no other mojo is causing this.

 

 

I booted up BITS and the relevant Tests passed. But strangely rdmsr 0x2E was zero....

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted
Rather cryptic:

Reading his "platform" I would say it is chipset related. As in IC[6-10] when he talks about older platforms, but I have yet to find anything useful. Maybe he was referring to the PCI configuration space?

 

Another thought: is RevoBoot actually running in ring-0?

Please correct me if I am wrong, but wasn't this ring-0 thing only there after the kernel started? Because it is security related? That is why I think that our boot loader is not troubled by this. Well. That's how I read it.

 

Update

New BIOS version (0709) for our P8P67-M PRO available from ASUS site ->link<-

Cool. Please give it a go and let us know if it changed anything.

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted
I made a quick kext to write to 0x2E and was able to reproduce the exact KP we are seeing on AICPUPM.

 

It's a bit redundant, but good to know that no other mojo is causing this.

Thanks. Now we know for sure. We just have to find that MSR / CSR or whatever it is.

 

I booted up BITS and the relevant Tests passed. But strangely rdmsr 0x2E was zero....

Yeah that is strange. Like BITS is setting the MSR we are after. I have to look at the source source code again...

 

 

 

Exactly what I have to control?

Booting without NullCPUPowerManagement.kext (and SleepEnabler.kext) would be the first thing to test.

 

How come I have BIOS version 703 when it isn't even there?

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
Reading his "platform" I would say it is chipset related. As in IC[6-10] when he talks about older platforms, but I have yet to find anything useful. Maybe he was referring to the PCI configuration space?

Couldn't find anything either. But PCI mapping seems like the wrong place for core cpu configuration.

 

What bumped me is the fact that 0x2E:15 is R/WO (write once). So if the BIOS is setting this bit there is no way until reset to set it again.

 

Please correct me if I am wrong, but wasn't this ring-0 thing only there after the kernel started? Because it is security related? That is why I think that our boot loader is not troubled by this. Well. That's how I read it.

Correct, ring-abstraction is a kernel thing.

 

I currently have version 0708 :unsure:

If you boot the new BIOS without NullCPU please write down RCX of the KP, thanks!

Link to comment
Share on other sites
Time2Retire
Time2Retire
Posted
  • Author
Posted

Got a great tip. It's here somewhere. On one of the 94 pages where a person using the nick name mm67 used it to make a certain write action possible on his MSI board, which itself is a bit weird since it is all about GB boards.

 

Can't we simply ask this mm67 where, what and why he did what he did?

 

Oh cool. I checked his profile and that shows: "Last Seen: Yesterday, 05:42 PM" so he's still around. Great.

Uhg. His signature reads:

 

Asus X58 Sabertooth@4.1 GHz, Radeon HD5770 Geekbench score:14113

Gigabyte GA-EP45-UD3 & Q9550@4.25 GHz, GTX 460 Geekbench score:10242

Asus P5Q Deluxe & E7400@4.0 GHz, Radeon HD5770

 

So now I wonder how valuable this tip actually is.

 

What's RCX? Sorry :unsure:

Just take a picture with your camera of the KP :|

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...