Jump to content

HD4600 SSDT Injection


4 posts in this topic

Recommended Posts

Hi there,


  I am in the process of getting a Haswell hackintosh running. Currently, both 10.8.4 (with 10.8.5 kernel) and 10.9 DP boot, but I have trouble getting integrated graphics to work. While I don't expect it to work in 10.8.4, it should be possible with 10.9.


  As far as my progress goes, I have extracted the DSDT and 7 SSDTs, recompiled (and fixed) them and Chameleon finds and loads them. And that's exactly where the problem kicks in: even though Chameleon says it loaded the SSDTs, it seemingly did not. How do I know: I modified SSDT-3, which contains the graphics device, but none of the changes appear in ioreg.


  My first solution was to start merging SSDT-3 with the base DSDT. While it was quite some work, my modifications to the graphics device (which I could do in the DSDT) now show up in ioreg correctly. Consequently, I would now proceed merging the other 6 SSDTs into the DSDT as well.


  On the other hand, I doubt that this is the proper way to go (let alone error prone). There must be some way to get the SSDTs to be used. As for the boot settings, I only used DropSSDT=Yes .. to my understanding this will drop the firmware SSDTs so my own can be loaded. But I also tried without this and got the same result. Is there a way to get more precise debugging output from Chameleon? Or should I try alternatives like RevoBoot or Clover?






PS: On second thought, merging the SSDTs also has its benefit: you can catch and fix more errors. In my case, the SSDT had an external int value declared, which simply did not exist. Instead, it should have been a method taking two arguments. With SSDTs, this stuff remains hidden.

Link to comment
Share on other sites



only 1 advice i think u must read...




about the loaders


u can try minimum Clover.. u have a uefi mobo no ?


about u post.. don't understand nothing.. u recompile the ssdt and fix ? with what if u don't apply any patches .. leave it original.. is already compiled...


good hack

Link to comment
Share on other sites



thanks for the help, I also just found the news shortly after posting but could't test it at that time yet. Now after some struggles with the new Chameleon it turns out my PciRoot was wrong. And while figuring that out, I managed to get the DSDT going .. problem here was a wrong “double byte”-order. For the DSDT, I followed Pike R. Alpha's blog entry from mid June and changed both device-id and AAPL,ig-platform-id as follows:

"device-id", Buffer (0x04) { 0x00, 0x00, 0x16, 0x0a },"AAPL,ig-platform-id", Buffer (0x04) { 0x00, 0x00, 0x16, 0x0a }
while it should have been

"device-id", Buffer (0x04) { 0x16, 0x0a, 0x00, 0x00 },"AAPL,ig-platform-id", Buffer (0x04) { 0x00, 0x00, 0x16, 0x0a }
Note the swapped double-bytes for the device-id. So I learned:
  • there’s no need to change device-id (though I do not understand why)
  • a wrong device-id will obviously keep the device from being recognised :)
  • IntelAzulFB does not seem to touch the device-id either
  • IntelAzulFB also won’t override any existing values (provided by a custom DSDT)
About the SSDT-fixing: I actually wasn’t referring to patching things for OS X to work. Instead I meant fixing compiler errors only. Under the assumption that iasl is correct, a decompiled DSDT or SSDT should also compile again properly or else the .aml won’t be correct in the first place either. By recompiling, I can get rid of those errors .. and then again recompiling those new DSDT or SSDT really works as expected :)





Edit: Code snippets had different IDs as well, but only the order of bytes was the real problem.

Link to comment
Share on other sites


  • Create New...