- Joined
- Apr 8, 2015
- Messages
- 59
- Motherboard
- OS X 10.10.3
- CPU
- i7-4790K
- Graphics
- GTX970
- Mac
- Classic Mac
- Mobile Phone
Hardware Configurations: i5-5200U with Intel HD Graphics 5500.
According to the kernel panic log, I figured out that the panic reason is "assertion failed minStolenSize <= fStolenMemorySize".
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.
I tried to read the disassemble code and patch the AppleIntelBDWGraphicsFramebuffer binary on Wednesday to pass the assertion and I succeeded, but IN A WRONG WAY, which led to that nothing shows up on the screen but a pointer. (It seems that I accidentally change the StolenFBMem to 0. (not sure))
According to the latest IOReg and verbose boot logs, Intel framebuffer drivers are loaded, the graphics card was recognized properly, the internal screen was detected correctly, the screen resolution seems right.
(We used FakeID, hence the model in ioreg above shows Intel Iris Graphics 6100)
So currently we get stuck here. I am not familiar with disassemble code and reverse engineering.
It will be great if someone can figure out which part of code is corresponding to the FBMemory assertion and patch it.
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.
For the framebuffer data, you can check those in my blog.
http://www.firewolf.science/2015/04...from-appleintelbdwgraphicsframebuffer-binary/
Latest IOReg from this laptop: View attachment withBDWGraphicsPeter’s MacBook Pro(1).ioreg
Any suggestion will be great.
Thanks in advance
According to the kernel panic log, I figured out that the panic reason is "assertion failed minStolenSize <= fStolenMemorySize".
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.
I tried to read the disassemble code and patch the AppleIntelBDWGraphicsFramebuffer binary on Wednesday to pass the assertion and I succeeded, but IN A WRONG WAY, which led to that nothing shows up on the screen but a pointer. (It seems that I accidentally change the StolenFBMem to 0. (not sure))
According to the latest IOReg and verbose boot logs, Intel framebuffer drivers are loaded, the graphics card was recognized properly, the internal screen was detected correctly, the screen resolution seems right.
(We used FakeID, hence the model in ioreg above shows Intel Iris Graphics 6100)
So currently we get stuck here. I am not familiar with disassemble code and reverse engineering.
It will be great if someone can figure out which part of code is corresponding to the FBMemory assertion and patch it.
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.
For the framebuffer data, you can check those in my blog.
http://www.firewolf.science/2015/04...from-appleintelbdwgraphicsframebuffer-binary/
Latest IOReg from this laptop: View attachment withBDWGraphicsPeter’s MacBook Pro(1).ioreg
Any suggestion will be great.
Thanks in advance