SSDT generation script (Ivybridge PM)

[PikeRAlpha]

Can someone explain this process to compile a SSDT using the executable script? I don't understand how to run it, where do I insert ./ssdtPRGen.sh 77 4200 1

Or do I need to run something in terminal to direct it to the shell commands. I am new to this. Sorry for the simple questions.

Sorry. This is a command line tool and thus you enter that in a terminal window.

 

[PikeRAlpha]

With "missing" P-State entry I can lock the CPU at 800 MHz, via BIOS Settings I can lock the CPU at the lowest multiplicator x16, 1600 MHz. According to Geekbench, Novabench CPU is at 1600 MHz roughly twice as fast as at 800 MHz.

As I haven't found a way to lock the CPU at frequencies from 900 to 1500 MHz, I can't say whether Desktop Ivy Bridge parts can have working SpeedStep/TurboBoost and lower idle frequencies than those official 1600 MHz.

I'll ask Intel to comment on this.

For my part I've everything like I want with small modifications to your generated SSDT table. (APLF 0x08 for idle speed of 1600 MHz, APSN 0x04 for four turbo states and duplicated entry for not being stucj at 800 MHz)

Wait. Are you saying that the turbo states don't work when you use the value calculated by the script? That would be odd.

 

[kpkp]

First of. You don't have to duplicate a P-State? And there is this line at the top of the script:

baseFrequency=1500

Change that to 1100 (like it says, 1200-100) and try again.

I have to figure out where I can get this value from, or at least add another optional argument to override this value.

I duplicated the lowest p-state too.
Yes, first i set it to 700 and got a KP, but at 1100 works fine, except for the big gap (12x-22x).

Take a look at the attached SSDTs, those give me all the p-states from 8, 12, 16...33). You will figure out the difference much faster then me it might help you at further script development.

 

[man217]

I'll ask Intel to comment on this.


Wait. Are you saying that the turbo states don't work when you use the value calculated by the script? That would be odd.

To get what I want, I'd to make small changes to the output of your script.

APLF is responsible for setting frequency of low frequency mode, it's easier to set this value in the generated ssdt-pr.dsl to 0x04 for 1200 MHz for mobile ivy bridge or 0x08 for 1600 MHz for desktop ivy bridge.

APSN ist responsible for setting CPUMaxNonTurboPState.

Your script calculates 0x07 for APSN for ./ssdtPRGen.sh 77 4200 1

I'm overclocking my 3770K, I want x39 or 3900 MHz for the highest Non Turbo P-State instead of x35 or 3500 MHz,
so I'd to change 0x07 to 0x04 for APSN in generated ssdt-pr.dsl

It's just easier to set APLF and APSN to wanted values in generated ssdt-pr.dsl instead of complicating ssdtPRGen.sh further.

 

[hackintoshx86]

Sorry. This is a command line tool and thus you enter that in a terminal window.

I guess this is over my head..... I can not get terminal to output a file to the /tmp location

./ssdtPRGen.sh 77 4200 1

I don't think I am doing this right in terminal.

cd Downloads/
sudo ./ssdtPRGen.sh 77 4200 1
open /tmp

Edit: I have created a SSDT.aml

 

[hackintoshx86]

I am not having any p-states generated.

I have idle 16x and full throttle 42x only.

The script generated the file to my desktop instead of the /tmp folder which was weird, but it compiled without errors using a DSDT editor.

 

[PikeRAlpha]

I duplicated the lowest p-state too. Yes, first i set it to 700 and got a KP, but at 1100 works fine, except for the big gap (12x-22x).

You should be using 1100. Only MacBookAir5,1 and MacBookAir5,2 use 800 MHz.

Take a look at the attached SSDTs, those give me all the p-states from 8, 12, 16...33). You will figure out the difference much faster then me it might help you at further script development.

The first problem I want to solve is the duplicated P-State, but that won't happen when people have EIST enabled in their UEFI BIOS, OC and use values that even Apple isn't using.

Listen. I am fine about using 800 MHz, but only when Intel said that it can be done. That Intel supports lower frequencies on desktop processors, and that using it won't hurt the lifespan. Better safe than sorry.

Also. The 2012 iMac's aren't using anything below 1600 MHz. The 2012 Mac mini and MacBook Pro don't use anything below 1200 MHz. Only the MacBook Air uses 800 MHz.

Note: I am using RevoBoot. The only boot loader I'm aware of to disable EIST. As it should, otherwise Intel's SpeedStep is doing the hard work. Not Apple's CPU PM, which is what we want. Don't we?

 

[PikeRAlpha]

I am not having any p-states generated. I have idle 16x and full throttle 42x only.

No APSS? Well that is odd. How did you run the script?

It might be just a simple change. You may need to duplicate the lowest P-State and increase the package length by one.

The script generated the file to my desktop instead of the /tmp folder which was weird, but it compiled without errors using a DSDT editor.

That is correct. The latest version of ssdtPRGen.sh was changed to easy the use. Also. The file generated is now called: SSDT_PR.dsl and should indeed compile without errors. Even with the latest version of Intel's ASL compiler/decompiler (iasl).

 

[hackintoshx86]

No APSS? Well that is odd. How did you run the script?

It might be just a simple change. You may need to duplicate the lowest P-State and increase the package length by one.


That is correct. The latest version of ssdtPRGen.sh was changed to easy the use. Also. The file generated is now called: SSDT_PR.dsl and should indeed compile without errors. Even with the latest version of Intel's ASL compiler/decompiler (iasl).

./ssdtPRGen.sh 77 4200 1 is how I ran the script.

Thanks for pointing the changes out in the new rev. for ease of use.

 

[PikeRAlpha]

./ssdtPRGen.sh 77 4200 1 is how I ran the script.

That should work. Look for Name (APSS, Package, (0xNN) in your SSDT_PR.dsl

Thanks for pointing the changes out in the new rev. for ease of use.

You're welcome. A next version should become even easier. Just one argument with the top turbo frequency. That should work for most setups. Making TDP and the CPU type override values.