Processor C-States

Yah! I have good news guys. I finally figured it out. The bad news is that I have no time to document it right now but I will later today. Check back in in a few hours from now!

A new version of AppleIntelCPUPowerManagementInfo.kext (v3.4) will also be released later today.

Update
Oops. I forgot that I had a birthday party and thus I was unable to finish my work in time. Let’s try again next week. Giving me some slack to release a brand new script. One that people will need to debug stuff.

Update-2
Ok. I first need to update ssdtPRGen.sh to make it work for certain motherboards that use _HID set to ACPI0004 to declare the processor objects from a Device scope. Without this it fails to work on these motherboards. I’ll try to commit a new update a.s.a.p. Done.

AppleGraphicsPowerManagement.sh

I wrote a new helper (bash) script called AppleGraphicsPowerManagement.sh One that I like to share with folks who use the IGPU for their desktop setup with HD graphics, and don’t see it stepping down to the lowest possible frequency. Which in my case is 200 MHz but it never reached a lower frequency than 750 MHz (0,75 GHz). Not without first running AppleGraphicsPowerManagement.sh

Ok. Let’s start by explaining why I said “helper (bash) script“. Yes indeed. This helper script is made for folks like me who use AppleHDA8Series.sh to create AppleHDA892.kext (example for my ALC 892) and want to use the Info.plist to inject AGPM data from it. Done the easy way…

Note: I also have other plug-ins in AppleHDA892.kext/Contents/PlugIns but that will be discussed in one of my next blog articles.

Next. Here is a screenshot of the Intel Power Gadget (v3.0.1) running on my Haswell setup.

Intel Power Gadget

Ignore the fact that it fails to show the estimated power usage (MSR 0x611 is Zero) and the temperature (next to a heater). Just look at the IGPU frequency (GT: 0,20 GHz) which was 0,75 before I ran my script. And this is what my script injects into the Info.plist:

<key>AGPM</key>
<dict>
    <key>CFBundleIdentifier</key>
    <string>com.apple.driver.AGPM</string>
    <key>IOClass</key>
    <string>AGPMController</string>
    <key>IONameMatch</key>
    <string>AGPMEnabler</string>
    <key>IOProviderClass</key>
    <string>IOPlatformPluginDevice</string>
    <key>Machines</key>
    <dict>
        <key>Mac-F60DEB81FF30ACF6</key>
        <dict>
            <key>IGPU</key>
            <dict>
                <key>Heuristic</key>
                <dict>
                    <key>EnableOverride</key>
                    <integer>0</integer>
                    <key>ID</key>
                    <integer>2</integer>
                </dict>
                <key>control-id</key>
                <integer>16</integer>
            </dict>
        </dict>
    </dict>
</dict>

Please note that the Mac-F60DEB81FF30ACF6 you see here will of course be different when you are using a different board-id. No worries. This will be checked by AppleGraphicsPowerManagement.sh Currently at version 0.6 but I will change/update it when required. Oh sure. I will add it to my Github repository, but at a later date.

Edit: Done! Now available from my Github repository.

p.s. Folks in need of different data could use this script after they modified it.

Have fun with it!

OS X Mavericks 10.9.2 (Build 13C44) Seeded

Apple seeded a third test build of OS X 10.9.2 (13C39) to registered Mac developers, available through the Software Update mechanism in the Mac App Store as well as through the Mac Dev Center.

10-9-2-build-13c44

Focus Areas
– Mail
– Messages
– VPN
– Graphics Drivers
– VoiceOver

Everyone else interested in testing OS X 10.9.2 (13C44) without being a registered Mac developer can download OSXUpdCombo10.9.2.pkg with help of: https://swscan.apple.com/content/catalogs/others/index-10.9seed-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog.gz

Please note that I may not share direct links to unreleased Apple software here so you will have to search for “OSXUpdCombo10.9.2.pkg” with help of the above link.

Hmm. It may be me, but it doesn’t seem like a lot was changed. Only a hand full of kexts. Not even one that we are interested in.

ssdtPRGen.sh version 8.8

Seems like power management in Mavericks really changed. Again. At least one person (Hackmodford) on Github issues confirmed that this was the case. And to be absolutely 100% certain that this is the case… I made you a new update of ssdtPRGen.sh that I committed seconds ago.

Please give ssdtPRGen.sh v8.8 a spin and let me know if this update solved the error:

XCPM: P-state table mismatch (error:0x8)
X86PlatformShim::sendPStates – pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x8
X86PlatformShim::start – Failed to send PStates

Note: The 0x8 is probably different for you!

p.s. I don’t know when power management was changed. In which version, so we have to figure that out together.

Update:
So far I have only have one confirmation that it works, with a i7-3770K, but I am working with Gringo Vermelho to see if we can get his configuration going.

I also changed ssdtPRGen.sh a bit so that it allows you to inject the extra P-States more easily. You do this by changing gIvyWorkAround in ssdtPRGen.sh. This are the supported values:

1 – Injects one extra Turbo P-State at he top with max-Turbo frequency + 1 MHz.
2 – Injects N extra Turbo P-State at the bottom.
3 – Injects both of them.

Get ssdtPRGen.sh version 9.0 now from Github repository, link below, and see if it is working for you. Thank you for testing this update!

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

New style of AppleHDA.kext patching (take III)

A month ago I published a first blog article about a New style of AppleHDA.kext patching and two weeks ago in a New style of AppleHDA.kext patching (take II) I started to get a lot more feedback and as a result we now have a much better script. One that really works.

In this blog article, called a New style of AppleHDA.kext patching (take III) I would not only like to thank the people who helped me, like Toleda, but I would also like to ask all of you to give the next version a go – committed later today.

I’d also like to stress that my days are slowly counting down so please, please report bugs and other possible suggestions to make the script even better.

Update:
Done. Version 2.4 has been committed into my repository. Please test this version and report bugs here: https://github.com/Piker-Alpha/AppleHDA8Series.sh/issues

Edit:
Link to Github issues was broken. Now fixed.

Thank you!

OS X Mavericks 10.9.2 (Build 13C39) Seeded

Apple seeded a second test build of OS X 10.9.2 (13C39) to registered Mac developers, available through the Software Update mechanism in the Mac App Store as well as through the Mac Dev Center.

10.9.2 Build 13C39

Everyone else interested in testing OS X 10.9.2 (13C39) without being a registered Mac developer can download OSXUpdCombo10.9.2.pkg with help of: https://swscan.apple.com/content/catalogs/others/index-10.9seed-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog.gz

Don’t know what changed for hackintosh users, but this update appears to be fine so far.

Edit: Image updated – I changed SystemVersion.plist to trigger an addition update run and forgot to change it back, and that was why the version info was 10.9 instead of 10.9.2

Three Dell U2713H(M) Monitors…

I am trying to get three Dell U2713HM monitors to work with a GigaByte Z87MX-D3H but I am running into some issues:

1.) The monitor connected to the DisplayPort is recognised as a built-in display rather than an external monitor.
Multi_Dell_U2713HM_Issues
Edit: Toleda suggested to change AAPL,ig-platform-id to 0x0d220003 but it turns out that I am already using it so that cannot be it. I also noticed that the DisplayPort connector is on port 0 which may be wrong.

Edit-2: Yup. I patched AppleIntelFramebufferAzul.kext and now it is using port 7, instead of port 0, and as a result the monitor is no longer recognised as a built-in display. I guess that settles it.

2.) The used image for the monitor is wrong.

Edit-2: Also solved by the AppleIntelFramebufferAzul.kext patch.

3.) The monitor connected to the HDMI port has a maximum resolution of 1920 x 1080 and requires EDID* edits.

Two questions:

1.) Has anyone ever solved this built-in / image problem before?

2.) Has anyone a working HDMI EDID* edit or know how to do this?

Update:

Mirroring enabled 2560 x 1440 on two of the three monitors, connected to DisplayPort and DVI connecter, but that is clearly not what I want. I need full control over the displays. However. This seems like a step closer to a real solution. This also counters something that ‘bcc9’ said. That this motherboard does not support dual-link DVI. Well. Mine certainly does.

*EDID is short of Extended Display Identification Data

Update-2:

I had some issues to get my Gigabyte GA-Z87MX-D3H motherboard to boot with a Displayport 1.2 cable plugged-in, but covering pin-20 (lower right corner) with a small piece of tape solved this problem.

New style of AppleHDA.kext patching (take II)

In a previous blog article I wrote about a New style of AppleHDA.kext patching and I guess that most of you have tried it, but… Toleda told me that it fails for people with Chameleon/Chimera when kernelcache is used. Folks using Clover appears to be fine I’m told. I also don’t have issues with it with RevoBoot (a private unreleased version).

Not only that. It was also too complicated, and that is why I wrote a script called AppleHDA8Series.sh. My first public version was 0.2 but I have since updated my Github repository with a slightly modified version. I am far from done, and a next update should be more fun to use, but please give this version a go and help me to improve AppleHDA8Series.sh Oops. I even ran out of time to add more text. Later!

Update:
A new major update to AppleHDA8Series.sh is now available from my Github repository. This version supports Realtek ALC 885, 887, 888, 889, 892, 898 and 1150 and will look in AppleHDA.kext and FakeSMC.kext for ConfigData. If AppleHDA8Series.sh can’t locate the required ConfigData, then it will try to download a file from Toleda’s Github repository and unzip it in a sub-directory of /tmp.

There are probably a couple of checks that I should add, but this has to be it for now. Later folks.

Update-2:
Good news. AppleHDA8Series.sh has been updated to version 1.5 and now supports four new arguments:

Usage: ./AppleHDA8Series.sh [-hald]
-h print help info
-a target ALC
-l target layout-id
-d target directory

Note: Currently it is not possible to copy/bin-patch the AppleHDA executable with AppleHDA8Series.sh (it only creates a symbolic link) but version 1.6 should change this. I also plan on adding support to copy/bin-patch the AppleHDAHardwareConfigDriver executable.

Update-3:
AppleHDA8Series.sh has been updated to version 1.6 and now supports a new argument:

-b AppleHDA

A next version will expand this so that you can use something like:

-b AppleHDA:\x8b\x19\xd4\x11,\x92\x08\xec\x10
or:
-b AppleHDA:x8bx19xd4x11,x92x08xecx10

Edit: Already implemented!

The last hurdle is to let you bin-patch the AppleHDAController binary, but that should be fine by the time we reach v2.0

Edit: Already implemented!

Update-4:
AppleHDA8Series.sh has been updated to version 2.0 and I think that this is it. Everything seems to work now so go ahead and give it a go.

Thanks for testing!

Happy New Year!

Happy New Year Everyone!

Let this be a year full of new exiting Apple hardware and software, but more importantly. One where health and family matters are far more important than having a blog or messing with a hack. The year of a new born baby and a new home. Well. In my case that is 😉