Contribute
Register

Gigabyte X299X - Catalina Support

Joined
Aug 6, 2013
Messages
48
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10900X
Graphics
RX 580
Mac
  1. MacBook Pro
Mobile Phone
  1. Android
Here's the original message quote.

I want to add that, with this card and macOS installed and my BT keyboard/touchpad are paired, both keyboard and touchpad work in BIOS. Comes handy when I see that dreaded BIOS error.
The link is to the US Amazon; it might not be available elsewhere. Try removing everything after ? (question mark)
Or just try searching for
"
Plug & Play Hackintosh WiFi M.2 NGFF Adapter BCM94360NG 802.11ac Bluetooth 4.0 WiFi Card for PC Catalina macOS Native for macOS AirDrop Continuity Handoff Better BCM94352Z DW1560 Support Intel NUC
"
This card works for me without any problems. Fully compatible replacement.
No need to install any drivers, supporting kexts or SSDTs.
It's a bit dated compared to Intel, but unlike Intel card the motherboard comes with, it just works.
Both BT and WiFi work.

WiFi might not be super fast as reported by Network Utility App, but I don't really care about WiFi, I have 10GbE switch :)

https://www.amazon.com/gp/product/B083YXS7VF/?tag=tonymacx86com-20

Hi, you're link isn't working anymore...
 
Joined
Aug 17, 2017
Messages
281
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
RX 5700 XT
Mac
  1. MacBook Pro
Mobile Phone
  1. iOS
The VCCSA issue is different: when the VCCSA voltage setting is changed from Auto, to for example 1.250V, this setting gets ignored whenever a shutdown or sleep/wake is done. It happens after both Windows and macOS shutdown.

After a full shutdown (but not restart), the BIOS setting still says 1.250V (or whatever), but VCCSA is actually running back at 0.9V. This is visible both in the BIOS (VCCSA is one of the values shown in the top right of each BIOS screen), and via any hardware monitoring software like HWInfo in Windows or HWMonitorSMC2 in macOS (there it will show up as 'VIN5').

When the issue occurs, VCCSA will show up as 0.9V instead of the value you set it to. I'm not 100% sure if this means it's actually 0.9V, or whether it's back to Auto.

In order to get it to re-apply, the user must change VCCSA to a different value (eg 1.245V) and then F10 in the BIOS. But it will only stay applied until the next shutdown or sleep/wake.

I used to have a tedious but effective solution for this: every time I did a cold boot, I'd go into the BIOS and flip the value between 1.250V and 1.245V (or vice versa), then F10 and boot normally. But more recently I've started making use of regular sleep and wake, which breaks that workaround because VCCSA also goes back to Auto (or 0.9V) when the system wakes from sleep.
Hi @TheBloke, the new beta bios fix this bug?
I didn't notice this because I didn't touch these settings for my overclock (limited to 4.7GHz for now).


There's a ton of info on this in CaseySJ's Z490 thread, so that would be the best place to look/ask to find out the finer details of TB firmware flashing.
As for the Thunderbolt: I learned that flashing the firmware does not make any improvements in terms of speed and latency. So in my case I decided to keep it original.
 
Joined
Mar 6, 2013
Messages
273
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
AMD 6900XT
Mobile Phone
  1. Android
Hey guys.. you're not going to believe this.

I think I've found the fix for our Designare 10G boot bug. A vanilla OpenCore fix, not requiring @JTR 's patch.

Set ConnectDrivers to false. That's it. :)

I've only tested it a couple of times, and only in the latest OpenCore 0.6.8. But I've booted from both USB and SSD using this change, and it boots absolutely fine with normal BIOS settings. No reset after 10 seconds, no safe mode.

From the manual:
"ConnectDrivers: This option is useful for loading drivers following UEFI driver model as they may not start by themselves. Examples of such drivers are filesystem or audio drivers. While effective, this option may not be necessary for drivers performing automatic connection, and may slightly slowdown the boot. Note: Some types of firmware, particularly those made by Apple, only connect the boot drive to speed up the boot process. Enable this option to be able to see all the boot options when running multiple drives."

So without this set I suppose there could theoretical be some side effect, like not being able to boot from certain drives. But I've not noticed anything yet - I get my normal macOS (NVMe drive 1) and Windows (NVMe drive 2) boot entries. It also saw the EFI on my USB stick.

Further time and testing is needed to ensure it definitely solves the problem forever. But so far it's looking great.

EDIT: This does cause at least one problem. With ConnectDrivers=false, it appears not to be possible to boot the macOS installer from a USB drive. You can boot from a USB EFI OK, but it won't find the "Install macOS Big Sur" DMG on the USB. Therefore if you were going to use this parameter for a new install, you'd first need to boot with ConnectDrivers=true (and thus hit the BIOS safe-mode issue, and proceeding at stock speeds with no XMP). Once macOS was installed, you could then set ConnectDrivers=false and booting would be fine after that.

Having thought about this more overnight I've realised that it probably should have been obvious that this parameter would affect things, as @JTR 's patch is to OcDriverConnectionLib, which is I believe disabled by ConnectDrivers=false. So setting that parameter bypasses the issue, but at the expense of the ability to boot from a USB installer. Whereas JTR's patch fixes the issue completely - but currently at the cost of requiring an external patch to standard OpenCore.
 
Last edited:
Joined
Jan 11, 2016
Messages
12
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
AMD Radeon Pro WX 7100
Mac
  1. MacBook Pro
Mobile Phone
  1. Android
Hey guys.. you're not going to believe this.

I think I've found the fix for our Designare 10G boot bug. A vanilla OpenCore fix, not requiring @JTR 's patch.

Set ConnectDrivers to false. That's it. :)

I've only tested it a couple of times, and only in the latest OpenCore 0.6.8. But I've booted from both USB and SSD using this change, and it boots absolutely fine with normal BIOS settings. No reset after 10 seconds, no safe mode.

This is not a new config parameter - it's been there since at least 0.5.7. I don't know if anyone has tried this unsuccessfully before and its behaviour has changed in recent versions, or if this was just staring us in the face for some time. Regardless, I'd not have thought to try it now were I not re-reading JTR's patch and his work on diagnosing the problem as being related to "driver connection".

I had seen in 0.6.7 there was a new parameter DisableSecurityPolicy which was a "UEFI quirk to workaround driver loading" which sounded like it was worth trying with regard to our problem. Didn't get around to until today, and then when searching for it I noticed ConnectDrivers. I tried that first, and.. it works :)

From the manual:
"ConnectDrivers: This option is useful for loading drivers following UEFI driver model as they may not start by themselves. Examples of such drivers are filesystem or audio drivers. While effective, this option may not be necessary for drivers performing automatic connection, and may slightly slowdown the boot. Note: Some types of firmware, particularly those made by Apple, only connect the boot drive to speed up the boot process. Enable this option to be able to see all the boot options when running multiple drives."

So without this set I suppose there could theoretical be some side effect, like not being able to boot from certain drives. But I've not noticed anything yet - I get my normal macOS (NVMe drive 1) and Windows (NVMe drive 2) boot entries. It also saw the EFI on my USB stick.

Further time and testing is needed to ensure it definitely solves the problem forever. But so far it's looking great.

Even if this does solve the problem, thanks again to JTR for all his work on diagnosing the problem and creating the patch. Without that work the last few months would have been unbearable, and I'd probably never have thought to try ConnectDrivers in the first place.

If everything is still looking good tomorrow I'll upload a vanilla 0.6.8 OpenCore EFI with updated kexts, and this config value set.
@TheBloke Hi, I have try set ConnectDrivers to false to install big sur, boot success but not found the install usb disk.But after install success, set ConnectDrivers to false works well.
 
Last edited:
Joined
Mar 6, 2013
Messages
273
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
AMD 6900XT
Mobile Phone
  1. Android
@TheBloke Hi, I have try set ConnectDrivers to false to install big sur, boot success but not found the install usb disk.But after install success, set ConnectDrivers to false works well.
Ahh yes, interesting. I see the same. It will boot from USB, but it can't see the DMG macOS installer from USB with ConnectDrivers=false. It does see the Recovery DMG on my NVMe without problems.

What's interesting is that it does see a full macOS install on USB. I plugged in an SSD via USB-to-SATA3 converter, and it found both the macOS install and the Recovery DMG on that external SSD:

OpenCore 0.6.8, booted from NVMe EFI, with ConnectDrivers = false:

1618137842932.png


It finds: macOS + Recovery on one NVMe; Windows on the other; a Big Sur installation + Recovery on SSD connected via USB; and the EFI from an "Install macOS Big Sur" flash drive. So everything has been detected OK except the macOS installer DMG on the USB stick. I wonder what's different about that.

As I've put in my edit to my post from last night, in hindsight I guess it should have been obvious that ConnectDrivers would have an effect on our issue given JTR's patch is to OcDriverConnectionLib, and I think ConnectDrivers=false disables this library entirely.

So there definitely is still a use for the patch in order to get full functionality. But I'm glad I've belatedly realised that it's also now possible to run day-to-day with a vanilla OpenCore, as until that patch gets submitted and integrated into OC it's always going to be a worry that one day it will no longer be possible to merge JTR's code.
 
Last edited:
Joined
Aug 6, 2013
Messages
48
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10900X
Graphics
RX 580
Mac
  1. MacBook Pro
Mobile Phone
  1. Android
Just FYI - setting ConnectDrivers=false under 0.6.6 fails validation.
My configuration is different though. I suppose it'll only work if no drivers are loaded in /UEFI/Drivers, unless something changed in OC from 0.6.6 to 0.6.7
On the other hand, I load OpenRuntime.efi as a driver, to speed up boot process.
Set ConnectDrivers to false. That's it. :)

I've only tested it a couple of times, and only in the latest OpenCore 0.6.8. But I've booted from both USB and SSD using this change, and it boots absolutely fine with normal BIOS settings. No reset after 10 seconds, no safe mode.
 
Joined
Sep 8, 2010
Messages
238
Motherboard
Gigabyte X299X-Designare-10G
CPU
i9-10980XE
Graphics
Radeon Pro WX 7100
Mac
  1. MacBook Air
  2. MacBook Pro
  3. Mac mini
Mobile Phone
  1. iOS
All good news, I have almost all the components, just the CPU and RAM :D
 
Joined
Mar 28, 2019
Messages
131
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
RX 580
Mac
  1. MacBook Pro
Mobile Phone
  1. Android
Some good news from me as well:
- The ConnectDrivers thing seems to work on my end, too, haven't encountered the previous issues thus far. Fingers crossed.
- I finally got around to mapping my USB ports properly, which resolved most of my USB issues. I used Hackintool for this, which made the process very simple.
 
Joined
Mar 6, 2013
Messages
273
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
AMD 6900XT
Mobile Phone
  1. Android
Just FYI - setting ConnectDrivers=false under 0.6.6 fails validation.
My configuration is different though. I suppose it'll only work if no drivers are loaded in /UEFI/Drivers, unless something changed in OC from 0.6.6 to 0.6.7
On the other hand, I load OpenRuntime.efi as a driver, to speed up boot process.
Yes, true:
Code:
HFS+ filesystem driver is loaded at UEFI->Drivers[1], but UEFI->ConnectDrivers is not enabled!

I have three drivers loaded via UEFI -> Drivers:
  • HFSPlus.efi - for loading HFS filesystems, eg DMG Recovery images
  • OpenRuntime - vital for many UEFI related tasks
  • OpenCanopy - the OC GUI
The OpenCore logs claims that all are loading fine:

Code:
00:293 00:001 OCABC: Awaiting rendezvous with OpenRuntime r12
00:299 00:001 OC: Driver OpenRuntime.efi at 0 is being loaded...
00:305 00:003 OCABC: Got rendezvous with OpenRuntime r12
00:309 00:001 OC: Driver OpenRuntime.efi at 0 is successfully loaded!
00:310 00:001 OC: Driver HfsPlus.efi at 1 is being loaded...
00:315 00:002 OC: Driver HfsPlus.efi at 1 is successfully loaded!
00:316 00:001 OC: Driver OpenCanopy.efi at 2 is being loaded...
00:327 00:001 OC: Driver OpenCanopy.efi at 2 is successfully loaded!

However I just checked my EFI logs from before I set ConnectDrivers=false, and I see there's an extra log line in those related to HfsPlus:
Code:
00:302 00:001 OC: Driver HfsPlus.efi at 1 needs connection.

So yes, as ocvalidate says, HfsPlus.efi can't load with ConnectDrivers=false, which is why "Install macOS Big Sur" can't be found: that's an HFS+ filesystem. Whereas the main OS Recovery can be loaded, because that comes from the APFS Recovery partition, and APFS support is built-in to OC.

Fortunately our system doesn't need any other UEFI drivers, but yes it is a bit of an annoyance not to be able to load HFS+ support for when it's occasionally required.

I looked through the OC code and confirmed that ConnectDrivers=false disables the code that JTR had to patch in order to fix the problem (Library/OcDriverConnectionLib/OcDriverConnectionLib.c), so it's obvious in hindsight that ConnectDrivers=false would also resolve the problem (albeit with a downside) if the system remained bootable, which fortunately it does.

- I finally got around to mapping my USB ports properly, which resolved most of my USB issues. I used Hackintool for this, which made the process very simple.
Glad you got it working finally. You could have used the USBMap.kext I included in my 0.6.7 EFI a month or so ago, but yes it's better to know how to do it oneself as well :) (Personally I prefer USBMapper to Hackintool though.)
 
Joined
Mar 28, 2019
Messages
131
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
RX 580
Mac
  1. MacBook Pro
Mobile Phone
  1. Android
I had a different SMBIOS, which I believe prevents that from being an option IIRC. I also had less ports active which I actually needed. I did try yours, but it didn't help with my particular situation, so I figured I'd bite the bullet and attempt my own version, which did eventually lead to a good result. Either way, thanks for all the hard work you've put into this already!
 
Top