Contribute
Register

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

I got rid of FakePCIID.kext and FakePCIID_Intel_HDMI_Audio.kext (fix loss HDMI audio after reboot). I modified AppleALC.kext for device-id 719d0000 (100 Series PCH HD Audio) Who has nuc7 (nuc8?) Check if it works on your configuration
 

Attachments

  • AppleALC modified.zip
    970.7 KB · Views: 98
Glad it all works for you. I use a USB-C external drive to run a backup version of my Catalina MAC OS. It uses the USB-3.1 Gen 1 and not Thunderbolt though. It does sleep.

Indeed, sleep/hotplug works fine with USB-C devices. It fails with actual Thunderbolt devices, at least with the HP dock I've tried. Would be great if somebody came up with a solution at some point.
 
There are strong arguments on both sides of kext placement, for me it's easier to leave them in the EFI folder now. Did you rebuild the kextcache after deleting them? Very important, its this command executed in terminal.

sudo kextcache -i /

The big downside of moving Kexts to your Mac OS installation is that your EFI folder isn't a COMPLETE copy of everything in one place. Made it easy for clean installs etc.

The main reason I have read PRO L/E location and not the EFI other folder is that the drivers are run in protected memory and that the Others folder this is not the case.

But if your Mac is working without issue keep your kexts in the EFI partition. Another thing is I was going to move my kexts to the L/E folder as I would lose HDMI audio after sleep or restart and have to move unplug and replug my HDMI cable.

In the end upgrading to Catalina fixed this. No idea why but something must have been wrong with my Mojave install somewhere.

The point being unless there is a real fix needed then leave things where they work is what I learnt from that. I moved them back to the EFI folder when I it didn't fix things.

If you do move your kexts it isn't a simple copy and paste make sure to follow a guide. At the moment Leesureone's EFI folder is very solid for me and works with no problems at all for my Intel NUC8i7BEH.
 
Indeed, sleep/hotplug works fine with USB-C devices. It fails with actual Thunderbolt devices, at least with the HP dock I've tried. Would be great if somebody came up with a solution at some point.

I did some searching a few weeks ago for a Thunderbolt 3 USB-C external enclosure for NVMExpress M.2. but they are so expensive compared to other enclosures.

What SSD hard drive are you running on your Thunderbolt 3? Have you done any benchmarks to see the MB per second read and write speed? Let me know what your getting if you can do a screenshot. Use BlackMagic Disk Speed test from App store if you don't have a benchmark software.

I get around 480mb second read and write on internal and external SATA 2.5" drives in a USB 3.0 and USB 3.1 showing the drive maxes out regardless of the interface.

Now my internal "Samsung 970 EVO Plus NVMe M.2" reads and writes a whopping 2800 mbs on average. NEARLY SIX TIMES the speed of the SATA SSD drives.

Anyway let me know your benchmark using Thunderbolt 3 USB-C on your SSD and what brand SSD your testing.
 
INTEL NUC8i7BEH thoughts on 2 drive options SSD NVMexpress M.2 vs 2.5" SSD drive speeds and where to put your main OPERATING SYSTEM ie Catalina

I see a lot of people use their NUC internal M.2 to install a GENUINE APPLE WiFi and Bluetooth Adapter as there is NO support for INTEL bluetooth and WiFi.

The SPEED LOSS of your operating system is huge if you do this and I thought I would point out the big difference in read and write speeds on M.2 SDD compared to SATA3 SSD 2.5" drive.

This link has a good summary of the speeds that are available for us. https://www.akitio.com/information-center/achieve-best-transfer-speeds-external-drives

Simply put the average speeds on my NUCi7BEH are as follows

Crucial MX500 500gb 2.5" SATA3 SSD averages out 480 mb second read and write speeds sequential reads. (Windows 10 550 mbs read and 510 mbs write.)

Samsung 970 EVO Plus NVMe M.2 500gb SSD averages about 2700 mbs read/write that is about 5.8 times faster. (Windows 10 3600 mbps) Not sure why speeds are better on Windows. Drivers maybe.

SUGGESTION: I would much rather and OS that is 5.8 times faster at 2800 mbps in reading and writing data, opening up applications, rebooting system than the slower 480mbs SATA3 Drives. No way I'm losing that speed for wifi and bluetooth.

SOLUTION: For Wifi/Bluetooth I use TP-Link Archer TU3 if I need WiFi. I mainly use Ethernet LAN connection anyway. You can also get Bluetooth adapters if you so need too. In Australia I just got one for $40 delivered. https://www.tp-link.com/us/support/download/archer-t3u/ WORKS ON CATALINA

ALSO: You can get an external M.2 to USB adapter and use a genuine Apple Wifi/bluetooth option too and keep your internal M.2. drive for your fast SSD drive 2700mbps ie:
Simplecom SE503 NVMe PCIe M.2 SSD to USB 3.1 Gen 2 Type-C External SSD Enclosure. You can get a normal USB 3.0 and not USB-C like this model.

NOTE ON external enclosures. You can get a $20 external USB 3.0 or 3.1 and even USB-C 3.1 gen 2 enclosures cheaply. As the SATA drives MAX out at around 480 mbps it doesn't make a difference for which adapter you choose with present SATA3 drives. You will get a little more speed on USB 3.1 gen 2 which MY NUC has.

THUNDERBOLT 3 USB-C speed would in theory be around 2700 mbps which is the same as the internal M.2 drive speed. If you have used your M.2 for wireless and don't use the port for monitor as I do.

https://www.akitio.com/information-center/achieve-best-transfer-speeds-external-drives

Interface Bottleneck Pros Cons
USB 3.1 Gen 1 ~300-400 MB/s Available on most computers Not fast enough for faster drives
USB 3.1 Gen 2 ~700-800 MB/s Fast enough for 1-2 SSDs Not fast enough for more than 2 drives
Thunderbolt 1 ~700-800 MB/s Fast enough for 1-2 SSDs Not fast enough for more than 2 drives
Thunderbolt 2 ~1375 MB/s Fast enough for 3-4 SSDs Not fast enough for NVMe based SSDs
Thunderbolt 3 ~2750 MB/s Enough bandwidth even when daisy chaining multiple devices. Not fast enough for certain NVMe based SSDs (e.g. Samsung 960 Pro)

CONCLUSIONS AND COMMENTS: If all you do is web browsing and word processing the SATA3 is fairly good. But if you do any Video editing with large files, gaming or transcoding etc then put your MAC OS on the M.2 port. Use the SATA for a second OS or extra storage. If you run out of drive space using an EXTERNAL drive is nearly as good as the internal M.2 and SATA3 ports.

I did all this testing this week and I though others might find this info helpful save them looking around.
 
Last edited:
The big downside of moving Kexts to your Mac OS installation is that your EFI folder isn't a COMPLETE copy of everything in one place. Made it easy for clean installs etc.

The main reason I have read PRO L/E location and not the EFI other folder is that the drivers are run in protected memory and that the Others folder this is not the case.

But if your Mac is working without issue keep your kexts in the EFI partition. Another thing is I was going to move my kexts to the L/E folder as I would lose HDMI audio after sleep or restart and have to move unplug and replug my HDMI cable.

In the end upgrading to Catalina fixed this. No idea why but something must have been wrong with my Mojave install somewhere.

The point being unless there is a real fix needed then leave things where they work is what I learnt from that. I moved them back to the EFI folder when I it didn't fix things.

If you do move your kexts it isn't a simple copy and paste make sure to follow a guide. At the moment Leesureone's EFI folder is very solid for me and works with no problems at all for my Intel NUC8i7BEH.
Just weighing in on kext placement. When I built my first Hackintosh nine years ago it was a given kexts were to be installed in S\L\E or later just L\E. Clover and UEFI booting were unknown so at that time it was really the only choice available. Today, and even in the last year and a half, things have changed significantly. The developer of Lilu and Whatevergreen states it’s essential Lilu, and all other dependent kexts, be placed in EFI\C\Other for proper functionality.
Below is a quote from @ModMike from his “the everything Works ASUS Z390 gaming i“ page here. Overall I agree with most of what he states and certainly easier to maintain and update. Please see below


Methodology
Before we start, it might be a good idea to discuss my heretical approach. I only install kexts in /EFI/Clover/Kexts/Other and I am a huge fan of Port Limit Removal Patches. Heresy you say? Consider this:
Spoiler: The Great Kext Schism
Lilu & WhatEverGreen (WEG) have drastically changed Hackintoshing by eliminating many kexts, some of which may not have been injectable.

The arguments put forth apply ONLY to this guide. If your system needs custom un-injectable kexts the following does not apply.
  1. The one and only reason cited for not installing kexts in /Others is because it “could” violate something claimed to be “Protected Memory Space”. This is not even a thing

    i. I searched "Protected Memory Space" on Apples developer site and it does not exist anywhere as a term or concept
    ii. Kexts by their very nature must be loaded into kernel space and are therefore not subject to OSX memory management! Even if "Protected Memory Space" did exist, the main reason cited for doing this is invalid
  2. Apple does recommend that 3rd party kexts be installed in /Library/Extensions but that’s for officially sanctioned, developed, and signed kexts, which ours are not so why break SIP?
  3. Even if the above did apply, OSX cannot manage kexts critical to booting. Lilu & WhatEverGreen (WEG) must be loaded before OSX for it to properly load its plug-ins and boot OSX
  4. WEG developers themselves instruct users to install WEG in EFI/Clover/Kexts/Other
  5. Lilu plug-Ins make up the majority of the plug-ins we need. Guess where they recommend they be installed?
  6. FakeSMC is a critical kext that must be injected (meaning loaded before OSX) and should be in /Others.
  7. That leaves 4 kexts and the SMC sensors that could live in /Library/Extensions. But if they can all be injected, why bother?
  8. Clover Configurator’s Kext installer is a great maintenance tool. It tracks nearly every and installs them in /Other by default, which implies that’s where they should go
  9. Rehabman, the developer of networking kexts, states that his kexts can be injected. In fact, the BrcmFirmwareData.kext is designed to be injected
  10. Installing kexts in /Others makes debugging very easy. If there is an issue with a kext installed in /L/E, then you can’t boot the system which makes repairs and testing very difficult. If everything is in /Other, you simply boot with a USB FAT32 drive that has your EFI on it
  11. Keeping OSX free of Hackintosh kexts lets you enable SIP mode and run as securely as an OEM Mac
  12. Putting everything in one shareable EFI folder vastly simplifies installation
  13. Putting everything in the /Other folder eliminates the need for kext installation and permission repair tools
  14. Pastrychef, who has helped hundreds of people, stated that moving kexts to /library/extensions has never helped solve one single issue he has come across. See what people think and do in his poll
Summary:
  1. The term or concept of "Protected Memory Space" does not exist in Apple's developer documentation
  2. WEG developers are unanimous in their position that kexts should be installed in /Other
  3. rehab man says it’s fine to inject them.
  4. Putting them in /Other simplifies maintenance and enables SIP.
Conclusion: All injectable kexts belong in Clover's /Other folder.
 
there is NO support for INTEL bluetooth and WiFi.

Intel Bluetooth is working if you have a dual boot system. Rebooting from Windows makes it work even after subsequent shutdown(s). The procedure with booting Windows only has to be repeated after unplugging power.
 
let me know your benchmark using Thunderbolt 3 USB-C on your SSD and what brand SSD your testing.

Unfortunately i don't have an actual thunderbolt drive, just a thunderbolt dock.
 
Intel Bluetooth is working if you have a dual boot system. Rebooting from Windows makes it work even after subsequent shutdown(s). The procedure with booting Windows only has to be repeated after unplugging power.

Can you clarify more on "Bluetooth working in Catalina" IF Dual Booting.

Are you saying Bluetooth is stable in MAC OS Catalina? I don't understand what the relationship that Bluetooth working has with NEEDING Windows as Dual Booting. So it seems you are saying if you unplug the power source that you first have to boot into Windows 10 and then restart and boot MAC OS for it to work in Catalina. That is weird.

Why does it need to be booted into windows first for it to then work with Mac OS what is the thinking behind that. I would have thought if the kext worked and was stable then it would work period?

Thanks for your post. I don't need bluetooth really but would be good to know as I sometimes use bluetooth headphones.
 
Just weighing in on kext placement. When I built my first Hackintosh nine years ago it was a given kexts were to be installed in S\L\E or later just L\E. Clover and UEFI booting were unknown so at that time it was really the only choice available. Today, and even in the last year and a half, things have changed significantly. The developer of Lilu and Whatevergreen states it’s essential Lilu, and all other dependent kexts, be placed in EFI\C\Other for proper functionality.
Below is a quote from @ModMike from his “the everything Works ASUS Z390 gaming i“ page here. Overall I agree with most of what he states and certainly easier to maintain and update. Please see below


Methodology
Before we start, it might be a good idea to discuss my heretical approach. I only install kexts in /EFI/Clover/Kexts/Other and I am a huge fan of Port Limit Removal Patches. Heresy you say? Consider this:
Spoiler: The Great Kext Schism
Lilu & WhatEverGreen (WEG) have drastically changed Hackintoshing by eliminating many kexts, some of which may not have been injectable.

The arguments put forth apply ONLY to this guide. If your system needs custom un-injectable kexts the following does not apply.
  1. The one and only reason cited for not installing kexts in /Others is because it “could” violate something claimed to be “Protected Memory Space”. This is not even a thing

    i. I searched "Protected Memory Space" on Apples developer site and it does not exist anywhere as a term or concept
    ii. Kexts by their very nature must be loaded into kernel space and are therefore not subject to OSX memory management! Even if "Protected Memory Space" did exist, the main reason cited for doing this is invalid
  2. Apple does recommend that 3rd party kexts be installed in /Library/Extensions but that’s for officially sanctioned, developed, and signed kexts, which ours are not so why break SIP?
  3. Even if the above did apply, OSX cannot manage kexts critical to booting. Lilu & WhatEverGreen (WEG) must be loaded before OSX for it to properly load its plug-ins and boot OSX
  4. WEG developers themselves instruct users to install WEG in EFI/Clover/Kexts/Other
  5. Lilu plug-Ins make up the majority of the plug-ins we need. Guess where they recommend they be installed?
  6. FakeSMC is a critical kext that must be injected (meaning loaded before OSX) and should be in /Others.
  7. That leaves 4 kexts and the SMC sensors that could live in /Library/Extensions. But if they can all be injected, why bother?
  8. Clover Configurator’s Kext installer is a great maintenance tool. It tracks nearly every and installs them in /Other by default, which implies that’s where they should go
  9. Rehabman, the developer of networking kexts, states that his kexts can be injected. In fact, the BrcmFirmwareData.kext is designed to be injected
  10. Installing kexts in /Others makes debugging very easy. If there is an issue with a kext installed in /L/E, then you can’t boot the system which makes repairs and testing very difficult. If everything is in /Other, you simply boot with a USB FAT32 drive that has your EFI on it
  11. Keeping OSX free of Hackintosh kexts lets you enable SIP mode and run as securely as an OEM Mac
  12. Putting everything in one shareable EFI folder vastly simplifies installation
  13. Putting everything in the /Other folder eliminates the need for kext installation and permission repair tools
  14. Pastrychef, who has helped hundreds of people, stated that moving kexts to /library/extensions has never helped solve one single issue he has come across. See what people think and do in his poll
Summary:
  1. The term or concept of "Protected Memory Space" does not exist in Apple's developer documentation
  2. WEG developers are unanimous in their position that kexts should be installed in /Other
  3. rehab man says it’s fine to inject them.
  4. Putting them in /Other simplifies maintenance and enables SIP.
Conclusion: All injectable kexts belong in Clover's /Other folder.

Thanks again for sharing your wisdom. I'm new to Hackintosh and have no history of the changes. I do understand that Clover is now the standard for UEFI Hackintoshing. All my kexts are in the Other directory and EVERYTHING that is supposed to work works. Good to have reasoning why I will continue to keep my kexts in the "other" directory in the EFI partition.

The big thing is for me as you say ONE EFI partition. I can copy as is to a bootable USB if I need recovery or clean install. I got my info from https://www.tonymacx86.com/threads/...an-sierra-high-sierra-mojave-catalina.268964/ Well the pole says it all. 56 % have their kexts in Other and no issues and it is the highest voted.

I'm happy to go with your wisdom and logic on this one as I wouldn't have a working Hackintosh without your help and EFI folder working as is. Thanks for the history too of how things have changed.
 
Last edited:
Back
Top