DSDT for Asus P8P67-M PRO

[mrmojorisin17]

Yep, same here.

I didn't realize that in huronplist was injected an ID (8086,1c03) different from mine (8086,1c02).

Now chipset is correctly recognized with real ID in both huronplist and AppleAHCIPort.kext's Info.plist

 

[flAked]

After 4 hours I can present a first draft of a complete DSDT for P8P67 rev3!

 

I cross-referenced every method and every address and as expected there are a couple of differences, mainly because of more PCI-lanes. I started renaming/adding the ARxx references to keep it in sync with my vanilla DSDT, but soon found out, that it could be stripped down further. Not done yet.

 

1) PCI-cards, FireWire, all USB-ports should work now.

 

2) Bluetooth and Sound are not working. (There is a mysterious device called BR20, don't know what it does yet.)

 

 

Remember that this is a work in progress DSDT, as such you take all responsibility testing it on your hardware.

 

ssdt_pr is meant to be used for i5-2005K and is not complete yet. It is, however, safe to use with NullCPUPM.

 

Have fun!

 

 

Credit goes to Sam for doing a fantastic job, could not have done it without her work!

 

P8P67_DSDT_WIP.zip

[elitee]

Looks good, I will try it tomorrow: one thing I did notice was that this

           OperationRegion (NBNV, SystemMemory, 0xBF5FCD98, 0x0100)

was different on my factory DSDT, the value was 0xDF5CBD98, and when I put the value in, putting the computer to sleep would actually shut it off, but never come on, whereas the other value would never turn the computer off, just attempt to.

 

After 4 hours I can present a first draft of a complete DSDT for P8P67 rev3!

 

I cross-referenced every method and every address and as expected there are a couple of differences, mainly because of more PCI-lanes. I started renaming/adding the ARxx references to keep it in sync with my vanilla DSDT, but soon found out, that it could be stripped down further. Not done yet.

 

 

P8P67_DSDT_WIP.zip

[elitee]

To get sound working with only DSDT and AppleHDA binpatch, add the following to your DSDT for Rev 3 Vanilla p8p67

            Device (HDEF)
           {
               Name (_ADR, 0x001B0000)
               Alias (PW94, _PRW)
               Method (_DSM, 4, NotSerialized)
               {
                   Store (Package (0x04)
                       {
                           "layout-id", 
                           Buffer (0x04)
                           {
                               0x7C, 0x03, 0x00, 0x00
                           }, 

                           "PinConfigurations", 
                           Buffer (Zero) {}
                       }, Local0)
                   MCDP (Arg2, RefOf (Local0))
                   Return (Local0)
               }
           }

    Method (MCDP, 2, NotSerialized)
   {
       If (LEqual (Arg0, Zero))
       {
           Store (Buffer (One)
               {
                   0x03
               }, Arg1)
       }
   }

 

The second method was already in the DSDT, DHP had it commented out. You could also inject this information with device-properties as she suggested, which is what she did and why it worked for her.

[flAked]

Confirmed, Audio is working. I'm not sure if I actually patched AppleHDA or MacMan's ALC8xxHDA.kext (also only plist) did the trick. One thing I noticed was that the digital output will shut itself down rather quickly and will come up again when playing. But this could be influenced by using MBP8,3.

 

EDIT: Yep, using MacPro3,1 fixed this. But might not be desirable in the long run if we want to replicate a MBP8,3.

 

EDIT2: Could you maybe post the md5 of the original AppleHDA if you still have it?

 

 

I missed the address for sleep, yeah. On my system it will shutdown with the power light still on, but never wakes up.

 

Strangely enough, with the current DSDT my sound-card (cmi8738) isn't working anymore, the kext loads but no device showing up.

[flAked]

Looking further at how maximum power dissipation per p-state is calculated, we can't see a linear correlation.

 

Using MBP8,3 as example: 45W max TDP, normal clock 2.2GHz

 

 

TDP to clock speed ratio (W/GHz) is therefor:

 

45 W / 2.2GHz = 20.45

 

 

If we take the PStateArray from the MBP8,3 we see:

 

2200: AFC8 = 45 000 20.45

2100: A518 = 42 264 20.13 -0.32

2000: 9A9D = 39 581 19.80 -0.33

1900: 920B = 37 387 19.00 -0.80

1800: 87F6 = 34 806 19.00 -0.00

1700: 7FBF = 32 703 19.00 -0.00

1600: 7613 = 30 227 18.00 -1.00

1500: 6E34 = 28 212 18.00 -0.00

1400: 64E4 = 25 828 18.00 -0.00

 

Therefor a non linear factor. Now, it would be too easy if they just used 20.45 for every p-state!

 

 

If we would apply a constant factor of 20.45 we get slightly higher max power dissipation per state, meaning we would rather stay in one state longer, than just switch to the higher frequency. Essentially "underclock-throttling" the CPU.

[elitee]

Confirmed, Audio is working. I'm not sure if I actually patched AppleHDA or MacMan's ALC8xxHDA.kext (also only plist) did the trick. One thing I noticed was that the digital output will shut itself down rather quickly and will come up again when playing. But this could be influenced by using MBP8,3.

 

EDIT2: Could you maybe post the md5 of the original AppleHDA if you still have it?

 

 

Don't have any way to test digital out, sorry! the md5sum of the compressed AppleHDA.kext I took from my 10.6.7 2011 MB is:

 

 

MD5 (AppleHDA.kext.zip) = 901a7ef36b8fc747ef5b80a631f09704

 

Here's the unmodified kext: AppleHDA.kext.zip

[Time2Retire]

Our SATA device-id is 1c02 because that's the desktop variant. Apple is using the mobility variant (1c03) with (using the Intel HM65 chipset). See also the Intel datasheets.

 

And about calculating the P-State Power. Look here:

 

M = ((1.1 - ((max_ratio - ratio) * 0.00625)) / 1.1) ^2

PStatePower = ((ratio / max_ratio) * M * TDP)

 

That's the formula to be used. The unknown value TDP can be calculated by reading two Sandy Bridge/Jaketown specific MSR's which I'll plan to add later tonight in RevoBoot.

[flAked]

M = ((1.1 - ((max_ratio - ratio) * 0.00625)) / 1.1) ^2

PStatePower = ((ratio / max_ratio) * M * TDP)

 

That's the formula to be used. The unknown value TDP can be calculated by reading two Sandy Bridge/Jaketown specific MSR's which I'll plan to add later tonight in RevoBoot.

 

Isn't TDP just the fixed Thermal Design Power specified for each CPU?

 

Would be neat to extract that directly from the MSR, but my RevoBoot is not yet fully configured, so I would test that formula with a handcrafted PSS.

[Time2Retire]

It is really simple. My i7-2600K's TDP is 255 Watt or 255.000 Milliwatt. I presume because my CPU is unlocked, otherwise it probably should have returned 95 Watt aka 95.000 Milliwatts.

 

Now check the first value in my _PSS which is 0x3E418 or yup 255.000 In short: i5-2500(K) users need to check the first (highest) value and that's your TDP

[flAked]

It is really simple. My i7-2600K's TDP is 255 Watt or 255.000 Milliwatt. I presume because my CPU is unlocked, otherwise it probably should have returned 95 Watt aka 95.000 Milliwatts.

 

Now check the first value in my _PSS which is 0x3E418 or yup 255.000 In short: i5-2500(K) users need to check the first (highest) value and that's your TDP

 

For the i5-2500K the highest multiplier seems to be x59 with 255W as well.

 

Are max_ratio and ratio the multipliers?

 

So max_ratio = 59 and ratio = for the specific p-state we want to calculate it for?

 

 

EDIT: or if using factory settings, TDP=95 and max_ratio = 37 ?

[Time2Retire]

For the i5-2500K the highest multiplier seems to be x59 with 255W as well.

No. That is 33 (3.3GHz) for the i5-2500(K) and 34 (3.4GHz) for the i7-2600(K). I might be one off here but that I have to check.

Are max_ratio and ratio the multipliers?

Yes. Note that max_ratio is the normal non-turbo frequency. Not the theoretical top multiplier in your BIOS.

 

So max_ratio = 59 and ratio = for the specific p-state we want to calculate it for?

Again. The 59 here should be either 33 or 34.

 

EDIT: or if using factory settings, TDP=95 and max_ratio = 37 ?

I'm still puzzled about this. We should try 95.000 and see what it does. Can easily be verified with a Linux distro. Not that I can do this but someone here should do it. Need to get some sleep now. Was a long day already.

 

p.s. Intel defined a P-State limit of 16 so we should only have 16 real P-States plus the turbo states.

[flAked]

EDIT: my post was totally wrong of course

 

I made a python script to get the values, and I found that max_ratio must be 22 for the MBP8,3.

 

That's because for the first p-state we want 45W, therefor M must be 1 and therefor (max_ratio - ratio) = 0.

 

So, to get P for x22 max_ratio must be 22.

 

TDP for the special TurboMode case is just set to max TDP and is not part of the calculation.

 

 

Regardless, I still get different numbers:

22: 45000
21: 42468
20: 39985
19: 37551
18: 35164
17: 32826
16: 30534
15: 28290
14: 26093
13: 23941
12: 21836

 

And here is the python script:

import math, sys

def pstatepower(r, max_ratio, tdp):
m = ( (1.1 - ((max_ratio - r) * 0.00625)) / 1.1)
m = m * m
p = ((float® / float(max_ratio)) * m * tdp)
return math.ceil(p)

ratios = [22, 21, 20, 19, 18, 17, 16, 15, 14, 13, 12]

max_ratio = 22

tdp = 45000

for r in ratios:
print '%g: %g' % (r, pstatepower(r, max_ratio, tdp))

[Time2Retire]

First. The max_ratio is 22 not 33. And the power calculation is really simple: TDP * 1000 – but only for the top core speed without turbo!

 

All other power states are done with the given calculation (by Intel).

 

Now take the power values from your _PSS object and use the following formula on them:

pstate_power / 45 / (ratio/max_ratio) / TDP = M

 

Then use the values to compare with what you get when you do your calculations with the other formula. This way we can see what margin Apple is using for the mobility CPU's because in all honesty... nobody knows or nobody wants to acknowledge anything when it is about Apple. Neither can I.

[flAked]

Ninja-edited on you See above post please.

 

It might be that they used a custom set of power values to tweak the thermal headroom required for mobile devices.

 

If we stick to the Intel formula we should be fine. It makes no sense to replicate their margin to our desktop CPUs.

 

 

Here is the PSS for my i5-2500K using the formula:

Name (PSS, Package (0x10)
{
/*  Core Frequency (MHz), Power (milliwats), Latency (ms), Bus Latency (ms), Control, Status */
           Package (0x06) { /* 3301 MHz */ 0xCE5, 0x17318, 10, 10, /* 37 */ 0x2500, 0x2500 },
           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 }
})

[davidm71]

Hi,

 

Bit of a new comer to the dsdt patching scene here and learning a few tricks as I move along in this great experience. I have a P8P67 Deluxe bios 1503 2600K board and I was wondering if someone could point me in the right direction to learn how to patch my DSDT file for C-State support and Sleep support. So far I have installed DSDTse and decompiled my dsdt file and corrected a dozen compiler warnings. The guides I'm reading right now say I have to analyze the Scope (_PR) section but I don't have one of those or any section that has 'CPU' in there in the DSDT file. So if anyone would be so kind to refer me to links or guides on sandy bridge dsdt patching so I could learn to do it on my own I would appreciate it!

 

Thank you.

[Time2Retire]

A quick post before going to my hockey training. Good news; I found the correct power value, in a different power plane, on my way home. It is set to 0x2f8 (760) and that in 1/8 Watt steps per P-State is our 95 Watt.

 

I also think to have located the bits to calculate/check the power (in Joules).

 

@davidm71: Forget about the old _PR info because everything is different with Intel's new SpeedStep (v2) and RAPL aka Running Average Power Limits.

[flAked]

Hi,

 

Bit of a new comer to the dsdt patching scene here and learning a few tricks as I move along in this great experience. I have a P8P67 Deluxe bios 1503 2600K board and I was wondering if someone could point me in the right direction to learn how to patch my DSDT file for C-State support and Sleep support. So far I have installed DSDTse and decompiled my dsdt file and corrected a dozen compiler warnings. The guides I'm reading right now say I have to analyze the Scope (_PR) section but I don't have one of those or any section that has 'CPU' in there in the DSDT file. So if anyone would be so kind to refer me to links or guides on sandy bridge dsdt patching so I could learn to do it on my own I would appreciate it!

 

Thank you.

 

Sandy Bridge is very new and not fully supported on OSX, yet.

Most of the DSDT guides aim to get a certain portion of hardware going or just supply a ready-made DSDT for a specific Mobo/CPU combination.

 

The point of this thread is to do it right and not quick fixes. That takes time. And DSDT's are very complex.

In order to edit your DSDT you need deep knowledge of your hardware. Be prepared that it might be very frustrating at first and you need to do a lot of reading.

 

We are currently figuring out how to get P-states going. There are ways to get sleep going under i386, but not via DSDT at the moment. Remember that P67 is very new and we might have to wait for the new iMac's to get new insights.

Besides, I don't really need sleep, I just have another coffee

 

 

If you are interested in jumping in, I would suggest booting up Linux from a DVD and dumping all your ACPI-tables with acpidump. You should find definitions for P001 and _PR. You could then have a look at Sam's factory dump and compare that to her edits and what I changed to make it work on the P8P67.

 

A detailed explanation about C-states: http://www.kexts.com/guides-tutorials/7067...management.html

[flAked]

Are _PCT and _PPC still necessary for SpeedStep v2?

 

Are they present in the MBP8,3 SSDT's?

[davidm71]

Sandy Bridge is very new and not fully supported on OSX, yet.

Most of the DSDT guides aim to get a certain portion of hardware going or just supply a ready-made DSDT for a specific Mobo/CPU combination.

 

The point of this thread is to do it right and not quick fixes. That takes time. And DSDT's are very complex.

In order to edit your DSDT you need deep knowledge of your hardware. Be prepared that it might be very frustrating at first and you need to do a lot of reading.

 

We are currently figuring out how to get P-states going. There are ways to get sleep going under i386, but not via DSDT at the moment. Remember that P67 is very new and we might have to wait for the new iMac's to get new insights.

Besides, I don't really need sleep, I just have another coffee

 

 

If you are interested in jumping in, I would suggest booting up Linux from a DVD and dumping all your ACPI-tables with acpidump. You should find definitions for P001 and _PR. You could then have a look at Sam's factory dump and compare that to her edits and what I changed to make it work on the P8P67.

 

A detailed explanation about C-states: http://www.kexts.com/guides-tutorials/7067...management.html

 

 

Thanks for replying. Later today I'll post those tables. Anyhow I've been reading a lot on dsdt guides on older hardware though. Still informative though incomplete. Unfortunately I need sleep as I caught a cold staying up to wee hours of the morning playing around with my new OSX box. I even have multigpu multimonitor support at native resolutions by injecting gfx strings for each of my three gpus but changing resolutions causes the screen to go all blue until next reboot. Must be depressed it has the wrong kext loaded.

 

I followed the basic P8P67 Pro guides but had problems getting the installer to load. I tried [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url], [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url] legacy, andymac, and others without success until the harddrive was connected to a real macbook pro and running the mpkg installer straight onto the drive. Since then I am on 10.6.7 with bridgehelper, P8P67 Pro package, and [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url] 3.4 with various options selected. Using VoodooHDA 2.7.2 install package for sound. Seems very stable but I'm sure it could be better.

 

Want to get it as Vanilla as possible. Had to disable C-states and speedstep to get sleepenabler.kext working though sometimes it doesn't wake up. Might have to re-enable those bios options next time I extract my tables?

 

Anyhow will post what I have later today. Can also post Everest table extracts if it would help too?

 

Thanks.

[flAked]

If you don't need the machine for production, I would suggest doing it the opposite way. It's a lot harder to figure out where the problem is if you have all those patches and extra kext installed.

 

If you want to go as vanilla as possible, do a fresh install (could be on a separate partition or external usb drive) and try to boot the system with the absolute minimum. Then figure out how to enable everything you need and if that component could work with just a DSDT edit.

 

Might be desirable to start a new thread about a vanilla installation on P8P67 Pro, to keep this thread on topic.

It get's hard to follow if we sidetrack to the whole install procedure.

 

I'll write up my own edits for the P8P67 after it's running smoothly with SpeedStep.

[davidm71]

If you don't need the machine for production, I would suggest doing it the opposite way. It's a lot harder to figure out where the problem is if you have all those patches and extra kext installed.

 

If you want to go as vanilla as possible, do a fresh install (could be on a separate partition or external usb drive) and try to boot the system with the absolute minimum. Then figure out how to enable everything you need and if that component could work with just a DSDT edit.

 

Might be desirable to start a new thread about a vanilla installation on P8P67 Pro, to keep this thread on topic.

It get's hard to follow if we sidetrack to the whole install procedure.

 

I'll write up my own edits for the P8P67 after it's running smoothly with SpeedStep.

 

I did all that a couple times already trying to make it as clean as possible of a vanilla install and it works just fine now and thats behind me. Bringing the thread back on topic I am ready for DSDT fun! So what tables should I post here or rather should I post a separate thread dedicated to the Deluxe model and DSDT fixing?

 

Thanks.

[Time2Retire]

Are _PCT and _PPC still necessary for SpeedStep v2?

 

Are they present in the MBP8,3 SSDT's?

Still present.

    Scope (\_PR.CPU0)
   {
       Method (_PPC, 0, NotSerialized)
       {
           Return (CPLT)
       }

       Name (_PCT, Package (0x02)
       {
           ResourceTemplate ()
           {
               Register (FFixedHW, 
                   0x00,               // Bit Width
                   0x00,               // Bit Offset
                   0x0000000000000000, // Address
                   ,)
           }, 

           ResourceTemplate ()
           {
               Register (FFixedHW, 
                   0x00,               // Bit Width
                   0x00,               // Bit Offset
                   0x0000000000000000, // Address
                   ,)
           }
       })

And CPLT points to some unknown IO region:

    OperationRegion (PLMT, SystemIO, 0x0310, 0x0A)
   Field (PLMT, WordAcc, Lock, Preserve)
   {
       CPLT,   8, 
       GPLT,   4, 
               Offset (0x02), 
       MPLT,   8, 
       CFIL,   8

[flAked]

I did all that a couple times already trying to make it as clean as possible of a vanilla install and it works just fine now and thats behind me. Bringing the thread back on topic I am ready for DSDT fun! So what tables should I post here or rather should I post a separate thread dedicated to the Deluxe model and DSDT fixing?

 

Thanks.

 

You could dump your complete ACPI with the SSDT and compare the devices and addresses in Sam's edit. You could then post those files and let other owners of the Deluxe model test them

[Time2Retire]

More new findings. Our Sandy Bridge CPU, both the i5 and i7 (K editions) CPU's have three power domains. One total package domain set to 255 Watt. One domain for the CPU cores set to 95 Watt, and one for the uncore (IGPU) graphics. Up to 160 Watt (apparently). The latter is probably more a theoretical value but whatever. We don't use the uncore anyway.

 

But wait a minute! Isn't this (in part) why AppleCPUPowerManagement.kext is KP'ing on our platform? Apple reads domain PP1 (the uncore graphics) also? There's only one way to find out... and that is to disassemble the kext (otool), but I signed an agreement not to participate in this so I won't do it.

 

Ok there is a second way and that is to write a little command tool to dump the MSR's. And looking at my agreement. That's not part of it. I better check LOL Nah better not. But anyone willing to have a go with it should keep an eye on RevoBoot i386/libsaio/cpu/essentials.h

 

Hey hey. Intel made an error in the P-State calculation because they assumed that everyone is using the uncore graphics. Err. Not us.