Gigabyte X299X - Catalina Support

[TheBloke]

That's right, that's the problem. It also happens immediately after selecting the OS, without delaying the boot initialization.
In my case it is a powered USB3 HDD the cause. But the exact same thing happens even when the second internal SSD with Windows is not set in the boot order of the BIOS.

Yup, it's going to happen pretty much all the time. You're quite lucky if it doesn't happen. For me - before I started using the patched OpenCore - the only time it didn't happen is if:
> I booted macOS automatically from NVMe drive
> and did not first press F12 or go into the BIOS
> and did not have any USB drives/sticks plugged in
> and did not have my Intel X520 fibre PCIe NIC plugged in - which seems to delay the boot process by about 5 seconds, and therefore triggers the issue 100% of the time if it's installed.

Since December I've been using JTR's patch for OpenCore and I can now boot perfectly every time, no problems ever.

I'd strongly recommend you consider migrating to OpenCore so you can use this patch. Actually I'd recommend OpenCore over Clover for any motherboard, even without needing this patch, but it's even more important with our broken motherboard.

Another detail is that even if I set the clock time correctly on Windows, after a Kernel panic the time returns wrong, both on MacOS and on Windows. RTC patch problem?

No idea what this could be. Again, it's very hard to know what's going wrong for you as you're using Clover and I think everyone else here (who has posted recently anyway) is on OpenCore now, and all the Dortania guides assume OpenCore.

You definitely need the three SSDTs listed on the Dortania guide - PLUG; EC-USBX; RTC0-RANGE. Without those you likely can't even boot at all (without RTC0-RANGE I would expect boot to hang around "PCI Configuration begins", as described here - and the RTC0-RANGE SSDT fixes that.)

At least with OpenCore, you should be able to boot and run normally with only those three SSDTs. I've not noticed any KPs related to clock / RTC issues.

The only doubt about usb is the HS13 port which I didn't include in the SSDT, but it keeps appearing and is reported as ITE Device (8595). Any idea?

I think ITE devices are for system monitoring - like what HWInfo does in Windows. Getting extra motherboard voltage readings, that kind of thing. I don't know of anything that uses it in macOS. HWMonitorSMC2 provides some basic voltage monitoring of a few motherboard values, which it describes as "ITE IT9699E" but I don't think they come from this USB ITE device, as it reads them with and without the USB device visible. I think it reads them in some other way.

I use the CorpNewt USB Mapping method (USBMap.kext) and I have no problem excluding the ITE USB port using that method - if I leave it out of the USB map, it doesn't show up any more. However I have left it enabled as I'm not near the port limit and it doesn't seem to be causing any problems.

I've not tried SSDT-UIAC and I don't have any experience of using that SSDT for USB mapping. I enable USBInjectAll along with XhciPortLimit to make sure all ports are visible prior to USB mapping, but then I disable both once I have my USB mapped. My concern about using USBInjectAll's mapping with SSDT-UIAC would be that USBInjectAll is no longer being developed, so it might not continue to work forever.

Thanks to this the Sleep worked perfectly in my previous GA X299 UD4 Pro, but now if I try to put this GA X229X to Sleep it just turns off the screen and nothing happens.

Several of us had this problem some months ago. It turned out that the SBUS SSDT that dolgarrean provided in the first post of this thread was blocking sleep. This can be diagnosed by checking the system logs for messages related to sleep, and looking for a line like "Sleep prevented by..".

I found that I could fix the SBUS SSDT to remove the part that broke sleep - I think it was the _DSM section that did that, for some reason. That SBUS SSDT is pretty much only cosmetic anyway, and not needed for functionality. If you look at the EFIs I uploaded a few pages back, you'll find they contain SBUS-NEW SSDT, and this one does not break sleep.

So if you have many SSDTs, I'd first check if you're using the SBUS SSDT and try removing that. If it still happens, try booting with no SSDTs installed except the three required ones (PLUG, EC-USBX, RTC0-RANGE) and see if that enables sleep to work.

If you still have the problem even when booting only with the required SSDTs, then maybe it's a different issue. Check your logs to see what's preventing sleep from occurring.

I have the F3e version, but I don't know if there are improvements compared to before, I have the same bugs that are currently also present on F3c.

Where did you get this F3E BIOS for X299X Designare 10G? Do you have a link, or can you upload it here?

I can't find anything about F3E via Google. Latest on the official website is still F3C, and I don't see anything on the Gigabyte forum about any later BIOS'.

 

[TheBloke]

Here's an updated OpenCore EFI for the Gigabyte Designare X299X 10G. It's what I'm currently using and seems to be working pretty well, with all MB features working and no glitches that I can spot. The only thing I'm unable to test is Thunderbolt, as I don't yet have any TB devices.

I'm currently running this on Catalina 10.15.7 but it should all work fine on BigSur as well.

Summary:

• OpenCore updated to version 0.6.7 (DEBUG)
  • Including @JTR 's special patch for the Designare 10's boot issue.
  • JTR's Github repo is here - it's a fork of OpenCore 0.6.4 with his patch in branch x299x-designare-10g_0.6.4.
  • As of the time of writing his patch will still apply cleanly to the latest OpenCore code.
• OpenCore config updated for 0.6.7 syntax, and passes ocvalidate check.
• All Acidanthera kexts at latest version (all DEBUG, but with debug logging not enabled.)
• OpenCore resources and HfsPlus.efi updated to latest version.
• Currently configured as MacPro 7,1 with Apple Secure Boot enabled (SecureBootModel = j160).

Features provided / configuration details:

• MacPro memory/PCIe warnings disabled via Acidanthera's new RestrictEvents.kext.
• Onboard WiFi with Airport via AirportItlwm, version 1.2.0
  • Kexts for both Catalina and BigSur are included; the Catalina version is currently active in config.plist.
  • A reminder that WiFi with Intel is currently pretty slow: max 40-50Mb/s.
• Onboard Bluetooth via IntelBluetoothFirmware
  • Also included is IntelBluetoothInjector which allows Bluetooth to be turned on/off via System Preferences.
• Onboard 10G/Gigabit network via patched SmallTree drivers, version 3.8.6, as created by @byteminer and me.
• SATA hotplug enabled via ACPI patch (this requires that hotplug is also enabled in the BIOS.)
  • This also causes SATA drivers to appear as yellow external drives.
  • Two ACPI patches are included - one for Catalina, one for BigSur. The correct patch should apply automatically as MinKernel/MaxKernel is set on each patch.
  • Disable the patches under ACPI -> Patch if you don't want this feature or don't like SATA drives showing as external.
• Dortania used for the three vital SSDTs: PLUG; EC-USBX; RTC0-RANGE.
• Thunderbolt SSDT as provided by @dolgarrenan
  • I edited it only to change the ACPI path, as originally it used PCI0 which would require an ACPI patch rename that would break booting Windows through OpenCore.
  • Thunderbolt has not been tested by me as I don't yet have any TB devices. I have confirmed that the two TB3 ports work fine as USB ports.
• XHCI USB mapped using USBMap.kext (created with CorpNewt's USBMapper tool)
  • I have not mapped the Thunderbolt or ASMedia USB ports as they only have four ports each, which is well below the 15-port limit. These two controllers are ignored by the USBMap.kext.
  • XhciPortLimit is set to false, and USBInjectAll is disabled - though it is still included in the config file in case you want to re-enable it and do your own USB mapping.
  • For the XHCI controller, I have mapped:
    • Rear MB ports
    • Header FUSB32_2 (the header just below the 24-pin motherboard power connector)
    • Internal Bluetooth adapter
    • Internal ITE device - unsure exactly what this will be used for, if anything.
    • A couple of ports are also used up on XHCI for when USB 2.0 devices are connected to the Thunderbolt ports.
  • If you want to use Header FUSB32_1 instead (or as well) you will need to do your own mapping for this. With the 15-port limit, it's not possible to map both headers at the same time. There would be just enough ports if you excluded the internal ITE port from the map - port HS13 - but I wanted to keep that included in case it ever proved useful for monitoring or anything.
• SSDT-GPRW and its associated ACPI Patch are included for anyone who has instant-wake issues when putting the system to sleep. It is not currently enabled. If you do enable it, you will only be able to wake the system with the power button.
• All cosmetic SSDTs removed; the only remaining non-Dortania SSDTs are:
  • DTGP - a helper method that can be used by other SSDTs.
  • Thunderbolt - dolgarrenan's Thunderbolt SSDT, which is untested by me at this time.
  • SBUS - dolgarrenan's SBUS SSDT, modified to remove the _DSM section which broke sleep. It renames the SBUS device and sets some properties on it. I'm pretty sure it's not required on this motherboard, but it doesn't seem to hurt anything either.
• All cosmetics moved to DeviceProperties:
  • Model, name and other properties set for:
    • WiFi, Intel X550 NICs, NVMe drives, SATA controllers, Realtek audio, USB controllers, Thunderbolt drives and devices, Power Management Controller
  • DeviceProperties are loaded only by macOS, so there's no risk of these properties affecting other OS'.
  • Moving these to DeviceProperties also keeps the SSDT section cleaner, reducing confusion about what is important for boot and what is only cosmetic.
• Kexts arranged into two folders - Acid for Acidanthera kexts, and Other for everything else.
• TSC sync fixed with TSCAdjustReset.kext - but CpuTscSync.kext is also included if you prefer it.
  • If you use TSCAdjustReset.kext and your CPU does not have 18 cores, remember to edit Contents/Info.plist to set IOCPUNumber correctly for the number of cores you have.
  • IOCPUNumber should be set to the number of logical cores minus 1, eg on a 10 core/20 thread system set the value to 19. It's currently set to 35, which is correct for the i9-10980XE and i9-9980XE.
• The config has Target = 65 meaning the DEBUG OpenCore will log to disk, but not to screen. Change to Target = 0 to disable this logging. Note that having DEBUG logging enabled can be very slow on USB drives, so expect a 5-20 second black screen delay if logging is enabled on a USB stick.

As usual, all serial numbers are set to CHANGEME and need to be edited.

Note: There are more kexts in the Kexts/Acid folder than are enabled in config.plist. I've also included the AirportBrcm and BrcmBluetooth kexts, which would be used by anyone who has a Broadcom WiFi/Bluetooth card. Plus a couple of others like HibernationFixup and RTCMemoryFixup. Kexts that are in the Kexts folder but not listed in config.plist can be safely deleted if you want to free up some space in the EFI.

Note 2: I have set SetApfsTrimTimeout to a high value, as suggested in OpenCore's manual. This increases the on-boot timeout for TRIMing NVMe drives, to ensure that the TRIM actually takes place. Apparently some NVMe controllers can be slow at this, and by default macOS times out after 10 seconds. This can lead to the drive never being properly trimmed. Be aware that this can increase boot times, perhaps significantly. For me it increases boot times by about an extra 10 seconds, but on certain NVMe drives it could be a lot longer. If necessary set SetApfsTrimTimeout to a lower value (it's in microseconds), or to -1 to use the macOS default.

Note 3: I have not configured LauncherPath, so there will not be a permanent boot entry created in EFI. If you dual-boot with Windows or other OS' you might want to change LauncherOption to Full: Dortania guide to LauncherOption.

Here's how the PCI section will look:

(Mine also includes an extra PCIe Intel X520 10GBe NIC, plus I've added cosmetic entries for my Vega 64 GPU and its audio device; I didn't include any GPU DeviceProperties in the EFI as people will have varying GPUs.)

 

[manpower]

Thank you so much @TheBloke my mobo up and running in Catalina using your latest OC setting! but I have critical problem running some 3D program like Maya it doesn't launch just quit! wondering cause by display card or other system issue? my MB X299X with 5700XT 64Gb Ram

 

[JTR]

- The main problem is that if I have an external hard drive connected via USB I cannot boot. The system shuts down immediately after selecting the OS.

This is most likely from the UEFI firmware bug with driver (re)connection on PciRoot(0x0)/Pci(0x1F,0x0)/Acpi(PNP0303,0x0).

I've noticed that it'll also semi-reliably break Windows Bitlocker unlock dialog if certain USB drives are inserted on boot. I've been poking at this issue a bit recently in the hopes of figuring out a workaround for Windows BDE unlock, or at least nailing down the triggering parameters in more detail. I think the call here is most likely being triggered as a side effect of Bitlocker looking for .BEK files on attached drives.

Anyways, digressions aside, for your issue, since you're using Clover, the fix for this issue is fairly straightforward — switch to my patched fork of OpenCore.

I haven't updated it past 0.6.4 yet (and honestly haven't even looked at the changelogs for anything past 0.6.4 outside of a passing glance at 0.6.6's changelog) as I've been extremely busy both personally and at work, but I plan on doing that soon — I just need to find the time to tackle this. I suspect rebasing to/past 0.6.6 might possibly run into some issues due to the major changes in 0.6.6, but I won't know for sure until I've actually gone and tried it.

- The second, less serious, is that the time is always wrong after a cold boot. It corrects itself with internet connection, but this causes problems with Dark Mode that is set to auto. This also happens on Windows.

This sounds like the good old time offset issue.

Assuming you only boot Windows and macOS on this hardware, and assuming that the old fix is still appropriate/working with Catalina and our hardware (I'm not sure if I've actually tested this yet on my X299X board), then the easiest fix for this would be to follow this guide:

https://www.howtogeek.com/323390/ho...ux-showing-different-times-when-dual-booting/

Specifically, look at the section "Option Two: Make Windows Use UTC Time".

 

[beltzak]

Thank you so much @TheBloke my mobo up and running in Catalina using your latest OC setting! but I have critical problem running some 3D program like Maya it doesn't launch just quit! wondering cause by display card or other system issue? my MB X299X with 5700XT 64Gb Ram

View attachment 512547

I have no problem in Catalina 10.15.6 running Maya.

cd /Applications/Autodesk/maya2020/Maya.app/Contents/MacOS
./Maya
Initialized VP2.0 renderer {
Version : 2016.11.53.12. Feature Level 5.
Adapter : AMD Radeon VII OpenGL Engine
Vendor ID: 4098. Device ID : 0x66AF
Driver : 4.1 ATI-3.10.15.
API : OpenGL V.4.1.
Max texture size : 16384 * 16384.
Max tex coords : 32
Shader versions supported (Vertex: 5, Geometry: 5, Pixel 5).
Shader compiler profile : (Best card profile)
Active stereo support available : 0
GPU Memory Limit : 16368 MB.
CPU Memory Limit: 62259.2 MB.
MultiDraw consolidation: enabled
}

OpenCL evaluator is attempting to initialize OpenCL.
Detected 1 OpenCL Platforms:
0: Apple. Apple. OpenCL 1.2 (Jul 5 2020 01:14:53).
Supported extensions: cl_APPLE_SetMemObjectDestructor cl_APPLE_ContextLoggingFunctions cl_APPLE_clut cl_APPLE_query_kernel_names cl_APPLE_gl_sharing cl_khr_gl_event
OpenCL evaluator choosing OpenCL platform Apple.
Choosing OpenCL Device AMD Radeon VII Compute Engine. Device Type: GPU Device is available.

2021-03-19 11:45:18.370 Maya[66361:16401053] Bad cursor rect event, flags = 0
2021-03-19 11:45:18.370 Maya[66361:16401053] Bad cursor rect event, flags = 0
2021-03-19 11:45:18.370 Maya[66361:16401053] Bad cursor rect event, flags = 0

Phoenix FD plugin resolved to '/Applications/Autodesk/maya2020/vray/plug-ins/vrayvolumegrid.bundle'
V-Ray VolumeGrid: loading /Applications/Autodesk/maya2020/vray/scripts/VRayVolumeGridInit.mel...
[2021/Mar/19|11:45:20] V-Ray: V-Ray Next for Maya, update 2.2 version 4.30.02 PLE from Apr 15 2020, 17:57:06

 

[TheBloke]

Thank you so much @TheBloke my mobo up and running in Catalina using your latest OC setting! but I have critical problem running some 3D program like Maya it doesn't launch just quit! wondering cause by display card or other system issue? my MB X299X with 5700XT 64Gb Ram

I have no problem in Catalina 10.15.6 running Maya.

Yeah I have no problems running 3D apps either. I don't use Maya, but I regularly use GPU acceleration and 3D in DaVinci Resolve Studio and Fusion Studio, and I've also (briefly) tested Blender.

Not really sure what could cause such issues. I've never used a 5000-series GPU so I don't know if there are any unusual issues with those, but I've not heard of any (besides that you need agdpmod=pikera to avoid a black screen.)

@manpower What does About This Mac -> Graphics/Displays show? Can you run GeekBench 5's Compute benchmark in both OpenCL and Metal modes?

If you run Maya from the command line like beltzak showed, what error(s) are displayed when it quits?

And have you had Maya working before, or is this the first time you tried it on this system? If it has worked before, what's the difference between now and then? What EFI were you using when it last worked?

Also, I see you have a different CPU to me - did you remember to edit TSCAdjustReset.kext/Contents/Info.plist and change the IOCpuNumber to <number of threads> minus 1? (Or you could switch to CpuTscSync.kext which doesn't need any configuration.) I believe that incorrect TSC adjustment can cause some weird issues, though I have no idea if that would include this sort of issue. But you want to make sure it's configured correctly regardless.

 

[manpower]

HI @TheBloke thanks for your prompt reply! According to your suggestion may I clearify change the IOCPUNumber from 35 to -1 (minus 1)? My CPU 10940X how to get this number actually?

Thanks

 

[djlild7hina]

HI @TheBloke thanks for your prompt reply! According to your suggestion may I clearify change the IOCPUNumber from 35 to -1 (minus 1)? My CPU 10940X how to get this number actually?

Thanks

10940x is 14 cores so 28 threads - 1. You would put in 27.

I have the IOCPUNumber adjusted here in my github by the amount of CPU cores.

shinoki7/ASUS-X299-Hackintosh

Contribute to shinoki7/ASUS-X299-Hackintosh development by creating an account on GitHub.

github.com

or you can just use https://github.com/acidanthera/CpuTscSync

 

[BerndVP]

Hi,
I'm looking to buy this board as a last Hackint0sh build before Apple stops using Intel processors.
Currently running a Z77X with 3770K for almost 10 years.

As of the last post I read some issues with the BIOS and stuff?

The dual 10G ports interests me and the onboard TB3 too.

What are you're opinions.

 

[TheBloke]

I'm looking to buy this board as a last Hackint0sh build before Apple stops using Intel processors.
Currently running a Z77X with 3770K for almost 10 years.

As of the last post I read some issues with the BIOS and stuff?

The dual 10G ports interests me and the onboard TB3 too.

That's a tricky question.

On the one hand, as you mentioned this board has a good range of HW. Dual 10GB is great if you can use it, and TB3 has lots of applications in a studio environment. There's also support for 256GB RAM, 3 x M2 slots, and an included 4 x M2 expansion card with RAID support (I'm not 100% sure if this works in macOS but I believe there was discussion of it working in some of the early posts in this thread).

That said, there is a LOT of resource sharing. Using multiple M2 ports will limit your SATA ports, and using the M2M M2 slot (second one down) will limit the second PCIe slot to x4 with a 48-lane CPU (eg i9-10980XE), or disable it completely with a 44-lane CPU.

Likewise - and something I didn't even realise until just now - the number of Thunderbolt devices can be limited by PCIe usage. Quoting the manual - "Because of the limited I/O resources of the PC architecture, the number of Thunderbolt devices that can be used is dependent on the number of the PCI Express devices being installed."

It doesn't say any more than that, so who knows exactly what the limit is. I only learned about that possible limitation just now, when I was Googling on the MB and found this review on Scan.co.uk :

Not very complimentary. He obviously had a 44-lane CPU hence losing the second PCIe slot completely when populating the second M2 slot. It's not quite as bad with a 48-lane CPU like the i9-10980XE; though a x4 PCIe slot is still quite restricted. Then again this is unlikely a factor for anyone who has an air-cooled GPU in slot 1, which will likely block slot 2 completely anyway.

I've not (yet) experienced most of these issues myself, because I'm not trying to max out the PCIe slots. I never expect to use PCIe slot 2 because my GPU in slot 1 covers it. I have used three slots at once: two x16 GPUs (my Vega 64 plus my new 6900XT which is not currently supported in macOS and only used for Windows) plus my x8 Intel X520 10GBe NIC (which I'm still using because my home 10GBe network is on SFP fibre so I can't yet use the 2 x onboard NICs for 10GBe until I get a new 10GBe switch.) That worked fine - however I wasn't also using Thunderbolt 3 at the time, so I don't know what effect that would have.

Last night on a whim I bought a CalDigit Thunderbolt 3 dock which will come later today, so I'll be doing my first TB3 testing soon. I'll report back when I know more about TB3, but several other users have been using it, and have described their experiences throughout this thread, especially in the earlier posts.

Be aware that if you do plan to use TB3 you will likely want to flash the TB3 firmware, a process that requires a ROM flasher (costs about £10-£15) and partially dismantling the board. You may already have seen the procedure for that in the first post. TB3 can apparently be used to some extent without flashing, but TB3 networking won't work for example.

On top of those considerations, there's also the BIOS. It's disgracefully buggy. By far the worst BIOS I've ever experienced, or recall hearing about.

Off the top of my head, here are the issues:

• BIOS hasn't been updated since December 2019 - which was only a month or two after the board was first released. No sign it will ever get another update, despite the board still being on sale.
• Board requires a special patched version of OpenCore due to a UEFI firmware bug.
• BIOS resets to French language every time the F12 boot picker is used.
• Failure to POST - eg from incorrect BIOS and/or overclock settings - can often lead to the BIOS resetting to default. Primarily an issue when setting up an overclock, and shouldn't be a day-to-day issue.
• If overclocking: VCCSA resets to Auto on every shutdown, and on wake-from-sleep.
  • This means you either can't do an overclock that requires a tuned VCCSA, or else must never sleep/wake - and must manually re-save VCCSA on every cold boot.
  • I did the set-VCCSA-on-every-cold-boot thing for a couple of months, but recently abandoned that because I wanted to start making use of sleep/wake. So now I've downgraded my overclock a bit to the point where I think I don't need to set VCCSA. In particular, I removed my RAM overclock. I might revisit this again later when I have more time for overclock testing.
• If overclocking RAM: RAM Training voltages have to be set manually to match your RAM voltages, as the board won't train correctly if the Training Voltages are left on Auto.
  • GB have been aware of this for over a year. There's a YouTube video about it - made by a guy with 100k subs who was sent the MB by Gigabyte for testing/review. He reported it to them immediately.
  • I won't link the video because it'll likely delay this post into 'moderation', but just search YouTube for DRAM Training voltage bug in Gigabyte X299X Designare BIOS.
  • This isn't a big deal once you know about it, as it's easily worked around. But it's hugely problematic until you learn of the issue, as it's easy to assume your RAM just can't overclock. And the fact it's never been fixed shows how little GB seem to care about this MB.

Several of these issues are only a factor if you overclock, so can be ignored if you don't plan to. The key issue for a Hackintosh has always been the boot failure problem, which thankfully has now been diagnosed and patched by @JTR . This patch is not yet part of official OpenCore (I'm hoping JTR plans to submit it to Acidanthera at some point), and so for now requires merging the patch and compiling OpenCore manually. A couple of days ago I uploaded the latest OpenCore version, 0.6.7, with this patch applied so there's no need to compile it yourself if you don't want to. I'll do the same for OpenCore 0.6.8 when it's released.

So how to sum this up? It's definitely a hugely flawed MB. Things would be improved if the BIOS bugs were fixed, but there's no sign that that's ever going to happen.

If you want to overclock heavily, it's hard to recommend this board. There's the BIOS bugs - of which the VCCSA bug is the significant one - but even without those, this is not a great board for a maximum overclock. It lacks some useful features/settings that other boards have, as I've learned when discussing my 10980XE overclock on an overclocking forum. As an example: many other X299 boards allow setting per-core voltages, allowing you to finely tune an overclock to get the maximum from every core. There's also some voltage protection systems that other MBs allow to be disabled, but this one does not.

If you have no plans to overclock then you'll not need to worry about that. Beyond the general BIOS issues - and the current inconvenience/worry of having to rely on a patched OpenCore - it might depend on how much hardware you plan to use. If you want to use TB3 plus also max out the PCIe slots and M2 slots, then you might want to look at some other boards to see if they have less resource sharing. Whereas if you don't plan to use more than one or two PCIe slots, that likely won't be a consideration.

Wish I could be more positive but this is a hard MB to recommend without a lot of caveats!