Jump to content

DSDT for Asus P8P67-M PRO


  • Please log in to reply
833 replies to this topic

#61
flAked

flAked

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 470 posts
  • Gender:Male
  • Location:internets

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 ?

#62
Time2Retire

Time2Retire

    Retired

  • Retired Developers
  • 1,012 posts
  • Gender:Female
  • Location:anonymouse.eu

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.

#63
flAked

flAked

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 470 posts
  • Gender:Male
  • Location:internets
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:
[codebox]22: 45000
21: 42468
20: 39985
19: 37551
18: 35164
17: 32826
16: 30534
15: 28290
14: 26093
13: 23941
12: 21836[/codebox]

And here is the python script:
[codebox]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))[/codebox]

#64
Time2Retire

Time2Retire

    Retired

  • Retired Developers
  • 1,012 posts
  • Gender:Female
  • Location:anonymouse.eu
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.

#65
flAked

flAked

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 470 posts
  • Gender:Male
  • Location:internets
Ninja-edited on you :D 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:
[codebox]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 }
})[/codebox]

#66
davidm71

davidm71

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 167 posts
  • Gender:Male
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.

#67
Time2Retire

Time2Retire

    Retired

  • Retired Developers
  • 1,012 posts
  • Gender:Female
  • Location:anonymouse.eu
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.

#68
flAked

flAked

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 470 posts
  • Gender:Male
  • Location:internets

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...management.html

#69
flAked

flAked

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 470 posts
  • Gender:Male
  • Location:internets
Are _PCT and _PPC still necessary for SpeedStep v2?

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

#70
davidm71

davidm71

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 167 posts
  • Gender:Male

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...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 #####, ##### 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 ##### 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.

#71
flAked

flAked

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 470 posts
  • Gender:Male
  • Location:internets
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.

#72
davidm71

davidm71

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 167 posts
  • Gender:Male

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.

#73
Time2Retire

Time2Retire

    Retired

  • Retired Developers
  • 1,012 posts
  • Gender:Female
  • Location:anonymouse.eu

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


#74
flAked

flAked

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 470 posts
  • Gender:Male
  • Location:internets

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 :)

#75
Time2Retire

Time2Retire

    Retired

  • Retired Developers
  • 1,012 posts
  • Gender:Female
  • Location:anonymouse.eu
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.

#76
flAked

flAked

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 470 posts
  • Gender:Male
  • Location:internets

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


PCT (Performance Control) is used to directly set the performance state either via control register (FFixedHW 0x199) or SystemIO (0x00). Ok, so MBP8,3 is using the SystemIO to set the state.

PPC (Performance Present Capabilities) is used by PCT to determine, which of the performance states are currently available. Intel is suggesting using this bit to set different states for docked or mobile scenarios.
Educated guess: PPC is determined by 4 values, could be AC status, Temps, GPU, Battery.

1) We could set PPC to always Zero, hence all performance state available.

2) We must check for _OST Evaluation in the SSDT, as this is called after PPC to propagate the states to OPSM.


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.

Could you elaborate on that? Sure, we have this massive number of 255W of which we only strive to use 95W (overclock anyone :D ), but in the p-state calculation we only use that - or do we?


I just read about Thermal Model 3.0 - do we have PTC, TSS & TPC indicating OSX is using it? I do have those in my vanilla SSDT, so SandyBridge i5 is supporting it. But I'm not sure what's different to SpeedStep / Turbo.

#77
Time2Retire

Time2Retire

    Retired

  • Retired Developers
  • 1,012 posts
  • Gender:Female
  • Location:anonymouse.eu

Could you elaborate on that? Sure, we have this massive number of 255W of which we only strive to use 95W (overclock anyone ;) ), but in the p-state calculation we only use that - or do we?

We do not use the graphics part, but Apple does, and they stuff 0xA0 (160) in that register. The one I am reading.

I just read about Thermal Model 3.0 - do we have PTC, TSS & TPC indicating OSX is using it? I do have those in my vanilla SSDT, so SandyBridge i5 is supporting it. But I'm not sure what's different to SpeedStep / Turbo.

Thermal throttling seems more like a precaution to prevent the hardware from running hot. Shutting it down when it gets over a certain threshold.

And I would say yes. Almost obvious since method _TSS is responsibe for adding the P-States for turbo speeds, at least on the new MBP 8 series. Luckily our DSDT also has this info, but we need to convert/add the missing bits.

BTW; Do you have a link to the thermal info?

#78
flAked

flAked

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 470 posts
  • Gender:Male
  • Location:internets

We do not use the graphics part, but Apple does, and they stuff 0xA0 (160) in that register. The one I am reading.

I get it, so we need to set the register and be happy.

And I would say yes. Almost obvious since method _TSS is responsibe for adding the P-States for turbo speeds, at least on the new MBP 8 series. Luckily our DSDT also has this info, but we need to convert/add the missing bits.

BTW; Do you have a link to the thermal info?


TSS is just like PSS, but it defines T-states for processor throttling. I think it is a separate mechanism and not directly influenced/linked to P-states.

In the ACPI specs, chapter 8.4.3 http://www.acpi.info...ACPIspec40a.pdf


@github: will test the TDP code later today, thanks!

EDIT: Nice, TDP info and RAPL are getting recognized. The question is, if we can read the value and it is correctly set by our BIOS, then AICPUM might crash for another reason all together?

BTW, is there a way to enable DB_LOG for the kernel via RevoBoot?

#79
Time2Retire

Time2Retire

    Retired

  • Retired Developers
  • 1,012 posts
  • Gender:Female
  • Location:anonymouse.eu

@github: will test the TDP code later today, thanks!

EDIT: Nice, TDP info and RAPL are getting recognized. The question is, if we can read the value and it is correctly set by our BIOS, then AICPUM might crash for another reason all together?

Thanks. Now. While I'm not aware of what that might be, but I think that running a small tool on the MBP 8 series to collect info might help us.

BTW, is there a way to enable DB_LOG for the kernel via RevoBoot?

I'm not familiar with DB_LOG but I do know that people use something like: debug=0x108 as boot argument.

One of my grandmothers died today so I am prolly off-line for some time. Need to get my thought straiten out first. Just so sad for grandpa :wacko:

#80
flAked

flAked

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 470 posts
  • Gender:Male
  • Location:internets

One of my grandmothers died today so I am prolly off-line for some time. Need to get my thought straiten out first. Just so sad for grandpa :D

So sad to hear that :)

Take your time and don't rush being normal again - unless it helps to get things off your mind, of course.

Best wishes!





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy