SSDT generation script (Ivybridge PM)

[PikeRAlpha]

Pike and Jeroen have updated RevoGirl's ssdtPRGen.sh script (v0.9 was written by RevoGirl) and added support for Ivy Bridge and Haswell processors. Many other improvements have since been added/tested and our update also includes a simple installer (app).

Instructions

1) Download the installer.

2) Run the installer (twice the first time).

Overclocking
ssdtPRGen supports overclocking, but then you have to open a terminal window and enter:

~/ssdtPRGen.[sh/command] Frequency

Note: [sh/command] means either ssdtPRGen.sh or ssdtPRGen.command

TDP
ssdtPRGen supports TDP override, by opening a terminal window and enter:

~/ssdtPRGen.[sh/command] Frequency Watts

BridgeType
ssdtPRGen supports BridgeType override, by opening a terminal window and enter:

~/ssdtPRGen.[sh/command] Frequency Watts Bridgetype

Note: 'bridgetype' can by 0 for Sandy Bridge, 1 for Ivy Bridge and 2 for Haswell.

CPU model
ssdtPRGen includes a list with (still unreleased) processor numbers (like: i7-3770K) so that you can fire up ssdtPRGen.app to generate SSDT_PR.dsl (on your Desktop) for your setup. You can also create a SSDT_PR.dsl for other setups. You do that by opening a terminal window and enter (example):

~/ssdtPRGen.[sh/command] i7-2600K

Here's another example: ~/ssdtPRGen.[sh/command] 'E3-1225 V2'

IASL
ssdtPRgen checks for IASL and download/install it when it can't find it – used to compile SSDT_PR.dsl to SSDT_PR.aml

AutoCopy
ssdtPRGen will ask you if you want to copy ~/Desktop/SSDT_PR.aml to /Extra/ssdt.aml

Note: The path will change automatically for RevoBoot and Clover.

Updates
Updating ssdtPRGen.sh is a easy. All you have to do is:
1) remove ~/ssdtPRGen.command
2) run ~/ssdtPRGen.app (the one with the icon)

Note: The installer (ssdtPRGen.app) checks ~/ssdtPRGen.command and when it isn't there (anymore) then it will update itself automatically.

Note: We are working on automatic updates for a next update.

Bugs
Let's start with an excerpt from a (still unpublished) book written by RevoGirl:

"My time over at [redacted] Inc. has taught me one important thing, and that is that software by design is flawed, and will fail eventually. Either due to a bug in the software, or so called 'user errors'. User errors however are no excuse, or should never become an excuse to blame the user from doing something wrong. That is why software designers should ask the end-users (user base) for feedback, because that will ultimately improve your work (product) and your relationship with said end-users, so that a next time someone does something unexpected, you have it covered. And remember; Nobody is perfect. Expect the unexpected. Be prepared..."

In short. We need your feedback to improve things. And to get things going. We need you to verify the bug with the latest version. We also need the output of the script so that we can try to reproduce the error. We may also need a dump from IORegistryExplorer [How to Guide] in case your CPU is stuck at a low frequency, or when power management doesn't seem to be working at all.

TIPS
In case the generated SSDT isn't working for your configuration, then check for Warnings/Errors produced by SSDTPRGen. Start by fixing them and make sure that you are using a model/board-id combo for Sandy/Ivy Bridge power management that fits your processor.

The next step is to make sure that SSDT's are dropped by the boot loader, and that it won't generate P/C-States for you because you don't need them with the generated SSDT.

Please note that certain model identifiers, notably the iMac12,n and iMac13,n identifiers, will use a reduced the number of triggered P-States. No worries. This is by design.

The last tip is perhaps the best one; Read all posts to see if someone else already solved the problem you are facing. And if nothing works, then provide us your IORegistry dump (see bugs for help) and the terminal output of ssdtPRGen.

Open Source
ssdtPRGen was and will always be Open Source. You can find the source code at:

https://github.com/Piker-Alpha/RevoBoot/tree/clang/i386/libsaio/acpi/Tools

Note: We kindly ask you to give back any improvements you make. This way we can share improvements from one single spot.

Limitations
ssdtPRGen has one known limitation, being the order of arguments:
~/ssdtPRGen.[sh/command] [CPU Model] [Frequency] [tdp in Watts] [Bridge Type]
Note: The CPU argument is optional.

Easy Installer

 

[toleda]

I have updated RevoGirl's ssdtPRGen.sh script, versions up until 0.9 were written by RevoGirl, and now it includes an option to generate Low Frequency P-States for Ivy bridge processors.

Thanks for the update. Perhaps this is a convenient time to fix a small problem.
Edit:
echo ' Scope (_PR.CPU0)'
to
echo ' Scope (\_PR.CPU0)'

 

[Bimmer325Ci]

I have updated RevoGirl's ssdtPRGen.sh script, versions up until 0.9 were written by RevoGirl, and now it includes an option to generate Low Frequency P-States for Ivy bridge processors. Example:

./sdtPRGen.sh 95 3900 1

"95" is the TDP value of your processor (see Intel datasheets).
"3900" is the maximum turbo clock speed.
"1" tells it to inject a name object, N x Low Frequency P-States and two other methods.

For a non Ivybridge processor, say i5-2500K running at stock speed, you enter:

./sdtPRGen.sh 95 3700 0

The generated ssdt-pr.dsl can be found in /tmp/

Note that someone told me that he needed to duplicate the lowest Low Frequency P-State (800MHz) for his i7-3770K in order to get SpeedStep going. No idea why, but we'll find out soon enough.


_

tried it out, CPU stuck at x8 (800MHz). entered: ./sdtPRGen.sh 69 3800 1

 

[PikeRAlpha]

@Toleda,

Sure. I will fix the error for the next update. Thanks!

@Bimmer325Ci,

Can you add "-v debug=0xffff" to your Kernel Flags in com.Apple.Boot.com and report back all relevant ACPI errors you see. Thanks.

Note: I removed the attachment and added a link to my Github repository for the latest version.

 

[man217]

Like Bimmer325Ci my CPU was first stuck at x8 (800 MHz). After duplication of lowest 800 MHz P-State entry everything works, MSRDumper reports
P-States from 16 to 42.

 

[PikeRAlpha]

Like Bimmer325Ci my CPU was first stuck at x8 (800 MHz). After duplication of lowest 800 MHz P-State entry everything works, MSRDumper reports
P-States from 16 to 42.

Ok. Can you e-mail me (see script for e-mail address) a dump from IORegistryExplorer with and without the duplicated 800MHz P-State? Thanks.

 

[man217]

Check your EMail

 

[PikeRAlpha]

Check your EMail

Got it. Working on it. Thanks.

I have updated the script to fix the ACST related debug errors. Please verify this for me.

p.s. Your cpu-type is 0x701 instead of 0x704

 

[man217]

I've tested version 1.5 of your script. ACST errors are gone.
Without duplicating/adding an additional P-State CPU is stuck at 800 MHz.
With duplicating/adding an additional P-State I get P-States from 1600 Mhz to highest P-State.
Changing Name (APLF, 0x08) to (APLF, 0x04) and Name (APSN, 0x07) to (APSN, 0x08)
like in ssdt.aml-i7oc.zip from Forum->Installation->Mountain Lion Desktop Support->ML: Native Ivy Bridge CPU and GPU Power Management
I get P-States from 1200 MHz to highest with Turbo Boost working like I configured it in BIOS settings.
One or dual Cores activation 4200 MHz
Three core activation 4100 MHz
Four cores activation 4000 MHz
I ran your script with ./ssdtPRGen.sh 95 4200 1

 

[PikeRAlpha]

Interesting. Can you use Name (APLF, 0x05) without lowering the max turbo speed? That should give you 1100MHz, but when you need to lower the max turbo multiplier in the BIOS first, then there may be a range limit defined somewhere in the source code.