Contribute
Register

[Guide] Intel Kaby Lake NUC7 using Clover UEFI (NUC7i7BNH, NUC7i5BNK, NUC7i3BNH, etc)

Status
Not open for further replies.
1) I had installed Sierra 10.12.6 in early Aug with the SKL spoof (Iris Graphics 540, device ID: 0x1926) and got 4K@60 on USB-C and 4K@30 on HDMI.
2) Yesterday i updated using this thread post #1 'Post Installation' for native KBL CPU and IGPU (Intel Iris Plus Graphics 640, Device ID: 5926). Everything rock solid, but now limited to 4K@30 on both USB-C and HDMI.

By swapping the ACPI/patched/SSDT-NUC7.aml between pre (spoof) and post (native) update, i can observe the change on the USB-C port. HDMI on both spoof and native is limited to 4K@30. There was the GitHub commit to 'Intel-NUC-DSDT-Patch' on Aug 19th that i suppose made the related changes.

1) Why is the USB-C using the native 'Intel Iris Plus Graphics 640' limited to 4K@30?
2) Why is the HDMI port limited to 4K@30 both with spoof and native?

Zipped Problem Report files attached of the NUC7i5BNK Sierra 10.12.6 updated for native KBL CPU and IGPU. Please advise if this belongs in one of the KL graphic threads. Thanks for all you do RehabMan!

Switching to SKL spoofing requires rolling back more than SSDT-NUC7.aml. Also required are config.plist patches required to change the connector-type for the HDMI port (from DP to HDMI). You will notice I moved all the SKL spoof specific patches to '#KextsToPatch-SKL-spoof' in the config.plist. It sounds like you didn't switch to SKL spoofing properly. Further guessing on your USB-C issue with 4k@60 with SKL spoofing would require the appropriate "Problem Reporting" files that correspond to that attempt.

Your ioreg shows a monitor connected to the 0105 port. It is marked as HDMI (connector-type=<00 08 00 00>). Is this monitor connected to HDMI? If so... then I suspect the current KBL drivers do not support 4k@60 on HDMI, at least not with ig-platform-id 0x59260000. You might try other ig-platform-id values. Keep in mind that changing the ig-platform-id may require different framebuffer patches to change the connector-type.

And please confirm how your monitor is connected in the ioreg you provided. Your questions seem to imply it is connected via USB-C. Is it? If it is actually connected to HDMI, why all the questions regarding USB-C?

You're in the right thread since framebuffer patching (matching framebuffer data to physical connector characteristics) is hardware specific.

On my NUC7i7BNH, the 0105 port is HDMI, and the 0204 port is USB-C (DP passthrough). If your system has the ports assigned differently, it requires a different framebuffer patch. Note that on my system, I'm using ig-platform-id 0x59270000 as the NUC7i7BN is HD650. Note also that I'm using iMac14,2 as per guide.

I have no 4k hardware here, so I really can't provide any confirmation of missing or present support in Apple's drivers.
 
And please confirm how your monitor is connected in the ioreg you provided. Your questions seem to imply it is connected via USB-C. Is it? If it is actually connected to HDMI, why all the questions regarding USB-C?

Thanks for shedding light on the SSDT-NUC7.aml. This is my first build, and much is based on reading your guides and trial-and-error.

Yes exactly, it was connected to the HDMI port for a final test when i generated the ioreg. Attached is the ioreg while attached via USB-C (Club 3d USB-C/HDMI adapter -> HDMI 2.0 cable -> Vizio M43-C1, port 5, 4K@60).

My objective would be to achieve 4K@60 with KBL native config at least via USB-C, and then as well on HDMI if possible (one less dongle). It sounded possible using the CoreDisplay-patcher.command from mac-pixel-clock-patch-V2. If 4K@60 is not possible with KBL at the moment, is there any disadvantage of using the SKL spoof in terms of performance, etc?

If anyone on the forum has 4K@60 using native KBL config, would be good hear. Much appreciated.
 

Attachments

  • ioreg-usb-c.ioreg.zip
    514 KB · Views: 84
Thanks for shedding light on the SSDT-NUC7.aml. This is my first build, and much is based on reading your guides and trial-and-error.

Yes exactly, it was connected to the HDMI port for a final test when i generated the ioreg. Attached is the ioreg while attached via USB-C (Club 3d USB-C/HDMI adapter -> HDMI 2.0 cable -> Vizio M43-C1, port 5, 4K@60).

My objective would be to achieve 4K@60 with KBL native config at least via USB-C, and then as well on HDMI if possible (one less dongle). It sounded possible using the CoreDisplay-patcher.command from mac-pixel-clock-patch-V2. If 4K@60 is not possible with KBL at the moment, is there any disadvantage of using the SKL spoof in terms of performance, etc?

If anyone on the forum has 4K@60 using native KBL config, would be good hear. Much appreciated.

The ioreg shows the connector-type data is correct (eg. framebuffer patch is correct).
If 4k@60 is not working, then it is not supported by the driver (at least with this ig-platform-id/SMBIOS combo).
You should try other ig-platorm-id values, other SMBIOS.
You could also try the pixel clock patch or CoreDisplayFixup.kext.

Or you could go back to SKL spoofing, and USB-C as you stated that worked previously.
I will look into making SKL spoof easier to switch to.
 
You should try other ig-platorm-id values, other SMBIOS.
You could also try the pixel clock patch or CoreDisplayFixup.kext.

Thanks for these suggestions. I'll report back with any breakthroughs. At least i am able to switch between spoof and native reliably. Certainly we'll see others come forward with interest in 4K@60 on NUC7.

Side note... if anyone is experiencing screen flicker / signal drops with 4K@60 on NUC7, check out discussions on the Intel support forum.
 
I will look into making SKL spoof easier to switch to.

Done.

If you want to switch to SKL spoofing (for graphics), it is relatively easy.
Just add SSDT-SkylakeSpoof.aml (from ./build) to ACPI/patched.
By default, SSDT-SkylakeSpoof.aml is not installed, so you get KBL native graphics drivers.

The config.plist also has the SKL patches now, so no changes needed there.
Keep in mind the patches won't apply first boot after switching because the kext is not in kernel cache. A cache rebuild and reboot fixes that.

Note: Also add a new feature (implemented in a similar way) that allows you to easily disable "hda-gfx" injection (may be useful during update scenarios). Read post #1 for more info.
 
Last edited:
Done.

If you want to switch to SKL spoofing (for graphics), it is relatively easy.

That is a very welcome enhancement, will give it a try.

I'm still confused as to how Apple 2017 hardware is KBL with many of the same IGPUs outputting 4K and above @60 (example iMac 18,1). Are they not using the native KBL either at the moment, or also some kind of spoof?

As recommended, will follow up with the folks at pixel clock patch project.
 
That is a very welcome enhancement, will give it a try.

I'm still confused as to how Apple 2017 hardware is KBL with many of the same IGPUs outputting 4K and above @60 (example iMac 18,1). Are they not using the native KBL either at the moment, or also some kind of spoof?

As recommended, will follow up with the folks at pixel clock patch project.

An iMac18,1 ioreg may offer valuable clues.
 
Just wanted to report that the 10.12.6 update allows hot-plug dual 1920x1200@60Hz for me using 18,1 SMBIOS without extra work. Thank you for all the attention to this platform. Hopefully apple will release something equivalent in the next year that I can replace the NUC with, but for now this is great.
 
Side note... if anyone is experiencing screen flicker / signal drops with 4K@60 on NUC7, check out discussions on the Intel support forum.

was just about to buy one of these when I read about the signal drop issues... does anyone here have this issue?
I read on the intel thread it affects all OS installs - win, linux and osx.
looks like theres no solution from intel yet. definitely going to pass until this is cleared up!
 
Side note... if anyone is experiencing screen flicker / signal drops with 4K@60 on NUC7, check out discussions on the Intel support forum.

Those signal drops have been a problem even since the NUC6 and it happens with non4k setups too. I think you have to be careful about the cables. They have to be perfect. And shorter is better.
 
Status
Not open for further replies.
Back
Top