Currently the only motherboard not supported at all is the B550 boards from AMD, they require a KVM to operate.
Recent developments have resolved this issue with SSDT-CPUR, see OpenCore Install Guide for more info (opens new window)
So with motherboards, the main thing to keep in mind is what controllers your system is running, specifically:
- Audio Interface Controller
- Networking Interface Controller (Ethernet)
- USB Controllers
- RTC vs AWAC
- Memory Maps and Protections
And in regards to AMD and Intel motherboards:
- Different brands have different levels of support, however overall all brands are boot-able assuming you're OK with tinkering (mentioned below).
- Pretty much all AMD motherboards are unfavorable due to the numerous hacks required to boot (opens new window), however the brand itself won't affect support very much with macOS.
- Misc hardware support like Audio and Ethernet are still something to keep in mind.
The main brands to avoid with Intel are:
- Weird Memory Layout that requires KASLR fix and just really poor ACPI programming, many Z390 systems are unbootable on Clover
- OpenCore can boot these systems relatively easily
- non-native USB controller, Weird Memory Layout
- USB issues mainly for Z390 and older, Z490 are fine
- Weird Memory Layout, requires KASLR fix
- Mainly Z390, Z370 and Z490 are known good
- USB issues on B460, H470 and Z490
- Z390 and older are fine
So our overall recommendation for brands(Intel):
- Z370 and older:
And main platform to avoid (for stability and ease of setup):
- B360 *
- B365 *
- H310 *
- H370 *
- Z390 *
Note (*): Only get these in case you need features from these that aren't found in Z370 or you want to overclock a 9th Gen CPU. Most of the issues with these have been corrected but they're still a big mess, see below.
With audio, most boards are supported and you can find a more extensive list from AppleALC (opens new window) for audio. VoodooHDA is another option for legacy users
note: AMD motherboard users will require VoodooHDA if you plan to use the onboard microphone header. Regular audio output works however with AppleALC
For ethernet basically all Gigabit NICs are supported(see below for more info)
- IntelMausiEthernet.kext (opens new window)
- For majority of Intel Controllers
- SmallTree-I211-AT-patch (opens new window)
- For I211-AT which is commonly found on AMD boards
- AtherosE2200Ethernet.kext (opens new window)
- For majority of Atheros Controllers
- RealtekRTL8111 (opens new window)
- For Realtek's Gigabit Ethernet
- LucyRTL8125Ethernet (opens new window)
- For Realtek's 2.5Gb Ethernet
For legacy ethernet controllers, you have a couple to choose from(systems with these chips are generally from a time before the Core i series of processors):
Note: Realtek L8200A is outright unsupported, for a full list see Networking section
Note 2: For those planning on buying Intel's Z490 boards, please note that the i225-V NIC is not supported officially without a device-id spoof. Example of this can be found here: Comet Lake i225-V spoof (opens new window)
For USB, things are fairly simple, most Ryzen/Matisse, Intel and AsMedia controllers work out of the box with no other configuration besides a USB map (opens new window). For AsRock users with Intel CPUs, you'll need to use XHCI-unsupported.kext(which can be found within RehabMan's USBInjectAll's project (opens new window). Many H370, B360, H310 and X79/X99/X299 users can also benefit from this
Special AMD Note: Due to how macOS builds USBs, they must be defined somewhere in the ACPI tables. For some reason, many AMD boards just forget to do this and users end up with a lot of broken USB ports. There is a fix but it involves manually adding the ports to the DSDT or SSDT (opens new window).
Special Asus 400 series note: Thanks to Asus breaking the ACPI spec, you'll need to use SSDT-RHUB (opens new window) to reset your ports.
With NVRAM, things have been mostly fixed for consumer platforms thanks to SSDT-PMC (opens new window). Mainly relevant for the following(Note 400 series like Z490 are not included):
There are however some boards without supported NVRAM, mainly HEDT and server boards:
- X299(Asus has working NVRAM though)
So fun part about Coffee Lake is that Intel changed a lot in how the iGPU display out work. Specifically that macOS has no clue how to properly address them. There is a fix but requires manual BusID patches through WhateverGreen (opens new window). Main victims of this:
Note that Z370 is not on the list, this is because the board is basically a Z270 so Apple's video map works fine with it
# RTC vs AWAC
With RTC vs AWAC, macOS outright won't boot with systems that have their clocks using AWAC and most BIOS GUIs don't even show the option to change it. This is mainly seen in the following:
- Z370(mainly Gigabyte and AsRock, as they back-ported the clock. Other boards are fine)
- X299(mainly ones released with 10th gen CPUs, AsRock and Gigabyte are the 2 main offenders)
- Asus has been back porting AWAC to even 2017 board with never BIOS updates, beware.
So we need to either:
- force RTC with an SSDT (opens new window),
- create a fake systems clock (opens new window)
- patch it out (opens new window)
You can find more info here on how to fix it: Getting started with ACPI (opens new window)
# Memory Maps and Protections
With this, main users affected:
- C612 (generally seen in server boards)
The issue these platforms face is that many rely on OsxAptioFix2Drv-free2000 which is now considered destructive to your system meaning build guides based of it are now invalid. More info can be found here (opens new window). These issues can mostly be alleviated by calculating your slide value: Understanding and fixing "Couldn't allocate runtime area" errors (opens new window)
Oh but to add to the fun, Intel introduced Memory protections which mean a lot of the firmware fixes provided by AptioMemoryFix/OpenCore are completely broken. Specifically that any memory patches provided are overridden meaning they're never used. Luckily OpenCore introduced a new quirk called
ProtectUefiServices which helps fix this by ensuring the patches are applied even after they're reset.