[Guide] Intel Skylake NUC6 (and Skull Canyon) using Clover UEFI (NUC6i5SYK, NUC6i7KYK, etc)

[den_breacker]

Read post #1, "Problem Reporting". Your problem may be monitor specific.

Ok, I've uploaded the files as explained in "problem reporting".
Can you take a look ?
Thanks !

 

[RehabMan]

Ok, I've uploaded the files as explained in "problem reporting".
Can you take a look ?
Thanks !

This ioreg only shows one monitor connected. Which port is it using? What type is the other port?

 

[totoro92]

Thanks for your guide and resources RehabMan, the i5 Skylake NUC (NUC6I5SYK) mostly works great with it. One thing that did, however, not work was display sleep, as I was often unable to wake up my monitor (DELL P2415Q, which runs at 4k@60Hz over DP1.2) after sleep. This problem occurred with both the iMac14,2 and iMac17,1 SMBIOS.

Sometimes I was able to wake up the display using the NUC power button, in which case the "AAPL,DisplayPipe" property would be set to ff ff 00 00 (in IORegistryExplorer) instead of the default 00 00 00 00 which I get after a fresh boot. When I could get the display to awake from sleep using this method, graphics glitches would occur as well. (Note that I could not find a replicable method to wake up the display).

Digging through the AppleIntelSKLGraphicsFramebuffer assembly, I found two routines which I could change to resolve this problem (AppleIntelFramebufferController::IsHPDLow and AppleIntelFramebufferController::SetDPPowerState). In both cases, I increased the amount of attempts they made to read/write hardware registers. Now, my monitor properly awakes from sleep, without glitches and with the proper "AAPL,DisplayPipe" value, both when the NUC itself is still on, and when the NUC awakes from sleep.

The Clover patches are included below:

<dict>
    <key>Comment</key>
    <string>Prolong HPD waiting period</string>
    <key>Name</key>
    <string>AppleIntelSKLGraphicsFramebuffer</string>
    <key>Find</key>
    <data>g/sURIjg</data>
    <key>Replace</key>
    <data>g/tkRIjg</data>
</dict>
<dict>
    <key>Comment</key>
    <string>Increase DP power state attempts</string>
    <key>Name</key>
    <string>AppleIntelSKLGraphicsFramebuffer</string>
    <key>Find</key>
    <data>QYP9Aw==</data>
    <key>Replace</key>
    <data>QYP9Mg==</data>
</dict>

I used the iMac17,1 SMBIOS with the 0x19260004 framebuffer.
This is the framebuffer patch I use:

<dict>
    <key>Comment</key>
    <string>Framebuffer configuration</string>
    <key>Name</key>
    <string>AppleIntelSKLGraphicsFramebuffer</string>
    <key>Find</key>
    <data>AQUJAAAEAADHAQAAAgQKAAAEAADHAQAA</data>
    <key>Replace</key>
    <data>AQUJAAAIAADHAQAAAgYKAAAEAADHAQAA</data>
</dict>

If people are experiencing similar sleep-related issues, let me know if this fixes anything for you.

 

[Andy1]

If people are experiencing similar sleep-related issues, let me know if this fixes anything for you.

You prompted me into looking at this again, so thanks for that.

These 3 patches ALL go in the KextsToPatch section of Clovers config.plist? If so thats where I tried them and it doesn't seem to have altered the behaviour I'm seeing. Note I'm using iMac14,2 and don't have the 0x19260004 frame buffer setting which may be relevant?

Also my sleep issues may be different to yours. Normally sleep is ok, however if I tick "Prevent Computer from sleeping automatically when display is off" it will never wake the monitor correctly and I need to force a reboot. Also if I power the display off/on it just recovers to a black screen. I'm using the DisplayPort. Same behaviour over HDMI.

 

[totoro92]

These 3 patches ALL go in the KextsToPatch section of Clovers config.plist?

Yes, these patches are intended to be used in the KextsToPatch section.

Note I'm using iMac14,2 and don't have the 0x19260004 frame buffer setting which may be relevant?

My mistake, I wrote framebuffer instead of platform identifier. The default in RehabMan's GitHub repository is 0x19260000, are you using this platform identifier? If so, you could try one of the values listed here as representing the Iris 540.

I've chosen to use 0x19260004 because, before I managed to get sleep/wake working, the 0x19260002 platform identifier was consistently giving me errors when I tried to wake up the display, whereas 0x19260004 was not.

TCON: Aux not ready at HW
TCON: BAN_DPCD_0x0_EXPECTED failed, got DEADBEEF

I have not yet tested these patches with the iMac14,2 SMBIOS, only with iMac17,1.

Also my sleep issues may be different to yours. Normally sleep is ok, however if I tick "Prevent Computer from sleeping automatically when display is off" it will never wake the monitor correctly and I need to force a reboot. Also if I power the display off/on it just recovers to a black screen. I'm using the DisplayPort. Same behaviour over HDMI.

The sleep issues do appear to be different. I did test a 1080p monitor connected over HDMI (as opposed to my 4K DP monitor), which went to sleep and awoke flawlessly (both with iMac14,2 and iMac17,1), without any patches.

The HDMI monitor, however could actually be turned off entirely and be powered back on. The DP monitor cannot, it can only be put to sleep (for example through Ctrl+Shift+Eject/Power) and woken up (this did not work for me without the patches). If I turn the DP monitor off and on again, it will recover to a black screen.

 

[Andy1]

I had looked for occurrences of ig-platform-id but couldn't find any. I guess this exposes my lack of understanding of how this installation technique really works.
Looking for 0x19260002, I find it in the comment

<string>HDMI-audio, port 0105, 0x19260000</string>

But this seems to be related to HDMI rather than DP? I would be interested to know how you changed this value.

I only have one 4k monitor, but have tried both HDMI and DP connectivity. Note prior to this I used and old HP monitor over DVI - HDMI and it worked correctly.

If I turn the DP monitor off and on again, it will recover to a black screen.

OK good to know.

however if I tick "Prevent Computer from sleeping automatically when display is off" it will never wake the monitor correctly

Have you any success with this setting?

I will experiment some more tonight. I'm a bit cautions about making changes, since everything else is rock solid (thanks Rehabman) and as I've intimated I don't really understand enough at the moment.

Thanks

 

[totoro92]

I had looked for occurrences of ig-platform-id but couldn't find any

In the RehabMan GitHub repository, the ig-platform-id is defined both in the config_nuc6.plist (Graphics/ig-platform-id) and in IGPU.dsl. I have copied the relevant section of IGPU.dsl here:

// Skylake/HD540
0x1926, 0, Package()
{
    "model", Buffer() { "Intel Iris Graphics 540" },
    "AAPL,ig-platform-id", Buffer() { 0x00, 0x00, 0x26, 0x19 },
    "hda-gfx", Buffer() { "onboard-1" },
},

To change the platform identifier to 0x19260004, you would change the first zero to 0x04 (the number is in little endian order). Like so:

"AAPL,ig-platform-id", Buffer() { 0x04, 0x00, 0x26, 0x19 },

Then recompile the DSL into an ASL and copy it to your EFI partition, overwriting the old one.

<string>HDMI-audio, port 0105, 0x19260000</string>

But this seems to be related to HDMI rather than DP? I would be interested to know how you changed this value.

This patch changes the type of the first port into HDMI (the default is DP) for the 0x19260000 platform identifier. The "framebuffer configuration" patch I posted above includes this change (and thus replaces the HDMI-audio patch), but for the 0x19260004 platform identifier.

Specifically, the default configuration for 0x19260004 looks like this (with each line representing one port):

0x01, 0x05, 0x09, 0x00, 0x00, 0x04, 0x00, 0x00, 0xc7, 0x01, 0x00, 0x00,
0x02, 0x04, 0x0a, 0x00, 0x00, 0x04, 0x00, 0x00, 0xc7, 0x01, 0x00, 0x00

I changed it to:

0x01, 0x05, 0x09, 0x00, 0x00, 0x08, 0x00, 0x00, 0xc7, 0x01, 0x00, 0x00,
0x02, 0x06, 0x0a, 0x00, 0x00, 0x04, 0x00, 0x00, 0xc7, 0x01, 0x00, 0x00

The sixth byte on each line represents the port type. The "framebuffer configuration" patch posted above is simply the Base64 encoded version of these changes. Note that it does not work for the 0x19260002 platform identifier, for which you would need another patch (because the 0xc7 bytes are 0x87 instead).

Use these Base64 strings if you use 0x19260002:

Find: AQUJAAAEAACHAQAAAgQKAAAEAACHAQAA
Replace: AQUJAAAIAACHAQAAAgYKAAAEAACHAQAA

The HDMI-audio patch itself should not affect the DP port (which is the second port).

Note prior to this I used and old HP monitor over DVI - HDMI and it worked correctly.

It is interesting a DVI-to-HDMI connector should make it work. The only reason I can come up with is that DVI does not support audio. Perhaps then, you could try to disable audio over HDMI? You could try to comment out the "hda-gfx" line in IGPU.dsl and also disable audio over HDMI in the BIOS.

Have you any success with this setting?

The "prevent computer from sleeping automatically when the display is off" setting does not alter display sleeping behaviour for me. It does cause the NUC to sleep after a while, when the display is in sleep mode.

 

[Andy1]

>totoro92

Many thanks for your detailed post. I'm still experimenting - changing these settings does appear to alter the behaviour of sleep, but as yet I haven't found one that fixes my problem completely. I'll let you know my findings once I've worked them out.

 

[andyph666]

Had everything working before until I did a git pull and then started over with the guide and did a make clean. Deleted all instances of nvmegeneric in clover efi and also in /l/e. I have the 10.11.6 hacknvme in the clover efi kexts 10.11 folder and also in other, but now I cannot boot at all. Can't even get into the usb installer or clover on the usb. Any ideas?

 

[Andy1]

A couple of observations:

Just checked the default config.plist and it sets ig-platform-id to 19160000, not 19260000 as would seem to be appropriate for Intel Iris 540?

I believe I have made a step forward in understanding my problem.

If I boot up with System Preferences/Energy Saver - "Prevent comp from sleeping when display is off" set on, then the first sleep will not recover the monitor, screen remains black and disk activity is full on. However if I boot without this setting, allow the computer to sleep fully (orange LED, CPU sleep) wake it up (no issues) and then set "Prevent comp from sleeping when display is off" it will subsequently sleep/wake correctly (from blue LED, CPU active). It seems the first sleep is setting something that allows correct behaviour thereafter. Any ideas how to troubleshoot? ioreg before and after sleep any use?