[Guide] Intel NUC7/NUC8 using Clover UEFI (NUC7i7Bxx,NUC8i7Bxx,etc)

[Gimmemoare]

Just changed id for graphics 640

How to change this id? Simply edit the plist string?

 

[amfbluffer]

Just wanted to add praise for Leesureone and the community. I've had a NUC8i7BEH sitting idle for months as a hobby unit. For hours would come up against what appeared to be a slide setting/memory error issue and/or other configuration issue and intermittently getting into setup boot screen but would never complete. Finally read to try HDD via usb instead of usb stick and Leesureone's NUC8 EFI folder worked flawlessly.

 

[Leesureone]

How to change this id? Simply edit the plist string?

Use Hackintool to patch the Device ID. Click on the "Patch" tab on the the top, check the framer buffer / Graphic Info is what you are looking for and then in the same window click the other "Patch" tab on the far right. Click the options you want to include in the patch and then "Generate Patch". From there export the patch and save it to your desktop, those "Device Properties" to your Config.plist

A better guide is here: an-idiots-guide-to-lilu-and-its-plug-ins.260063

 

[Manuelmr]

If I understand your question correctly the answer is no. The boot loaders are too different and use different drivers and config.plist formatting. You can exchange the entire EFI folder and make the switch that way

Thanks for your help. It is the first time that I do this and there are many things that I do not understand yet. Excuse my English.

 

[Leesureone]

Thanks for your help. It is the first time that I do this and there are many things that I do not understand yet. Excuse my English.

No worries

 

[Gimmemoare]

Use Hackintool to patch the Device ID. Click on the "Patch" tab on the the top, check the framer buffer / Graphic Info is what you are looking for and then in the same window click the other "Patch" tab on the far right. Click the options you want to include in the patch and then "Generate Patch". From there export the patch and save it to your desktop, those "Device Properties" to your Config.plist

A better guide is here: an-idiots-guide-to-lilu-and-its-plug-ins.260063

Thank you, it's all correct now.

 

[konsti]

Hello everyone. Hi @Leesureone hope you are well. I have been using on my NUC8i7BEH the FakePCIID and FakePCIID_Intel_HDMI_Audio kexts (from Rehabman) that allows the HDEF to device obtain a second "iteration" that immediately detects my DisplayPort or HDMI connections and allows digital audio.

To prepare for OC and move to modern patching methods etc. I have been searching for alternatives as to how to stop the use of FakePCIIDs, but I could not find any method that would bring some results.

With FakePCIIDs that's attaching to my [8086:9dc8] audio controller, I obtain a second audio controller (rather, Codec) that allows for HDMI/DisplayPort digital audio:

The first, analogue audio (Realtek) uses Class AppleHDADriver and second digital audio (Kabylake HDMI) uses Class AppleHDAHDMI_DPDriver (per Hackintool). When I remove FakePCIID*kext from /L/E/ this "device" is obviously gone and I cannot get DP/HDMI audio; AppleALC uses layout-id=3 and both IGPU and HDEF contain the needed hda-gfx=onboard-1 values in IORegistry. But no digital audio detected as present, per my tweaking. As you can see below, HDEF obtains two IOHDACodecDevice@1F,3,0 and 1F,3,2 with FacePCIID clearly attached to it.

Any idea or suggestion as to how we can replicate what FakePCIIDs does for HDMI/DP audio? By injecting a non-existent HDAU device (nor B0D3 in my DSDT)? But under which device/scope in SSDT? Or by injecting WhateverGreen device properties in Clover configuration? I could not generate a patch that would result to this (via Hackintool)... Any feedback is very welcome... Thanks!

 

[Leesureone]

Hello everyone. Hi @Leesureone hope you are well. I have been using on my NUC8i7BEH the FakePCIID and FakePCIID_Intel_HDMI_Audio kexts (from Rehabman) that allows the HDEF to device obtain a second "iteration" that immediately detects my DisplayPort or HDMI connections and allows digital audio.

To prepare for OC and move to modern patching methods etc. I have been searching for alternatives as to how to stop the use of FakePCIIDs, but I could not find any method that would bring some results.

With FakePCIIDs that's attaching to my [8086:9dc8] audio controller, I obtain a second audio controller (rather, Codec) that allows for HDMI/DisplayPort digital audio:

View attachment 475922

The first, analogue audio (Realtek) uses Class AppleHDADriver and second digital audio (Kabylake HDMI) uses Class AppleHDAHDMI_DPDriver (per Hackintool). When I remove FakePCIID*kext from /L/E/ this "device" is obviously gone and I cannot get DP/HDMI audio; AppleALC uses layout-id=3 and both IGPU and HDEF contain the needed hda-gfx=onboard-1 values in IORegistry. But no digital audio detected as present, per my tweaking. As you can see below, HDEF obtains two IOHDACodecDevice@1F,3,0 and 1F,3,2 with FacePCIID clearly attached to it.

View attachment 475923

Any idea or suggestion as to how we can replicate what FakePCIIDs does for HDMI/DP audio? By injecting a non-existent HDAU device (nor B0D3 in my DSDT)? But under which device/scope in SSDT? Or by injecting WhateverGreen device properties in Clover configuration? I could not generate a patch that would result to this (via Hackintool)... Any feedback is very welcome... Thanks!

@konsti, good to hear from you.. For simplicity you can still use those FakePCIID kexts if you like. I've got them in a couple of the OC EFI folders on page 90 of this thread. For the NUC10 I had to resort to VoodooHDA.kext which also identifies both audio outputs.

 

[konsti]

I haven't bugged you for some time since I read you moved on to NUC10 Been trying to get it myself but they became all of a sudden very expensive, so still using NUC8 that works flawlessly... Thus, I assume from your answer that FakePCIIDs are here to stay until they "die", due to incompatibilities or other... no alternative for this, I guess, correct? Was just wondering if other users moved on with new techniques... in any case warm thanks for the EFI ZIPs in your post #894 of Page 90 that is a good kick-start into OC for NUC8 when I get some more free time! Cheers mate.

 

[macdude007]

HedgeHog2k said:


So I took the time to make a custom USB SSDT for the NUC8. I was preparing myself for a long evening but wow was that an easy job! The reading took longer then executing. I did it a second time and it took me literly 5minutes... And best of all it seems to work work very well:
- first of all, all usb ports still seem to function with a USB2 and USB3 drive (for test I copied a 2gb file from an external drive to the hack and it took 10seconds, so full speed)
- the hack goes to sleep perfectly fine
- when I woke it up (I let it sleep for about 10mins) all my BT devices connected fine
- after reboot BT devices working fine

what still doesn't work:
- I still have audio stuttering with my Bose BT headset sometimes (but I believe this is more linked to the headset, because in all honestely I had issues before on windows
- Tapp my keyboard/mouse/trackpad to wake it up from sleep (so same behaviour as with dongle), that's a bummer. But I'll investigate!

Attached:
- The sleepwake file, but I don't understand any of it.
- I've also attached the SSDT (both the dsl and aml, both can be opened with Maciasl). I guess it should work for everybody with a NUC8i7BEH(2)? Basically it limits your USB ports to 9 (so well below the 15 port limit)
HS01 - usb2 front right
HS02 - usb2 front left
HS03 - usb2 bottom rear
HS04 - usb2 bottom top
HS05 - usb2 internal1 (BT), internal2 not mapped
SS01 - usb3 front right
SS02 - usb3 front left usb3
SS03 - usb3 bottom rear
SS04 - usb3 bottom top

I have not yet enabled again the sdcard reader kext, which most likely is another port I need to map.

Let's see how the hack handles a full night of sleep!

We might hear from him, he wanted the perfect Mac substitute and got as close as you can get with an NUC. He told us he was signing off after buying a real Mac. Its worth trying his usb ssdt.aml file, he configured it to activate the internal headers as well which I don't think you need. It should still work although you may still have Bluetooth problems being he disabled internal Bluetooth.

Leeureone ----- Do you have the EFI folder updated with the USB DSDT information embedded in it? I would like to get it if it is available or if someone has done the DSDT. I allowed an Update to Catalina and now there seems to be a problem with the Recovery Partition. It disappeared. It appears that all I need for a near perfect HacMini 8 Gen is to fix the USB-SleepWake Issues and that can be done with the DSDT fix that HedgeHog2K came up with. I would like to get his DSDT or -----> ((Its worth trying his usb ssdt.aml file, he configured it to activate the internal headers as well which I don't think you need.)) I would like his DSDT or ssdt.aml which you mentioned in your reply. I don't know what the difference is between them... Has anyone embedded that file which ever it is... in your EFI Folder? That would be the folder to have. By the way. There seems to be a perception that if the BT drops out/cuts out, that it is no good or not working properly. I will look more at that. Mine works ok (lower case) since it drops out when I move my head. When I look at the NUC the signal comes back. I think the problem is signal strength and will look more at that; although, it is not a priority at the moment. The driver could be at fault by not increasing the signal. I will reboot in Windows 10 and see if the BT has a stronger signal. My iPhone signal works around the house. the NUC works next to the unit at my computer desk. Very weak... but it works. I use it for sound. The headphone jack seems to not work too good and I am not sure why, I will look at that some later, right now my focus is on reliable USB-2 & 3.o which operate my drives and other much more important items. Maybe someone has put the USB fix files in an EFI?