Jump to content
bcc9

Intel HD Graphics 4600 (Haswell) working displayport

190 posts in this topic

Recommended Posts

Just an update on progress since last time. Since I don't have any options in my BIOS to modify the VRAM provided to the 4600, I tried playing around with the values under DSDT. I literally tested every value listed from 2GB - 1MB and it didn't seem to do anything about the glitches and artifacts. Some may have made it glitch faster, giving more image to work with before I would fix it but otherwise, no real significant change. I haven't looked much into trying to disable my GeForce yet, but I am planning on giving it a test within the next few days. At the very least, i'm hoping my battery performance goes up with it disabled.

 

I changed my SystemType back to 2 and haven't had any issues since that i've noticed. I briefly tested out ssdtPRGen to see if maybe, just maybe I could get CPUPM to work with my Haswell and give me support but that didn't work either. It's looking like waiting for 10.8.5 final is my only option at this point.

 

I also merged your IGPU change into my current DSDT. Performance doesn't seem to have changed since doing so, so that's good. I did notice that after the merge, I am given a brightness slider under Display prefs but it's purely cosmetic and doesn't work. I really need to look into fixing that. >_>

Can you post some test to compare with others cards? 

Share this post


Link to post
Share on other sites
Advertisement

*sigh* You gotta be more specific with requests. My last reply had a ton of info in it and I'm not going to even try to decipher what it is you're referring to. If it has anything to do with my dsdt, search the thread and the forum. Everything is already posted here. Again, you just need to look.

Share this post


Link to post
Share on other sites

*sigh* You gotta be more specific with requests. My last reply had a ton of info in it and I'm not going to even try to decipher what it is you're referring to. If it has anything to do with my dsdt, search the thread and the forum. Everything is already posted here. Again, you just need to look.

I mean test about how fast is to get video on board.  Like Heaven. We can compare with discrete cards your benchmark. 

And maybe it´s better on board video that a discrete video card.

 

http://unigine.com/products/heaven/

Share this post


Link to post
Share on other sites

Heaven is lousy, about 6 to 8 fps on Extreme preset, about 12 to 15 on Custom preset. Though according to CInebench this card scroes as much as AMD HD4870, which is a direct competitor to old G92-series cards like 9800GTX+ and GTS250. Personally, after switching from GTS250, the OSX UI w/ HD4600 performs very snappy. When it comes to extensive OpenGL graphics it performs on par with HD4000, possibly slightly better, but it's on 10.8 (no new GL support). Playing TeamFortress wasn't as pleasant as I otherwise had hoped.

Share this post


Link to post
Share on other sites

BTW, as of the current chameleon mainline version, there's no need to inject via dsdt or ssdt. You can simply configure your ig-platform-id in org.chameleon.Boot.plist. Mainline 2262 version of chameleon is here: http://www.insanelymac.com/forum/files/file/59-chameleon-22-svn/

ermac's announcement is on the home page: http://www.insanelymac.com/_/osx86/intel-hd4000-and-haswell-inject-aaplig-platfor-r1005

 

For the ig-platform-id I listed in post #1 that works with displayport, I use:

        <key>GraphicsEnabler</key>
        <string>Yes</string>
        <key>IntelAzulFB</key>
        <string>10</string>
in my org.chameleon.Boot.plist.

Share this post


Link to post
Share on other sites

BTW, as of the current chameleon mainline version, there's no need to inject via dsdt or ssdt. You can simply configure your ig-platform-id in org.chameleon.Boot.plist. Mainline 2262 version of chameleon is here: http://www.insanelymac.com/forum/files/file/59-chameleon-22-svn/

ermac's announcement is on the home page: http://www.insanelymac.com/_/osx86/intel-hd4000-and-haswell-inject-aaplig-platfor-r1005

 

For the ig-platform-id I listed in post #1 that works with displayport, I use:

        <key>GraphicsEnabler</key>
        <string>Yes</string>
        <key>IntelAzulFB</key>
        <string>10</string>
in my org.chameleon.Boot.plist.

 

 

 

thanks my intel 4600 woooorkiing :D

Share this post


Link to post
Share on other sites

Do you know how to get  ig-platform-id ??? thanks

 

i  jusy used this  in my org.chameleon.Boot.plist.

 

<key>GraphicsEnabler</key>

<string>Yes</string>

<key>IntelAzulFB</key>

<string>10</string>

Share this post


Link to post
Share on other sites

Good find, toleda! Hopefully this not off-topic indeed.

I guess the only option is to wait for new Core i3 processor release and hope for a major BIOS update coming from AMI... It's not the first issue with BIOS, at least not at my board. I can't disable UART and LPT, they simply won't turn off.. same with IGPU, if discrete graphics card is installed and IGPU is turned off in BIOS it's still seen by the system (Windows included)...

Share this post


Link to post
Share on other sites

BTW, as of the current chameleon mainline version, there's no need to inject via dsdt or ssdt. You can simply configure your ig-platform-id in org.chameleon.Boot.plist. Mainline 2262 version of chameleon is here: http://www.insanelymac.com/forum/files/file/59-chameleon-22-svn/ermac's announcement is on the home page: http://www.insanelymac.com/_/osx86/intel-hd4000-and-haswell-inject-aaplig-platfor-r1005For the ig-platform-id I listed in post #1 that works with displayport, I use:

<key>GraphicsEnabler</key>
        <string>Yes</string>
        <key>IntelAzulFB</key>
        <string>10</string>
in my org.chameleon.Boot.plist.

Thanks for this. Mine works using either 8-0 as the value. 10 does not work for me and sadly, this has not fixed my booting artifacts/glitching issues. However, using 9 as the value makes the booting glitches less obvious and switching my refresh rate seems not to fix the issue. When I can, I'll test out more values and maybe I can find the "sweet spot" for my system.

 

UPDATE: Got it! If I use 12 as the value, my startup artifacts and glitches virtually disappear and I do NOT have to change my refresh rate to make the system usable anymore! I still can see one tiny artifact on the login screen but it's so insignificant that it can be easily overlooked and considering I did further testing using around 9 different values without getting any fix for it, i'd say it's not worth any extra work on my part. Other than that, everything looks dandy. Thanks again for pointing this out. It made my testing MUCH easier. :)

Share this post


Link to post
Share on other sites

Unexpected behavior with Azul framebuffer 03 00 22 0d.  Booting with both DP and HDMI connected, IOReg shows DP (port 0x7) and HDMI (port 0x5).  Booting with DP only, display shows on port 0x7.  Booting with HDMI only, display shows on port 0x7, not port 0x5.  Editing port 0x5 for the HDMI connector makes no difference.  It appears the Azul framebuffers are not configured to the physical motherboard connectors while the SB and IB framebuffers are.

Share this post


Link to post
Share on other sites

Unexpected behavior with Azul framebuffer 03 00 22 0d.  Booting with both DP and HDMI connected, IOReg shows DP (port 0x7) and HDMI (port 0x5).  Booting with DP only, display shows on port 0x7.  Booting with HDMI only, display shows on port 0x7, not port 0x5.  Editing port 0x5 for the HDMI connector makes no difference.  It appears the Azul framebuffers are not configured to the physical motherboard connectors while the SB and IB framebuffers are.

Yes, that is what Pike R Alpha had said on his blog a while back. I agree also, what shows up in ioreg as Port Numbers is obviously not the physical port number as it depends on what is actually plugged in. Maybe to do with the time delay element that Pike also mentioned in the decoding of the binary for the kext for prioritising the different connectors. The other thing about this particular frame buffer is that two of the connections have the same time delay (or priority).

On my board I have one DP, 1 HDMI and 1 DVI connection. I have not managed  to amend any of the connection types successfully to DVI on my board (always scrambled). whereas the HDMI and DP connections both work fine and seem to swap around port numbers according to what is present at boot.

Share this post


Link to post
Share on other sites

Not sure how useful this could be, but I've traced the log to procedure AppleHDAController::checkCodecCommandTimeout(unsigned int, bool) inside AppleHDAController and the errors related to that:

kernel[0]: Sound assertion - Command/Response TIMED OUT and ( kRequestStateMatch == fCodecRequest->state = 2 ), fCodecRequest->command->codec: 0xffffff80184a4800, fCodecRequest->command->verb: 0xF0000, fPoweredDown: 0
kernel[0]: Sound assertion in AppleHDAController at line 5459
kernel[0]: Sound assertion in AppleHDAController at line 5460
kernel[0]: Sound assertion in IOHDACodecDevice at line 161
kernel[0]: Sound assertion in IOHDACodecDevice at line 567
kernel[0]: Sound assertion in AppleHDAController at line 4693
kernel[0]: Sound assertion in AppleHDAEngine at line 599
kernel[0]: Sound assertion in AppleHDAEngine at line 6963

 
I've tried making it go directly to 0x80B3 offset by patching 0f84b2010000 to 0f85d6010000 and all the errors except 599 assertion are gone from the log (which as of 10.8.5 I also get on my ALC269, and it wasn't there before.. so its nothing to worry about)...When OSX starts up a display mirror icon appears in the menu bar for a brief second and then GUI freezes, mouse is not responding, nor is the keyboard.
 
I think in general it just stalls expecting the command from codec and it never happens (same as with BT 30 sec timeout for configurePM procedure that I had patch to not wait for 30 seconds)...
 
In the attached pdf with purple arrows is marked the routine of this procedure based on console log and the end result. With red circle what I believe is the failure, which ends up as return, meaning the procedure partially loops and thus errors in console appear twice in a row. With green circle is what I believe should happen when this procedure succeeds.. I could of corse try just reversing the je to jne at 0x807e to see if the comparison to 1 would return false (not equal) and it would jump to 0x80b3.. but I don't want all the errors to be produced along the way. I'm not that good with assembly code so pardon if I'm just waffling complete nonsense here .. but that are my observations. 
 

Share this post


Link to post
Share on other sites

Haswell/HD4600  HDMI Audio is working in 10.8.5, see Mountain Lion HDMI Audio - OSx86 10.8 (Mountain Lion) - InsanelyMac Forum

 

Summary, two patches (credit: PikeRAlpha) and new HDMI audio dsdt edits/HDMI audio ssdt (credit bcc9):

1. AppleHDA.kext, fixes missing codec

2. AppleIntelFramebufferAzul.kext, assigns DP to port 0x5 and HDMI to port 0x7 in 0x0300220D framebuffer, DP and/or HDMI audio working

3. dsdt/ssdt, add HDAU@3, remove HDEF/hda-gfx injection, both dsdt edits and the ssdt enable native HD4600 AGPM.

 

My hypothesis was completely wrong.  Appears device_id 0x0c0c was included in AppleHDAController and disabled. Intentional?  Test plan failure? Interestingly, the disabling is different in AppleHDA.kext _v2.4.7 and _v2.5.2.

 

Mavericks details: Haswell HDAU solution | Pike's Universum

Share this post


Link to post
Share on other sites

Haswell/HD4600  HDMI Audio is working in 10.8.5, see Mountain Lion HDMI Audio - OSx86 10.8 (Mountain Lion) - InsanelyMac Forum

 

Summary, two patches (credit: PikeRAlpha) and new HDMI audio dsdt edits/HDMI audio ssdt (credit bcc9):

1. AppleHDA.kext, fixes missing codec

2. AppleIntelFramebufferAzul.kext, assigns DP to port 0x5 and HDMI to port 0x7 in 0x0300220D framebuffer, DP and/or HDMI audio working

3. dsdt/ssdt, add HDAU@3, remove HDEF/hda-gfx injection, both dsdt edits and the ssdt enable native HD4600 AGPM.

 

My hypothesis was completely wrong.  Appears device_id 0x0c0c was included in AppleHDAController and disabled. Intentional?  Test plan failure? Interestingly, the disabling is different in AppleHDA.kext _v2.4.7 and _v2.5.2.

 

Mavericks details: Haswell HDAU solution | Pike's Universum

Yeah, I was searching in post-problem area as well, should have looked at controller init first... time out occurs because it fails to initialize it.

 

The codec is not missing it's just that 0x0c0c controller (non Apple-native) is not being rooted correctly (on purpose I assume). The series of checks for it's initialization are similar to how codec-id is being matched in AppleHDA. Here device-id of 8086 HDMI controller is being matched instead, but only the one used by Apple is actually being rooted all the way through to initialization. Actually, the checks (or *disabling* how you call it) are fairly identical across 10.8.5 and 10.9, I ended up just doing the same thing as I would with codec-id matching:

4D6hr.png

Could you test the same approach for 10.9 binary as well ? Left is for 10.9 and right is for 10.8.5: http://puu.sh/4D7C4.png

As you can see the algo is identical: compare device-id of hdmi audio controller (not codec) to 0x0c0b if it hasn't matched jump and compare with 0x0d0b, then if hasn't matched jump and compare with 0x0c0c and here we end up with dead route. Whereas if we change device id of 0x0c0b to 0x0c0c we will get a match and jump to check if device id is 0x0a0c and if we patch here again to 0x0c0c we get a mach and jump to controller init subroutine.

 

Also, I've mentioned it over Pike's blog. The sound assertion 599 you may see in 10.8.5 appears due to missing device-property called MaximumBootBeepVolume. I've checked your git repos and none of the edits seem to include it, so people with Haswell (and everyone else who has updated to 10.8.5 and possibly 10.9 DPs) are bound to get sound assertion errors in their log due to lacking this property.

Share this post


Link to post
Share on other sites

The JA instruction below the CMP 0x0c0b in AppleHDAController::setupHostInterface() won't make the jump when you change it to 0x0c0c because it is equal and not greater than. The result is that not all devices will be checked (which is what we want it to do). This is why we only changed the JMP for 0x0c0c.

Share this post


Link to post
Share on other sites

This jump will most likely require an address recalculation after every OS update though, that's why I was looking at trying to make it more universal. The approach i've mentioned works for me (with 0x0c0c) in 10.8.5 but the operator sure is different in 10.9 DP8 after comparing 0x0c0b to controller's device id. Though, 77 is still an "jump short if not below or equal", whilst 7F used in 10.8.5 is "jump short if not less or equal" .. which is basically same thing since *equal* is there. So it should work nonetheless.

 

UPD:

My understanding of the check sequence in both 10.8.5 and 10.8 DP8: 

	If (!(gDeviceId <= 0x0b0c)) // device id is not 0x0a0c or 0x0b0c
	{
		If (!(gDeviceId <= 0x0d0b))
		{
				If (!(gDeviceId <= 0x1c1f))
				{
					If (dDeviceId == 0x1c20){ ... }	
					Else { ...}
				}
		}
		Else
		{
			If (gDeviceId == 0x0c0c) { Fail () }
		}
	}
	Else
	{
		If (gDeviceId == 0x0a0c) { Init () }
		Else{ Fail () }
	}

So, we can assume that by changing 0x0b0c to 0x0c0c we make it execute the Else statement (it's equal!), where when checking for match to 0x0a0c, which we substitute with 0x0c0c again, we get an equals match and we go to Init () ?

Honestly, the difference in jump operators (0x77 vs 0x7F) is most likely due to different ways of compiling the binary for target OS 10.8 and 10.9..  the algo still remains the same.

 

UPD2: 

Well, it supposedly ends up as a panic in 10.9 DP8 .. so not so universal after all.. 

 

UPD3:

Changing the opcode for this *initial* check from 77 to 7f appears to work though. Hopefully, if it's a case of this opcode being JA for target OS 10.9 (and JG for 10.8) it would be pretty much universal to patch it like this, without the need to recalculate the jump address (which will most likely change with updates):

0b0c000077 >  0c0c00007f
0c0a0000 > 0c0c0000

UPD4:

The person who was testing DP8 patch for me has mistakenly left Pike's patch in place as well, which resulted in panic. So my assumption was indeed correct and it's still possible, even in 10.9 DP8 to patch:

3d0b0c0000 > 3d0c0c0000
3d0c0a0000 > 3d0c0c0000

Share this post


Link to post
Share on other sites

So my suspicion here http://www.insanelymac.com/forum/topic/290783-intel-hd-graphics-4600-haswell-working-displayport/page-3?do=findComment&comment=1937848 that you needed the connector-type set correctly for working HDMI audio was right.  I originally found this years back when working on HDMI audio for nvidia graphics, and some people found it to be a necessary fix at the time.

Looks like it's now needed for intel too; nice work.

I agree with TimeWalker that a patch that needs to be re-done each release is not very desirable.  
I haven't seen documentation for the patch, or bothered to look at the code, but if it's just matching on the device-id have you tried overriding that via injection, instead of doing a binary patch?

Share this post


Link to post
Share on other sites

So my suspicion here http://www.insanelymac.com/forum/topic/290783-intel-hd-graphics-4600-haswell-working-displayport/page-3?do=findComment&comment=1937848 that you needed the connector-type set correctly for working HDMI was right.  I originally found this years back when working on HDMI audio for nvidia graphics, and some people found it to be a necessary fix at the time.

Looks like it's now needed for intel too; nice work.

I agree with TimeWalker that a patch that needs to be re-done each release is not very desirable.  

I haven't seen documentation for the patch, or bothered to look at the code, but if it's just matching on the device-id have you tried overriding that via injection, instead of doing a binary patch?

It appears to be reading the controller id from physical PCI root (same as with codec-ids), as substituting ID hasn't done anything. I've tried it at one point and even though IOReg pretty much was matching one from MBA6,2 there wasn't any improvement. I found that on my mobo with no DP I'm perfectly fine with 0x0A160000 platform id, which makes my HDMI appear with signal type 8 and connector type 8 with no additional edits to the framebuffer. 

 

Pike's binary patch just reroutes the 0x0c0c controller id to the offset where Apple's 0x0a0c is being router for initialization. This requires address calculation (nothing major, but still not terribly comfortable for most people out there).

Share this post


Link to post
Share on other sites

It appears to be reading the controller id from physical PCI root (same as with codec-ids), as substituting ID hasn't done anything. I've tried it at one point and even though IOReg pretty much was matching one from MBA6,2 there wasn't any improvement. I found that on my mobo with no DP I'm perfectly fine with 0x0A160000 platform id, which makes my HDMI appear with signal type 8 and connector type 8 with no additional edits to the framebuffer. 

You can dsdt edit a patch that changes the PCI ID for a device in the PCI config memory, thru the device's _INI method.  This is what I really meant, and it sounds like it would do the job.

 

Edit: Actually, wait, I think that only works for subsystem ID, with the device-id being read only.  

Edit: Actually, wait, I think that only works for subsystem ID, with the device-id being read only.  

I wonder if we could patch this via an efi driver, since the integrated graphics device-id is being determined at run-time based upon the CPU.

Share this post


Link to post
Share on other sites

Haswell DVI2HDMI and HDM!x2 audio working.

 

Three displays supported, two with HDMI audio (Intel)

  1. DP + HDMI or DP + DVI
  2. DVI (w/DVI2HDMI adapter)
  3. HDMI, HDMIx2 or HDMI + DVI
  4. Native: DP and DPx2, no Azul edit required

AppleIntelFramebufferAzul.kext/Framebuffer 0x0300220D/edit

01 05 12 00 00 04 00 00 07 01 00 00 
02 04 14 00 00 08 00 00 06 00 00 00
03 06 12 00 00 08 00 00 06 00 00 00

Share this post


Link to post
Share on other sites

Fellas, sorry if a bit off topic, don't want to create a new topic for a minor issue.

 

How i can find the value to patch and substitute in AppleIntelFramebufferAzul to show a correct Iris Pro ID instead of HD4600 (0412 to 0d22) in this capture ?

 

I can hex edit, no problem.

 

Thanks a lot

post-497804-0-46592400-1382650672_thumb.png

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.

  • Similar Content

    • By magneto5371
      Hello guys.
      I am setting up my first Hackintosh. Here are the specs:
       
      Mobo: Adlink M-342 with AMI Aptio 4 UEFI
      Intel i3 2120 SandyBridge
      4GB RAM
      500 GB SeaGate HDD
       
      So, here's the issue. The first part of the installation process works perfectly. At the end of the process, I am asked to perform a restart. I do that, it boots back to Clover. I select the HFS partition where I installed OSx, it loads for a while and then the screen goes blank.
      The only way I found so far to be able to boot to OSx is to set a FakeID in Clover's Graphics Injection menu. The only FakeID that works is this one:
      0x041680862 Which is not even a real FakeID. There is no other way, at the moment, to boot to OSx but this one, which is far from a perfect solution (the screen flickers every now and then and I cannot select resolutions different from 1024x768).
       
      I really need help on this. HD4600 is known to be fully compatible with OSx, so nobody else has ever had this issue before (apparently).
      Thanks for your help.
    • By Dmitry R
      Hi guys, 
       
      I've just faced with a strange problem of lacking QE/CI acceleration on a fresh 10.10.4 install on my Samsung NP900x3c, i7 ivy, HD4000, 1920x1080, ALC269VC, no dsdt patches, Clover 3259 bootloader. The thing is that with the same Clover config I can boot 10.9 and have full acceleration while 10.10 is booting but no QE/CI. Another thing is that 10.9 provides desktop and QE/CI only with the following ig-platform-id:  0x01660002 0x01660008 and 0x01660009, other ig-platform-id prevents 10.9 from booting, while 10.10 provides fully functional desktop with any ig-platform-id but no QE/CI at all
      I attached clover config, darwindump and ioreg of 10.10 Any help would be very much appreciated
       
      Thank you, Dmitry
      config.plist.zip
      Dmitry’s Samsung clover-only.zip
      DarwinDumper_2.9.8_Clover_X64_3259_Yos_dima.zip
    • By Austere.J
      After several weeks' work with @lisai9093, now it's time to post a guide.  
       
      GUIDE: Intel HD Graphics 5500 on OS X Yosemite 10.10.3  
       

       
      Before we get started:
       
      The basic idea to make Broadwell's integrated graphics card work does not change. If you have Intel HD Graphics 5300 or other IGPU models supported by AppleIntelBDWGraphicsFramebuffer.kext, you can try it by yourself.
       
      Brief Introduction:
       
      The basic idea to let Intel HD Graphics 5500 work is still injecting AAPL, ig-platform-id.
       
      However, Apple raised the minimum stolen memory in the AppleIntelBDWGraphicsFramebuffer binary of OS X Yosemite 10.10.3. Kernel panic will happen if the DVMT pre-allocated memory in BIOS settings is lower than 66MB. This is not a big deal for Desktop PCs users, because one can easily change the DVMT pre-allocated memory in BIOS.
       
      But this is catastrophic for laptop users, because
      (1) the default value of DVMT pre-allocated memory in most laptops BIOS is 32MB.
      (2) OEM will not unlock these advanced settings/menus for us.
      (3) We can try to modify BIOS but cannot pass the security check during flashing modified BIOS.
       
      Detailed Step-by-step guide:
       
      STEP 1: Check the current DVMT pre-allocated memory size.
      Open the Screen Resolution window, click the Advanced settings and check Dedicated Video Memory.
       

       
      After I played with changing DVMT pre-allocated memory in BIOS, the following pattern can be found.
      If Dedicated Video Memory = 0MB, then DVMT pre-allocated memory in BIOS settings is 32MB.
      If Dedicated Video Memory = 32MB, then DVMT pre-allocated memory in BIOS settings is 64MB.
      If Dedicated Video Memory = 64MB, then DVMT pre-allocated memory in BIOS settings is 96MB.
      If Dedicated Video Memory = 128MB, then DVMT pre-allocated memory in BIOS settings is 128MB.
       
      TABLES: Relationship between Dedicated Video Memory detected by OS and DVMT pre-allocated memory in BIOS settings.

      In general, if DVMT pre-allocated memory in BIOS settings is less or equal to 96MB, the StolenMemory that could be detected by OS is (DVMT - 32) MB.
      If DVMT pre-allocated memory in BIOS settings is larger or equal to 128MB, the StolenMemory that could be detected by OS is (DVMT) MB. (equal to the value of DVMT pre-allocated memory)
       
      Now let's come back to our main topic, Dedicated Video Memory >=64MB (i.e. DVMT pre-allocated memory >= 96MB) will pass the assertion/kernel panic.
      Note that OS X can not boot on some laptops if DVMT pre-allocated memory is >= 128MB.
      Therefore, if your current DVMT pre-allocated memory size <= 64MB (i.e. Dedicated Video Memory <= 32MB), you can either choose using our patch in STEP 2.1 or changing DVMT pre-allocated setting in STEP 2.2
       
      STEP 2.1: Apply the patch to pass the Stolen Memory assertion.
       
      We need to patch AppleIntelBDWGraphicsFramebuffer binary file.
      Find 39CF763C and replace it with 39CF773C.
       
      After using this patch, in theory you don't have to change your BIOS settings. You can try to inject ig-platform-id and see what happens.
      If you encounter some problems, try to modify Framebuffer data in AppleIntelBDWGraphicsFramebuffer binary.
      Detailed information on Broadwell's framebuffer can be found on this page.
       
      STEP 2.2: Using EFI Shell to change DVMT settings in BIOS.
       
      (1) Prepare a bootable USB drive with EFI Shell
      Prepare a USB stick and format it with FAT32 filesystem.
      Download this EFI shell and you can find a folder named BOOT after extracting.
      Copy this BOOT folder to your USB stick.
       
      (2) Dump/Fetch a completed BIOS file.
      You can use specific BIOS utility to save a copy of your BIOS on Desktop.
      e.g. For AMI Aptio UEFI BIOS, you can use AMI BIOS Utility.
       
      (3) Extract BIOS Settings from a BIOS file.
      Download UEFITools from https://github.com/LongSoft/UEFITool/releases
      Open your BIOS file with UEFITools.
      Find the module labeled with Setup and extract the PE32 image section in this module as a binary file.
       

       
      Now, you will have a binary file on your Desktop. In my case, I name it Setup.bin.
      Next, download the Universal IFR Extractor (Windows version only) from http://donovan6000.blogspot.ca/2014/02/universal-ifr-extractor.html or from here: Universal IFR Extractor.exe.
       
      Open the Universal IFR Extractor in Windows, open the binary you just extracted from UEFITools and click Extract to save the BIOS settings in plain text format.

       
      Now open the extracted setup IFR.txt and find the keyword "DVMT".
      And you can find the variable representing DVMT pre-allocated memory and its values.
       

       
      In this case, DVMT pre-allocated memory's variable is 0x1C3. The value of 96MB is 0x3. Record these two values.
      Next, restart your computer and boot from the USB drive with EFI Shell.
      Here, we use setup_var command to change our BIOS settings.
      syntax: setup_var address value OK, now type the command in EFI shell.
      In this case, the command is setup_var 0x1C3 0x3. (Change the value of 0x1C3 to 0x3, which means changing the DVMT to 96MB.)
      After changing the DVMT pre-allocated memory, go back to Windows and double check whether your current Dedicated Video Memory is 64MB. (96 - 32 = 64MB)
      STEP 3: Injecting AAPL, ig-platform-id
      You can use either Clover or DSDT/SSDTs to inject AAPL, ig-platform-id.
       
      If you want to use Clover, let InjectIntel = True and ig-platform-id=0x16160002.
       
      If you want to use DSDT/SSDT to inject AAPL, ig-platform-id, 0x16160002 is working fine.
      Then open your DSDT, find Device (GFX0) or Device (IGPU) or Name (_ADR, 0x00020000) and add the Device-Specific Method.
      Method (_DSM, 4, NotSerialized) { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x08) { "device-id", Buffer (0x04) { 0x16, 0x16, 0x00, 0x00 }, "AAPL,ig-platform-id", Buffer (0x04) { 0x02, 0x00, 0x16, 0x16 }, "model", Buffer (0x17) { "Intel HD Graphics 5500" }, "hda-gfx", Buffer (0x0A) { "onboard-1" } }) } Place your DSDT in /EFI/Clover/ACPI/Patched/
      Restart your computer and you will find Intel HD Graphics 5500 is working now.
       
      Some Issues you may encounter:
      (1) Garbled Screen Issue
      Enable Legacy Support in your BIOS settings.
       
      (2) Screen Freeze Issue (GPU hang and restart)
      Using FakeSMC 5.3.820 or other 5.x.xxx version will decrease the opportunity to freeze.
      (Note that please delete CPUSensors.kext from FakeSMC.kext if you get kernel panic related to CPUSensors.kext)
       
      Reference and Special Thanks:
      Thanks to Rehabman for his advice on garbled screen issue.
      Thanks to nguyenmac for his clues on freeze issue.
      Thanks to sontrg for his direction to BIOS modification.
      Thanks to Google for providing information. Thanks to the-darkvoid for his QHD+ Guide on HD4600.
×