- Mar 6, 2013
- Gigabyte X299X Designare 10G
- AMD 6900XT
- Mobile Phone
Sure. First thing to let you know is that the initial basis for this EFI was @dolgarrenan's work in this thread: https://www.tonymacx86.com/threads/gigabyte-x299x-catalina-support.288625
He got the motherboard first, and did a great deal of the initial testing and setup. Therefore a lot of the SSDTs were first created, or collected together, by him. Some I have later modified, along with the config.
The EFI as uploaded is 100% functional in Catalina and Big Sur, but not complete in terms of cosmetics and tidying up. This is something I'm still working on.
To be clear, I've never uploaded the EFI as a complete and recommended EFI, only to help anyone getting stuck and to discuss with other users (especially in that other thread, listed above). It definitely needs some cleaning up throughout, and there are a number of SSDT related things that I still don't understand myself.
I certainly don't have KPs on boot. As per the docs, it should only affect safe mode. Not sure why that's false. Possibly I was experimenting and turned it off and forgot to turn it back on. Perhaps it should be True, though I have successfully booted once into safe mode with this config, so also possible that it's not needed on our board.
Strange, I have it as false in all my EFI backups. Again, I must have been experimenting and forgot it was enabled. Can definitely be set to false, though does no harm at true.
We have a very annoying and unique bug on the Designare motherboard, that you've probably already seen - the boot failure issue caused by booting from BIOS Boot Override, F12 boot menu, or after being in the BIOS and then "Exit without saving". It's discussed at length in that thread above. It also often occurs when there are two OpenCore EFI partitions visible to the BIOS at once, eg when booting from USB stick with an SSD also installed.
In the course of trying to debug and fix this issue, I've tweaked a number of Quirks. So far, completely unsuccessfully.
False because the OpenCore Configuration checker shows it as being suggested as FALSE. I've had it TRUE before also, and noticed no difference. Given that description, probably it has no effect at all on our 200-series system.
This one I turned off deliberately, because an OpenCore debug message stated that it's not required on my system.
I enabled it to get full functionality of Bluetooth including Continuity I haven't been able to confirm whether it actually has improved Continuity support, because I can't yet get Continuity working with AirportItlwm. It replaces an old kext, Bluetooth4LEContinuityFixup.kext.ExtendBTFeatureFlags (You: TRUE, Dortania: FALSE, OC doc: "Set FeatureFlags to 0x0F for full functionality of Bluetooth, including Continuity" ) Why do you need this?
If you don't plan to use Continuity you can probably set it to False, and definitely if you won't use bluetooth at all.
I never quite understood which way round this should be. "PanicNoKextDump" implies that TRUE = you won't get kext dumps. So I set it to false. I am getting panic dump info when I get kernel panics.
Maybe it should be true, not sure.
Correct.And you're using a lot of ACPI patches:
SSDT-X299X-DESIGNARE10G-DTGP.aml: "Required for DSDT patching"
Yes, I don't know what dolgarrenan added this. You'll see it's disabled in config.plist. Remove it.SSDT-X299X-DESIGNARE10G-ALS0.aml: I thought this is for Laptops only?
Same purpose yes, but containing only the code needed for this motherboard - the full SSDT-PLUG.aml is much larger, as it covers all possible permutations of CPU names.
The Dortania guide has a combined EC-USBX listed as required for Skylake-X/Cascade Lake-X, as did dolgarrenan's original EFI, so that's what I'm still using. I haven't specifically checked as to whether the EC part is needed or not. Maybe you're right and the EC part isn't needed, I don't yet know.SSDT-X299X-DESIGNARE10G-PC00-EC-USBX.aml: "Hides the firmware embedded controller and fixes some USB problems" Do you have an EC in your firmware? I haven't found PNP0C09 in my System DSDT. USBX is necessary thou.
As with PLUG, this is basically the same as SSDT-RTC0-RANGE but containing only the code needed for this motherboard.
This is a kext that dolgarrenan sourced and I don't know what most of it does - you'll see I posted questions about this just today. I edited it to have the right name for my GPU, but the rest is unaltered and I don't yet understand the rest of the contents. It's on my list to research.
I currently have this disabled in config.plist, until I understand better what it's doing, and whether any of the advanced code is needed on my GPU.
100% cosmetic I believe.SSDT-X299X-DESIGNARE10G-PC00-NVMeSSD.aml: Same thing here. You added the third controller of the board. But what does it do? Wha't not working without it? Cosmetic?
I use DeviceProperties for cosmetics on this device. Renaming the device is again something inherited from dolgarrenan (and maybe KGP before him) which I've been trying to understand whether is purely cosmetic or important. I believe now it's likely entirely cosmetic, and therefore this SSDT is not important.SSDT-X299X-DESIGNARE10G-PC00-ARPT-INTEL-NODSM.aml: Rename _SB_.PC00.RP01.PXSX->ARPT, right? Why don't you use the config.plist patch section? Cosmetic?
I don't use ACPI Patches because in OpenCore they will apply to all operating systems, with no way to configure them to apply only in macOS. Therefore they should be avoided if at all possible by anyone planning to boot other operating systems from OpenCore, eg Windows.
Cosmetic, can be done with DeviceProperties.SSDT-X299X-DESIGNARE10G-PC00-ARPT-BRCM.aml: Cosmetic?
Cosmetic, can be done with DeviceProperties.SSDT-X299X-DESIGNARE10G-PC00-ASMEDIA-SATA.aml: Cosmetic?
Not looked into it yet, as I don't use the onboard audio at all. I have a USB sound card.SSDT-X299X-DESIGNARE10G-PC00-HDEF.aml: _SB_.PC00.CAVS->HDEF and naming right?
I plan to test onboard audio at some point, just for completeness, but haven't done so yet.
Nope, works fine for me with and without this SSDT. Probably just cosmetic, or else not required.SSDT-X299X-DESIGNARE10G-PC00-PMCR.aml: Dortania doc: "This SSDT is required for all "true" 300 series motherboards(Z370 is excluded), it specifically brings back NVRAM support and requires very little configuration for the end user." NVRAM works fine for me without the patch. Does it not work for you?
Users of some other X299 motherboards are having major NVRAM problems and have experimented with using this SSDT to fix them, but with no luck so far.
Only cosmetic as far as I know. dolgarrenan's original version broke sleep, which I traced back to the _DSM properties in this SSDT. So I removed them and went with this version. But, again, it can be removed.SSDT-X299X-DESIGNARE10G-PC00-SBUS-NEW.aml: Dortania doc: "AppleSMBusController: Aids with correct temperature, fan, voltage, ICH, etc readings. AppleSMBusPCI: Same idea as AppleSMBusController except for low bandwidth PCI devices. Memory Reporting: Aids in proper memory reporting and can aid in getting better kernel panic details if memory related." What's the benefit of this patch?
Yes, I believe so. I don't yet have any TB3 devices to test. And I think possible it's only required if TB3 firmware patching isn't done, which is something I plan to try sometime soon. There's a lot more info on this in the X299X thread I link above.SSDT-X299X-DESIGNARE10G-PC00-THUNDERBOLT.aml: Necessary for TB3 plug and play, right?
I believe cosmetic. Originally applied properties to the 10GBe GPUs. I moved those properties to DeviceProperties, so now all this does is rename the devices (I think XGBE and XGBF?) I'm not yet aware of any functional benefit to having them renamed, so almost certainly can be removed.SSDT-X299X-DESIGNARE10G-PC00-X550T-NODSM.aml: cosmetic?
USB stuff. This is something I need to understand better, and I will likely remove it eventually. As you'll see in this thread, many of the X299 users here are going for a non-SSDT approach to USB handling, using a USB.kext that does all USB mapping. I plan to go the same way also. In the meantime, this SSDT gets all USB controllers named (cosmetic?) and I believe ensures all USB ports work (at least with XhciPatchLimit = true).
The system will run flawlessly - possibly with the exception of full USB port support - with only the following SSDTs loaded:Have you tried to remove a few of you patches and check whether you system sit still running flawlessly? I guess a few things might not be necessary.
On top of that you're likely to want to add some form of USB mapping. But nothing else appears to be required for day-to-day operation. Though I still want to understand the potential benefits of a GPU SSDT or DeviceProperties, as per my recent post in this thread, and some observations I made about differences noticed when having a GPU SSDT/DeviceProperties.