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

[sdelaroq]

That setup looks fine. Except I'm not running the latest Clover. I've been watching the Clover threads for quite a while, waiting for things to calm down. Lot's of churn, lack of code review before checking, and broken code there lately, so still sticking with v3967.

Thanks for watching! There's no v3967 available from sourceforge, could you please provide me with a 3967 installer?

 

[RehabMan]

Thanks for watching! There's no v3967 available from sourceforge, could you please provide me with a 3967 installer?

Try one of the versions close to that version that is available...
I don't want to get into distributing Clover itself.

 

[sdelaroq]

Try one of the versions close to that version that is available...
I don't want to get into distributing Clover itself.

I fixed it!
The reason why it crashed is probably because I did not exactly followed your instructions but I don't know exactly how I did this mistake.
What I did to fix it: I ran 'make install_sc' and it output errors about permissions forbidding removing files in the 'nuc.git/AppleHDA_NUCHDA_Resources' folder. I deleted the files from the Finder (admin password was required) and re-ran 'make install_sc'. Since I rebooted, macOS is stable.
Thanks for your time, thanks for this guide, and sorry for my stupid mistake .
Seb

Edit: Spoke too fast... instability is still there but at a slightly lower level

 

[kernelpanicd]

I was troubleshooting something else and removed the Brcm and FakePCIID_Broadcom kexts and the USB BT dongle still works.

$ ls /Library/Extensions/
ACS6x.kext            FakeSMC_ACPISensors.kext
ATTOCelerityFC8.kext        FakeSMC_CPUSensors.kext
ATTOExpressSASHBA2.kext        FakeSMC_GPUSensors.kext
ATTOExpressSASRAID2.kext    FakeSMC_LPCSensors.kext
ArcMSR.kext            HighPointIOP.kext
CalDigitHDProDrv.kext        HighPointRR.kext
CodecCommander.kext        LittleSnitch.kext
EnergyDriver.kext        PromiseSTEX.kext
FakePCIID.kext            SoftRAID.kext
FakeSMC.kext            USBInjectAll.kext

$ ls /Volumes/EFI/EFI/CLOVER/kexts/Other/
FakeSMC.kext            HackrNVMeFamily-10_12_3.kext    IntelMausiEthernet220.kext    USBInjectAll.kext

Even updated kextcache twice and rebooted, still works. I guess its just natively supported?

 

[RehabMan]

I was troubleshooting something else and removed the Brcm and FakePCIID_Broadcom kexts and the USB BT dongle still works.

$ ls /Library/Extensions/
ACS6x.kext            FakeSMC_ACPISensors.kext
ATTOCelerityFC8.kext        FakeSMC_CPUSensors.kext
ATTOExpressSASHBA2.kext        FakeSMC_GPUSensors.kext
ATTOExpressSASRAID2.kext    FakeSMC_LPCSensors.kext
ArcMSR.kext            HighPointIOP.kext
CalDigitHDProDrv.kext        HighPointRR.kext
CodecCommander.kext        LittleSnitch.kext
EnergyDriver.kext        PromiseSTEX.kext
FakePCIID.kext            SoftRAID.kext
FakeSMC.kext            USBInjectAll.kext

$ ls /Volumes/EFI/EFI/CLOVER/kexts/Other/
FakeSMC.kext            HackrNVMeFamily-10_12_3.kext    IntelMausiEthernet220.kext    USBInjectAll.kext

Even updated kextcache twice and rebooted, still works. I guess its just natively supported?

There is limited support for bluetooth controllers without a firmware uploader. But for certain features, the firmware controller needs firmware. Also, keep in mind firmware will stay loaded on a warm restarts. Cold boots and wake from sleep are a different matter.

 

[kernelpanicd]

There is limited support for bluetooth controllers without a firmware uploader. But for certain features, the firmware controller needs firmware. Also, keep in mind firmware will stay loaded on a warm restarts. Cold boots and wake from sleep are a different matter.

I did several cold boots and it works just fine. I disabled sleep on the machine so can't say for that.

 

[RehabMan]

I did several cold boots and it works just fine.

Keywords "limited support".

 

[Lepus48]

There is limited support for bluetooth controllers without a firmware uploader. But for certain features, the firmware controller needs firmware. Also, keep in mind firmware will stay loaded on a warm restarts. Cold boots and wake from sleep are a different matter.

I'm using this usb bluetooth adapter on my machine without the Broadcom kexts, but only to occasionally connect some earphones. What types of features are likely not to work without a firmware uploader?

 

[RehabMan]

What types of features are likely not to work without a firmware uploader?

No idea. For my laptops, I always use the BrcmPatchRAM kexts to load firmware (I don't use BT or WiFi on my NUC6s). I don't see the point in testing with an invalid configuration.

 

[Andy1]

I hope you don't mind me posting a how does it work question here? I’m trying to understand how the audio hacks fit together on this NUC. I don't have any audio problems, just looking to see how it works.

This is what I understand to be the happening.

1/ Binary patch the native AppleHDA kext as follows, using KextsToPatch:

a) Replace Native ALC262 Codec Id with id for our NUC codec, ALC283
b) Change Resource string, to look for extension zml.zlib instead of xml.zlib

2/ Copy appropriate layout and platforms files for ALC283 to ~AppleHDA.kext/Contents/Resource *.zml.zlib

OK that was the easy bit I think.

3/ ACPI related, ah

a) Rename HDAS to HDEF (ACPI object rename) required by OSX
b) Add SSDT-Config creates RMCF device , sets AUDL to 1 (no audio injection) and FAKH to 1 (HDMI audio related)
c) Add SSDT-HDEF
// inject properties for audio

Method(_SB.PCI0.HDEF._DSM, 4)
{
If (Ones == \RMCF.AUDL) { Return(0) }

I'm trying to understand this line as, I would guess that as we set \RMCF.AUDL to 1 in 3b) , we should just return out of the method at this point? However I see later that we do the following:

{
"layout-id", Buffer(4) { },
"RM,disable_FakePCIID", Ones,
"hda-gfx", Buffer() { "onboard-1" },
"PinConfigurations", Buffer() { },
}

and I’m pretty sure we do this stuff as I experimented with changing values of onboard-1 and the settings altered in IOReg

d) SSDT-NUCHDA

Seems to create RMCF.cache entry with CodecCommander / CodecCommanderProbeInit sections. The later has a LayoutID and PinConfigs which seem to be the real PinConfigs for our Codec

Are these used in preference to the PinConfigurations Data that exists directly under HDEF?

Probably a hundred other questions, but understanding this might jog me along the way a bit.