Jump to content
frankiee

AppleGraphicsDevicePolicy "on the fly" patching - impossible? (alternate idea, but still does not seem to work)

120 posts in this topic

Recommended Posts

So I had some time to look at the SMBIOS 6,1 + AppleGraphicsDevicePolicy issue once again. And unfortunately it seems it is still impossible to patch it on the fly using a kext and / or Clover? Problem is that while you can manually patch the kext, that wont work for the installer and the recovery partition ...

 

I also had an idea how to do it but I wonder why this does not work. As you might now, changing "config1" to "none" is not possible since Clover only allows patching .plist entries with the same length. OK, so I thought "different", and tried to patch the System definitions itself.

 

I.e. changing Mac-F60DEB81FF30ACF6 to a bogus value like Mac-XXXXXXXXXXXXXXXX and then change a definition which already has the entry "none", like Mac-00BE6ED71E35EB86 to Mac-F60DEB81FF30ACF6 in a 2nd step.

 

Like this:

<key>KextsToPatch</key>
<array>
	<dict>
		<key>Comment</key>
		<string>MacPro 6,1 SMBIOS Patch 1</string>
		<key>Find</key>
		<string>4d61632d46363044454238314646333041434636</string>
		<key>InfoPlistPatch</key>
		<true/>
		<key>Name</key>
		<string>AppleGraphicsDevicePolicy</string>
		<key>Replace</key>
		<string>4d61632d58585858585858585858585858585858</string>
	</dict>
	<dict>
		<key>Comment</key>
		<string>MacPro 6,1 SMBIOS Patch 2</string>
		<key>Find</key>
		<string>4d61632d30304245364544373145333545423836</string>
		<key>InfoPlistPatch</key>
		<true/>
		<key>Name</key>
		<string>AppleGraphicsDevicePolicy</string>
		<key>Replace</key>
		<string>4d61632d46363044454238314646333041434636</string>
	</dict>
</array>
</dict>

And guessing from the boot log the patch seems to be executed:

0:125  0:000  KextsToPatch 0: AppleGraphicsDevicePolicy (MacPro 6,1 SMBIOS Patch 1) Info.plist patch, data len: 20
0:125  0:000  KextsToPatch 1: AppleGraphicsDevicePolicy (MacPro 6,1 SMBIOS Patch 2) Info.plist patch, data len: 20

But .... getting a black screen again :mad:

 

So ... did I still do something wrong or is it really impossible to do that? Any other ideas?

 

I would absolutely prefer this way instead of always patching the kext after any updates, or having to boot with nv_disable when I want to access the recovery partition.

 

Share this post


Link to post
Share on other sites
Advertisement

I don't have a MacPro SMBIOS, so I can't test really this out easily, but what would happen if you patched "Config1" to, say, "0Config" or some other nonexistent configuration name of the same strlen() as Config1? Would it cause a KP, or would it just do the same thing as if "none" had been specified?

Share this post


Link to post
Share on other sites

Yeah, it almost seems like that. So the only other option seems to be using the 5,1 definition. But I heard that CPU PM is not working as efficiently then. Any take on this?

Share this post


Link to post
Share on other sites

I read somewhere (I think it was Clover tickets on SF) that the value is read from the kext from the filesystem, so patching it in the kernelcache won't work.

 

Ah - that would be the explanation, but how stupid is that? Only thing I can imagine to combat this behavior would be to "binpatch" this kext, but unfortunately,  that is beyond my capabilities.

 

Just add this mod file to :AppleGraphicsControl.kext...AppleGraphicsDevicePolicy..

 

Thanks, but I know how to do this. The point of my question was about being able to patch on the fly without actually modifying anything in S/L/E.

Share this post


Link to post
Share on other sites

my question was about being able to patch on the fly without actually modifying anything in S/L/E.

Make a dummy kext with the Info.plist/edited property, install the dummy kext to EFI/CLOVER/kexts/10...

Share this post


Link to post
Share on other sites

Make a dummy kext with the Info.plist/edited property, install the dummy kext to EFI/CLOVER/kexts/10...

 

Well, sounds interesting, but how can I do that, is there any guide?

Share this post


Link to post
Share on other sites

I think, but I'm not sure of that, you just have to copy the patched kext into the kexts folder of clover (efi...10.11) and rename to AppleGraphicsControl1.kext.

Share this post


Link to post
Share on other sites

I think, but I'm not sure of that, you just have to copy the patched kext into the kexts folder of clover (efi...10.11) and rename to AppleGraphicsControl1.kext.

 

Since he mentions a "dummy" kext I guess he is referring to this kind of thing: https://pikeralpha.wordpress.com/2013/12/17/new-style-of-applehda-kext-patching/???

 

I actually use Pikes method for patchless AppleHDA operation and it works great, but ... it does not work when placing this kext in "EFI/Clover/kexts/..."

 

Of course I can try this, but I am a bit clueless right now. So any help / pointers to the right direction so that I am able to build and try such a dummy kext would be greatly appreciated!

Share this post


Link to post
Share on other sites

So I found this post by shilhohhh: http://www.insanelymac.com/forum/topic/305648-clover-kext-infoplist-patch/?p=2145801

 

Apparently he already tried patching with a dummy kext, but it does not seem to work :cry:

 

Seems we are running out of options ... So either I change SMBIOS back to 5,1 or someone finds another way.

Share this post


Link to post
Share on other sites

So I had some time to look at the SMBIOS 6,1 + AppleGraphicsDevicePolicy issue once again. And unfortunately it seems it is still impossible to patch it on the fly using a kext and / or Clover? Problem is that while you can manually patch the kext, that wont work for the installer and the recovery partition ...

 

I also had an idea how to do it but I wonder why this does not work. As you might now, changing "config1" to "none" is not possible since Clover only allows patching .plist entries with the same length. OK, so I thought "different", and tried to patch the System definitions itself.

 

I.e. changing Mac-F60DEB81FF30ACF6 to a bogus value like Mac-XXXXXXXXXXXXXXXX and then change a definition which already has the entry "none", like Mac-00BE6ED71E35EB86 to Mac-F60DEB81FF30ACF6 in a 2nd step.

 

Like this:

<key>KextsToPatch</key>
<array>
	<dict>
		<key>Comment</key>
		<string>MacPro 6,1 SMBIOS Patch 1</string>
		<key>Find</key>
		<string>4d61632d46363044454238314646333041434636</string>
		<key>InfoPlistPatch</key>
		<true/>
		<key>Name</key>
		<string>AppleGraphicsDevicePolicy</string>
		<key>Replace</key>
		<string>4d61632d58585858585858585858585858585858</string>
	</dict>
	<dict>
		<key>Comment</key>
		<string>MacPro 6,1 SMBIOS Patch 2</string>
		<key>Find</key>
		<string>4d61632d30304245364544373145333545423836</string>
		<key>InfoPlistPatch</key>
		<true/>
		<key>Name</key>
		<string>AppleGraphicsDevicePolicy</string>
		<key>Replace</key>
		<string>4d61632d46363044454238314646333041434636</string>
	</dict>
</array>
</dict>

And guessing from the boot log the patch seems to be executed:

0:125  0:000  KextsToPatch 0: AppleGraphicsDevicePolicy (MacPro 6,1 SMBIOS Patch 1) Info.plist patch, data len: 20
0:125  0:000  KextsToPatch 1: AppleGraphicsDevicePolicy (MacPro 6,1 SMBIOS Patch 2) Info.plist patch, data len: 20

But .... getting a black screen again :mad:

 

So ... did I still do something wrong or is it really impossible to do that? Any other ideas?

 

I would absolutely prefer this way instead of always patching the kext after any updates, or having to boot with nv_disable when I want to access the recovery partition.

Anyone notice the sample written wrong?

It is not a , it must be because there are hex digits not characters.

Share this post


Link to post
Share on other sites

Anyone notice the sample written wrong?

It is not a <string>, it must be <data> because there are hex digits not characters.

 

Uuups. Yes you are right. But even if I change that it still does not work. So it really seems to be impossible which is such a pity.

 

But seeing my error, what about  logging if the patch was actually applied or not? Clover only complains about apparent errors like different length, but what about logging more details, i.e. if Clover  has found the data to replace, and if it has managed to replace it? Think this would help debugging issues - like this one - with kext patching. (Well, of course if the patch has the desired effect is a different story as we have seen here, but still it would be helpful to know if the search data was  found at all)

Share this post


Link to post
Share on other sites

Try this:

 

<key>KextsToPatch</key>

<array>

<dict>

<key>Comment</key>

<string>AppleGraphicsDevicePolicy (board-id) Patch © Pike R. Alpha</string>

<key>Find</key>

<data>

Ym9hcmQtaWQ=

</data>

<key>Name</key>

<string>AppleGraphicsDevicePolicy</string>

<key>Replace</key>

<data>

Ym9hcmQtaXg=

</data>

</dict>

</array>

Share this post


Link to post
Share on other sites

Pike! You are the man :thumbsup_anim:

 

Just checked and at least with my El Cap test installation it apparently seems to work. Unfortunately, the recovery partition still refuses to boot into anything else than the dreaded black screen even with that patch - but thats the smaller problem, since here I can use an alternate Clover config with Mac Pro 5,1 SMBIOS, thats enough for the occasional recovery boot I guess.

 

So if this patch survives Apple updates -> no more manual fiddling - Yay! Very good.

 

Thanks a lot and it's good to see you back.

Share this post


Link to post
Share on other sites

Nice Patch,

 

but ist works only with 1 display connected. When i use 2 displays i got a black screen and 3 seconds later the system does a reboot.

Share this post


Link to post
Share on other sites

Try this:

 

<key>KextsToPatch</key>

<array>

<dict>

<key>Comment</key>

<string>AppleGraphicsDevicePolicy (board-id) Patch © Pike R. Alpha</string>

<key>Find</key>

<data>

Ym9hcmQtaWQ=

</data>

<key>Name</key>

<string>AppleGraphicsDevicePolicy</string>

<key>Replace</key>

<data>

Ym9hcmQtaXg=

</data>

</dict>

</array>

Interesting patch... 'board-id' to 'board-ix'. So... Apple's code, failing to get the board-id from the ioreg, returns success for a whitelist check! Nice...

 

Too bad I don't think they do the same in AirPortBrcm4360.

 

Note: I have developed a patch (not board-id specific) for abgn whitelist, but no way to test (do not have the hardware subject to this whitelist check).

Share this post


Link to post
Share on other sites

May i practise my english here too?

I posted some note about avoiding blackscreen with macpro sysdef after reading his blog (last year if i can remember, before my pc completely dead after bios flashing failured & wait for months from ebay) with the same topic (manually changing plist to none) so clearly i mention Pike there. But instead of using those method, i use ssdt (forked from his repo) to change label "PEGP" to "GFX1" to get rid from this problem after i got dumped macpro DSDT somewhere in this forum.

 

** Edit: "PEGP" to "GFX1"

Edited by cecekpawon

Share this post


Link to post
Share on other sites

May i practise my english here too?

I posted some note about avoiding blackscreen with macpro sysdef after reading his blog (last year if i can remember, before my pc completely dead after bios flashing failured & wait for months from ebay) with the same topic (manually changing plist to none) so clearly i mention Pike there. But instead of using those method, i use ssdt (forked from his repo) to change label "GFX0" to "GFX1" to get rid from this problem after i got dumped macpro DSDT somewhere in this forum.

 

That also sounds like an interesting approcach! Unfortunately I do not understand anything you wrote ;) But it might be another route to try. Can you explain it in english here? Ah and this is what these forums should be about, discussing different technical approaches to solve problems, instead of going on a personal vendetta.

Share this post


Link to post
Share on other sites

Basically i just need to change igpu ("GFX0") to "GFX2" & discrete ("PEGP") to "GFX1" in DSDT. You can use SSDT method above or simple clover patch below:

<key>ACPI</key>
<dict>
  <key>DSDT</key>
  <dict>
    <key>Patches</key>
    <array>
      <dict>
        <key>Comment</key>
        <string>GFX0 [to] GFX2</string>
        <key>Find</key>
        <data>
        R0ZYMA==
        </data>
        <key>Replace</key>
        <data>
        R0ZYMg==
        </data>
      </dict>
      <dict>
        <key>Comment</key>
        <string>PEGP [to] GFX1</string>
        <key>Find</key>
        <data>
        UEVHUA==
        </data>
        <key>Replace</key>
        <data>
        R0ZYMQ==
        </data>
      </dict>
    </array>
  </dict>
</dict>

I dont guarantee it will work for you.. but you may try sir

Share this post


Link to post
Share on other sites

I think what he is saying in the blog post is that your discrete GPU needs to be GFX1 and your integrated one GFX2, first with address 0x00000000 (Zero) and second with 0x00020000.

The SSDT snippet he posted disables GFX0 and PEG0 via 'Name (_STA, Zero)'. He is also mentioning you need to set 'AAPL,ig-platform-id' on GFX2 to enable AirPlay Mirroring.

 

And no, I don't understand the language, I used Google Translate and some logic.

 

EDIT: Meh, took too long to write.

Share this post


Link to post
Share on other sites

I think what he is saying in the blog post is that your discrete GPU needs to be GFX1 and your integrated one GFX2, first with address 0x00000000 (Zero) and second with 0x00020000.

The SSDT snippet he posted disables GFX0 and PEG0 via 'Name (_STA, Zero)'. He is also mentioning you need to set 'AAPL,ig-platform-id' on GFX2 to enable AirPlay Mirroring.

 

And no, I don't understand the language, I used Google Translate and some logic.

 

EDIT: Meh, took too long to write.

 

I never trust Google Translate, can be so misleading ;)

 

But of course you may be right, just looks like this. Thing is, I only have a discrete GPU and not an internal one, and the ACPI path to the card is "_SB.PCI0.NPE3.PXS1" I do not see "GFX0" anywhere in ioReg, so not sure if that would work with my setup and how to modify it. Nevertheless, I can imagine this approach would be even more robust than the Clover patch, but I basically know not much ACPI coding, so I have no clue how to adapt this.

 

But as I understand I could try to just rename "PXS1" to "GFX1"?

Share this post


Link to post
Share on other sites

To determine GPU address check Clover bootlog / run bdmesg from terminal:

PCI (00|01:00.00) : 10DE 0FC6 class=030000
Found NVidia model=MSi GeForce GTX 650

Then check your DSDT:

Name (_ADR, 0x00010000)

Or with dspci:

$ /Applications/DPCIManager_ML/dspci
...
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK107 [GeForce GTX 650] [10de:0fc6] (rev a2) (subsys 1462:0010)

Or boot with Clover inject <GPU> true, and compare it with your original DSDT.

 

You can safely rename "PXS1" to "GFX1" if you have successfully injected properties in "_SB.PCI0.NPE3.PXS1" before, and ignoring "GFX0" since you dont have any Intel GPU. Even if im not sure about this (with only single GPU device) but you may try, since macpro come with dual GPU.

 

Despite that, you can stay with previously method with zero risk to take

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×