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

[RehabMan]

I disabled both of these patches in config.plist and now hot-plugging the USB-C monitor worked.

Thank you.

Are either of the monitors 4k? Both?

Please attach full "Problem Reporting" files for this scenario.
Attach ioreg in three different configurations:
- booting with HDMI monitor, no USB-C monitor ever connected
- booting with USB-C monitor, no HDMI monitor ever connected
- both monitors connected

 

[star-affinity]

Wow, I don't get it. Now I again did ”boot without caches” from Clover and once in I used Terminal.app to clear kext caches and after that I can't boot normally.

Edit:
And doing touch /System/Library/Extensions fixed it. Phew…

Edit 2:
Too bad my Bluetooth dongle doesn't seem to work anymore in High Sierra. Or at least it stopped working now after the update from Sierra. Was working fine before. Can't seem to find my devices anymore even if Bluetooth is enabled. Maybe there's a fix…

Edit 3:
I keep getting this in system.log:

com.apple.xpc.launchd[1] (com.apple.displaypolicyd): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
com.apple.xpc.launchd[1] (com.apple.displaypolicyd[1417]): Service exited with abnormal code: 1
com.apple.xpc.launchd[1] (com.apple.displaypolicyd): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
com.apple.xpc.launchd[1] (com.apple.displaypolicyd[1420]): Service exited with abnormal code: 1
com.apple.xpc.launchd[1] (com.apple.displaypolicyd): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
com.apple.xpc.launchd[1] (com.apple.displaypolicyd[1424]): Service exited with abnormal code: 1
com.apple.xpc.launchd[1] (com.apple.displaypolicyd): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.

Any ideas on that?
Sorry, I will attach problem report files before asking more…

Edit 4:
Now I just unloaded the System Daemon com.apple.displaypolicyd (using the app LaunchControl) and the excessive logging in system.log stopped. How bad is it to stop that daemon? Anyone knows what it does?

 

[RehabMan]

Wow, I don't get it. Now I again did ”boot without caches” from Clover and once in I used Terminal.app to clear kext caches and after that I can't boot normally.

Edit:
And doing touch /System/Library/Extensions fixed it. Phew…

Edit 2:
Too bad my Bluetooth dongle doesn't seem to work anymore in High Sierra. Or at least it stopped working now after the update from Sierra. Was working fine before. Can't seem to find my devices anymore even if Bluetooth is enabled. Maybe there's a fix…

Edit 3:
I keep getting this in system.log:

com.apple.xpc.launchd[1] (com.apple.displaypolicyd): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
com.apple.xpc.launchd[1] (com.apple.displaypolicyd[1417]): Service exited with abnormal code: 1
com.apple.xpc.launchd[1] (com.apple.displaypolicyd): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
com.apple.xpc.launchd[1] (com.apple.displaypolicyd[1420]): Service exited with abnormal code: 1
com.apple.xpc.launchd[1] (com.apple.displaypolicyd): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
com.apple.xpc.launchd[1] (com.apple.displaypolicyd[1424]): Service exited with abnormal code: 1
com.apple.xpc.launchd[1] (com.apple.displaypolicyd): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.

Any ideas on that?
Sorry, I will attach problem report files before asking more…

Edit 4:
Now I just unloaded the System Daemon com.apple.displaypolicyd (using the app LaunchControl) and the excessive logging in system.log stopped. How bad is it to stop that daemon? Anyone knows what it does?

No "Problem Reporting" files attached.
Read FAQ, "Problem Reporting" again. Carefully. Attach all requested files/output.
https://www.tonymacx86.com/threads/faq-read-first-laptop-frequent-questions.164990/
Use the tool mentioned in the FAQ, that way it is less likely you'll omit something.

 

[jukes]

Edit 2:
Too bad my Bluetooth dongle doesn't seem to work anymore in High Sierra. Or at least it stopped working now after the update from Sierra. Was working fine before. Can't seem to find my devices anymore even if Bluetooth is enabled. Maybe there's a fix…

This happened to me as well. Try disabling the onboard Intel bluetooth in the system's BIOS, that should let your dongle work again. I have no idea why this wasn't necessary in Sierra.

 

[RehabMan]

This happened to me as well. Try disabling the onboard Intel bluetooth in the system's BIOS, that should let your dongle work again. I have no idea why this wasn't necessary in Sierra.

Multiple bluetooth controllers always problematic, always should be avoided.
One of those macOS/OS X "common knowledge" sort of things...

 

[RehabMan]

Are either of the monitors 4k? Both?

Please attach full "Problem Reporting" files for this scenario.
Attach ioreg in three different configurations:
- booting with HDMI monitor, no USB-C monitor ever connected
- booting with USB-C monitor, no HDMI monitor ever connected
- both monitors connected

Also, here is a few alternative patches. For these tests, disable the two patches: "0x59260002 0x59270004 2xDP, #1 of 2", "0x59260002 0x59270004 2xDP, #2 of 2"

alt#1 (this is the same as repo patches, but 0105 and 0204 reversed):
Comment: 0x59260002 0x59270004 2xDP, #1 of 2
Find: <01030303 00009003>
Replace: <01030202 00009003>

Comment: 0x59260002 0x59270004 2xDP, #2 of 2 (alt#1)
Find: <00000800 02000000 98040000 01050900 00040000 c7030000 02040a00 00040000 c7030000>
Replace: <02040a00 00040000 c7030000 01050900 00040000 c7030000 ff000000 01000000 20000000>

alt#2 (this keeps the connector counts same, but still moves 0105/0204 to @0, @1):
Comment: 0x59260002 0x59270004 2xDP, #1 of 1 (alt#2)
Find: <00000800 02000000 98040000 01050900 00040000 c7030000 02040a00 00040000 c7030000>
Replace: <01050900 00040000 c7030000 02040a00 00040000 c7030000 ff000000 01000000 20000000>

alt#3 (same as above, but reversed 0105/0204)
Comment: 0x59260002 0x59270004 2xDP, #1 of 1 (alt#3)
Find: <00000800 02000000 98040000 01050900 00040000 c7030000 02040a00 00040000 c7030000>
Replace: <02040a00 00040000 c7030000 01050900 00040000 c7030000 ff000000 01000000 20000000>

alt#4 (keeping 0105 in @1 @2, but nullify LVDS @0)
Comment: 0x59260002 0x59270004 2xDP, #1 of 1 (alt#4)
Find: <00000800 02000000 98040000 01050900 00040000 c7030000 02040a00 00040000 c7030000>
Replace: <ff000000 01000000 20000000 02040a00 00040000 c7030000 01050900 00040000 c7030000>

 

[jukes]

Are either of the monitors 4k? Both?

No.

Please attach full "Problem Reporting" files for this scenario.
Attach ioreg in three different configurations:
- booting with HDMI monitor, no USB-C monitor ever connected
- booting with USB-C monitor, no HDMI monitor ever connected
- both monitors connected

I was trying to collect this data and have run into a problem.

Both HDMI and HDMI+USB-C hotplug worked fine.

USB-C was completely unstable. OS X seems to think that there are two monitors connected, even though there are not. The USB-C monitor would auto power off every 30-ish seconds, and I would need to power-cycle it to get the desktop to appear. Hotplugging HDMI did nothing.

Now, when I try and boot I always hang on "Waiting for DSMOS..."

Booting without caches does not help. Is there a thread dedicated to fixing this problem? (I made no changes to anything, was just switching monitors and running the Problem Reporting commands. Could "sudo touch /System/Library/Extensions && sudo kextcache -u /" have caused a problem when run from the unstable USB-C configuration?)

Edit 1: extracted the Problem Reporting files for the three configurations using the recovery terminal, and attached here.
Edit 2: removed themes from USB-C Clover.
Edit 3: grammar.

 

[RehabMan]

Edit 1: extracted the Problem Reporting files for the three configurations using the recovery terminal, and attached here.

Recovery not useful.
Resolve your booting issue first.

But these "Problem Reporting" files don't look to be collected from recovery anyway (kextcache would not show those kexts, as they are not present in the recovery volume).
Perhaps you should clarify.

 

[jukes]

Recovery not useful.
Resolve your booting issue first.

But these "Problem Reporting" files don't look to be collected from recovery anyway (kextcache would not show those kexts, as they are not present in the recovery volume).
Perhaps you should clarify.

These are the results collected as you asked (HDMI-only, HDMI with hotplugged USB-C, USB-C-only (unstable). USB-C with hotplugged HDMI doesn't seem to be different than USB-C only).

I can no longer boot after the USB-C experiment, so I had to go and copy them off of the drive using the recovery terminal.

Right now I'm trying to understand why performing the experiment has triggered the "Waiting for DSMOS..." hang. The only thing I can imagine is that something bad happened when I ran "sudo kextcache -u /" from the unstable USB-C configuration.

Edit: tried to clarify.

 

[RehabMan]

These are the results collected as you asked (HDMI-only, HDMI with hotplugged USB-C, USB-C-only (unstable). USB-C with hotplugged HDMI doesn't seem to be different than USB-C only).

But you wrote "Edit 1: extracted the Problem Reporting files for the three configurations using the recovery terminal, and attached here."

What do you mean by "using the recovery terminal".

I can no longer boot after the USB-C experiment,

What experiment?

so I had to go and copy them off of the drive using the recovery terminal.

What do you mean by "them"?

Right now I'm trying to understand why performing the experiment has triggered the "Waiting for DSMOS..." hang. The only thing I can imagine is that something bad happened when I ran "sudo kextcache -u /" from the unstable USB-C configuration.

What was unstable?
"Waiting for DSMOS" without a corresponding "DSMOS has arrived" implies that FakeSMC is missing or not loading.

Note that my request was for "Problem Reporting" files with three different ioreg captures.
No need to run full problem reporting procedures for each ioreg... (kextcache, EFI/Clover, other data would remain the same).

The ioreg you attached for the USB-C only case looks to have had HDMI connected as well. ?! Also, note that in that case it seems to have changed the connector-type to <00 04 00 00> for the HDMI, where as the one for HDMI_USB-C did not.