Surface Book 2: UHD 620 Graphic Acceleration/Framebuffer Issue

[Hack.intosh]

CPU - Intel i7-8650U

GPU - Intel UHD 620 / Disabled dGPU in bios

RAM - SK Hynix 16GB 1867MHz

Network - 88W8897 Avastar 802.11ac Wireless

Audio - ALC298

Input - HID Keyboard/Mouse

SMBIOS - MacBookPro15,2

OS - Monterey 12.5

 

When the device-id is '16900000' dummy number. Graphics showing as 'Intel UHD 620 26 MB'

 

Cannot boot into macOS when using '16590000' from Dortania Guide.

 

I have also tried AAPL,ig-platform-ids 00001B59 (current), 00001659, 0000C087 without success.

 

Tackling the graphics issue first but there are other issues such as wifi, bluetooth, sound, dual battery which I'll create another post for unless I manage to figure it out first. Any help would be much appreciated. Thanks

 

 

SB15.IOREG EFI.zip

[Baio77]

For CPU Kabylake -R test this patch : https://drive.google.com/drive/folders/1RuTtuQ2dNnu01zKXcD8jWkfde1LjmLN3?usp=sharing.
Connector patch is not included.

If you still have problems delete device-id or change it to C087
 

[Hack.intosh]

without - doesn't boot in macOS but keeps dragging with applekeystore

with - doesn't boot - goes blank and restarts.

 

no luck.

[Hervé]

@Hack.intosh The OC config and IOReg you attached in post #1 show that you were:

1. injecting KBL framebuffer layout 0x591B0000
2. faking iGPU device 0x9016
3. using SMBIOS MBP15,2
4. using boot args -igfxlspcon -igfxmlr -igfxdvmt -disablegfxfirmware

I believe only #3 to be correct, #1 and #2 being totally wrong with #4 most likely unnecessary. If you look at my old Latitude 7490 guide (i7-8650U CPU with UHD 620 graphics) or other Latitude 7x90/5x90 guides, you would see that the expected properties to inject are:

• KBL framebuffer layout 0x59160000 or 0x87C00000
• iGPU device id 0x5916 (not sure about 0x87C0)

 

As such, your injected properties should look like this:

AAPL,ig-platform-id         00001659    DATA
device-id                   16590000    DATA
framebuffer-patch-enable    1           NUMBER
framebuffer-fbmem           00009000    DATA
framebuffer-stolenmem       00003001    DATA

or

AAPL,ig-platform-id         0000C087    DATA
device-id                   16590000    DATA
framebuffer-patch-enable    1           NUMBER
framebuffer-fbmem           00009000    DATA
framebuffer-stolenmem       00003001    DATA

or possibly

AAPL,ig-platform-id         0000C087    DATA
device-id                   C0870000    DATA
framebuffer-patch-enable    1           NUMBER
framebuffer-fbmem           00009000    DATA
framebuffer-stolenmem       00003001    DATA

but framebuffer layout 0x87C00000 and device id 0x87C0 usually are for Amber Lake platforms.

 

Did you try such settings combination without your -igfx---- boot args at all?

[Hack.intosh]

I have tried all three with -igfxdvmt (can't set dvmt in bios) and without igfx---- args. All three do not boot, with results in a restart loop. 

 

initially faking iGPU device 0x9016 was a typo when editing device-id but that resulted in the Surface Book actually booting in macOS (to my surprise). I'm under the impression, the issue lays in either the device-id, frame buffers or args? I've tried many combinations prior to posting but with device-id removed - it will boot without graphics acceleration.

[Hervé]

It's perfectly normal that you booted without acceleration when injecting an incorrect iGPU id such as 0x9016. You'd have experienced the same result with id 0x1234 or 0x5678. When such parameters are invalid (same applies to framebuffer layout), macOS boots in VESA mode, i.e. a very basic graphics mode without graphics driver that you could compare to Windows safe mode.

 

Try booting with only -disablegfxfirmware boot arg alongside the revised properties injection.

 

You stated that the dGPU was disabled in BIOS so I assume this is an option for this Surface Book 2 which is presumably fitted with nVidia Optimus technology. Usually, disabling Optimus limits the laptop to its dGPU only, voiding dual GPU operation. If you want to run on the UHD 620 for Hackintosh purposes, you probably need to re-enable Optimus but disable the dGPU through patched SSDT. To prove this, do try to re-enable dGPU in BIOS but boot with boot arg -wegnoegpu.

[Hack.intosh]

Thanks for pointing out the fake gpu, understandable. I tried all three but all with the same outcome. It will boot to the apple logo 1/3 of the way, the logo goes bright for a second before going blank to a blank backlit display shortly restarting - repeat. IOReg attached. Seems to be 1x display detected 

SB15 02.ioreg EFI.zip

[Hervé]

This IOReg shows you're faking iGPU id 0x5917 so it's never going to work... If you have another macOS system, you could try to access this Surface Book 2 remotely but you'd have to setup screen sharing to begin with. You can do that when you boot with one of those invalid ids. You may need to inject your screen EDID if screen goes black when graphics initialize.

[Hack.intosh]

I’ve set up screen sharing using an invalid fake gpu as suggested, tested and working with the fake gpu then had device-id removed altogether afterwards. I do have another MacBook to remote into the surface book but the it won’t connect as you would’ve guess. Not familiar with injecting my screen’s EDID. I’ve googled but came up with unrelated results. Do you have a link of sorts? Also, is this method going to resolved this issue?

[Hack.intosh]

edit - found a guide and managed to do as you requested. Learnt something new! Anyways, here's the new IOREG attached using my EDID.

SB15 03.ioreg