[Success] ASRock Z390 Phantom Gaming-ITX + TB3 + iGPU + Mojave + SFF Build

Feb 18, 2019
ASUS Z690 Maximus Extreme
  1. MacBook Air
Mobile Phone
  1. iOS
rj510's Build:
ASRock Z390 Phantom Gaming-ITX + TB3 + iGPU with Mojave


ASRock Z390 Phantom Gaming-ITX/ac

G.SKILL TridentZ RGB Series 32GB (2 x 16GB) DDR4 SDRAM 4000, Model F4-4000C19D-32GTZR

Intel Core i9-9900K Processor

WD BLACK SN750 1TB NVMe Internal Gaming SSD - Gen3 PCIe, M.2 2280 - WDS100T3X0C

Plugable USB C to M.2 NVMe Tool-free Enclosure USB C and Thunderbolt 3 Compatible, USB 3.1

CORSAIR SF750 CP-9020186-NA 750W SFX 80 PLUS PLATINUM Cert. Full Modular Power Supply

OEM Dell Wireless DW1560 802.11ac Broadcom BCM94352Z M.2 NGFF WIFI Card

These work too at half the price:

Already Owned

BenQ 27 inch 4K PhotoVue Photographer Monitor (SW271)

Logitech K780 Wireless USB Mac/Win/iOS Keyboard

Logitech M510 Wireless USB Mouse - connected to same USB receiver as keyboard

PowerColor Vega 56 Nano - no longer available

CalDigit TS3 Plus Thunderbolt 3 Dock

Logitech C920S Pro HD Webcam


Over the past few months, I've built a few Hackintoshes (hats off to this forum and especially CaseySJ), based on Gigabyte Aorus Xtreme Waterforce and a Designare. These builds were desirable mainly because of the presence of Thunderbolt (TB3) ports. While these machines are working very well, a smaller footprint was needed. In keeping with the need for TB3, the only Z390 SFF style board with TB3 is the ASRock Z390 Phantom Gaming ITX mobo.

The Build

Key Features[

  • Small form factor (SFF) build
  • Only mITX mobo with TB3
  • BIOS allows CFG Lock to be disabled (unlock MSR 0xE2 register)
  • Uses iGPU - for even smaller SFF (graphics can be added; simple BIOS adjustment, see below)
  • BT/Wifi work (incompatible Intel PCB easily swapped out for a Broadcom PCB)
  • Wake, sleep, shutdown, restart — all work well (without panics)
  • Working: Messaging, Airdrop, iCloud and FaceTime
  • Thunderbolt (TB3 and USB-C) is working!

While many users, across several threads, have working Hackintoshes with this motherboard, none seem to have gotten the Thunderbolt 3 (TB3) port working. After gathering the equipment, installing the Bluetooth unit (see Replacing the BT PCB Spoiler), cloning a working copy of the Designare Mojave build (using SuperDuper), I got the ASRock Z390 ITX up and running. The immediate problem was then verifying all USB ports and making a good SSDT UIAC file. All was working except for TB3. I researched many threads, that dealt with TB3 on various motherboards. None of the SSDTs seemed to work until I used the one CaseySJ had developed for the Designare build here.

After modifications (below), it worked, but only if the TB3 dock was plugged in during boot and then unplugged and re-plugged. After several days of testing (with innumerable re-boots), TB3 is working without needing to plug/re-plug. It was a balance of proper USB initialization, TB3 SSDT adjustments and the BIOS settings. If the TB dock and Apollo x6 are powered and plugged in on booting, they're all loaded and running automatically. Nice!

One key was updating the BIOS to v1.6. There are several threads discussing the benefits of v1.2. But I could not get consistent results with v1.2 and decided to test out v1.6. It works very well, but does require some specific settings in BIOS (see Spoiler, below). I did keep @pupin's patch active in the ACPI/DSDT Patch section of Clover (see the attached config.plist files below).

While getting the TB3 to work, I also tested USB port limits by 2 methods: USBPorts.kext vs SSDT-UIAC + uia_exclude. The USBPorts KEXT method seemed to interfere with the TB3 functionality, giving erratic results. The SSDT-UIAC method, which is what I've uploaded, seems the best for the ASRock Z390 ITX mobo.

As for displaying various Clover pages, as I've attached complete config.plist files for iMac19,1 and MacMini8,1 (less serial numbers). You can see all details on the pages for yourselves. (Whichever file you use, you must rename it to simply 'config.plist' to auto load during booting.)

Since this build is intended for a SFF case, I initially only used the internal GPU to keep things as small as possible. This meant that in BIOS, the PCI slot was turned off. (I have tested with graphics cards, both an AMD Vega 56 and an RX 580 and the config files seem to work just fine as is; see below for more details regarding the Vega 56.)

Both Mojave 10.14.4 and 10.14.5 work well. The CPU is an i9-9900K and there is 32GB of RAM.

I've attached a Clover Configurator made config.plist file (iMac19,1 without SNs), the SSDT files (compressed in the "Patched" folder), along with images of the KEXT and drivers64UEFI folders. All items seemed necessary for a stable boot and graphics function (iGPU) running at 4K from the HDMI port. I used Hackintool to refine the Clover config files Device/Properties (see Spoiler, below).

The CPU page in the Clover Config file show type 0x01005. Feel free to delete this value. If left, it will populate the "About Mac" window with the proper i9 processor information (if you are using the Mojave special release of 14.4 or greater).

WiFi/BT works well after replacing the PCB with a Broadcom unit---actually a Dell DW1650 or Broadcom BCM94352Z (described in the Clover Devices/Arbitrary section). The PCB swap is very easily, involving removing two screws from the mobo bottom and unplugging the battery from the mobo. See the "Replacing the BT PCB" Spoiler for details.

Other items are shown in the Devices/Arbitrary section of the Clover Config file. These items are mostly descriptive in nature and provide information on the Mac's system information pages, esp the PCI section (see the "System Information Spoiler for more details).

The KEXT "Other" folder contains all the KEXTs that I've used along with an internal (ignored during boot) folder called "in LE folder". This folder contains KEXTs that were placed inside the /L/E/ folder (followed by running Kext Utility). There are various reasons these KEXT are best left in that folder instead of in the "Other" folder on the EFI boot partition: the presence in the /L/E/ folder seems to better allow BT to function during log-in, rather than after.

One pleasant surprise, after working so hard on the TB3 issue, was finding that the sensors revealed both voltage and fan data (report shown below). These same KEXTs and app do not show voltages and fan data on Designare. So, the display of this data has to do with properties of this mobo. It's is nice to see so much data, so I uploaded the whole KEXT folder, including the copy of HWMonitorSMC2 v2.4.5, so others can try it out.

I also attached images showing the IORegistryExplorer section (see Spoiler) for TB and USB ports with an attached CalDigit Dock to which is attached a camera, an SD card reader and a UAD Apollo x6---all work.

I provided an image to show that I chose not to use the USB ports beneath the Ethernet port: HS09/SS06. On the boot page of the Clover config file, I further eliminated via uia_exclude the following:

HS07, HS09, HS10, HS11, HS12, HS13, SS06, SS09, SS10, USR1, URS2​

My active USB ports are:

Injected (via USBPort kext) are: HS01-06, HS08, HS14, SS01-05, SS07, SS08 = 15 ports​

The WiFi/BT unit uses HS14. SSP1 and SSP2 are not include in the 15 USB limit and are associated with TB3. The internal USB 2 header and marked it in an attached image (HS01/HS02). Thanks to @pupin for adding the internal USB3 header information: HS10,SS10 is the first one and HS11,SS08 is the second one.

The EC and USB SSDTs are for power settings and seem to work across many other motherboards. The remaining DDST is for TB3. I downloaded the V4 TB3 SSDT file from CaseySJ's thread, and modified it for the ASRock Z390 PG ITX mobo; basically substituting RP21 for RP05 and internalizing the SSDT-DTPG file to use only one file for TB3. I also drew heavily on the Hackintool thread and the Intel Framebuffer patching thread here and here.

Installation Notes

I've noticed some display flickering that I've now attributed to active BT. Before arriving at this conclusion, I read many threads which mostly suggested that changing the SYMBIOS would stop the flickering. I didn't want to change from the latest iMac19,1, so I started looking at other factors. If Wifi is on or off, no flickering. If BT is powered, then there is often, but not always, flickering. If BT is removed (turning off HS14 or physically removing the BT module), the display has no flickering. And this is presently only with iGPU (verified by adding a graphics card which did not flicker). The presence or absence of the antenna on the BT was not the issue; if it was powered, there was flickering. Increasing "Share Memory" (Advanced\Chipset Configuration) in BIOS to 256M seemed to have helped too.

The flickering stopped after updating to BIOS v1.6. (It is possible that perhaps my copy of v1.2 was corrupted, I did not re-flash it to check this out.) Bottom line is that I'd recommend updating BIOS to v1.6 (from ASRock site). If you update to 4.0, ASRock says you cannot downgrade. Once v1.6 worked with TB3 and stopped the flickering, I chose not to upgrade the BIOS to v4.0.

One thing I've observed is how easily corrupted the BIOS can become, especially during the initial boot panics. So once the OSX system is regularly booting and seems to be running okay, the BIOS should probably be re-flashed to minimize any stability problems it would otherwise contribute. I think some of the problems with various panics may stem from BIOS corruption. (I have to remind myself to do this, and once I re-flash the BIOS, I'm amazed at how smoothly the system then runs.)

Graphics Card

Once the iGPU settings were worked out, a PowerColor Vega 56 graphics card was tested. The only BIOS change required, from what was posted for the iGPU, was setting the pop-up, in Advanced\Chipset Configuration, for "Primary Graphics Adapter" from "Onboard" to "PCIe". The iGPU was left "Enabled". See the BIOS Spoiler for more information. Also see he Benchmarks Spoiler for the results of the iGPU vs Vega 56, as well as the stock vs the over clocked CPU.

Initial Install - Seeding

I did not start this build with a clean install, but instead used SuperDuper to clone a working Mojave 10.14.4 Aorus Designare Z390 build (based on CaseySJ's thread). I use this cloned SSD to 'seed' the new build, preferring this over the tedium of using a USB flash drive to perform a fresh install.

I attach this new SSD (a PCIe M.2; the WD drive listed above) via USB3 in an externalized housing (the Plugable USB-C adapter listed above). In other words, I do not immediately fix this drive to the mobo in the M.2 slot. By keeping the SSD externalized, I can easily move this drive between the new mobo build and a working Mac to fix problems and change files in the EFI partition. Once adjusted, this drive is transferred back to the new build and re-booted/tested. This cycle is repeated until the new system is booting. This method makes faster work of fixing the boot panics often found while getting the graphics set up on a new mobo. After all is working, this drive is then removed from the external case and placed into the M.2 slot on the mobo.

If you need to perform a fresh install (for example, if this is your first Hackintosh build), then I'd refer you to CaseySJ's build here, where there is an excellent description about how to perform the USB install (and how to prepare it under a Spoiler: UniBeast step-by-step), or look at a simplified install in the Spoiler below.

The following (simplified) steps are taken from a post by the recently retired genus, KGP, here, section D.4.

Follow the individual steps detailed below to successfully setup macOS Mojave 10.14.x on an unformatted, new drive (such as an NVMe, SSD or HDD).

1. In order to perform a clean install of macOS Mojave 10.14.x, prepare the destination drive for the macOS installation by formatting the drive with HFS+ [(Mac OS Extended (Journaled)] and a GUID partition table by means of Apple's Disk Utility on any other Hackintosh or Mac. This will create an empty HFS+ Partition and a yet empty EFI-partition on the drive.

2. Copy the EFI-Folder (see new attachment to this thread) to the yet empty EFI Partition.

3. Now connect the Destination Drive to your Hackintosh System and boot the latter with the plugged macOS Mojave 10.14.x USB Flash Drive Installer, your previously created (not shown here).

4. While booting your system, press the F8/F12/Del (as per your BIOS) button to enter the BIOS boot menu. Select to boot from your macOS USB Flash Drive Installer.

5. Subsequently, click on the USB Flash Drive Installer Icon in the clover boot menu to boot the respective macOS Installer partition on your macOS USB Flash Drive Installer.

6. After successful boot, pass the individual steps of the macOS 10.14.x Mojave installation menu and finally select the destination drive of your macOS 10.14.x Mojave Installation, which should be the system disk you successfully formatted above. In the next step, the Installer will create a macOS Mojave 10.14.x Installer Partition on the system disk and subsequently reboot your system.

7. During system reboot, just press again the F8/F12/Del (as per your BIOS) button to again enter the BIOS boot menu. Select again to boot from your USB Flash Drive. In contrary to #6 above, click this time on the "Install MacOS..." Icon in the Clover boot screen to boot the newly created macOS Mojave 10.14.x Installer Partition on your system disk.

8. After successful boot, you will enter now the macOS Mojave 10.14.x Installer Screen with a progress bar starting at about 34 minutes.

9. After another reboot, press again the F8/F12/Del (as per your BIOS) button to enter the BIOS boot menu once more. Select to boot with your System Disk EFI-folder. Click on the "MacOS Mojave" icon (the Installer icon should have disappeared) on the Clover boot screen to boot the new macOS Mojave partition of your system disk.

10. After successful boot, postpone the requested iCloud registration until you've got BT and WiFi working.


There are two choices for an SFF build: small and really small.

For my initial build, I'm using a small SFF build and selected a Dan S4-SFX by SSFLAB (here). This case can take a full sized graphics card (air cooled) as well as the above Corsair SFX 750W PS. However, if you want to only use the iGPU, since we've got it working, you can skip the graphics card and use a smaller, less expensive PS, such as Silvertone SFX 450W (here), saving some money.

With the Dan S4, CPU cooling can be either air-cooled (Noctua) or an AIO. A 120mm AIO will fit the Dan S4, but is a little tight with the tubing. A better choice might be the newly re-designed Asetek 645LT (here). This 92mm AIO will better fit almost any SFF case. The Asetek AIO is sold for $99 when ordered with the Dan S4 case. The Asetek can be found on eBay but at ridiculous prices.

Keep in mind that with excess cabling and tubing comes poorer air flow through the case, resulting in poorer thermals and greater potential for CPU or RAM throttling. So cable and tube management issues are not simply cosmetic.

To help with cabling, one can turn to custom cables to reduce clutter and improve thermals. PSLATE Cutoms is one source for the Dan S4 (here).

If one doesn't mind using a slightly larger case, another option beyond the Dan S4 is Raijintek Ophion M Evo ALS (here). This case offers a more relaxed (less space constrained) build, allowing for up to 240mm AIO for the CPU, along with full graphic card support. If you're using the iGPU, such a large case seems excessive. So if you're using this case, you might as well use a graphics card, like an AMD Sapphire RX580, a used Vega 56 or 64, or the latest Radeon VII. With one of these graphics cards, you'll need to use the larger 650 or 750W SFX power supply.

Another option for an SFF case is a Circle Pro (here). This case is rather Mac-like, but seems to be unavailable. It claims up to a 240mm AIO can fit, but a 120mm AIO with more case fans for cooling might make for better thermals.

Now for a really small SFF build, a Modivio S, SE, M or ME case might be better. The ME Xcase (here) is a good compromise, depending on your PS preferences. This case allows for either an internal or external PS, while the M version uses only an external PS. If internal, then the HDPLEX is a good source (here) using one of their nano supplies. Ideally, a 300W would fit the ME Xcase, but it is now obsolete and cannot be found. The 160W is an option, but if OC the CPU, one can easily get over the 95W PS requirement (not even considering the power requirements of the mobo, CPU cooling, fans and attached USB devices), again leading to throttling. I recommend at least a 300W PS for a SFF build using the iGPU. If you use a graphics card, the PS requirements go up from there. So if you use a graphics card and a larger PS, you need a larger case for better thermals.

Anyhow, back to the Modivio. If the iGPU is used, there is room in the ME Xcase for an internal 400W HDPLEX PS and an air cooled CPU or an AIO, if the Asetek 92mm AIO is used. Modivio sells a special bracket for the Asetek for an additional $20. With the ME Xcase, if you choose to use a 120mm AIO, then the 400W will not fit internally. If the 92mm AIO is used, several small 80x15mm fans can be placed about the ME Xcase, such as these, further improving thermals.


1. To access UEFI Setup, press and hold Delete on a USB Keyboard while the system is booting up
2. Set as in following images.
3. CSM is disabled (image not shown).
4. Save and exit.

Above, left: adj BIOS for dGPU in PCIe slot.
Above, right: CFG Lock switch, you want to disable it. (Also see CFG Lock Spoiler.)

The photos below show the sequence of how to replace Intel BT PCB with the Broadcom BT M.2 PCB.
  1. Remove the battery plug (if careful, may leave attached to mobo)
  2. Turn over mobo and remove 2 screws holding the BT shield to mobo
  3. Lift off BT shield/PCB unit straight up (last photo shows PCB socket on mobo)
  4. Remove single screw in cover of shield (this screw is shorter than the two mobo screws)
  5. Next, lift and slide this cover towards left (once removed, later removals are easier)
  6. Note the small, black foam; it helps to isolate jacks from screw
  7. Gently unplug antenna leads
  8. Un-screw PCB retaining screw, noting the distance of screw to top of PCB (if the PCB is pushed all the way to the top, it will not be long enough to mate into the mobo socket)
  9. Remove the Intel PCB; replace with Broadcom PCB
  10. Re-attach antenna leads and replace foam
  11. Replace cover, being careful to tuck antenna leads behind PCB without dislocating jacks, and its screw
  12. Push unit back into mobo socket and replace screws on bottom of mobo.
  13. Re-plug the battery if removed. Finished!
For trouble-shooting BT issues, see this link.

For re-setting BT (within the MacOS itself), see this link.



The ASRock mobo, like many current mobos, cancels SATA ports based on M.2 SSD usage. With the ASRock mobo, it cancels SATA_1 if the rear M.2 (M.2_1) is used. The front M.2 (M.2_2) does not affect the SATA ports (probably because it is using SATA_3, which isn't physically available).

The front M.2 socket is revealed after removing the heatsink (remember to remove the protective plastic tape from the heatsink thermal pad before re-installing onto your M.2 drive).

Besides cancelling one SATA port, using the rear M.2 socket does not allow for good thermals. First, once mounted in a case, few enclosures will provide sufficient room for a heatsink on the rear drive. Second, there is usually poor air flow about the back of the mobo. Things to consider when populating the rear M.2_1 socket.

There are two RBG headers in the upper right corner as shown in photo below. One is 5V, the other, 12V. Depending upon what RBG LEDs you want to connect, you need to be sure to use the correct voltage, matching the manufacturer's recommendations with either of the two voltages on the ASRock mobo.

This is a patch developed by @pupin (here), which is entered into the Clover Configurator ACPI secion: ACPI\DSDT\Patches. The problem is apparently "an uninitialized variable in Device(RTC) that makes OSX DSDT parser freak out." It seems to be a very clever and important contribution by @pupin allowing us to use this mobo. Thanks!

This code is already included in the attached Clover config.plist file.

          <string>Fix AsRock Z390 BIOS DSDT Device(RTC) bug</string>

The data entered into the Clover Configurator section Devices/Arbitrary and Devices/Properties (bottom), provide informational data for the Mac System Information windows.

These Arbitrary comments appear below in the System Information window under PCI. The Broadcom BT/Wifi controller is listed at the bottom of the above Clover Arbitrary section and at the top line below in the Mac. And the Realtek ALC1220 in the top line of the Properties section, appearing 3rd from the bottom below.


There are also some functional changes applied such as frame buffer corrections in the properties section, specifically using via "PciRoot(0x0)/Pci(0x2,0x0)". Without these comments (and data), you'd not get 4K out the HDMI port. These data also properly assign the correct ports to HDMI or DP.

However, if you're using a graphics card, and running Mojave 14.5, this section should be deleted. It is only important when solely using the iGPU.

The following Clover page, "Rt Variables", contains a value in the upper right, the CsrActiveConfig value. This value controls the System Integrity Protection (SIP). SIP is usually best kept disabled for Hackintoshes. 0x00 enables SIP, 0x67 is the value typically used to disable SIP (although some use 0x3FF). I've read several accounts that 0x3E7 may be better.

There are reports that 0x67 can cause Clover kext injection failures, and 0x3E7 does not. So I'm using 0x3E7 for now.

This window simply shows that the TB3 connection is working to activate the UAD Apollo x6 (it also works with the UAD Twin using TB2 through a TB3 dock). UAD seems to be very sensitive, so if the TB3 connection works with it, it works with just about everything else.

The present dock being used is a CalDigit TS3, listed above. This unit contains an SD card reader as well as various USB ports. I've got a Logitech C920S webcam attached to the dock. Both the card reader and the webcam are listed on the IORegistryExplorer Spoiler.

TB3 BIOS Settings (updated 5/25/19):


The above BIOS settings seem to work. However, after updating Clover, this BIOS page may need to be changed. It is not clear to me why this is. Sometimes, it only involves changing Thunderbolt Boot Support (highlighted above) from Disabled to Boot once, to get TB3 working again.


As KGP has said in his X299 build, if the PCI listing (described above in the System Information spoiler) properly shows the TB3 PCI items, then the SSDT TB3 file is working. If the SST TB3 file has loaded and is working and the TB3 device is not connected, it must be one of two things: the BIOS TB boot section needs to be changed or your TB3 device is not connected (turned off, un-plugged or broken).


As an aside, in the System Information image above, under Hardware, below the highlighted PCI section, you can see the item named Thunderbolt. This item seems to always be unpopulated on Hackintoshes, so don't fret about it. As long as the PCI section is properly populated as shown above, all is should be working well.

So it you have problems with a TB3 device, first look at the PCI listing to ensure that the SSDT TB3 file has properly loaded. If it has, make sure your device is turned on (some devices need to be on and connected before booting in the OS). If there is still no connection, then finally play with the TB BIOS settings to get the connection working (this latter step may require multiple re-boots to get things sorted out).

Most instances of using HWMonitorSMC2 on Hackintoshes do not show all available data, in particular, the voltage and fan data. When using the same sensor kexts on a recent Gigabyte Designare Z390 build, as are used on this ASRock build, the fan and voltage data were not displayed. However, on this build the fan and voltage data are properly displayed. This probably means it's the properties of this ASRock mobo that allow the sensor kexts to properly work.

The following is using FakeSMC with sensors (there is only 1 fan on the CPU):

The following is using a newly updated (5/19) VirtualSMC with its sensors (there is only 1 fan on the CPU):

General system benchmarks Geekbench (CPU – iGPU)​

Next, a Vega 56 graphics card was installed (PowerColor Vega 56 Nano, air cooled) and the CPU was over-clocked to 4.7GHz. No special settings were needed with Mojave 14.5 for the Vega 56. CPU temps went to 85°C and PD was 120W (the CPU is presently air cooled). No special voltage adjustments were made, so this was a quick test of simplified OC that was not optimized (in other words, there was possible throttling). Once an AIO is added, more robust over-clocking will be possible.

The only BIOS adjustment to enable the Vega 56 card was changing the pop-up for "Primary Graphics Adapter" from "Onboard" to "PCIe" (Advanced\Chipset Configuration). The iGPU was left "Enabled" on the same page. The Share Memory is was left at 256M.

General system benchmarks Geekbench (4.7GHz CPU – Vega 56)​

General system benchmarks Cinebench (4.7GHz CPU – Vega 56)​

The MSR 0xE2 register is used by real Macs for OSX XCPM power management. This register is writeable (not locked).

On Hackintosh mobos, this register is typically locked. If a kernel attempts to write to this locked register, a panic occurs, resulting in either a freeze or a re-boot. To avoid this problem, Clover uses patches. Some of those are shown below on the Kernel and Kext Patches page, where the KernelPm and AppleIntelCPUPM boxes are checked.

The ASRock Z390 Ph Gam ITX mobo has within BIOS a "CFG Lock" option. If set to "disabled", then the MSR 0xE2 is set to un-lock. This avoids panics allowing a write to occur at this register. The KernelPm and AppleIntelCPUPM boxes can then be left un-checked.

We want to therefore make sure that the CFG Lock is disabled (as below).

The attached Clover config.plist for the iMac19,1 for this build leaves these boxes un-checked. (If you do have the boxes checked, and the CFG Lock is disabled, you will not notice any panics.)

If the XCPM is properly loaded, you can verify by typing the following in Terminal.

type: sysctl machdep.xcpm.mode

This should give a value of "1"; this means the XCPM is active.

next, type: kextstat|grep -y appleintelcpu

This should give a blank (empty); this means the Apple Intel CPU management is not working.

Finally, type: sysctl -n machdep.xcpm.vectors_loaded_count

This should return "1", meaning that XCPM is properly loaded.

These findings were verified on this build and show that XCPM is working properly.

For native-like NVRAM, Clover's RC scripts can be deleted. To ensure their deletion, you can run the following from a Terminal window:

sudo rm -rf /etc/rc.boot.d
sudo rm -rf /etc/rc.shutdown.d

the following attempt to remove all Clover files for a fresh re-set
sudo rm -rf /Volumes/EFI/nvram.plist
sudo rm -rf /etc/rc.clover.lib
sudo rm -rf etc/rc.boot.d/20.mount_ESP.local
sudo rm -rf /etc/rc.boot.d/70.disable_sleep_proxy_client.local.disabled
sudo rm -rf /etc/rc.boot.d/80.save_nvram_plist.local

and finally, look for and remove this file: Library/PreferencePanes/Clover.prefPane

USBPorts is a method of limiting USB ports using only one kext file. It does not require USBInjectAll nor any Clover Boot arguments like uia_exclude=HS07. This requires changes to the config.plist (so a 2nd config.plist was uploaded) as well as a re-done kexts/other folder, which was also uploaded.

The advantage to this method is that while very mobo specific, it should be more resistant (more vanilla-like) to OS updates. Also, it does not require any Kernel and Kext Patches. Essentially USBPorts injects only the USB ports that you want and leaves all other ports disabled.

A disadvantage is it is a bit more awkward to edit, requiring Xcode or PLIST Editor to change values. The version I supplied in the upload turns on (and leaves off, along with items not even listed, such as USR1, etc) the following. [I attached an RTF text file so you can edit this as well. This file attempts to graphically represent the mobo.]


To edit, open the kext file (which is a folder) named USBPorts-z390-ASRock-PhGmITX-iMac19,1-v7 that is inside the kexts/Other folder.

Next, open the Info.plist file inside that folder with PLIST Editor. I also attached with the USBPorts folder, another copy of USB-Layout.rtf if you wish to edit and keep with your edited map kext file (folder) to better remember what changes you've made. (The image below has an older file name, but the idea for editing is the same.)


Once inside PLIST Editor, you'll see the following:

You can then selectively edit the USB entries. A few things to notice: this file is specific for iMac19,1. Change this value, such as iMac18,3, if you're using a different SYMBIOS like 18,3.

Editing specific ports requires setting the port number and its properties. HS01 and HS02 are best left as 255 rather than 0; this applies to HS14 that supplies the Wifi/BT module. SS07/SS08 are USB-C and is probably best set to 9. If you have trouble with wake/sleep disconnects, try 255 instead of 9 for these ports. All others function fine when set to 3.

The other thing to notice is how to count port numbers. HS01 to HS09 are <01000000> to <09000000>, HS10 to HS14 are <<0a000000> to <0e000000>, SS01 to SS09 are <11000000> to <19000000>, while SS10 is <1a000000>. The port-count is the last value of your USB selection. Below, the last port is SS08, so its value is used for the port-count, <18000000>. If you choose SS05 as your last value (leaving off SS07 and SS08), your port-count will be <15000000>.


Update: 14 July 2019:


On 14 July 2019, this kext file was updated to also include injection of SSP1 for activation of the USB-C port, which is part of the TB3 port. This section is named: iMac19,1-XHC5 as shown above and in greater detail below. This does not count as part of the 15 USB port limit, so do not erase or change it (if you want of change the "iMac19,1" part to another SYMBIOS, like iMac18,3, be my guest).


There are a few threads on the web regarding using no SSDT files for TB activation. The threads I read ended up dropping this and going back to an SSDT file. In testing on the mobo, with again Alpine Ridge, not the more robust Titan Ridge, this sans TB SSDT seems to be as affective and perhaps more reliable.

While setting it up, I decided to attempt to eliminate problems some have had with graphics cards and the iGPU (meaning to remove the iGPU's graphics properties in the Devices/Properties section). This led me to look at transferring the Realtek ALC1220 data from the Properties to the Arbitrary section as well as expanding on the various entries in the Arbitrary section.





The above entries lead to a detailed PCI section, which is more complete than most SSDTs. (The blue highighted entries are those associated with the dock attached through the TB3 port, and so are not described in any Arbitrary entries.)


The functionality of this method may better identify, without re-labelling, the IORegistryEntry objects. This would suggest this method, like the USBPorts, is more vanilla-like. Further investigation leads me to believe a combination of SSDT for TB and USBPorts injection through a kext is the best compromise.

IORegistryExplorer entries: no TB dock connected; then reboot, with TB dock connected. (Hot-plugging of dock is not available.) RP21 is the TB3 site on this mobo. The images below are, again, with no TB SSDT file.



LSPCI and Hackintools were used to identify the entries:


The following image is of the IORegistry TB section without any TB SSDT ("native" condition). TB3 connection does occur even under these conditions. UAD Apollo unit could not be hot-plugged. (I've found on an X299 system that in the native, the UAD could not be hot-plugged, but could with a proper SSDT. I'll hopefully post this X299 system in a new thread in the near future.)

After developing, through countless reiterations and reboots, a new TB3 SSDT, the following IORegistry image was obtained. It seems to accurately description the various branches: DSBx are within the mobo's system; "pic-bridge@x" are within the attached dock. The dock's branches do not have to labelled for hot-plugging of UAD Apollo on either the Z390 Designare or the X299 system I mentioned above. However, both of these other systems use Titan Ridge, not Alpine Ridge that is on the ASRock Z390 ITX mobo.

This latest TB3 SSDT for this mobo is attached below (as file: SSDT-Z390-TB3AR-ASRock-Z390-ITX-v3), but it too does not re-connect to the UAD Apollo unit if the UAD device is disconnected from the dock (hot-plugging). I think this must be a property (limitation) of Alpine Ridge.

If you're having trouble logging onto iCloud or the App Store, you probably have lost "en0", the main ethernet port configuration. (There a a few other problems that can prevent logging into iCloud or the App Store, but the one described here is a common, subtle cause that is easily remedied.)

The problem of no "en0" is found by looking at the System Information window, specifically the Network tab (a greater discussion of the System Information is in a spoiler above). Shown below is no en0 situation: there are en5, en2, en7, en8, en9 and en1, but no en0.

no en0.jpg

To fix this problem, you need to remove a NetworkInterface preferences file. The easiest way to do that is using the following command in Terminal:

sudo rm /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist

After copying and pasting the above command, press the Enter key. You'll then be asked to supply your password. Following this, you'll need to re-boot to enable the changes.

You can check the System Information Network tab again to verify the fix. Shown below is the corrected version of the above image, following a re-boot. Now, there's an en0 and you should be able to log into iCloud and the App Store.

restored en0.jpg

  • 19 May 2019: Added Clover config.plist file removing KernelPm and AppleIntelCPUPM (see Advanced: 0xE2 spoiler). Recommended to use after installation is working.
  • 20 May 2019: After discussion with @pupin (here), it seems best to change from OsxAptioFix2Drv-free2000.efi to AptioMemoryFix-64.efi + EmuVariableUefi-64.efi. Slide=0 is now not needed and was removed from the Clover config.plist files. The and the config files were updated.
  • 21 May 2019: Reduced the Clover config file to one, only providing for settings with CFG Lock disabled. Updated BIOS Spoiler images.
  • 22 May 2019: Added a simplified install Spoiler under the Initial Install - Seeding section.
  • 23 May 2019: Big update: ACPI/patched folder slightly changed and updated. The drivers64UEFI folder was simplified and updated to use several files developed by vit9696. In particular, AppleUiSupport supports FileVault2 GUI, hotkey parsing when combined with AptioInputFix. Additionally, AptioInputFix seems to give smoother mouse tracking. VirtualSMC.efi newly updated a few days ago, was tested and seems to work well. But this meant that the Kexts folder needed updating since FakeSMC doesn't play nice with VirtualSMC.efi. VirtualSMC.kext was used, along with some new sensors. The sensors report the number of fans more accurately than when FakeSMC was used.
  • 25 May 2019: Major overhaul as TB3 stopped working after I updated Clover to r4934. All seems to be working now, but TB BIOS was re-done as was the TB3 patched file. Also in Kexts/Other folder all items are stored there. None are now present in /L/E/ (remember to re-build the caches files with Kext Utility after removing any additions). Also updated was the config.plist file with minor changes (slide=0 was added back) and the Devices/Arbitrary section was updated to reflect an M.2 SSD in the front M.2 position.
  • 26 May 2019: AppleALC updated to 1.3.8; Lilu updated to v1.3.6; WEG updated to 1.2.9. Fixed HWMonitorSMC2 download.
  • 3 June 2019: Big update: ACPI/patched folder slightly changed and updated. A themes folder was uploaded which gives various Clover log-on screens with which to play. Most importantly, USBPorts system was added. This has been in the works for a couple of weeks, but took some time to polish. The update requires changes to the config.plist Boot section as well as the kexts/Other folder. Both of these changes were uploaded in addition to the old method which using USBInjectAll. See the above USBPorts spoiler for more information.
  • 5 June 2019: Correction of internal USB headers (thanks @pupin) as shown on the main mobo image at top of this post as well as a new kexts-USBPorts folder.
  • 9 June 2019: TB3 SSDT was re-worked, trying to make it as customized for this mobo as possible. Before booting the computer, you must have the dock powered and and devices like the UAD Apollo already powered and connected to the dock. These items and cameras, SD card readers connected to the dock will be connected on log-in to the computer. This SSDT will allow hot-plugging of a USB-C drive to the dock, but the dock itself cannot be un-plugged and re-plugged. (But does anyone really need to un-plug the dock?) One annoying issue is if UAD Apollo is turned off, it will not re-connect to the dock when turned back on. This may be related to the UAD driver, since a hard drive can be hot-plugged.
  • 12 June 2019: Notable update, removing Devices/Properties entries and significantly enlarging the descriptive Devices/Arbitrary section. The Arbitrary section now properly identifies the major entries seen in Hackintool's PCI section (as can then be viewed in the PCI section on the System Information page). Another notable change is removing any TB SSDT file. Even without the Arbitrary description, the TB3 port is active. See the above Look: No TB SSDT spoiler for more details. These changes are included the v2 of the NoSN-config-19,1 plist file, and an updated patches folder (v2). The patches folder change is simply to remove the latest SSDT-Z390-AR-TB3-ASRock-Z390-ITX.aml file. So for a basic EFI folder, I'm using v2 of the described patches and plist files attached below, along with the and the files. NOTE: these changes work best with Mojave 10.14.5 for optimal GPU recognition. Earlier OSX versions were not tested. For best sleep/wake function, set the Energy Saver settings as in this post here.
  • 17 June 2019: TB3 SSDT was re-worked once more in an attempt to get hot-plugging. Not successful, although the SSDT seems to be accurate for this mobo (see above TB3 SSDT Redux spoiler).
  • 30 June 2019: Made a slight change to Clover/Devices/Arbitrary for Broadcom description. It seems that have any data in this section can prevent the Wifi driver from loading. A new config file. was uploaded as V3 below. You can either disable this item or delete it. The remaining string values are useful to provide data in the PCI section of System Information. How this came about is that I noticed a lost of AirDrop, which turned out to be a loss of Wifi on the Z390 Designare build. I finally tracked the loss of Wifi to the DATA entries for the Broadcom Arbitrary description: so I'm applying this finding to the ASRock mobo.
  • 7 July 2019: Updated both Config.plists for better audio (thanks to work by moronim, here). One config.plist is for UIA (labelled -V2) and the other for the USBPorts (labelled -V4) methods of USB inactivation. These changes are in the Arbitrary section of Clover/Devices. Added trouble-shooting BT issues to above BT Spoiler.
  • 14 July 2019: Big Bastille Day update. Updated kexts, ACPI patched and drivers64UEFI folders to latest versions. Only USBPorts setup is supported. Updated config.plist file reflect USBPorts rather than SSDT-UIAC/USBInjectAll method for limiting USB ports. TB3 port now has USB-C working with complex, updated USBPort kext (called V7). The updated config is also called V7 as is the TB3 SSDT file: they all work together to keep the PCI system and USB-C functionality intact. All entries are for an iMac19,1 (and require input of your own SN, Board SN and UUIDs). The USB-C and TB3 still do not allow hot-plugging. Devices must be connected and turned on prior to boot. See this post for more details.
  • 19 July 2019: Update USBPorts injection and SSDT-TB3 for better SSP1 USB-C 3.1 functionality. USB-C via the TB port now runs at 10 Gbps, which is the speed spec'd by Intel for Alpine Ridge (theoretic is 22 Gbps but there are some other things going on, so Intel only guarantees 10 Gbps when used as a USB 3.1 port; see here near bottom of thread). Unfortunately, still cannot get hot-plugging to work; many variations tried. Also tried using USBInjectAll.kext (instead of USBPort.kext, but no UIAC SSDT) with together with Clover/Boot argument: uia_exclude=HS07;HS09;HS10;HS11;HS12;HS13;SS06;SS09;SS10;USR1;USR2. This set-up allows for same 10 Gbps speed but still no hot-plugging. Kext and SSDT-TB3 labelled V8.
  • 26 July 2019: Update AppleALC, Lilu and WhateverGreen kexts for Mojave 10.14.6. Pink lines are now removed during Apple progress bar boot.
  • 8 Sept 2019: Added Spoiler for Trouble Logging into iCloud.
  • 23 Sept 2019: Added BIOS image update, see thread post for that day, here.
  • 4 Oct 2019: While previously discussed in this mobo thread, an iGPU only config.plist file was not clearly presented since the first few posts. So below is a current iGPU only file (NoSN-config-iGPU.plist). The various kexts, drivers and ACPI files remain the same, using USBPorts. The file is for an iMac19,1 (and require input of your own SN, Board SN and UUIDs), and rename to config.plist before re-booting.


    6.5 MB · Views: 1,097
    23.3 MB · Views: 835
  • USBPorts-editing-in-PLIST Editor.jpg
    USBPorts-editing-in-PLIST Editor.jpg
    295.4 KB · Views: 1,791
  • USBPorts-USB port properties.jpg
    USBPorts-USB port properties.jpg
    137 KB · Views: 1,767
  • 1559749992216.png
    581.3 KB · Views: 4,191
  • Screen Shot 2019-06-30 at 10.17.41 PM.jpg
    Screen Shot 2019-06-30 at 10.17.41 PM.jpg
    148.7 KB · Views: 2,529
    652.7 KB · Views: 1,114
    141.8 KB · Views: 1,084
  • NoSN-config-19,
    3.6 KB · Views: 1,100
  • SSDT-Z390-ASRock-ITX-AR-TB3-V8.aml
    8.5 KB · Views: 1,505
  • USBPorts-z390-ASRock-PhGmITX-iMac19,
    5.8 KB · Views: 1,243
    4.7 KB · Views: 1,156
    35.7 MB · Views: 3,071
    3.5 MB · Views: 1,610
    9.7 MB · Views: 865
    9.8 MB · Views: 968
  • NoSN-config-iGPU.plist
    17.9 KB · Views: 1,245
Last edited:
Nice work @rj510 ! So I have a very similar setup as you (also SFF! I have a Louqe Ghost atm and also have a Dan A4 Case sitting on the shelf) and am curious if I can just throw in the TB3 SSDT and have TB3 working? Also can you clarify what the two extra SSDT's are for? The ones you labeled as "for power settings"? Thanks!
Awesome post~! I'm building my first Hackintosh and im going SFF with the same MOBO. I'm planning to swap the Wifi card too and was wondering why you would remove the MOBO battery when swapping?
Awesome post~! I'm building my first Hackintosh and im going SFF with the same MOBO. I'm planning to swap the Wifi card too and was wondering why you would remove the MOBO battery when swapping?

In the main mobo image above, in the upper left corner next to the BT/Wifi housing, the mobo battery is attached via red/black wires to a plug to the mobo. This can easily be unplugged while working on the PCB exchange, and then later re-plugged. If the battery is unplugged, the BIOS will re-set itself and require inputting current date and time information on re-booting the system. I think it easier to unplug the battery to give more freedom of movement while doing the PCB swap, as the two pieces of the housing are a little tricky to initially separate. However, you could dangle the housing from the battery wires, while working on it, leaving the battery attached to the mobo.

I should add some photos of the PCB swap itself, as PCB should not be all the way flush with the internal screw that holds the it in place inside the housing. Instead, there should be some space at the top of the PCB and this retaining screw, otherwise, the PCB will be too far from the surface of the mobo when the BT/Wifi housing is re-installed, and the PCB won't fully seat in its M.2 slot.
Nice work @rj510 ! So I have a very similar setup as you (also SFF! I have a Louqe Ghost atm and also have a Dan A4 Case sitting on the shelf) and am curious if I can just throw in the TB3 SSDT and have TB3 working? Also can you clarify what the two extra SSDT's are for? The ones you labeled as "for power settings"? Thanks!
Those are nice cases. I have a Dan A4 too, along with another one, that I've now described in the first post.

As for the TB3, if you're using this mobo and if your USB ports are properly delineated, then yes the SSDT TB3 file should work.

As for the patches for power management files, they were derived from an app called USBMap (by corpnewt). You can download it from here. These files help better manage wake/sleep issues, and possibly even shutdown problems.

Double-clicking on the USBMap.command file opens a Terminal window. Press the "U" key then the Enter key, and you'll see a listing for proper USB power management settings. If you use those extra SSDT files, all will return "True". If you've not used them, you'll see "False" for one or both. The app can write out these files, which is what I've uploaded. I did the write out from the ASRock mobo (what I posted is a sample done from my laptop, which I'm using as I write this). But in my testing, both of these SSDT files are the same no matter what mobo is used to create them.

This app can also be used to help refine the USB ports (but be careful if you turn off all ports and have no keyboard/mouse access; this is another reason I keep the boot drive externalized until all is working, before installing in the M.2 slot on the mobo). Googling on "USBMap" will lead to better understanding of how to use it.


  • USB-Map1.jpg
    156.1 KB · Views: 934
  • USB-Map2.jpg
    119.4 KB · Views: 914
Last edited:
Thanks for this comprehensive guide @rj510..
If I am using i5-9600K, should I adjust something rj?
Thanks for this comprehensive guide @rj510..
If I am using i5-9600K, should I adjust something rj?

Your CPU has the same UHD 630 as the i9-9900K. So the graphics section, the most critical, will be the same. I think the only change might be a cosmetic one regarding the CPU Type shown in the attached Clover page.

The type entered ("0x01005") is for an i9-9900K. This simply used to allow the About Mac menu item to displaying the correct processor type. It is informational only, not a functional issue. I would leave as is and see what is displayed. If not correct, then simply delete "0x01005" and leave blank (or possibly someone knows another value to try).

The short answer is all should work as is.


  • Clover_CPU_Type.jpg
    221.5 KB · Views: 851
Thanks @rj510. I will try that as soon as I receive the components :)
Hi! I have a nearly identical build (ASRock Phantom Gaming ITX and Intel 9900k) but I'm having trouble getting things to install. I've created a bootable USB using UnBeast; replaced the config.plist with the one you supplied; put the kexts in the 'other' folder and /Library/Extensions/ folder; followed your BIOS settings; and dropped in the drivers64UEFI stuff. But I'm getting seemingly random restarts when trying to install. Some times it will get all the way to where I can restart into the installer partition, but then it reboots. I've tried verbose mode, but it's restarting after it gets into the installer.
Hi! I have a nearly identical build (ASRock Phantom Gaming ITX and Intel 9900k) but I'm having trouble getting things to install. I've created a bootable USB using UnBeast; replaced the config.plist with the one you supplied; put the kexts in the 'other' folder and /Library/Extensions/ folder; followed your BIOS settings; and dropped in the drivers64UEFI stuff. But I'm getting seemingly random restarts when trying to install. Some times it will get all the way to where I can restart into the installer partition, but then it reboots. I've tried verbose mode, but it's restarting after it gets into the installer.

I'll try to help. My guide is mainly for an up and running system (where I 'seed' with a new EFI folder, a previously installed system---but I've added a simplistic Fresh Install guide in a Spoiler under the Initial Install - Seeding section---CaseySJ's thread I referred to earlier in that same section, also does a great job of describing how to make the USB Installer).

It's not clear exactly where you are in the install process. First off, what BIOS version are you using and have you adjusted the BIOS correctly (esp, the CFG unlock)? (It would be good to see all you BIOS settings if you are uncertain; take photos, compress a folder containing the photos and upload.)

Some re-starts are normal during an install. During one of them, you need to select the Mac install Mojave in the Clover boot-loader, rather than the boot drive to finish an install. I'm not clear at what stage you're at of the install.

And, are you using the iGPU or a graphics card (if the latter, which one)? Did you swap out the BT card (are your keyboard and mouse, hard wired)? Did you install the Patches folder inside the ACPI folder within Clover. This latter step is important to get the USB ports working correctly.

You might try adding to the boot arguments in the config.plist file: slide=0, debug=0x100, keepsyms=1.

Prior to the re-boot, is it stopping at the same place (when you say 'random' it makes me think it's stoping at different places)? (Also, maybe upload an image of the screen showing the verbose read-out.)

And which version of Mojave are you using?
Last edited: