ssdtPRGen.sh v21.1 Released

A new update of ssdtPRGen.sh (v21.1) is now available from my Github repository.

Changes

board-id and model combinations added of the new MacBook Pro’s:

Mac-473D31EABEB93F9B:MacBookPro13,1 (IGPU only)
Mac-66E35819EE2D0D05:MacBookPro13,2 (IGPU only)
Mac-A5C67F76ED83108C:MacBookPro13,3 (GFX0 and IGPU)

There is also Mac-4BFBC784B845591E (IGPU only) but that one isn’t yet used. This one is most likely declared for the new MacBook Air.

Edit: Actually. I have no idea why I said that. Honestly. Nobody but Apple knowns what it will be used for. A BTO one perhaps?

Bug Reports

Bug reports (so called ‘issues’) can be filed at:

https://github.com/Piker-Alpha/ssdtPRGen.sh/issues

Please do not use my blog for bug reports.

Thank you!

Advertisements

12 thoughts on “ssdtPRGen.sh v21.1 Released

  1. Hi Pike, first of all I wanna wish you a happy new year. Then I want to ask this, I have configured in bios my CPU (6900k) overclock per core used: 1or2 =x40, 3=x39 …. 8=x36.
    How should I run your script? Is the correct way to pass -turbo=4000 option? Should I use any other option?
    Thank you very much

  2. Hi Pike!

    Is it possible to throttle the CPU by inputting lower values as parameters? I’m attempting to do so with a Kaby Lake, and even though it’ll generate the SSDT with 0 turbo Pstates, it still kicks up to max turbo frequency when it needs to.

    If this is the intended behaviour, do you know of any other way to disable turboboost?
    I’ve tried disabling it in bios to no avail.

  3. Pike,

    I’m on a Dell XPS 15 9550 with a i7-6700HQ, one of the same CPUs present in the new MacBook Pros. If I set plugin-type on CPU0 to 1 with a model identifier of MacBookPro13,3 (which should be correct for my CPU) and it loads X86PlatformPlugin, I get a KP. If I use your freqVectorsEdit.sh to switch to MacBookPro13,2 or MacBook9,1 values I also get a KP. It’s only when I use freqVectorsEdit.sh to switch to MacBookPro13,1 values that the system boots.The only real different I can see is that MacBookPro13,1 lacks these values:

    iocs_engage (20000000), iocs_disengage (15000000), iocs_cstflr (8), iocs_rtrigger (10)

    I haven’t had any luck finding out why these would make a difference. Can you help?

  4. I managed to get my problem solved with your xcpm_idle kernel patch. I’d tried before but there was a bug in Clover preventing it from being applied. 🙂

    An interesting side note: now that X86PlatformPlugin is loading, the OS is now fiddling with the HWP_REQUEST register.

    Specifically, when the laptop is on AC power, the energy performance preference byte fluctuates to either 0x20 or 0x80. I can’t tell if it is correlated to load. When it’s on battery, it stays at 0x80.

    It is also dynamically changing the desired performance byte on both AC and battery. I’ve seen values 0x23, 0x1a, 0x1f. It seems to fluctuate between the latter two values when the laptop is idle-ish. The max performance is always set at 0x23, minimum at 0x08, which are correct for my i7-6700HQ. HWP capabilities returns 0x1091A23. Curiously, CPU frequency never drops below 1.3Ghz, where before it would regularly drop to 800Mhz. Geekbench is 4292/13081.

    Without injecting plugin-type, the HWP request register stays at the default 0x80002301, and Geekbench is 4149/12607.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s