FireWolf Pl.

Update 4 @ 2015.04.18 21:30 PM PDT

A full detailed guide on how to make Intel HD Graphics 5500 work is now available.

Please check https://www.firewolf.science/2015/04/guide-intel-hd-graphics-5500-on-os-x-yosemite-10-10-3/

Update 3 @ 2015.04.14 19:20 AM PDT

We somehow fixed the garbled screen issue on Monday simply by enabling Legacy Support in BIOS.

However, now comes a new issue that GPU will randomly stops working. (Kind of like Nvidia Fermi Freeze, but different.)

I have a new hypothesis and will test it later.

Update 2 @ 2015.04.12 01:50 AM PDT

Excited!!! My friend @lisai9093 and I succeeded!!!

We figured out a new and proper way/patch to pass the assertion. And no more kernel panic, no more “black screen”.

But garbled and not built-in internal screen so far. (maybe due to the DVMT in BIOS settings is 32MB; the current conclusion is that we need figure out how to unlock AMI Aptio V UEFI BIOS to access all hidden menus. So we can change DVMT pre-allocated memory size (to 64MB or more) and in theory fix the garbled screen.)

Anyway, Intel HD Graphics 5500 was recognized by OS X, and the screen resolution is correct as usual. Intel Broadwell’s framebuffer drivers were loaded properly with full QE/CI.

I also started new threads (to seek for help) on both insanelymac and tonymacx86 forum two days ago. But I haven’t updated the information in those posts. I will update those threads as soon as I have time.

http://www.insanelymac.com/forum/topic/305597-intel-hd-graphics-5500-need-some-help/

http://www.tonymacx86.com/yosemite-laptop-support/161591-intel-hd-graphics-5500-need-some-help.html

Update @ 2015.04.10

First of all, thanks for following this post.

Well, to be honest, I need some help now, cuz I am not familiar with reverse engineering. I also plan to start a topic on insanelymac or/and tonymacx86 forum (seek for help.).

According to the kernel panic log, it is “assertion failed minStolenSize <= fStolenMemorySize” that caused kernel panic.

So basically if we can pass this assertion, kernel panic will not happen and in theory framebuffer drivers will be loaded and our graphics cards will be happy. And actually it do work in this way.

On Wednesday midnight, I read the disassemble code of AppleIntelBDWGraphicsFramebuffer binary and tried to patch it to pass the assertion.

And to my surprise, it worked. lisai9093 used my patched drivers and successfully pass the assertion. (i.e. no more kernel panic)

However, the screen just shows nothing but a mouse pointer. According to lisai9093, the movement of mouse is very smooth. The screen resolution is correct and there is no distortion.

We tried to change ig-platform-id, checked the pixel clock frequency, even changed the port, but still “black screen”.

On Thursday, I started to doubt whether I patched the binary in a right way, and the answer is definitely “NO, I WAS WRONG.”

Indeed, my patch passed the assertion, but in a wrong way. To be more specific, it seems that I accidentally changed the stolenMemory constant to 0. (not sure) (I should modify the function part to let the assertion always return true but not change the constant.)

So that’s why lisai9093’s screen showed nothing, because there is no stolen memory for the integrated graphics card to show something.

But according to his latest ioreg, we can make sure that the graphics card really works, as the framebuffer driver was loaded properly; screen resolution is correct; the internal screen was recognized correctly, the graphics card was recognized successfully (We used FakeID, hence the model in ioreg below shows Intel Iris Graphics 6100) And the verbose boot logs also prove this. [IGPU] xxxxxx showing below. (Graphics Accelerator is running and working fine.)

Again, I am not familiar with disassemble and reverse engineering. (This is way beyond my current knowledge.)

So we need someone who is familiar with disassemble code and figure out which part of code is corresponding to the FBMemory assertion.

Here is a quicklook of partial disassemble code of AppleIntelBDWGraphicsFramebuffer binary.

And I guess offset 0x01a02c 0x01a02e OR 0x01a081 0x01a087 may be related to the FBMemory assertion.

Last but not least, I added a new post about the framebuffer data from AppleIntelBDWGraphicsFramebuffer binary on my blog.

If you are interested in that, please have a look. 🙂

https://www.firewolf.science/2015/04/framebuffer-data-extracted-from-appleintelbdwgraphicsframebuffer-binary/

---

 

Recently, I worked with @lisai9093 on his new Dell Inspiron 7548 laptop with Intel’s Broadwell processor. The detailed hardware configurations are as follows.

Processor: Intel Core i5-5200U @ 2.20GHz TBF: 2.70GHz

RAM: 8GB 1600MHz

Graphics Card: Intel HD Graphics 5500 (0x80861616)

Sound Card: ALC3234 (= ALC255) (AppleHDA.kext)

Wireless: BCM94352Z (NGFF) (DSDT+FakePCIID.kext)

Screen Resolution: 1920×1080

Current OS X Version: 10.10.3 Final Version (14D131)

Current Bootloader: Clover rev3193

So far, the sound card, wireless card and battery percentage are working fine. Broadwell’s i5-5200U cannot be recognized properly (Showing Unknown in About This Mac) before injecting CPU Type by Clover. ACPI_SMC_PlatformPlugin.kext will be loaded and CPU power management cannot work properly before creating a custom CpuPm SSDT. Intel’s new integrated graphics card is problematic. Kernel panic will happen once AppleIntelBDWGraphicsFramebuffer.kext is loaded. (i.e. ig-platform-id is injected.)

For the installation part, we first used 10.10.2 (14C109) installer with enabling Haswell-E patch (KernelHaswellE) in Clover to skip the kernel check, then upgraded to 10.10.3 Beta 5, 6, 7. By injecting CPUType = 0x0606 in Clover, i5-5200U can be recognized as “Intel Core i5” with correct frequency in “About This Mac”.

After reading Pike’s ssdtPRGen.sh (v15.6), I generated a custom CpuPm SSDT by injecting new Board-IDs and information of Broadwell CPUs in his code. Now X86PlatformPlugin.kext and X86PlatformShim.kext can be loaded properly and “IOPPF: XCPM Mode” apprears in the console. However, “XCPM: P-state tables mismatch” also appears in the console due to the inappropriate SMBios(?)(not sure).

 

Previous: (Before placing custom SSDT.aml)

After:

For the graphics card, just panic if ig-platform-id is injected. We still keep trying.

FYI, here are some information related to Intel’s new integrated graphics cards.

Intel HD Graphics 5300: 0x8086161E

Intel HD Graphics 5500: 0x80861616

Intel HD Graphics 6000: 0x80861626 (MacBook Air ig-platform-id = 0x16260006)

Intel Iris Graphics 6100: 0x8086162b (MacBook Pro ig-platform-id = 0x162b0002)

Intel Iris Pro Graphics 6200: 0x80861622???

Well, this is just a quick note. As Apple released two betas this week, I guess b7 will be the final one.

Special thanks to Pike R Alpha for his amazing ssdtPRGen script.

Installation Notes: Hackintosh on a new laptop with Intel Broadwell processor [Intel HD Graphics 5500 working but not perfect]