Hey
@TheBloke!
Can you elaborate on a few settings that differ from the Dortania guide?
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.
EnableSafeModeSlide (You: FALSE, Dortania: TRUE,
Github doc:
"Patch the bootloader to enable KASLR in safe mode.") I assume you don't have Kernel Panics on boot?
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.
ProtectMemoryRegions (You: TRUE, Dortania: FALSE,
Github doc:
"Protect memory regions from incorrect access. Only needed by very old firmwares.") Why do you need it?
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.
ProtectUefiServices (You: FALSE, Dortania: TRUE,
Dortania doc:
"Protects UEFI services from being overridden by the firmware, mainly relevant for VMs, 300 series and newer systems like Ice Lake and Comet Lake.") Why don't you need it?
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.
ProvideCustomSlide (You: FALSE, Dortania: TRUE,
Dortania doc:
"This makes sure the kernel will only choose good regions and avoid those that may result in boot failures. It's still random but omits those bad regions in its randomization") Why don't you need it?
This one I turned off deliberately, because an OpenCore debug message stated that it's not required on my system.
ExtendBTFeatureFlags (You: TRUE, Dortania: FALSE, OC doc: "Set FeatureFlags to 0x0F for full functionality of Bluetooth, including Continuity" ) Why do you need this?
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.
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.
PanicNoKextDump (You: FALSE, Dortania: TRUE,
Dortania doc:
"Allows for reading kernel panics logs when kernel panics occur") Why don't you need it?
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.
And you're using a lot of ACPI patches:
SSDT-X299X-DESIGNARE10G-DTGP.aml: "Required for DSDT patching"
Correct.
SSDT-X299X-DESIGNARE10G-ALS0.aml: I thought this is for Laptops only?
Yes, I don't know what dolgarrenan added this. You'll see it's disabled in config.plist. Remove it.
SSDT-X299X-DESIGNARE10G-PC00-PLUG.aml:
Dortania doc:
"The purpose of SSDT-PLUG is to allow the kernel's XCPM(XNU's CPU Power Management) to manage our CPU's power management" Same as OC ACPI
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.
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.
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-RTC0.aml:
Dortania doc: "The purpose of SSDT-AWAC/RTC0 is to fix the system clocks found on newer hardware". Why is your version better than the OC ACPI Sample/SSDT-RTC0-RANGE.aml?
As with PLUG, this is basically the same as SSDT-RTC0-RANGE but containing only the code needed for this motherboard.
SSDT-X299X-DESIGNARE10G-Vega64.aml: It's based on works from
KGP but modified. You removed the overclocking, right? What else does it do? I do understand the naming, but not the other stuff. Do you have any glitches without it?
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.
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?
100% cosmetic I believe.
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 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.
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.
SSDT-X299X-DESIGNARE10G-PC00-ARPT-BRCM.aml: Cosmetic?
Cosmetic, can be done with DeviceProperties.
SSDT-X299X-DESIGNARE10G-PC00-ASMEDIA-SATA.aml: Cosmetic?
Cosmetic, can be done with DeviceProperties.
SSDT-X299X-DESIGNARE10G-PC00-HDEF.aml: _SB_.PC00.CAVS->HDEF and naming right?
Not looked into it yet, as I don't use the onboard audio at all. I have a USB sound card.
I plan to test onboard audio at some point, just for completeness, but haven't done so yet.
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?
Nope, works fine for me with and without this SSDT. Probably just cosmetic, or else not required.
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.
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?
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-THUNDERBOLT.aml: Necessary for TB3 plug and play, right?
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-X550T-NODSM.aml: cosmetic?
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-XHC.aml: It's based on works from
KGP but modified. You added he third controller, right? What else does it do? I do understand the naming, but not the other stuff. Do you have any glitches without it?
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).
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.
The system will run flawlessly - possibly with the exception of full USB port support - with only the following SSDTs loaded:
> PLUG
> RTC0
> EC-USBX
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.
