Contribute
Register

Gigabyte X299X - Catalina Support

Joined
Mar 6, 2013
Messages
274
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
AMD 6900XT
Mobile Phone
  1. Android
Do you guys have the original Intel and Bluetooth working in the Designare 10g? I had to change the device. I know they were patching it but I thought that could take some time.
Handoff or Continuity?

Yes, both work. WiFi speeds are pretty bad compared to Windows, so for 24/7 WiFi usage you may well still be better off with a Broadcom device. But for occasional or backup WiFi usage, yes we can get this out of the box with no need to purchase replacement hardware. Hopefully Intel WiFi speeds will improve in the future.

Bluetooth



Bluetooth requires working USB SSDTs - I didn't have it working for a while when I was playing around with SSDTs and not all were loaded. The XHC SSDT that Dolg provided does the job. Then working Bluetooth is provided by the triple combo of BrcmInjectBluetooth, BrcmFirmwareData and BrcmPatchRAM3.

There's no need to use BT4LEContinuityFixup.kext any more, as this feature is now provided by an OpenCore quirk.

In order for Bluetooth to work, you should see a valid Firmware Version in About This Mac -> Bluetooth. It will also show working Low Energy etc:
LoUHzmY.png


I can even use my Bluetooth trackpad to wake my system from sleep, which is pretty cool.

Intel WiFi

Intel WiFi can be enabled using itlwm, like byteminer told us about the other day. I've just installed that for the first time myself today.

There's two versions of itlwm: itlwm and AirportItlwm. The Airport one they say is still in Beta.

There's a detailed FAQ available describing the differences. The following is a summary:

itlwm
  • Provides working WiFi, but the device appears to macOS as an Ethernet device
  • Requires a separate app to make WiFi connections: Heliport
  • Can connect to hidden WiFi networks
  • Does not support Handoff, shared clipboard, or other Continuity services
  • Does not support Location Services
  • Easy to install, no special settings required
  • Maximum 802.11n at 20Mhz

AirportItlwm
  • Provides working WiFi, and appears as a WiFi device
  • Therefore does not require a separate app - you can use standard Apple WiFi preferences
  • Cannot connect to hidden WiFi networks
  • Supports Handoff and Shared Clipboard, but not (yet) any other Continuity Services
  • Supports Location Services
  • May have problems connecting to iPhone HotSpot and with Apple Bluetooth peripherals (my Magic Trackpad 2 seems fine, though - at least when only using 5Ghz WiFi)
  • Requires special OpenCore config: you must either boot with AppleSecureBoot, or else manually inject IO80211Family.
  • Maximum 802.11n at 20Mhz

I just installed AirportItlwm and it appears to be working OK. To do this I chose the method of enabling AppleSecureBoot in my OpenCore config, and I set the SecureBootModel to j160 for MacPro 7,1.

This worked perfectly at the first attempt. In the OC manual it has this warning about enabling Secure Boot: "As with T2 Macs, unsigned kernel drivers and several signed kernel drivers, including NVIDIA Web Drivers, cannot be installed." I thought this would mean that my SmallTree drivers in /Library/Extensions would stop working, because they show as having an invalid signature. But they kept working fine. Nonetheless I've moved to loading them from EFI, just in case.

I am loading AirportItlwm from EFI also, which I think is the recommended (or only) method for this kext.



I've not yet done any advanced testing, eg of Handoff/Shared Clipboard, but for basic WiFi usage it's working.

My speeds are pretty awful:

oKM0dM7.png


That's when connected at 5Ghz, using the little magnetic aerial that came with the motherboard.

In Windows I get 340Mb/s down and 37Mb/s up, on a fibre internet connection with listed speeds of 350 / 40. So I'm getting less than 10% of that speed in macOS.

On the itlwm page it says the author got speeds of up to 80Mb/s where I'm not even reaching 30Mb/s. I'm not quite sure why I have less than half what the author got. Maybe AirportItlwm performs worse than itlwm, or maybe it's affected by connection quality, and I'd need to be closer to the router to get 80Mb/s; my router is downstairs through the floor, about 10m away.

The author says that the (much) lower speeds compared to Windows are due to itlwm only supporting 802.11n and 20Mhz.

2.4Ghz interference with Bluetooth

On the itlwm page it mentions that using 2.4Ghz WiFi can interfere with Bluetooth, and I've found this to be the case in my setup. When I ran a speed test while connected to my router at 2.4Ghz my bluetooth Magic Trackpad was very jerky and unpleasant to use. Connecting at 5Ghz solved this problem.


Personally I have no plans to use the WiFi for actual connectivity, as I'll be cabled at all times at 1Gbe and 10Gbe. But I am interested in having a working WiFi connection, because I've seen in the past that some apps require it.

For example, speaking of Sidecar - there are other apps that enable use of iPad as an additional monitor. One that I purchased a while ago is called Duet. I used that for a while on my old Hack, then when Mojave was released they had to change the method of connecting an extra screen. The method they chose required a working WiFi connection with Airport, even when cabled on Ethernet. So after that point I was never able to use my iPad as a second screen.

That's the reason why I'm trying the Airport version of itlwm - I want the real WiFi connection more than actually care about using the WiFi for data transfer.

I plan to try Duet again soon on the new Mac, now that I have working Airport again. Hopefully I can use that to allow using my iPad as an extra screen again.
 
Last edited:
Joined
Mar 6, 2013
Messages
274
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
AMD 6900XT
Mobile Phone
  1. Android
Quick follow up on AirportItlwm: I'm so far completely unable to get any kind of Continuity stuff working.

I have an iPad Air running iOS 12.4.9. I barely ever use it but I got it out to test this.

Both macOS and the iPad are logged into the same iCloud account, they're on the same WiFi network and both at 5Ghz, they both have Bluetooth enabled, and they can see each other and connect to each other over BT. Both have Handoff enabled in Preferences.

But the shared clipboard isn't working, and I don't see the Handoff option in any app, eg Safari.

I've no idea how one debugs this, and to be honest it's not something I particularly care about given I never use the iPad anyway.

I also had one failure with AirportItlwm: on one occasion I booted macOS and Airportitlwm failed to properly initialised or load.

I briefly saw a message in the verbose boot log indicating that it had failed to apply the firmware, and then in macOS I couldn't establish a WiFi connection. WiFi Preferences indicated that WiFi was disabled, but clicking "Turn On" did nothing.

Since then I've rebooted multiple times, including dual booting back and forth between Windows and macOS, and it's worked every time. So I'm not quite sure what caused that one failure.

Right now I'm not sure if I could generally recommend AirportItlwm, given I can't get the Continuity stuff to work which is its main point versus itlwm. If you just want a working WiFi connection and don't want to buy Broadcom, I'd think that the standard itlwm is probably more reliable and certainly a bit easier to get going.
 
Joined
Oct 28, 2017
Messages
50
Motherboard
Gigabyte x299x Designare 10G
CPU
i9 10940x
Graphics
Radeon VII
Mac
  1. MacBook Pro
Mobile Phone
  1. iOS
My understanding is that Sidecar will never work because we don't have an iGPU. On non-iGPU Macs, the T2 chip is used to accelerate Sidecar, and we don't have a T2.

Thanks for the info. Did not know that, I gave away my ipad air 2 (mum) so I am not using now.

I have Continuity and Handoff working but not very reliable. I don't care thou don't find it much need of it as I do completyl different workflow in a computer than idevices. Thank you for the work, trouble and testing you have been doing man. I can't wait to get home and start testing everyhting ;P

Cheers
 
Joined
Mar 6, 2013
Messages
274
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
AMD 6900XT
Mobile Phone
  1. Android
Hi @Ellybz - I was wondering whether you might have a moment to help me understand a little more about using DeviceProperties, as you explained back in July:

If it is only a matter of cosmetic issue, I suggest you to use device properties in OpenCore vs SSDTs ( old school ).
Very simple and effective. You'll need Hackintool: PCIe section. Look for your device, right click to copy the device path and report the elements inside OC /DeviceProperties. If you want to add some vendor ID or other fields, you'll find them with IOReg. Check the exemples below and you should be all

I am still working on SSDTs for the Designare and I have started to use DeviceProperties instead of SSDT _DSM sections. I am following your method - look in Hackintool to get device path, and then specify the properties using DeviceProperties. I am copying the properties out of the SSDTs that dolgarrenan provided.

This seems to work well, at least in the few I've tested.

But I would like to understand this a bit better, and in particular to understand whether there any situations where I can't use DeviceProperties, and an SSDT must be used?

To put it another way: if I converted every _DSM section in my SSDTs to DeviceProperties in config.plist, would I run into any problems?

You said "if only a matter of cosmetic issue", which suggests that not every _DSM could convert to DeviceProperties?

And the OpenCore manual says:
"For all kernel drivers, which may inspect the IODeviceTree plane without probing (e.g. Lilu and its plugins such as WhateverGreen) it is particularly important to ensure device presence in the ACPI tables. Failing to do so may result in all kinds of erratic behaviour caused by ignoring the injected device properties as they were not constructed at the first stage."

Which also suggests the same. But I don't yet know how I can know which properties are OK to specify in DeviceProperties, and which must be in an SSDT?

The reason that I like the idea of DeviceProperties is that it only applies to macOS, and it allows the user to see everything in config.plist, rather than having to check between config.plist and SSDTs to see what's being set up.

I have had a look around for an example EFI that uses DeviceProperties in the way you described, but so far I have not found any. I found one example EFI from you (in the X299 BigSur thread), and also looked at lolflatsix's EFIs in the same thread, but neither had any DeviceProperties configured. dolgarrenan's EFI uses DeviceProperties to configure a couple of Thunderbolt devices, but the vast majority are configured via SSDT.

Thanks in advance for any advice.
 
Last edited:

Ellybz

Retired
Joined
Apr 16, 2017
Messages
417
Motherboard
Gigabyte X299 WU-8
CPU
I9-7980Xe
Graphics
RX 580
Mobile Phone
  1. Android
My position has evolved since July. In some cases ( Thunderbolt, changing curve fans of a GPU, etc.. ) SSDTs were more efficient or easier to manage than DeviceProperties. The issue with SSDTs was that if you're not using OSX ( Windows, Linux, etc..) Your side OS might be prone to erratic behaviors because you're feeding it an OSX argument.

In the past, a user called NDK created a custom version of OpenCore adding a quirk to disengage SSDTs if you're not using OSX. I loved his approach. Unfortunately, the devs of OpenCore did not see eye to eye and refuse to add his quirk in their releases. I know that you can add the "IF" argument in SSDTs to restrict their loading exclusively to OSX but still..

As Hackintosh users, we are in some sense artists, pirates or pioneers , so we have to try different ways in approaching problem solving ( and not always follow what everyone says :lol: ). So, the only advice I can give you is: "If It bugs you, try something else" ;)

Since the last few months I got rid of all my SSDTs. I wanted my EFI to be as "Vanilla" as possible. Because my WU-8 does not need SSDTs for EC, RTC, AWAC to boot. ( Even with Big Sur ), I only used SSDTs for USBX & CPUPM, but I decided to get rid of them.

USBX:
The longest part was to map all my USB ports , Including TB & Inateck PCIe USB card , in my USBPorts.kext . After this was done, I incorporated the properties of SSDT-USBX in the kext, verified that the properties were loaded without the SSDT & got rid of that SSDT. This approach is explained here by @Loloflatsix :
What will you gain?
- Saying goodbye to SSDT-USBX
- No more 15 ports limits. (22 XHCI working ports on WU-8 )

PLUG ( XCPM ):
MacOS native power management is NOT mandatory. ( if it bothers you, think of it this way: If it was mandatory, the devs of OpenCore would have integrated it as part the bootloader , not as a separate SSDT. Performances are similar. Only differences can results in improper sleep, higher temperature or higher power consumption. If your Bios can handle XCPM properly ( it should ) & no bugs above are reported, you can get rid of it.

Thankfully, works great on my system ( 18c @ 4.9Ghz - 1.2Ghz in Idle : 6 Speedsteps ) . Sleeps/Wake also work.
Zero bug. Using it this way for the past 4 months.
Cinebench score in BS are above 10000pts but a bit lower than Mojave/Catalina ( 10400) . Still better than the 2020 MacPro 28cores.

PS: I'm using a Music Producer & I use my system for work under heavy loads 18/6 and and it is completely stable. Not a single KP.
Many tools exist to verify that your XCPM is working properly. Look it up.

I'm attaching my EFI below. ( Mojave /Catalina /Big Sur ). I do not use WIFI. I have a USB Key for bluetooth.
Airplay also works.

Today is Sunday so, relaxing day, I could respond to your post. I'm usually quite busy with work, so If don't respond in the future, thanks for understanding.
All my best and Good luck.

If you read all my thesis, kudos to you :lol:

Slot 1: IEEE1394
Slot 2: TB Alpine Ridge
Slot 3: RME Audio Card
Slot 4: Inateck KT5001
Slot 5: Asus Hyper M.2
Slot 7: GPU RX580
( All Recognized via Deviceproperties )

Screen Shot 2020-11-15 at 21.59.46.png
 

Attachments

  • Ellybz EFI OC063.zip
    2.8 MB · Views: 38
Last edited:
Joined
Mar 6, 2013
Messages
274
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
AMD 6900XT
Mobile Phone
  1. Android
Wow, thanks so much @Ellybz for the detailed response. That's extremely useful.
Today is Sunday so, relaxing day, I could respond to your post. I'm usually quite busy with work, so If don't respond in the future, thanks for understanding.
All my best and Good luck.
I quite understand. I do have a few more questions, but please don't feel any urgency to respond. Your excellent post has given me plenty to research and test. And I think I should take the time to read the 75 pages of that Big Sur X299 thread, which I am sure will teach me even more.

My position has evolved since July. In some cases ( Thunderbolt, changing curve fans of a GPU, etc.. ) SSDTs were more efficient or easier to manage than DeviceProperties. The issue with SSDTs was that if you're not using OSX ( Windows, Linux, etc..) Your side OS might be prone to erratic behaviors because you're feeding it an OSX argument.

In the past, a user called NDK created a custom version of OpenCore adding a quirk to disengage SSDTs if you're not using OSX. I loved his approach. Unfortunately, the devs of OpenCore did not see eye to eye and refuse to add his quirk in their releases. I know that you can add the "IF" argument in SSDTs to restrict their loading exclusively to OSX but still..
Yeah, dolgarrenan was using that NDK fork. It's a big shame that the OC developers decided not to integrate those changes, because it would simplify a lot of things. I kind of understand their reasoning - that SSDTs should be set up correctly - but that doesn't account for ACPI patches, and my understanding is that not all ACPI patches can be converted to SSDTs. Or at least, not necessarily in a simple way.

Even when they can be it's extra work and not everyone understands how, myself included at the moment. It feels to me that it could save a lot of users a lot of effort if OpenCore could be optionally configured to only apply SSDTs and ACPI Patches to macOS. Oh well!

I went through all my SSDTs and added those IF statements and that generally seems to work OK. I don't think I've done it perfectly, as I didn't understand exactly where I needed to put the IF, so I basically surrounded the whole of each SSDT in an IF _OSI ("Darwin") { ... }. That's not how the Dortania SSDTs do it, but it does seem to work - I can dual-boot Windows and macOS.

However dolgarrenan's config also had a lot of ACPI patches, which I think he sourced from KGP's original config. Having all those patches in config.plist would always break Windows boot. Many I think were cosmetic, changing names to resemble a real Mac Pro 2019, like FPU -> MATH and renaming the CPUs to start FP. Those could be removed fairly easily.

But at least one has proved stubborn: renaming _DSM to XDSM. Without this patch I have been unable to load dolgarrenan's XHC SSDT, as it applies a _DSM on several USB devices, and this triggers an AE_ALREADY_EXISTS error because that/those device(s) already have a _DSM in the system DSDT.

Then I found that I could still boot Windows even with the _DSM -> XDSM ACPI rename, so currently that is the one ACPI patch I still have enabled.

But like you said I would much prefer a 'clean' EFI that changes nothing for Windows. Hence my starting to look at DeviceProperties instead, so I can try and avoid using _DSM in any SSDT.

As Hackintosh users, we are in some sense artists, pirates or pioneers , so we have to try different ways in approaching problem solving ( and not always follow what everyone says :lol: ). So, the only advice I can give you is: "If It bugs you, try something else" ;)
Yeah, this has caused me some confusion. I've been unsure as to what the 'right' solution is, but recently have realised there likely isn't a single correct answer, but instead various different configuration options and styles, many of which could work OK.

To be clear, I don't have a problem with using SSDTs in general. What I ideally want to achieve is a config that is perfect in both macOS and Windows. So I'd definitely like to avoid ACPI patches, given that OpenCore will apply these to all operating systems.

I don't mind a few SSDTs because they can have that IF statement. But if the SSDT then requires an ACPI patch - like the XHC SSDT currently does - then yes I would like to get rid of it, even when that ACPI patch seems to boot Windows OK (who knows what issues there could be in Windows that won't show up until much later.)
Since the last few months I got rid of all my SSDTs. I wanted my EFI to be as "Vanilla" as possible. Because my WU-8 does not need SSDTs for EC, RTC, AWAC to boot. ( Even with Big Sur ), I only used SSDTs for USBX & CPUPM, but I decided to get rid of them.
Yours is the first EFI I have ever seen with zero AML files! This is really cool and very interesting.
USBX:
The longest part was to map all my USB ports , Including TB & Inateck PCIe USB card , in my USBPorts.kext . After this was done, I incorporated the properties of SSDT-USBX in the kext, verified that the properties were loaded without the SSDT & got rid of that SSDT.
What will you gain?
- Saying goodbye to SSDT-USBX
- No more 15 ports limits. (22 XHCI working ports on WU-8 )
This is really cool. I had not realised this was possible. I'm definitely going to try this method, so I can remove that XHC SSDT which should allow me to also remove the _DSM -> XDSM ACPI patch.
PLUG ( XCPM ):
MacOS native power management is NOT mandatory. ( if it bothers you, think of it this way: If it was mandatory, the devs of OpenCore would have integrated it as part the bootloader , not as a separate SSDT. Performances are similar. Only differences can results in improper sleep, higher temperature or higher power consumption. If your Bios can handle XCPM properly ( it should ) & no bugs above are reported, you can get rid of it.

Many tools exist to verify that your XCPM is working properly. Look it up.
This covers another thing I had not understood. I was asking earlier in this thread: "what does it actually mean to have power management working?"

When I first booted with the config in the OP, I did not have XCPM working, at least according to Dortania's definition: I did not have X86PlatformPlugin attached to the first core. But then when I looked in HWMonitor and Intel Power Gadget, I could see the cores were adjusting their speed from 1200Mhz up to 4600Mhz, and that the fans were spinning up and down according to load, etc.

So I didn't really understand what would be different if power management was 'working'.

I will Google those sources you mentioned to confirm whether power management is functional, and will try them with and without the PLUG SSDT.

My current thought is that if there is no downside to it, I will still have the PLUG SSDT installed, with the IF to prevent loading in Windows. But I'd definitely like to understand better how PM works with and without X86PlatformPlugin.

Thankfully, works great on my system ( 18c @ 4.9Ghz - 1.2Ghz in Idle : 6 Speedsteps ) . Sleeps/Wake also work.
Zero bug. Using it this way for the past 4 months.
Cinebench score in BS are above 10000pts but a bit lower than Mojave/Catalina ( 10400) . Still better than the 2020 MacPro 28cores.
Very nice! Currently the best I can achieve with my AIO is 18c @ 4.6Ghz, but I have ordered parts for a full custom water loop which will be with me in a week or so I hope (all parts coming from Germany), and I hope then I can get at least 4.8, maybe 4.9.

Speaking of sleep/wake, do you happen to know any more about why we need AppleXcpmCfgLock on our Gigabyte motherboards?

I have confirmed that CFG LOCK is definitely unlocked via VerifyMsr, and I even tried the UEFITool patching method (with Modified Grub Shell) to set it to 0x00 just in case.

Which makes me wonder : could it be that there's some other variable that's still locked, and which could be unlocked via UEFITool?

Again it would be great to have things as 'clean' as possible, meaning it'd be nice to be able to disable AppleXcpmCfgLock if there was some way to patch the BIOS to make it unnecessary. The docs describe it as a hack, and the fewer hacks the better it seems to me.

Have you or anyone done any testing or research on that for GB motherboards?

Slot 1: IEEE1394
Slot 2: TB Alpine Ridge
Slot 3: RME Audio Card
Slot 4: Inateck KT5001
Slot 5: Asus Hyper M.2
Slot 7: GPU RX580
( All Recognized via Deviceproperties )
Really cool, and exactly what I hoped would be possible.

Final question: I see you are using iMacPro SMBIOS. Can I ask what makes you decide to use that vs Mac Pro 7,1? Is there any clear pro/con to choosing either? Or is it more a case of personal preference?

I am on Mac Pro 7,1. I chose this because a) Dortania's SMBIOS guide lists Mac Pro 7,1 as a "Cacade Lake-W" system, versus Skylake-W on iMacPro, and my system is Cascade Lake X, and b) I felt that Mac Pro better fits our hardware, both in terms of performance (when overclocked) and upgrade-ability.

But I see a number of users, yourself included, using iMacPro, which makes me wonder if there's some reason I should consider using that instead?

If you read all my thesis, kudos to you :lol:
No, kudos to you for the great explanation! Thank you again for taking the time to explain all this to me, it's been super helpful.
 
Last edited:
Joined
Apr 17, 2020
Messages
26
Motherboard
Gigabyte Designare x299x
CPU
10980xe
Graphics
Radeon VII
@TheBloke A quick follow up on my upgrade to 0.6.3 using the provided EFI folder. Well, it did not go well. Somehow using the specific acpi SSDT's resulted in my opencore partition crashing. First, I had to modify some things in the EFI to make the scripts run (as it would do nothing initially). It then ran the scripts and tried to do the installation at boot (with verbose enabled I could see the scripts running correctly). However, it would post an airport message (i'm assuming referring to the airport kexts) and this would make the computer endlessly reboot. In the end, my windows OS somehow also was also damaged due to the opencore corruption. This I couldn't make sense of as they are installed on seperate SSD's. But it took it down with it. Eventually i had to reinstall & restore both OS's from backups and reused an previous EFI to get Opencore and Windows back running. Another day when I'm feeling brave again, I will give it another shot with a clean EFI. I, too, am wondering why those files are working for others here and not me.
 
Joined
Mar 6, 2013
Messages
274
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
AMD 6900XT
Mobile Phone
  1. Android
I'm sorry you're having such trouble, @robdaghost . I can't really understand what's happening.

First, I had to modify some things in the EFI to make the scripts run (as it would do nothing initially).

The only thing that should have needed editing in the EFI is the SMBIOS, filling in your serial number etc, where I wrote "CHANGEME". When you say you edited it, what did you change exactly?

In the end, my windows OS somehow also was also damaged due to the opencore corruption. This I couldn't make sense of as they are installed on seperate SSD's. But it took it down with it.

Did you remember to clear NVRAM on your first boot with the new EFI? It's the last option in the OpenCore boot menu.

In what way exactly was Windows damaged? And how were you trying to boot it? Remember that the EFI I uploaded cannot boot Windows from the OpenCore boot menu. Windows has to be booted from the BIOS Override Menu. Attempting to boot Windows from OpenCore using the EFIs so far uploaded to this thread (mine, dolgarrenan's, etc) will quickly fail with an ACPI_BIOS_ERROR blue screen, on account of both the ACPI patches and the SSDTs, which OpenCore will apply both to macOS and Windows.

If Windows fails on boot too many times it can then cause future Windows boots to bring up the "Repairing Windows" menu (can't remember the exact name), but in that menu you can just choose to reboot and then subsequent boots will work fine - at least if they're done from the BIOS Boot Override menu.

I do now have an EFI that can dual-boot macOS and Windows, directly from the OpenCore boot picker, but I've not posted it yet as I'm still working on refining the SSDTs. Later today I will upload in its current state, which at least can dual-boot Windows.

However, it would post an airport message (i'm assuming referring to the airport kexts) and this would make the computer endlessly reboot.
I've definitely not seen that problem. The only Airport kext is AirportBrcmFixup, which is only of any use if you have replaced your WiFi mini-PCIe card with a Broadcom model.

You could just disable this kext if it did seem to be causing problems.

However I've booted with AirportBrcmFixup enabled many times - without having a Broadcom WiFi installed - and it doesn't cause any issues for me at all; the kext just doesn't load if the device isn't found. So maybe it's another problem.

In this sort of situation it would be useful to get a photograph or video of the errors so we can help debug. Also, if the reboot is caused by a kernel panic, there's an OpenCore setting that gives you a log of that panic in your EFI partition, in a file called panic-<date>.txt.

I think I had that enabled in the EFI I uploaded, but I'll make sure it's definitely enabled in the next EFI I upload.

It then ran the scripts and tried to do the installation at boot (with verbose enabled I could see the scripts running correctly).
What do you mean by 'scripts'? The SSDTs?

Were you doing a fresh installation of macOS? Or booting an existing install? I haven't actually tested a new installation of macOS, so I can't 100% confirm that works. But I'd be quite surprised if it didn't. I have done several upgrades (eg Catalina security update, and Catalina -> BigSur) using this EFI, and they were successful.

What version of macOS were you installing / attempting to run?

Do you have any extra PCI devices installed, besides the GPU?

If you upload the exact EFI you had these issues with, I will look at it and try it on my system and try and work out what was causing you all these problems.

Later today I will upload my current EFI. It's not complete yet but it is working well for me, and can now dual-boot Windows direct from OpenCore.
 
Last edited:
Joined
Mar 6, 2013
Messages
274
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
AMD 6900XT
Mobile Phone
  1. Android
INTERIM EFI - GB Designare 10G - OpenCore 0.6.3 - Windows and macOS Dual Bootable

Here's my current EFI file, primarily for @robdaghost . It is not yet complete as I would like it, as I plan to do a lot more changes to SSDTs and DeviceProperties, along the lines of what I was discussing with Ellybz.

But it's working OK for me, and unlike previous EFIs should work fine for dual booting Windows and macOS (and probably Linux too - untested) directly from OpenCore.

EFI summary / changes compared to previous EFI:
  1. Dual boot with Windows, direct from OpenCore boot picker, tested and working.
  2. Working power management, via fixed SSDT.
  3. Working sleep, via disabling cosmetic properties for SBUS.
  4. Working wake, via enabling AppleXcpmCfgLock.
  5. Set BootProtect=BootStrap, which creates a permanent OpenCore boot option, preventing Windows upgrades from breaking OpenCore boot
  6. All ACPI patches removed, except for _DSM -> XDSM which remains required for the XHC SSDT. I hope to remove this patch also in future. This patch does not seem to affect Windows.
  7. SSDTs edited so they didn't require the ACPI Patches included in dolgarrenan's config.
  8. SSDTs edited to include IF statement such that they only load in macOS.
    1. I don't think I've done this in the ideal way, as for many SSDTs I just surrounded the whole SSDT in a big IF statement. But it does seem to work. I'll work on improving this later.
  9. DeviceProperties used to inject cosmetic properties for a couple of devices, namely Intel X550 NICs and Intel AX200 WiFi. These values were then removed from the appropriate SSDT.
    1. This is a work in progress - in future I plan to have most or all such properties set via DeviceProperties, not SSDTs.
  10. All kexts upgraded to their latest versions.
  11. Added driver kexts for:
    1. SmallTree Intel NIC drivers, version 3.8.6 patched
      1. If you already have this installed in /L/E, you can disable the kext in config.plist.
    2. AirportItlwm, providing basic (slow) WiFi on our included Intel AX200 WiFi card, with some Continuity support - namely Shared Clipboard and Handoff.
      1. Disabled in config.plist by default, and requires Secure Boot to be enabled for it to work - see instructions below.
      2. I've not managed to get Handoff or Shared Clipboard working yet myself. But basic WiFi does work.
  12. Organised kexts into two folders: Acid for Acidanthera kexts, Other for everything else.
  13. All Acidanthera kexts are DEBUG versions, allowing debug to be enabled via boot-args. Debugging is not enabled in the current config.plist.
    1. To enable logging for all Acidanthera kexts at once (will be very verbose), add -liludbgall boot arg.
    2. To enable logging for an individual kext, check its GitHub page for the arg to use. For example, WhateverGreen is -wegdbg.
  14. OpenCore is also DEBUG, and debugging IS enabled, via Target setting. Currently it will log to disk, but not to screen (screen debugging slows down boot a lot.) Change Target to 0to disable all logging.
    1. However I recommend it's left enabled until the EFI is confirmed working for you.
    2. I added an XML comment describing various options for the Target setting, eg for enabling logging to screen, to disk or both.
  15. Added numerous comments throughout the file, both in comment sections and as XML comments. These comments explain the purpose of the SSDTs, kexts and DeviceProperties, and give some information on a few OpenCore configuration values.
Instructions for use (primarily for @robdaghost )
  1. Edit the config.plist to change the three CHANGEME values in PlatformInfo -> Genericto match your current SMBIOS values.
    1. The SMBIOS is set up for MacPro 7,1. It should work fine on iMacPro 1,1 also, but I've tested primarily on MacPro 7,1. If you want to use iMacPro 1,1 you'll need to edit the SystemProductName also.
  2. No other changes should be needed in the EFI to boot.
    1. If you find you need to change something else, then something is probably wrong. Check your BIOS settings (I uploaded a basic F3C BIOS config a few days ago), and/or report back.
  3. On the first boot, clear NVRAM via the last option in the OpenCore boot picker. This will trigger a reboot. After the system comes back up you can then launch macOS from OpenCore.
    1. Do not attempt to boot macOS without clearing the NVRAM first, as it may fail. You shouldn't need to clear NVRAM again after this.
  4. As discussed before, never boot OpenCore from the F12 boot menu, BIOS Boot Override menu, or after having been in the BIOS and "Exit Without Saving".
    1. The one exception is if you need to boot OpenCore from a USB drive, eg because your main SSD/NVMe config is broken. Trying to boot with two OpenCore EFIs visible will trigger the boot issue.
    2. In this scenario, boot the USB from the Boot Override menu. The first boot will fail after 10 second, then you can try again and it will succeed. RAM will go down to 2666Mhz and any CPU overclock will be temporarily disabled.
    3. As soon as you're ready to boot normally again from NVMe/SSD, remove the USB stick, go into the BIOS and hit F10 to re-apply BIOS settings, then let OpenCore boot normally.
  5. I would strongly recommend to test with an existing macOS Catalina installation, and not to try either a new install, or Big Sur, at least not until you've confirmed everything works on an existing Catalina install.
    1. Failed boots should not be able to break your existing macOS install - at least not in Catalina and prior versions of macOS. BigSur may be a bit different due to its filesystem changes.
    2. I've had hundreds of failed boots over the years, in both Clover and OpenCore, and I'm still using the same macOS install I've had since 2015.
    3. I believe BigSur will work with this config - though it might require SecureBootModel as described below - but I've not yet really tested it.
  6. I would recommend to test the first boot without a Windows SSD installed, to simplify things. It shouldn't affect anything, but keep things simple on the first try.
    1. Once macOS is confirmed working, the Windows SSD/NVMe can be re-added, and Windows boot can be tested from the OpenCore boot menu.
  7. To set macOS as the default boot option within OpenCore, launch it from the OpenCore boot picker with Control-Enter.
  8. In order to install Big Sur or upgrade to it I believe you will need to change SecureBootModel to Default, or j160 (for MacPro 7,1 SMBIOS). There is a comment in the config file explaining a bit more about this.
  9. AirportItlwm is disabled. If you enable it, you must first change SecureBootModel, as described in point 8; AirportItlwm will not load unless a Secure Boot is done (or if IO80211 is injected, but I have not configured for that in this EFI.)
    1. I would do all testing with AirportItlwm disabled, and only enable it if a) you still have the original Intel AX200 WiFi installed, b) you want to use WiFi, and c) you've confirmed you can boot macOS OK without it.
  10. If/when you're happy that everything is working, you can disable all DEBUG logging by changing Target to 0. You could then optionally replace the OpenCore install with the RELEASE version.
  11. If you get a kernel panic on boot, the text of the KP will be logged to /Volumes/EFI/panic-*.txt, which can be very useful for debug.
  12. Note that if you boot the EFI from a USB stick rather than NVMe:
    1. Ideally you don't want to do this if there is also an OpenCore EFI on the NVMe/SSD, as otherwise you'll hit the usual boot failure BIOS issue. If you need to anyway, see point 4.
    2. With the current config.plist debug settings, boot will be VERY slow. This is due to the logging to disk being very slow on USB. It may take several minutes, including some time at a black screen before the boot picker appears. Just be patient, it is working.
    3. If you want to test from USB and the delays get too annoying, change Target to 0 on the USB EFI.
If you get problems, try to take photos and/or videos of the boot process and upload them here. Also get the latest /Volumes/EFI/opencore-*.txt log files (which will be created when Target = 65, as it is in the provided EFI) and upload them here. Ditto any /Volumes/EFI/panic-*.txt files.

Good luck! Do report back if you get any problems, and include as much debug information as possible.
 

Attachments

  • TheBloke.OpenCore.0.6.3-DEBUG.EFI.17112020.zip
    73.5 MB · Views: 44
Last edited:
Top