Contribute
Register

SUCCESS: Asus prime Z370-A MK II + i5-9600K + Sapphire Pulse RX 580

Status
Not open for further replies.
Joined
Jul 17, 2019
Messages
123
Motherboard
Asus TUF Gaming Z590-PLUS WIFI
CPU
i9-10900K
Graphics
RX 6800 XT
Mac
  1. MacBook Pro
  2. Mac mini
Mobile Phone
  1. iOS
Aldaro's Classic Workstation: Antec SX1030b Restoration

280256_antec_sx1030b.jpg



ASUS PRIME Z370-A Motherboard
Amazon | Newegg

Crucial Ballistix Sport LT (16GB) x2 for 32GB Total Memory
Amazon | Newegg

Intel Core i5-9600K Processor
Amazon | Newegg

Cool Master Hyper 212 EVO CPU Cooler
No link available

Sapphire RX 580 Pulse 8GB Graphics Card
Amazon | Newegg

Samsung 970 EVO 500GB x2 ssd
Amazon | Newegg

Seasonic Focus PX-750 80+ platinum 750w Power Supply
No link available

Antec SX1030b Computer Case
No link available - this case is very old

Introduction
This build, for all intents, and purposes, represents a near spec for spec match to the 2019, 27 inch iMac. More specifically, the non custom configuration which uses the 9600k, and Radeon pro 580. The primary objective for this build, is to have a system which strikes a solid balance between reliability, cost, and performance. For the first two points, I'd say this build definitely meets expectations, and for performance, it actually pulls ahead of the iMac which I used as a reference. With Z370 having been released back in 2017, I don't think it is worth trying to find this board for two obvious reasons.
  • Finding this, and other Z370 boards has been quite difficult for some time now, and is only going to get actively worse.
  • Z390 no longer poses the same headaches that were present early on in the platform's lifecycle. As of writing this, coffee lake has been replaced by comet lake; so, if you're looking at a coffee lake build, I don't think there's a lot of time left before the only parts left are overpriced.
Because of the hardware I chose, I was very critical when it came to assessing just how well macOS ran, and overall, the end result is a pretty nice hack that, for the most part, hasn't left me with a sense that something is missing.

What's working?
  • Core macOS functionality
  • Graphics acceleration for both the RX 580 and UHD 630
  • Apple services; including iCloud, iMessage, FaceTime, calls using iPhone, etc.
  • Air Drop, Continuity, HandOff
  • Sidecar w/ Apple Pencil support
  • Native Wi-Fi & Bluetooth
  • Sleep/Wake
  • CPU power management
  • USB, including Fast charging, and USB 3.1 gen 2
  • and much more
What's not working?
  • As of 10.15.4, there appears to be issues with HDR displays upon waking from sleep. This seems to be an issue that effects regular Macs, as I'm experiencing the same problems on my MacBook Pro.
  • As an extension of the previous, the use of codeless kexts to fix the color profile will cause some displays to not work on a different connector type than the one which was used when you generated said codeless kext.
  • Some DRM content; however, this is definitely improving, and is much better than a few months ago.
  • USB 3.1 gen 2 often gets misreported as only functioning at 5 Gbps (rest assured that it is running at full speed).

Downloads
Here you will find all relevant files to my build. Please keep in mind that this is constantly updating; so, I encourage everyone to check back regularly to see what bugs have been reported, and fixed. A list of changes made to any of the attached files can be found below; however, if all you're interested in is downloading what I have attached to this thread, think of this blurb like a spoiler. Click the clover logo to download my clover EFI folder, and the OC logo to download my OC EFI folder. I previously had an "extras" attachment, but I didn't see it as support important to link anymore.

clover.png OpenCore logo
Clover 5.0-r5127 OpenCore 0.6.4
The Build

Motherboard

I chose this motherboard primarily for its well established macOS compatibility. It has been extensively tested by the hackintosh community and makes a great choice, especially if you’re working on your first build.
  • The Good. This board does not throw any punches; it sticks to the essentials, and therefor, setting up macOS is very easy. The addition of a dedicated ASMedia USB 3.1 gen 2 controller provides much more breathing room when it comes to that pesky 15 port per controller limit. On top of that, I've found that having two separate controllers is very helpful for devices like USB mics, audio interfaces, DACs, and even some external SSDs. Being a standard ATX board, there is plenty of expansion slots available to you.
  • The Bad. The onboard I/O, and more specifically the rear I/O, is very basic, and you may find yourself pressed for connectivity options. While you still get things like USB, and audio headers, it would’ve been great to see a little more options around the back. This board also does not handle overclocking too well. Now sure, it can do it; however, you won’t be setting any records here, and I wouldn’t try to overclock an i9 on this thing.
CPU
With the release of the early 2019 iMac, Apple added proper support for desktop coffee lake CPUs, and therefor, getting a reliable macOS install became much easier. This CPU works well for what I’m doing with this machine, and on top of that, this particular chip is found in one of the stock iMac 19,1 configurations.

Heatsink & Fans
Because I’m not really overclocking, the Cooler Master Hyper 212 EVO was a great choice. Considering the cost, it does a pretty decent job at keeping this i5 cooled in a case where air flow is a little sub par. For thermal paste, I decided to get some thermal grizzly, as I wanted the best results possible. The case fans are nothing special, but they suffice. One major drawback to this case is that smaller fans are needed for proper airflow, and therefor this thing is pretty loud.

Graphics Card
For a few years now, native support for the RX 580 has existed in macOS, and with the use of other Polaris GPUs on other Macs, these drivers seem to get a lot of attention from Apple. This results in a reasonably stable driver that just works with few issues to speak of, but it’s definitely not without flaw. As for the Sapphire Pulse itself, this particular RX 580 was used by Apple in one of their dev kits, and was also the basis in which the macOS RX 580 driver was built.

Power Supply
I’ve had the Focus PX-750 for a little while now and it is rock solid. It can pump out more than enough power for my build, and the 80+ platinum certification is a nice display of its capabilities.

Case
The Antec SX1030b is an old home server case and places a lot of emphasis on the HDD bays. Drives can easily be slid in, and out of the front drive bays, as to allow one to replace a bad drive on a moments notice. I went with this case, as it was something that I already had, and I couldn’t justify purchasing yet another PC case (especially since I’ve got some empty ones).

Wi-Fi/Bluetooth
In an effort to keep things simple, and ensure compatibility, I chose a BCM94360CD. This particular card is found in some Macs and can be installed in pretty much any modern PC with a simple PCIe x1 adapter. Features like Air Drop, continuity, handoff, and sidecar work as expected. To top it off, this card doesn't require the use of any fixup kext to get its features working correctly.

Ethernet
The idea of placing a gigabit Ethernet card in one of your PCIE slots seems absurd in 2020; however, for the sake of compatibility, that’s exactly what I did. The Intel i210 is natively supported in macOS, as this particular controller is found in some thunderbolt docks; one example would be the CalDigit TS3+. This card works exactly as you’d expect it to, and I can even use it in recovery for things like restoring from time machine backups. This card can be somewhat overpriced at times, and I think for most, the onboard LAN will work just fine. That being said, if you need ethernet connectivity, and have concerns about kext injection randomly breaking, the i210 will definitely provide some peace of mind.

Chapter I - Installation

Prerequisites

  • Access to a Mac to download and create the bootable USB installation drive
  • AUSB flash drive with at least 16 GB of storage, as to accommodate the larger installer size seen with Big Sur.
    • tip: using a separate USB drive for the bootloader will make the whole process a lot easier, as the macOS install drive does not need to be modified; however, this'll require you to copy a pre-existing UniBeast folder, or create a clover folder from scratch on the secondary drive's EFI partition.
  • Some macOS nohow goes a long way here. If you've worked with Macs and macOS in the past, this will be noticeably easier for you.
  • A solid chunk of free time. This is especially true for newcomers, as mistakes can easily be made, and you'll want to have enough time to troubleshoot, and debug your problem.
Section I - UEFI Settings
For this board, there aren't a whole lot of things that need adjustment; however, you want to make sure to check the following
  • Advanced
    • CPU options
      • Intel virtualization technology (VT-x) > Enabled
        • System agent configuration
          • VT-d > Leave this disabled in the beginning, but know that it can be enabled later on without problems.
          • Above 4G Decoding > Enabled
          • Primary display > PCIE - only applicable for those using DGPUs
          • GPU Multi Monitor > Enabled > This will enable the IGPU and allow for features like Intel QuickSync to function correctly.
          • DVMT Preallocated Memory > 64 MB should be more than enough
    • PCH Configuration
      • IOAPIC 24-119 entries > Enabled
      • USB configuration > USB Mouse and Keyboard simulator > Disabled - this should fix XHCI Handoff
  • Boot
    • Fast boot > Disabled
    • CSM compatibility module > Disabled - Few modern operating systems will actually need CSM support; moreover, leaving it enabled can cause some weird behavior. It's best practice to disable it.
    • Secure boot > Enabled - I think this is a bug, but for some reason, it cannot be disabled; however, it doesn't have an impact on macOS anymore.
    • OS Type > Other OS - NOTE: There are some instances in which running macOS in "Windows 10 mode" could provide some benefit, but for this case, we'll keep it simple.
You'll notice I didn't mention CFG lock, and that's due to the fact that it is disabled by default when you load the optimized defaults. If you have XMP memory, make sure you enable all relevant settings.

Section II: Creating the macOS installation drive
Regardless the bootloader you wish to use, the first step is to create a bootable macOS installation drive. To accomplish this, open Disk Utility, and select "Show All Devices" within the view context menu. This will allow you to see physical devices with their partitions and logical volumes.

Screen Shot 2020-04-15 at 3.06.05 PM.png


You should now see your flash drive and its associated partitions. Select the drive, select erase, and make sure the format is set to "Mac OS Extended (Journaled)". If you have multiple SSDs in your build, please do NOT use the default name of "Untitled" (especially if one of those SSDs contains a Windows installation). While macOS will enumerate the Volume name, as to avoid having drives with the same name, that enumeration will not be visibly obvious in finder, and running the below command with "Untitled" set as the target volume can potentially blank out your Windows drive. You either need to check the enumeration, or just choose a different name to prevent this from happening.

Screen Shot 2020-04-15 at 3.07.31 PM.png

Once the drive has been formatted, open up a Finder window, navigate to /Applications, and make sure you have "Install macOS <version name goes here>". If you don't see it, try downloading it again from the App Store. Right click on the app, select "Show package contents", and navigate to Contents > Resources. In this folder, you'll see a command line executable named "createinstallmedia". Open the terminal, and drag, and drop the createinstallmedia executable onto the terminal window to auto-fill its path. All that's left to do, is to append --volume /Volumes/"YOUR VOLUME NAME HERE" to the command, and it should be good to go. The final command should look something like this:

Bash:
sudo /Applications/Install\ macOS\ Catalina.app/Contents/Resources/createinstallmedia --volume /Volumes/volumename

For this example, I'm using Catalina since I generally like to wait until a new release of macOS has received at least one, or two major "point" updates before I make the jump on my main drive. I can confirm that these general instructions are exactly identical for Big Sur; so, it's just a matter of replacing the name. The quality of your USB drive will have a significant impact on the time it takes to create your bootable installer; so, don't use something cheap, as it won't only be slow, but you may face issues with the installer files becoming corrupted. Once the process finishes, your shiny new installation drive should automatically mount.

Section III - setting up the bootloader
Here is where you'll spend a significant portion of your time. It is absolutely vital that you configure your bootloader correctly, as failing to do so will result in a system that won't be able to boot. In the past, I kept the scope of this thread limited to clover; however, OpenCore's relevance cannot be ignored, and as such, it needs to be covered.

Picking a bootloader
I know someone is going to mention some obscure bootloader from years past, but today there are two main bootloaders to choose from; Clover, and OpenCore. I have tested these bootloaders and they both work with the latest version of macOS (for now that is). They each have their strengths, and weaknesses; so, let's do a quick comparison.

Clover
Between the two, Clover is still the most widely used; though, I'm not sure how much longer that'll remain true with OpenCore quickly gaining ground. Clover sits at the core of Unibeast and Multibeast for more recent versions of macOS, excluding Big Sur. Because it has been around a long time, there's a chance that any issue you're experiencing has already been solved by someone else with a similar configuration.

Pros
  • Compared to OpenCore, Clover is much easier to setup and configure. Installer packages are made for each revision, and these packages can additionally be used to update the bootloader. This holds true for those who have a Multibeast setup, but require a newer Clover revision; a good example of this would be upgrading from Catalina to Big Sur.
  • Clover is way more forgiving when it comes to minor mistakes in your config. Because there exists a set of assumed default behaviors, you could have some pretty large pieces missing from your config, and still have a rock solid setup.
  • IRQ conflicts can be easily patched via a series of boolean fixes within the ACPI section of your config. There are other boolean values that, when set appropriately, can replace some of the SSDTs you'd need for OpenCore (e.g SSDT-PLUG).
  • A number of temporary changes can be made to your config from the boot picker. This goes beyond changing boot args, and while I can't mention all of them, here's a quick list of some of the things that you can alter
    • DSDT IRQ fixes
    • DSDT hotpatches (e.g enabling or disabling device renames)
    • Quirks (r5120+)
    • Some device properties (e.g setting a fake PCI device ID)
    • kext injection (i.e enabling or disabling certain injected kexts)
  • Multibooting isn't as messy
Cons
  • I can only speak from the perspective of an English speaker, but official documentation is not good, and you'll likely be relying on what you can find from other forum threads.
  • There's a reason Multibeast isn't updated with every clover revision. Each revision of Clover is a bit of a wildcard; you have no idea if a new release is going to be stable. The best way to try to avoid buggy Clover revisions, is to look at the degree of changes made since the previous; for example, r5104 was the first of the C++ builds ... it was a mess.
  • Up until recently, Clover relied on old XNU zombie code for kext injection; however, the issue of reliance on old macOS zombie code goes a bit further than that
  • The code base is somewhat bloated. This results in either half baked features, random breaking of already existing features, or both with each revision. FixOwnership had been broken for several revisions now, and it was just fixed with the release of r5127.
While still perfectly functional today, Clover is definitely past its prime, and will likely be surpassed by OpenCore.

OpenCore
What makes OpenCore different, especially compared to clover, is that it has been designed with security and quality in mind, allowing for the use of many security features found on real Macs, such as SIP and FileVault. A more comprehensive look can be found here. Yes, this is pretty much word for word from the dortania github.io page, and there's a reason for that; it's clear, as well as accurate. For the pros and cons, it'd be perfectly sufficient to copy paste what's already there, but nonetheless, I want to highlight a couple from each category.

Pros:
  • Better security overall, as you don't need to disable SIP, FileVault is natively supported, and proper support for secure boot.
  • Faster boot times due to the reduction of unnecessary patching
  • Vastly superior kext injection; even with clover implementing OC's kext injection, it still falls short of OC itself.
  • While not super specific to this build, OC supports more versions of macOS than Clover. This is worth noting since recent builds of clover seem to have dropped decent support for releases older than 10.11
  • Official documentation is incredibly good
Cons:
  • OpenCore is far less forgiving when it comes to config.plist. If there's anything missing, you won't be able to get anywhere. Fortunately, there are tools out there to help you through the process.
  • No IRQ conflict patching; instead, you'll need to use something like SSDTTime in order to yield the same results.
  • No macOS only ACPI patching ... and this is what makes multibooting with OC a bit more frustrating
Another very important thing to take note of with OpenCore is that kext support for all acidanthera extensions (e.g Lilu, VirtualSMC, WhateverGreen, etc) will become exclusive to OC. This doesn't mean that they'll stop functioning under Clover; however, compatibility with Clover will not be tested, and there's a chance these extensions may break on Clover sooner than some would like.

EFI PARTITIONS: Mounting, and mounting, and other general information
If you wish to use one of my attached EFI folders, all you need to do is copy the extracted folder called "EFI" to either your Install macOS, or isolated USB drive. The size of an EFI partition can vary, but it seems that Disk Utility will default to 209.7 MB. For the few people who care, the acceptable range for an EFI partition is 100 MB to 550 MB. I've seen guides which, despite using OpenCore, still instruct people to download Clover Configurator for the purpose of mounting, and unmounting EFI partitions. This is completely unnecessary, as this can not only be done in the command line, but it can also be done with other tools that you're more likely to use anyway (e.g hackintool). EFI Agent is an app that takes the "Disks" section of hackintool, and shrinks it down to something which can comfortably fit in a menu bar application; so, if you want something lightweight, it's a good option for you.

Hackintool
Select "Disks" in the main toolbar; you'll be presented with a list of all detected EFI partitions in the first table, and the second will contain a list of all disks with their respective partitions. This even includes any disk image you may have mounted; so, for the sake of decluttering, unmount any unnecessary disk image, and while we're at it, eject any irrelevant drives.
Screen Shot 2020-12-04 at 11.07.01 PM.png

You'll notice that I do not have an install macOS USB drive connected, and that's, because I like to isolate my bootloader to its own drive. From the top table, we can easily see that our bootloader USB is disk5 and its EFI partition is disk5s1. Simply right click disk5s1 in the second table, and you should see a mount option at the top of the list. Assuming it's not greyed out, select it, and enter your admin password to mount the partition. Once mounted, hackintool will display the mount point for your EFI partition. /Volumes/EFI is the default; however, if you mount multiple EFI partitions, the others will be enumerated to avoid conflicting names. Unfortunately, this enumeration is NOT represented at all in the Finder for some reason, and you'll have to switch on over to the terminal in order to properly see this. That said, I strongly recommend you only have a single EFI partition mounted at a time to avoid careless mistakes. Fortunately, the same right click menu provides an unmount option as well; I know, obvious statement, but it's still worth mentioning.

Command line
macOS contains several command line utilities for handling disks and disk images, but for now we only need to focus on diskutil. For a lack of better words, this is basically a command line version of disk utility, but with some additional functionality. Like before, we need to determine the disk, as well as partition number associated with our USB drive and its EFI partition.
Bash:
$ diskutil list
You should get some output that resembles the following
Code:
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *4.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         4.0 TB     disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +4.0 TB     disk1
                                 Physical Store disk0s2
   1:                APFS Volume Files HD                1.0 TB     disk1s1

/dev/disk2 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *512.1 GB   disk2
   1:           Windows Recovery                         554.7 MB   disk2s1
   2:                        EFI NO NAME                 104.9 MB   disk2s2
   3:         Microsoft Reserved                         16.8 MB    disk2s3
   4:       Microsoft Basic Data                         511.4 GB   disk2s4

/dev/disk3 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk3
   1:                        EFI EFI                     209.7 MB   disk3s1
   2:                 Apple_APFS Container disk4         499.9 GB   disk3s2

/dev/disk4 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +499.9 GB   disk4
                                 Physical Store disk3s2
   1:                APFS Volume Macintosh HD - Data     166.6 GB   disk4s1
   2:                APFS Volume Preboot                 92.4 MB    disk4s2
   3:                APFS Volume Recovery                529.0 MB   disk4s3
   4:                APFS Volume VM                      3.2 GB     disk4s4
   5:                APFS Volume Macintosh HD            11.1 GB    disk4s5

/dev/disk5 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *4.1 GB     disk5
   1:                        EFI EFI                     209.7 MB   disk5s1
   2:       Microsoft Basic Data CLOVER                  3.9 GB     disk5s2
If you're new to macOS, you may've noticed that APFS volumes have a separate entry that is completely different than their associated physical disk. APFS is a containerized filesystem that allows for volumes within a container to dynamically share space. This has many practical use cases, but just to site a very relevant example, this is what allows macOS to cleanly separate the system and data partitions, as these partitions can dynamically resize within the APFS container. I point this out, because it's important to note which disks represent a physical drive, synthesized volume, and disk image.

Like the hackintool example, our USB drive is disk5, and its EFI partition is disk5s1. To mount this partition simply use diskutil mount.
Bash:
$ sudo diskutil mount /dev/disk5s1
That's all there is to it. Because the EFI partition is mounted as a volume, you can additionally unmount it by referring to the volume name if you want. Both commands are listed below.
Bash:
$ sudo diskutil unmount /dev/disk5s1
$ sudo diskutil unmount /Volumes/EFI
I strongly recommend you stick with the more traditional command, as volume names can sometimes conflict, and cause some odd consequences.

Required files for both bootloaders
Regardless of which bootloader you choose, there are a number of additional files that are required for both to function correctly, and successfully boot macOS.
  • Kexts
    • Lilu.kext - Provides a platform that allows for arbitrary kext, library, and framework patching.
    • VirtualSMC.kext - Emulates AppleSMC (this replaced FakeSMC).
    • WhateverGreen.kext - Lilu plugin that provides GPU patches for a fair number of GPUs.
    • AppleALC.kext - Lilu plugin that enables native HD audio on codecs not officially supported by Apple.
    • IntelMausi.kext - Enables support for some Intel ethernet controllers (not required if you're using an i210).
  • ACPI files
    • SSDT-EC.aml - This provides macOS with the necessary EC device in order to boot. Do NOT USE other common alternatives, such as SSDT-EC-USBX.aml, or other variations of SSDT-EC; they will not work. The file I provided ensures that this motherboard's EC0 device does not get initialized by macOS. If EC0 is detected by macOS, an incompatible driver will attach itself to this device that can cause all kinds of weirdness with your build. While on this topic, I want to reiterate the following point; do NOT RENAME EC0 TO EC. While this file is included in my EFI folders, I felt it was important to directly link it for those who will not be using any of the attached EFIs.
    • SSDT-USBX.aml - Defines USB power properties to enable fast charging for iPhones, iPads, and other devices that support it. Some USB devices that require a little extra power will not function without this file. If you plan on using my USBPorts.kext, you do not need SSDT-USBX.aml, as the power properties are already defined in the kext.
    • SSDT-PLUG.aml (OpenCore only) - This is the equivilent to clover's generate PluginType option, and as such, will provide proper CPU power management. This can be used in clover as well if you wish to omit the generate PluginType option from config.plist.

STRONGLY RECOMMENDED - creating a separate bootloader drive
There are many reasons to keep the bootloader on its own drive; the biggest one being that you do not need to modify your Install macOS USB drive, and it can therefor be used on a real Mac. Attempting to boot clover on a genuine Mac will result in said Mac turning into a fancy brick; so, don't do it (you have been warned). Of course, you also get the main partition of the drive to store whatever tools you need, which will definitely be helpful should you find yourself without an internet connection during the initial phase of post install. Setting up this separate drive is very easy.

Disk utility drive preparation
  1. Open disk utility
  2. In the top left hand corner, just below the close, minimize, and maximize buttons, you should see a button labeled view; click it, and make sure "show all devices" is selected.
  3. Once you see your flash drive, select it from the left hand menu, and click erase to reformat the drive. I recommend using FAT32, labeled as MS-DOS (FAT) in Disk Utility, as EXFAT has some major corruption issues, and FAT32, having been around a long time, is generally considered to be good when it comes to compatibility. If you're using a larger drive, be aware that FAT32 can only store files that are smaller than ~4 GB. The name of the drive is completely arbitrary and is entirely up to you to decide. I recommend not using something super generic, as names like "untitled" are often the default when nothing is entered, and having multiple volumes called "untitled" can potentially result in some applications (especially the macOS installation create media tool) to overwrite the wrong drive when reformatting.
  4. Once the drive has finished formatting, the main volume should be mounted by default. Before running the clover package, make sure that an EFI partition was created on your USB drive. This may seem obvious; however, there are cases in which older drives seem to have trouble writing said partition during formatting. If this is the case for your drive, find a different one to use.
Section IIIa - setting up and configuring clover
These instructions are relevant for the latest versions of macOS Big Sur, Catalina, and Mojave. Starting with the release of clover r5120, the clover devs have been integrating more, and more parts of OpenCore directly into clover itself. Some people are calling this hybrid thing CloverCore, but I'm not going to weigh in on that one.
  1. Grab the clover installation package. This is a direct link to the stock release assets found on the CloverHackyColor GitHub page.
  2. Unmount any EFI partitions you may have currently mounted. The clover installation package will automatically mount the EFI partition of the target drive upon completion.
  3. Open the clover installer and proceed up to the prompt that gives you the option to customize your installation.
  4. Click Change Install Location, select your USB drive, and click continue.
  5. Because the stock clover package's default options aren't ideal for today's hacks, click customize, and select the following options
    • Clover for UEFI booting only
    • Install Clover in the ESP
    • Drivers off (optional)
    • expand UEFI Drivers
    • Uncheck Recommended drivers
      • expand File System drivers
        • ApfsDriverLoader
        • VBoxHfs (alternative, Apple's HFSPlus EFI driver can be used, but it is not included)
      • expand Memory fix drivers
        • OpenRuntime - This is the ONLY memory fix driver present in r5127
    • Alternative screenshot view
  6. That's it ... you don't need much at all; click install, and the whole thing shouldn't take longer than 2 minutes.
  7. Add the required kexts to EFI/CLOVER/kexts/Other and the aml files to EFI/CLOVER/ACPI/patched.

config.plist setup and optimizations - If you wish to skip the details, replace the stock config.plist with the one included in my EFI folder, or another config file that you know works with your hardware. Even if you're using a lot of the same components that are listed in this build, minor differences can have an impact on your config. That being said, the included config.plist should work for most who are using this board, or even Z370 in general. Now that you have everything in place, it's time to reboot, and give your installer a shot. Weather you opted to keep everything on a single USB drive, or isolate the bootloader to its own drive, the macOS installation process should be pretty uneventful assuming all goes well.

Section IIIb - setting up and configuring OpenCore
While I strongly urge you to read the OpenCore vanilla guide, we will be using a tool called OC-Gen-X to make the setup process easier. While far from being a substitute for reviewing the OC guide, and performing an extensive manual setup, this tool significantly reduces the potential for human error, and increases the likelihood of having a working OC setup the first time round. Because I feel it is required, here is the obligatory disclaimer of “I am not associated with this project and cannot guarantee its stability”. This setup process will follow similar logic to installation method #2; so, please have a look at that before continuing onward. Of course, you don’t need to pay attention to the clover specific details, but become comfortable with the idea of compartmentalizing your boot loader away from your macOS installation USB drive. Click the OC-Gen-X logo bellow to download the application.
ocgenx.png
System Type
Upon opening the application, you’ll be presented with a section in which you must specify a platform type. For this build, you want to select coffee lake.
Screen Shot 2020-08-31 at 1.50.06 PM.png

kext
In the “kext” tab, you’ll see multiple sub tabs in which you can select any number of kernel extensions you may need for your system. The extensions you’ll find throughout these tabs are among the most common, and should be perfectly sufficient for getting your build up, and running.

Essential
Starting with essential, Lilu and VirtualSMC are already selected by default. There’s a reason this tab is called essential, as without these extensions, we wouldn’t be able to get anywhere; so, leave them selected.​
Screen Shot 2020-08-31 at 1.50.36 PM.png
VirtualSMC Plugins
For VirtualSMC plugins, desktop users only need SMCProcessor, and SMCSuperIO. The remaining two plugins are exclusive to laptops, and can therefor be ignored.​
Screen Shot 2020-08-31 at 1.50.51 PM.png
Graphics
WhateverGreen is the only extension you’ll find under graphics, and while it’s not technically required, it’ll save you a lot of headaches, especially when it comes to the hybrid dGPU + IGPU combo used in this build. In real iMacs, Apple makes use of both the onboard Intel UHD graphics, and a dedicated GPU to squeeze out some extra performance, as well as improve the overall user experience. After WhateverGreen is checked, you can specify some additional boot arguments. In this example, I added “igfxframe=0x3E980003” to properly define the IGPU platform ID. This can be used to replace a device property entry; however, you shouldn’t use the boot arg long term.​
Screen Shot 2020-08-31 at 1.51.46 PM.png
Audio
The audio tab is nearly identical to graphics; the only extension here is AppleALC, and it is required if you want your onboard audio working in macOS. Once selected, you can specify additional boot args. Just like before, we can pass in an argument (alcid=7) that temporarily allows us to skip over adding a PCI device property entry. Your layout ID will likely be different if you are using a different motherboard, but if you’re using the PRIME Z370-A, layout 7 is what you’ll need.​
Screen Shot 2020-09-01 at 8.15.59 PM.png
Ethernet
There are 5 extensions to choose from under the ethernet tab, and the only one you’ll need (assuming you’re using the onboard LAN) is IntelMausi. If you picked up an i210, you won’t need any additional ethernet drivers, as this controller is already supported natively in macOS.​
Screen Shot 2020-08-31 at 1.52.17 PM.png
USB
Under USB, the only extension you’ll find is USBInjectAll. This kext attempts to inject properties for all ports on specific controllers, and when combined with the port limit patch, will make every USB port on your system visible to macOS. I’ll say it now, and I’ll say it again; please do NOT use the port limit patch as your solution for USB. While OC’s port limit patch is a bit cleaner than what you’d find in clover/the original KextToPatch method, the port limit patch cannot guarantee that the port limit is removed from all parts of macOS in which it is defined. Furthermore, having more than 15 ports per controller will cause USB ports to pop up outside the expected memory addresses macOS reserves for USB; which, you guessed it, can result in generalized system instability. If you plan on using my USBPorts.kext, you don’t need to add USBInjectAll.​
Screen Shot 2020-08-31 at 1.52.25 PM.png
Because this build does not require any additional Wi-FI, or bluetooth kexts, those tabs will not be covered, but for those who may need some additional extensions for Wi-Fi, you have a few options available in the appropriate tab.

Firmware Drivers
The defaults predefined for Firmware Drivers are correct, and you do not need to make any changes. OpenRuntime.efi can sort of be equated to the old AptioMemoryFix, and of course HFSPlus.efi is needed in order to boot from HFS+ formatted drives. Notice that ApfsDriverLoader.efi is absent, and that is because it is now built-in directly to OpenCore.
Screen Shot 2020-08-31 at 1.52.42 PM.png

SMBIOS
For SMBIOS, please review the idiot’s guide to iMessage linked at the bottom of this thread, as I will not be covering how to generate SMBIOS information in this thread. That being said, it is a good idea to have SMBIOS information prepared ahead of time, as it’ll make setting up your Apple services substantially easier. The fields are self explanatory here.
Screen Shot 2020-08-31 at 1.53.03 PM.png

Additional BootArgs
For the final tab, Additional BootArgs, you can specify the usual -v debug=0x100 and keepsyms=1 like you would in clover. I’ve noticed that the boot args defined sometimes become formatted incorrectly in the final config; so, we’ll review everything in a bit. Aside from that, we’re now ready to hit the lovely generate button to get our EFI folder. Assuming all went well, you should see an “EFI generation complete” dialog, and your new EFI folder should now be on your desktop.
Screen Shot 2020-08-31 at 1.53.41 PM.png

Pretty nice, right? Resist the urge to copy the freshly generated folder to your USB drive, as there are a few things that need to be done. Because they were directly specified, the kexts are automatically placed in EFI/OC/kexts, but the SSDTs needed are not automatically downloaded for you, and we therefor need to get them ourselves. The two most important SSDTs are SSDT-EC.aml and SSDT-PLUG.aml. SSDT-EC.aml provides macOS with the required EC device and SSDT-PLUG addresses power management. Unlike clover, there are no config.plist options to generate things like Cstates, or PluginType; so, we need something like SSDT-PLUG.aml to fill that hole. You can find these SSDTs in my OC EFI folder, and of course, the OC vanilla guide. SSDT-USBX.aml defines USB power property values, and is good to have for those using USBInjectAll.kext. These values are defined within the USBPorts.kext; so, this SSDT becomes redundant for those using my port map, or once you have successfully generated your own.
Screen Shot 2020-08-31 at 1.54.56 PM.png

Once downloaded, place these SSDTs in EFI/OC/ACPI. Unlike clover, all kexts, EFI drivers, tools, and ACPI files must be defined in your config.plist; failing to do so will result in OC not loading them, and obviously, we want them to load. To automate the process of adding all appropriate entries to config.plist, you can use ProperTree, or OpenCore configurator to add these items to your config. In this guide, we’ll be using ProperTree, and I recommend you do so too, as OpenCore configurator can cause issues with your config. You can download an archive of the ProperTree GitHub master branch by clicking here. Once downloaded, you’ll find two app build scripts in the scripts folder. For the sake of compatibility, I went with the python2 command. All you need to do, is double click whichever script you wish to use, and a ProperTree application bundle will be generated in the main ProperTree folder. At this point, you can move it to your Applications folder if you wish to do so, but it is not explicitly required.
Screen Shot 2020-09-01 at 9.03.47 PM.png

ProperTree is a very basic plist editor, but it’ll get the job done; moreover, it can be used cross platform for those who need something on Windows, or Linux. Open your OC config.plist with ProperTree and press command + shift + r to perform a clean snapshot. Select EFI/OC and proper tree will find all files that need to be specified in your config. The below screenshot reflects some of the changes made during the snapshot; notice how the ACPI files are now present in our config, and if we were to scroll down towards the bottom, our EFI drivers are now present as well.
Screen Shot 2020-09-01 at 9.24.58 PM.png

There are a few additional config.plist changes that need to be made, but they’re pretty minimal. You can use ProperTree for these as well; however, I’m going to switch over to a more polished plist editor for the remainder of this guide.

config.plist edits

Booter > Quirks
Expand Booter > Quirks; Because this motherboard doesn't seem to support MATS correctly, we need to change the following quirks. That said, if anyone doesn't have issues with MATS on this board, please drop a comment.​
  • EnableWriteUnprotector - TRUE: This quirk permits write access to UEFI runtime services code via bypassing RX runtime permissions. More specifically, disabling the write protection bit on CR0 register. This has the downside of weakening overall firmware security; so, that's something to keep in mind. If you have a different board that supports MATS, please leave this disabled.
  • RebuildAppleMemoryMap - FALSE: This quirk generates a memory map that is compatible with macOS. The memory map CANNOT exceed 4096 bytes, as the kernel maps it as a single 4 KB page. Because this quirk is heavily dependent on memory attribute table permissions, it doesn't work well with this particular board.
  • SetupVirtualMap - FALSE: This quirk is generally not needed on newer boards which have memory protection such as OVMF.
  • SyncRuntimePermissions - FALSE: Some firmware fail to properly handle runtime permissions, and by extension, incorrectly mark OpenRuntime as non executable in the memory map, as well as the memory attribute tables. This quirk is almost always used in combination with RebuildAppleMemoryMap.
Kernel > Quirks
Expand Kernel > Quirks; Here's where OpenCore gets a leg up over clover's ease of use; these quirks represent some of the most common kernel and kext patches that you'd otherwise have to manually specify. For us, I want to highlight three of these.​
  • AppleCpuPmCfgLock > FALSE: Disables PKG_CST_CONFIG_CONTROL (0xE2) MSR modification in AppleIntelCPUPowerManagement.kext. Because this motherboard allows us to set CFG lock without any headaches, we don't need this quirk. If your board does require it, please review the steps for disabling CFG lock in firmwares where it is hidden.
  • AppleXcpmCfgLock > FALSE: Companion to previously listed quirk; again, we don't need this since we can just disable CFG lock
  • XhciPortLimit > FALSE: If you have a USB map, please disable this quirk. This is the USB port limit removal patch, and while it is a bit cleaner than those used in the past, you should still never use this as a long term solution.
Screen Shot 2020-09-01 at 9.28.27 PM.png
NVRAM > 7C436110-AB2A-4BBB-A880-FE41995C9F82
The three highlighted keys boot-args, csr-active-config, and prev-lang:kbd are left blank by default. While this shouldn’t cause problems, it’s generally a good idea to correct these. Sometimes OC-Gen-X inappropriately concatenates boot arguments that should be separated with spaces; so, double check that your specified boot args are in order. Csr-active-config often causes a lot of confusion, because it seems to be a moving target. Here are some examples and what these values do​
  • 00000000 - SIP enabled: This enables all components of SIP; which, is something that is perfectly doable with OpenCore.
  • E7030000 - SIP practically disabled: You're probably more familiar with this value in the form of 0x3E7, and while this does effectively disable SIP, it is now considered deprecated.
  • 67000000 - old SIP mostly disabled: More commonly recognized as 0x67, this value has also been deprecated
  • 77000000 - SIP fully disabled: This is the NVRAM value that gets set whenever you boot a real Mac into recovery and issue the command csrutil disable.
It is also perfectly valid to leave csr-active-config blank, as you can technically set it in recovery. This is technically the preferred way of changing SIP status in OC. Finally, prev-lang-kbd defines a keyboard layout. This value can be entered as either a data, or string value.​
Screen Shot 2020-09-01 at 9.33.31 PM.png
PlatformInfo > Generic
The two values we need to concern ourselves with here are ROM and SpoofVendor. It isn't always required to set a value for ROM, but if you need to set it, use the MAC address of your primary network controller (typically en0). SpoofVendor should speak for itself.​
As far as we're concerned, that's it; however, please run your config through the OpenCore sanity checker once you finish, as OC-Gen-X has sometimes had broken releases. If, for example, you tried to use it when 0.6.3 was first released, you probably got a kernel panic. This panic was due to the generated config missing a boolean value in the UEFI dictionary, and remember; OpenCore ASSUMES NOTHING!

Section IV - First boot initial setup
The actual installation process itself is boring and is the exact same as it is on a real Mac; just don't forget to format your internal drive. Once you wait for paint to dry, you should be greeted with the usual macOS setup prompts. If you didn't generate unique SMBIOS information, do NOT ATTEMPT TO LOG IN to your AppleID; it will fail. Just skip over anything AppleID related during initial setup and address it later.

Hooray, we're finally at a macOS desktop! If you decided to go with one of my EFI folders, the experience you have OOB should be pretty decent, and it's now a matter of copying the EFI folder from your USB drive over to your internal drive to make macOS properly bootable.

At this point, we have completed macOS installation with our bootloader of choice, and have placed an EFI folder on the physical drive in which macOS is installed; so, we no longer need our USB drive, as booting off the internal SSD should be just fine.

Chapter II - post installation optimizations
Here's where the fun really begins. While the provided EFI folders should provide a fairly nice experience, everyone's setup is different, and there are likely changes that need to be made. I'm going to try to address a broad range of topics, as to provide some better insight into the process; so, you're not just left hanging with an EFI folder without knowing how to customize it, or properly troubleshoot problems that may arise.

Sleep:
As we would expect with this kind of a build, sleep works perfectly fine, but there are tweaks you may need to make in order to prevent some rather annoying bugs. Starting things off in the "Energy Saver" tab in system preferences, we have some obvious changes.
Screen Shot 2020-12-06 at 8.01.28 PM.png

  • If left enabled, "Wake for ethernet access" will almost always cause your system to immediately wake from sleep. This is especially problematic if you're using a natively supported ethernet controller such as the i210.
  • Enable power nap > disabled: This feature allows macOS to utilize time machine, as well as receive iCloud notifications while the system is asleep. Unfortunately, leaving this enabled will result in the dreaded "darkwake" problem, and in addition to that, it doesn't really work on hacks anyway.
  • Put hard disks to sleep when possible > disabled**: So this has a lot to do with the SATA controller, and some of the odd things that could occur, as remember, the 200 series PCH SATA controllers are technically unsupported. The real 2019 iMac uses a variation of the 100 series PCH and its SATA controller. This is also true for the 2017 iMacs; however, the simple addition of SATA-Unssuported.kext seems to smooth things out a bit by giving the device some valid properties instead of leaving us with "Generic AHCI controller". Where problems really start to arise, is whenever you have a SATA based optical drive connected to your system since macOS attempts to initialize it as a hard drive. I have no idea why this occurs, but nevertheless this resulted in macOS "putting the drive to sleep" and subsequently panicking when it couldn't wake it back up. Fortunately, this is easy to work around with the PowerTimeoutKernelPanic quirk that has now been ported over to Clover. Unfortunately, the issues don't stop there; Finder can randomly become unresponsive, and upon shutdown, the menu bar will disappear, but the dock will remain present. File management starts really acting up, and you are left with no choice, but to hard reset, or shutdown your system.
While the laptop interface for this section has changed significantly in Big Sur, the desktop energy saver settings remain exactly the same.

Devices > properties table
XML:
       <key>Properties</key>
        <dict>
            <key>PciRoot(0x0)/Pci(0x1F,0x3)</key>
            <dict>
                <key>layout-id</key>
                <data>BwAAAA==</data>
            </dict>
            <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
            <dict>
                <key>AAPL,ig-platform-id</key>
                <data>AwCYPg==</data>
            </dict>
        </dict>
This table is setup in nearly the exact same way for both clover and OpenCore; so, a lot of this information is interchangeable to fit your bootloader of choice. This is the correct location for defining attributes about PCI devices, and is also used by WEG for IGPU configuration. The IGPU properties in my config.plist should be reasonably compatible for those who are using a dedicated GPU, and a 9th gen cannon lake CPU. 8th gen CPU users MUST use a different platform ID in order for your IGPU to function correctly. The raw XML uses base 64; so, entering something like 0x3E980003 is not correct if you're editing this file with a standard text editor, which is generally not recommended. If you're using clover configurator, these values MUST be entered hex swapped. Here is a small comparison of the main platform IDs you may end up using:
Code:
//coffee lake 9th gen IGPU (headless)
0x3E980003 - standard hex
0300983E - hex swapped
AwCYPg== - base64 swapped

//coffee lake 8th gen IGPU (headless)
0x3E920003 - hex
0300923E - hex swapped
AwCSPg== - base64 swapped

//coffee lake IGPU is primary graphics device
0x3E9B0007 - Hex
07009B3E - Hex swapped
BwCbPg== - base64 swapped
If you're using the IGPU as the primary GPU, there are additional steps you'll probably have to take in order to get everything working correctly; a good example would be defining your motherboard's GPU connector types. Failing to do this often results in erratic behavior, and ports that just flat out don't work. At the end of this thread, I have a link to the hackintool release thread, which provides a good starting point for correctly patching your IGPU framebuffer.

In my config, I also provide another PCI entry for the onboard audio controller. There isn't much to be said about this entry, as it only requires a single attribute for our purposes. This attribute, layout-id, you guessed it, is used to set your AppleALC layout ID. This motherboard uses layout 7, and is written as 07000000, as similar to the IGPU properties, any DATA values must be entered hex swapped.

Section II. - SMBIOS:
As mentioned above, the serial number in the prebuilt EFI WILL NOT work, and is only in the config to satisfy a requirement. At the bottom of this thread, I have provided a link to the idiot's guide to iMessage, which should be more than sufficient to get your Apple services working. Spoiler ahead; because this motherboard has working NVRAM, you do not need to go through the extra steps in the iMessage guide to see if the SMUUIDs you generate are useable, they are (you're welcome). For simplicity, both clover, and hackintool can generate S/Ns; however, it is not recommended that you use clover configurator for this purpose, as nobody exactly knows how it does the generation.

Section III. - USB mapping:
The USBPorts.kext found in my EFI folder will ONLY work for those using the iMac19,1 SMBIOS, and even then, there's a good chance that you have your internal headers hooked up to your case differently. By default, USBInjectAll.kext is enabled in both EFI folders in conjunction with the port limit patch. The easiest way to go about port mapping is to use hackintool, as it will generate an injector kext, as well as a compatible SSDT for USBInjectAll; however, the former is vastly superior to the latter. Make sure you're using a modern version of hackintool to do the mapping, as newer kexts will contain a PCI property match. This is important for this board, as the ASMedia controller uses the generic ACPI name of PXSX.

NATIVE USB AT THE ACPI LEVEL
So, you have your injector kext, and everything works great, but perhaps you want to slim down on the number of extensions that you need to inject. The common codeless injector works by attaching itself to AppleUSBHostPlatformProperties.kext and assumes the structure of said kext remains the same. There are 2 major issues with this approach
  • Any structural changes to this kext's info.plist will cause your injector to break, as well as USBInjectAll, to some extent, and without your injector, all your ports on this motherboard will show up as internal.
  • In keeping with the vanilla spirit of things, I prefer to keep the system's setup as close to the real iMac19,1, and if we look at the defined SMBIOS definitions within the kext, you'll notice iMac 19,1, and 19,2 are absent. Interestingly enough, the new 2020 iMacs made their way into this kext.
That leaves us with one option; implementing native USB at the ACPI level. I will NOT BE COVERING the basics of how to extract, and disassemble your ACPI tables, as that's a reasonable prerequisite for this process.

STEP 1: Identifying where your USB port properties are in your ACPI tables
I wish I could tell you that there were a shortcut to make this easier, but there isn't, and you just have to go with process of elimination. That being said, the enumerated SSDTs will sometimes have names that can tell you which ones do not include USB properties, but this can sometimes be misleading. Because I already know my setup, I know that the file I need to edit is SSDT-4_xh_rvp08. While highly discouraged, this particular file can be edited directly without disassembly, and it does not rely on other OpCodes found within other SSDTs.

STEP 2: Review SSDT and attempt compile WITHOUT any changes
This may seem quite obvious, but you want to make sure your OEM SSDT can compile as is. If it compiles, great; however, if it doesn't, then you have some debugging on your hands, because mine compiles without requiring any kind of additional work, we can get straight into the meat of things.

Taking a quick look at this SSDT, we can see a bunch of external calls to Devices defined in the DSDT, which is to be expected. Along the side, we will find every scope definition, which, we can easily access by a single click. Within the scope "Scope (\_SB.PCI0.XHC.RHUB)", you need to locate the methods GUPC, and TUPC.

STEP 3: Add additional methods for USB3 and type-c if needed.
The native OEM GUPC method defines an internal USB connector, whereas TUPC defines USB 2.0 type-A. We know this based on the second item in PCKG for both methods. GUPC being 0xFF and TUPC being Zero. You'll notice that the hex values for connector types are identical to what you'd see in your injector kext, and SSDT-UIAC. What we need to do, is create additional methods for USB3 Type-A, as well as USB-C if needed. Don't worry, this isn't as hard as it sounds; we can simply copy paste our GUPC method under TUPC, and make the required modifications to set the right connector types.
Code:
        Method (GUPC, 1, Serialized)
        {
            Name (PCKG, Package (0x04)
            {
                Zero,
                0xFF,
                Zero,
                Zero
            })
            PCKG [Zero] = Arg0
            Return (PCKG) /* \_SB_.PCI0.XHC_.RHUB.GUPC.PCKG */
        }

        Method (TUPC, 1, Serialized)
        {
            Name (PCKG, Package (0x04)
            {
                One,
                Zero,
                Zero,
                Zero
            })
            PCKG [One] = Arg0
            Return (PCKG) /* \_SB_.PCI0.XHC_.RHUB.TUPC.PCKG */
        }
        Method (XUPC, 1, Serialized)
        {
            Name (PCKG, Package (0x04)
            {
                Zero,
                0x03,
                Zero,
                Zero
            })
            PCKG [Zero] = Arg0
            Return (PCKG) /* \_SB_.PCI0.XHC_.RHUB.GUPC.PCKG */
        }
Confusing? Let's look at this code in some more detail. Because the intel controller on this board doesn't have any USB-C ports, no methods are needed for those connector types. The ASMedia controller pretty much has all of its methods in the DSDT, and therefor, making any modifications to it would be impractical. In the above code sample, I grabbed my OEM GUPC, and TUPC methods, and added another method underneath called XUPC. Let's have a look at that method on its own.
Code:
        Method (XUPC, 1, Serialized)
        {
            Name (PCKG, Package (0x04)
            {
                Zero,
                0x03,
                Zero,
                Zero
            })
            PCKG [Zero] = Arg0
            Return (PCKG) /* \_SB_.PCI0.XHC_.RHUB.GUPC.PCKG */
        }
You might be looking at this and asking yourself, "Hey, isn't that just the same code used for the GUPC method"? That's because it is, but with only two modifications; first, we can't reuse the name GUPC, and given this method will define USB3 Type-A, I figured XUPC would be fitting. Last, the second value in PCKG was changed from 0xFF to 0x03 to represent the correct connector type. That second value is key, because it allows us to easily define the connector type for the given method; now, if you've already done USB mapping, you probably already know what the values are for the most common connector types. If you need a USB C method, you'd simply replace 0x03 with 0x09, or 0x0A.

STEP 4: Disable unused ports
Now it's time to do our map; first, we can easily disable ports that we do not need. For this, let's use HS01 as an example. Every port in this SSDT is defined within its own scope; which, makes this kind of change very easy. Here is the OEM code for HS01
Code:
    Scope (\_SB.PCI0.XHC.RHUB.HS01)
    {
        Method (_UPC, 0, NotSerialized)  // _UPC: USB Port Capabilities
        {
            Return (GUPC (One))
        }

        Method (_PLD, 0, NotSerialized)  // _PLD: Physical Location of Device
        {
            Return (GPLD (DerefOf (UHSD [Zero]), One))
        }
    }
We have two methods; _UPC (USB port capabilities) and _PLD (Physical Location of Device). Looking at _UPC, we can see that it returns (GUPC (One)). This indicates that this port is internal, and is active. To deactivate the port, all we need to do is change (GUPC (One)) to (GUPC (Zero))
Code:
    Scope (\_SB.PCI0.XHC.RHUB.HS01)
    {
        Method (_UPC, 0, NotSerialized)  // _UPC: USB Port Capabilities
        {
            Return (GUPC (Zero)) //was previously One
        }

        Method (_PLD, 0, NotSerialized)  // _PLD: Physical Location of Device
        {
            Return (GPLD (DerefOf (UHSD [Zero]), One))
        }
    }
Repeat this for all ports you wish to deactivate, and don't forget to keep that 15 port per controller limit in mind. This is why I highly recommend you first get your USB working via an injector kext before attempting this. You can use the injector kext as a guide to tell what needs to be deactivated, and what ports need other modifications.

STEP 5: Set appropriate connector types
As you go through deactivating ports, you'll quickly notice that _UPC always returns (GUPC (One)). This is what causes all of your ports to show up as internal to macOS. To fix this problem, we need to change GUPC in the return statement, to the method which corresponds with the connector type we need for our specific port. On this motherboard, the ports HS13, and HS14 are the two physical USB2 ports located on the rear I/O; so, we need to replace GUPC with TUPC in order for macOS to see the right connector type. Here's what that looks like.
Code:
        Scope (\_SB.PCI0.XHC.RHUB.HS13)
        {
            Method (_UPC, 0, NotSerialized)  // _UPC: USB Port Capabilities
            {
                Return (TUPC (Zero))
            }

            Method (_PLD, 0, NotSerialized)  // _PLD: Physical Location of Device
            {
                Return (GPLD (DerefOf (UHSD [0x0C]), 0x0D))
            }
        }
Wait a minute ... why are you setting the return statement for TUPC to be Zero? This has to do with how TUPC is defined above. To start, let's look at the following from GUPC.
Code:
PCKG [Zero] = Arg0
... and here's the same statement, but from TUPC
Code:
PCKG [One] = Arg0
Whenever a value is returned to TUPC, it is instead sent to the second value in PCKG; which, based on the code sample above, defines the connector type, and not the active status. This is only applicable for TUPC; everything else returns to the first value of PCKG for other global UPC methods. With that out of the way, lets proceed!

Now it's time to put our new method to work and see how it holds up. When defining a USB3 port, the same rules apply regarding the connector type; that is, the USB2 personality of a USB3 port must be defined as USB3 via the appropriate method. On this motherboard HS05/SS05, and HS06/SS06 are the two USB3 ports that sit below the USB2 ports on the rear I/O. Like the USB2 port, we need to replace GUPC with the appropriate method name; in this case, that'd be XUPC (the method we just added).
Code:
    Scope (\_SB.PCI0.XHC.RHUB.SS05)
    {
        Method (_UPC, 0, NotSerialized)  // _UPC: USB Port Capabilities
        {
            Return (XUPC (One))
        }

        Method (_PLD, 0, NotSerialized)  // _PLD: Physical Location of Device
        {
            Return (GPLD (DerefOf (USSD [0x04]), 0x05))
        }
    }
Now for the USB2 personality; remember, USB3 ports gain their backwards compatibility by having separate sets of pins for the different standards, and that's why you need to use the USB3 connector type.
Code:
    Scope (\_SB.PCI0.XHC.RHUB.HS05)
    {
        Method (_UPC, 0, NotSerialized)  // _UPC: USB Port Capabilities
        {
            Return (XUPC (One))
        }

        Method (_PLD, 0, NotSerialized)  // _PLD: Physical Location of Device
        {
            Return (GPLD (DerefOf (UHSD [0x04]), 0x05))
        }
    }
Repeat this process for the ports you wish to use, compile your SSDT, and place it in the appropriate directory on your EFI partition for patched ACPI files (I assume that by this point you already know this).

STEP 6: Drop tables
In order for this SSDT to load, you must drop the original OEM table. In our case, this is SSDT-4_xh_rvp08 and you can find the required drop table markup in my configs for both bootloaders. They're disabled by default; for clover, simply uncomment the "DropTables" dictionary under ACPI, and in OpenCore, you'll find an entry under ACPI > Delete, just change "Enabled" to TRUE. Like every other SSDT, you need to tell OpenCore to load this patched file. Like the drop table example, I already have an entry for this in my OC config under ACPI > Add; just save the patched SSDT as "SSDT-XHC.aml", and you should be good to go. If you are building your own config, here are the drop table entries you'll need.

Clover:
Code:
<array>
    <dict>
        <key>TableId</key>
        <string>xh_rvp08</string>
        <key>Signature</key>
        <string>SSDT</string>
    </dict>
</array>
</plist>

OpenCore:
Code:
<dict>
    <key>All</key>
    <true/>
    <key>Comment</key>
    <string>DropXhc</string>
    <key>Enabled</key>
    <true/>
    <key>OemTableId</key>
    <data>eGhfcnZwMDg=</data>
    <key>TableLength</key>
    <integer>0</integer>
    <key>TableSignature</key>
    <data>U1NEVA==</data>
</dict>
</plist>
Please keep in mind that I am in no way an ACPI expert; however, I wanted to share something I learned, as well as provide another way for setting up USB on your builds!

OC EFI folder
December 19th, 2020 - OC 0.6.4

OC has been updated to release version 0.6.4, and as such all relevant changes to OC are also reflected in this version of the folder. This release addresses even more compatibility issues people were having with Big Sur. There's not much to place in a bulleted list; however, I realized I'd made a major mistake with my 0.6.3 folder. I left my drop xh_rvp08 entry enabled, and as such, there's a good chance those who used the folder experienced significant issues. I have addressed this oversight with this newer revision.

November 25th, 2020 - OC 0.6.3
OC has been updated to release version 0.6.3, and as such all relevant changes to OC are also reflected in this version of the folder. This release addresses compatibility issues people were having with Big Sur; most notably, an issue in which codeless injector kexts would not load correctly
  • Added SSDT-XHC.aml to /EFI/OC/ACPI: (disabled by default) - This is meant to serve as a reference for my USB map in native ACPI form. I strongly recommended you avoid using this file, but it's there for those who just want to wing it.
  • Added SSDT-XHC.aml to config.plist > ACPI > Add: (disabled by default) - provides the appropriate entry for SSDT-XHC.aml to load should you wish to use it.
  • Added entry to config.plist > ACPI > Delete (disabled by default) - This, when enabled, will drop SSDT-4_xh_rvp08.aml.
  • Booter > Quirks: disabled RebuildAppleMemoryMap, SetupVirtualMemoryMap, and SyncRuntimePermissions - Because, in my configuration that is, EnableWriteUnprotector is required for the system to boot. This seems to indicate an issue with MATS support. If you encounter early stage boot failures, ReEnable some, or all of these quirks.
  • All kexts were updated to current release versions.
September 9th, 2020 - OC 0.6.1
OC has been updated to release version 0.6.1, and as such all relevant changes to OC are also reflected in this version of the folder. One of the biggest changes is the requirement of needing to specify a kext's architecture when adding it to config.plist. If you have any problems, please refer to the OC vanilla guide for more information. Here is a list of changes that were made.
  • Added missing SSDT-HPET.aml to OC/ACPI. This file is disabled by default, and should only be used in conjunction with my SSDTTime patches (which must also be manually enabled).
  • Switched config settings to reflect the default use of USBInjectAll.kext. My port map is still present, but is disabled by default. The builtin port limit removal patch was enabled for the sake of making mapping easier. You can attempt to use my port map; however, there's a strong chance that your USB port setup doesn't match mine (especially when it comes to the front/internal headers).
  • All kexts were updated to current release versions.
  • Added CtlnaAHCIPort.kext to OC/Kexts directory. This is in preparation for macOS Big Sur, as SATA-Unsupported.kext seems to have stopped working due to the removal of a class definition in Apple's AHCI extension. Of course, this new kext isn't needed in older versions of macOS; so, it'll only be loaded if OC is booting Big Sur.
August 31st, 2020 - OC 0.6.0
OC has been updated to release version 0.6.0, and as such all relevant changes to OC are also reflected in this version of the folder. If you have any problems, please refer to the OC vanilla guide for more information. Here is a list of changes that were made.
  • Included SSDTTime DSDT patches - These are disabled by default, and must be enabled by editing the config. While these may work for some of you, it is highly recommended that you run SSDTTime yourself, as the required patches may differ based on your individual hardware, UEFI version, and more.
  • OpenCanopy enabled by default - The image resources are included; however, the audio files for AudioDxe are not; so, please make sure to grab them before trying to use AudioDxe.
  • Removed unnecessary tools - this was done to clean up the boot picker, and yes, NVRAM reset is still functional. If you need the tools, please download the OC release ZIP and copy them over.
  • kext updates for all essential extensions - I think this is pretty self explanatory.
  • Included USBInjectall and enabled port limit patch - Please do not use this long term, as you could face stability problems down the road. My USBPorts.kext is still present, but you'll need to enable it in config.plist. Make sure you disable USBInjectall.kext if you wish to use my USBPorts.kext, as the two will conflict.
  • SSDT-USBX.aml is present once again - While power values are present in my USBPorts.kext, this SSDT will define correct power values for those using USBInjectall.kext.
  • In the original 0.6.0 upload, I had accidentally left SSDT-HPET.aml active and forgot to include SSDT-USBX.aml. If you downloaded the original file, please see the updated link, as I have corrected this issue

May 28th, 2020 - OC 0.5.8
OC has been updated to release version 0.5.8, and as such all relevant changes to OC are also reflected in this version of the folder. If you have any problems, please refer to the OC vanilla guide for more information. Here is a list of changes that were made.
  • Removed ApfsDriverLoader.efi - This efi driver is no longer needed, as it is now built in to OpenCore itself.
  • Removed NdkBootPicker.efi - While an excellent graphical boot picker, I wanted to stick with stock OC files.
  • Added OpenCanopy.efi - This is the official graphical boot picker included with OC, and more closely resembles Apple's stock boot picker.
  • Updated kexts to latest version
NOTE: Please be sure to run SSDTTime to improve stability, power management, and other quality of life aspects of your build. The clover ACPI fixes are not represented in the same way in OpenCore, and as such, the best way to get them back is via SSDTTime.

May 14th, 2020 - OC 0.5.7
This is the first finished version of my OC folder for this particular build. Please keep in mind that I'm still relatively new to this bootloader, and how it works; so, please keep this in mind. Feedback is greatly appreciated. From RC2,
  • Added NdkBootPicker.efi - this will present a graphical boot picker instead of builtin text-only one.
  • Disabled SSDT-USBX.aml - this SSDT is redundant, as USBPorts.kext contains power values. It may; however, be re enabled for those who wish to redo port mapping.
The clover IRQ fixes are not present in OC's config, and as such, they need to be applied differently. Please follow the instructions for patching out IRQ conflicts using SSDTTime. For more general information, please refer to the OpenCore vanilla guide.

Clover EFI folder
December 2nd, 2020 - Clover r5127

This is a minor revision to my recently uploaded Clover EFI. The package installer should now work correctly on Big Sur, and as per this compatibility update, I just wanted to update my EFI folder to the latest build of Clover as well. Some functionality has been restored; things like FixOwnership should now function correctly, as well as a few additional properties that broke during the move to an OpenCore base.

November 25th, 2020 - Clover r5126
Clover has received a significant number of changes since my last major update to this thread. While I did attach a copy of r5122 awhile ago, I did so silently, as I didn't think it was stable enough at the time. Starting in r5125, Clover began using OpenCore's kext injection; in fact, Clover has integrated a lot of OpenCore's code into Clover itself.
  • Supports Big Sur: - This includes the installation environment, and while things may seem to crash at times during installation, they haven't, and you should be able to work your way through the install process as you normally would.
  • Replaced AptioMemoryFix.efi with OpenRuntime.efi - In the current r5126 installer, OpenRuntime is the only memory fix driver available as an option, as every other memory fix driver has been deprecated.
  • Added Quirks dictionary to config.plist - Earlier implementations of OpenRuntime for clover had a separate plist file for OcQuirks, but it has finally made its way into the main config. This dictionary is now REQUIRED in order for clover's memory fix driver to work correctly. The quirks available to us are a mix of OC's booter, as well as kernel quirks.
  • Selected available quirks that are closest to what's being used in OC EFI: - This gets a separate entry; so, I can stress an important point. Do NOT USE configurator to edit this section. In traditional clover configurator fashion, the app will exclude any quirks that are not explicitly defined. This is a problem, as the default behavior for OcQuirks can change pretty frequently, and with the clover wiki being a bit cryptic, it's better not to assume anything in this section. Another thing to watch out for, is even if you do not touch the quirks section when working on your config in configurator, the app will still rearrange the order of the quirks dictionary.
  • Added complete set of FakeSMC extensions to kexts/off: - Some Mojave users may wish to use FakeSMC for its better sensor support, and while I have gotten this to work on Catalina, and Big Sur, I don't recommended you use it on either of those two versions.
  • Added ACPI/off directory: - This is for the purpose of including option ACPI files that some may wish to use, such as SSDT-XHC.aml.
  • Added DropTable entry required for SSDT-XHC to work: (disabled by default) - Here's another example where you must stay away from configurator. I achieved this behavior by commenting out the DropTables section in config.plist. The big issue with configurator, is that it does not seem to understand sections which have been commented out, and trying to add the appropriate entry for DropTables will result in a duplication of the markup in your config, making it quite messy.
  • All kexts were updated to current release versions.

Additional resources
There's only so much I can cover in this one post, and I strongly urge everyone to go through at least some of these resources
An idiot's guide to Lilu and its plugins
The New Beginner's Guide to USB port Configuration
An Idiot's Guide to iMessage
Hackintool release thread
Official Clover GitHub repository

Conclusion
As far as I can tell, everything that'd you'd see on a hackintosh stability, and functionality checklist works perfectly on this setup. Overall, this is a very stable build, and makes for a good first hackintosh for those who are just getting started. As stated above, there are a lot of resources out there that really make this whole process a lot easier.

Screen Shot 2020-04-15 at 4.31.06 PM.png

Screen Shot 2020-05-09 at 3.40.37 PM.png
 

Attachments

  • Screen Shot 2020-04-15 at 3.06.05 PM.png
    Screen Shot 2020-04-15 at 3.06.05 PM.png
    687.6 KB · Views: 203
  • Screen Shot 2020-04-15 at 3.06.05 PM.png
    Screen Shot 2020-04-15 at 3.06.05 PM.png
    687.6 KB · Views: 189
  • Screen Shot 2020-04-15 at 4.07.47 PM.png
    Screen Shot 2020-04-15 at 4.07.47 PM.png
    390.3 KB · Views: 2,937
  • Screen Shot 2020-05-06 at 11.04.45 AM.png
    Screen Shot 2020-05-06 at 11.04.45 AM.png
    536.6 KB · Views: 174
  • Screen Shot 2020-05-06 at 11.04.45 AM.png
    Screen Shot 2020-05-06 at 11.04.45 AM.png
    536.6 KB · Views: 1,887
  • SSDT-EC.aml
    196 bytes · Views: 446
  • Screen Shot 2020-05-06 at 11.04.45 AM.png
    Screen Shot 2020-05-06 at 11.04.45 AM.png
    536.6 KB · Views: 712
  • OC-0.6.3.zip
    2.8 MB · Views: 276
  • EFI-r5127.zip
    4.4 MB · Views: 408
  • EFI-0.6.4-RELEASE.zip
    2.8 MB · Views: 542
Last edited:
Thanks for the build Aldaro! I'm in the process of doing something very similar: Z370 A Prime (not MKII), i7-9700K and RX 580 Pulse. I was wondering if you knew if your EFI folder could work. That would save me some time!

Also, I've seen you're using SMBIOS 19,1 for the i5-9600K, do you think it would be applicable as well to my i7? I've seen mixed reports about it.
 
You're welcome, and my EFI folder should yield good results for your build. Looking at Apple's site, I think iMac 19,1 is the way to go. While an i7 9700k is not a configurable option, the presence of an i5 9600k, and i9 9900k indicates that this CPU should work well for this particular SMBIOS. iMac 19,2 can work for CPUs with locked multipliers, but even then, there aren't any 9th gen options available for this specific Mac. Moreover, the Radeon pro 580X found in one of the stock configurations of iMac 19,1 is nearly identical to the RX 580 (even going as far as to share the same shortened PCI device ID). In addition to this, it shares the same framebuffer identifier with the RX 580, ATY,Orinoco. I gathered this information from the system information app on a real iMac 19,1, and for my reference, exported some of the file's contents.
 
Thanx so much Aldaro, it all seems very promising! I'm considering to move to a RX5700, because my RX580 Pulse literally just stop working properly (hardware problem with the fan controller), but now you praised the RX580 so much, I might be considered an used RX580... Time will tell!
 
If you need better performance out of your GPU, I'd step things up to the 5700 XT. That being said, on my 2019 MacBook Pro, the navi drivers are a nightmare.
 
That's exactly my dilemma for these last few days (luxury problems, mind you). I don't need more GPU perf, I guess the most demanding games I'll be playing in 2020 are Wasteland 3 and Anno 1800, so not that much power hungry, though I need to display them on a 2560x1440 (working setup has 2 of these). I was just stepping up to the 5700 series to have a lasting GPU, i didn't want to buy a 580 now and change it in 2 years because macos doesn't support it anymore... And to be honest people seem to be 50/50 divided on the subject subject, some have a perfectly functioning 5700 (lilu+weg), and for others, it is not the case at all.
Would you care to extend a little bit on the nightmare aspects of the navi drivers on your macbook ?
 
It's been a few years since my last hackintosh, so it's time for me to build a new one and update to Catalina. Your components were similar to the ones I have decided upon, with the exception of the Prime board instead of yours.

Has the other poster found this to be successful while using your instructions?

Where in the BIOS menu is the CFG lock? There seems to be a good deal of confusion from other threads in locating it.

Also, curious about the i5 vs i7. And your RAM is no longer available but had been updated-will this still work in your opinion?

Thanks for a concise, well written guide.
 
Last edited:
This was the RAM suggested by Amazon as a new version/replacement for the link in the original poster's spec list:

Crucial Ballistix 2666 MHz DDR4 DRAM Desktop Gaming Memory Kit 16GB (8GBx2) CL16 BL2K8G26C16U4B (Black)


Thanks for letting me know, and good luck on your install.
 
Also, any concerns about this? I found it when putting the build together on PCPartsPicker:

Warning!Some Intel Z370 chipset motherboards may need a BIOS update prior to using Coffee Lake Refresh CPUs. Upgrading the BIOS may require a different CPU that is supported by older BIOS revisions.
 
Status
Not open for further replies.
Back
Top