Gigabyte X299X - Catalina Support

[TheBloke]

'm just off to bed but tomorrow I'll upload a latest EFI and some BIOS settings to go with it.

I'm on Catalina and I haven't really tested Mojave, although I did boot Mojave a couple of times before I did the initial upgrade from Mojave to Catalina (my older system is Mojave 10.14.6).

Regarding BIOS settings, there's actually very little that needs to be changed to get you at least booting and mostly usable:

> CSM = disabled
> Above 4G Decoding = Enabled (required for working USB and Ethernet; at least it was for me)
> Fast boot = disabled (I think this is default anyway)
> Secure boot = disabled (I think default)
> VT-D = disabled (if you don't have the appropriate OpenCore config for this, but the EFI I posted does so it can be left at Enabled)

I'm pretty sure that from a completely default BIOS ("Load Optimized Defaults"), just checking those four settings is enough to get booted if you have the right config. It's probably good to set C6/C7 = Enabled and maximum C state = C6, though I haven't tested it to confirm its effect yet.

Anyway I'll give you an F3C BIOS config tomorrow so you can be sure.

It did not do this with the generic SSDT's, so that's why I was using those instead.

Yeah, and you can probably get nearly everything working OK with the generics. Since I wrote that message to you I've done more experimenting with the generic SSDTs and I haven't actually found a huge amount of difference with those vs dolgarrenan's customised SSDTs. I know that dolgarrenan's SSDTs result in About This Mac -> PCI showing correct data, but in terms of practical, important effects, I haven't really found any yet.

His SSDTs are probably required for working Thunderbolt 3 but I for one am not yet trying TB3 so I can't yet speak to that.

I actually just got into a situation where I can't currently boot my config that uses the customised SSDTs, it hangs early in the boot process - similar to what you described. I'm going to debug it tomorrow, but the one thing I changed recently was I started using a GPU SSDT, where previously I'd not. I used dolgarrenan's as a base and just changed the GPU name for my GPU, and that may be introducing problems. So that could be a reason you found it couldn't boot. I removed the GPU SSDT from my EFI very early in my testing, so you won't find it in the EFIs I've posted.

Anyway, I do know that the 0.6.3 EFI I posted should definitely boot fine, at least on Catalina and hopefully therefore also on Mojave.

It won't have working sleep/wake, and it won't have fully working power management (though it does seem to mostly work, and I'm yet to understand the exact difference made by having it working 'fully' as per Dortania guides). But it should boot, run apps, get decent performance, etc.

Just remember to always boot it 'normally' - meaning, don't use F12 boot menu, don't load it from the BIOS Boot Override menu, and if you go into the BIOS but don't change anything, hit restart - don't do "Exit without saving". Any of those booting methods will give the dreaded boot failure restart. But booting normally (a 'straight through' boot as I call it) should work fine with the EFI I uploaded.

Note that the EFI won't have any onboard LAN, for that you'll need to install the SmallTree drivers (from the first post) into /Library/Extensions and then update kextcache - or use a utility to do that, like Hackintool. Or you can add the SmallTree drivers to the EFI as byteminer is, though he also reports non-working ethernet, so that may not be the best idea.

I'll post another interim EFI tomorrow which will have working power management, updated NVMefix, and will enable sleep (but not yet wake). And I'll post a non-overclocked BIOS config to go with it.

Also please note that i did not do any of the disassembly of my motherboard for thunderbolt as indicated in the first post. I do not know if this prevents things from working the same way it does for you guys

I haven't done this either yet. I don't believe this should be a block to getting a working, bootable system. I think it should only affect the usage of certain TB3 devices.

It's still possible that it might in some way affect sleep/wake, but I think that's now looking unlikely.

 

[TheBloke]

Display and mac os sleeps, but hardware not completely as it reawakens. I believe hardware sleep is not functioning because of "darkwake=0". i will try playing with this later.)

Can you explain what you mean exactly? When you trigger sleep, does your PC power down properly? Ie lights go off on the mouse, fans stop spinning, etc? But then at some point later it automatically powers on again? If so, how long before it powers back on?

If the fans never stop spinning and the mouse (if you have one) never goes dark, then that's not actually going to sleep at all. That's the issue I had until recently - the monitor goes dark and shows no signal, but the PC itself never powers down and USB devices etc remain active. Logs show it never went to sleep at all.

But if you are getting a full proper sleep in which the PC does power down - even if it then wakes up again some time later - then you're doing better than we are. In which case that could point to Mojave vs Catalina, which would be interesting and useful to know. I can test with Mojave fairly easily, and will do that tomorrow.

 

[TheBloke]

Hey guys

Quick update on where I've got to. I hoped to post an updated EFI today but SSDT stuff is taking a bit longer than I thought. But I'm making some progress on dual-boot and on understanding what dolgarrenan put together for us.

On sleep / wake

No progress on fixing the KP on wake. I've tried numerous combinations of options and SSDTs. I've tried running with an OpenCore config close to identical to Edkroket's - the guy who said he had working sleep/wake on the Aorus MB. I've tried disabling all of dolgarrenan's SSDTs and running only with the SSDTs provided by the Dortania guide which are the only ones 100% required. I've also tried disabling various kexts that I have installed on my own system, just to rule them out as possible causes, including disabling the VirtualSMC plugins as I had noted SMC was mentioned after AppleACPI in the kernel panic.

I've also tried a few BIOS options that I thought might have some effect.

So far, no luck. I can sleep 100% reliably as long as the dolgarrenan SBUS SSDT is not loaded, but a wake always causes an immediate KP.

I'll return to investigating this tomorrow. If he is saying he does have working sleep & wake (albeit with an auto wake) then that's very interesting, and seems quite possibly due to him running Mojave. So I'll do a Mojave test tomorrow.

If Mojave does work and Catalina doesn't, at least that gives something concrete to research further and ask some experts about.

On dual booting Windows from OpenCore

This is looking better. I have now successfully booted both macOS and Windows from the same OpenCore config file.

In order to achieve this I removed all of the static ACPI patches from config.plist (which OpenCore will always apply to every OS, and which break Windows), and then went through the SSDTs to edit them so they didn't need those static patches, and to make sure they all had an If statement ensuring they would run only on macOS.

Many of the ACPI patches appear to be cosmetic, added by dolgarrenan so that devices would have the same name as they do on a real Mac Pro. A couple of them were important for running the SSDTs that dolgarrenan provided, especially the PC00 -> PCI0 rename. Hence I needed to edit the SSDTs once the ACPI patches were gone.

This is my first time editing SSDts so there's still a bunch of things I don't fully understand, and I don't have them all perfect yet. But I've confirmed it can work in principle so I'm confident we can get a fully capable system that can dual-boot Windows via OpenCore.

It's also pretty cool that OpenCore now uses macOS' "Startup Disk" system. You can set your default boot option in System Preferences -> Startup Disk, which means if you do want to go to Windows you can also use this UI to reboot to Windows. I guess if BootCamp software is installed you can do it the other way around as well, but I've not looked at that yet.

Small Tree drivers - EFI vs /L/E

A minor thing: I thought I'd do a quick test as to whether having the SmallTree kext in EFI makes any difference vs /L/E, given that byteminer had network issues and the OP seemed to indicate there was some difference in performance.

Result: I can't tell any difference, at least not when testing with a 1GBe connection.

The network has been 100% reliable for me regardless of the driver location, so I think you can put the kext wherever you prefer. I'll double check again when I've got a 10GBe connection.


I'll hopefully be able to post an updated EFI in the next 24 hours which will be dual-boot capable.

 

[TheBloke]

Wake fails on Mojave too

I did the Mojave 10.14.6 test. I had to switch SMBIOS to iMacPro 1,1 in order to boot Mojave. I booted with a basic config.plist that only used the essential Dortania SSDTs, no ACPI patches, no dolgarrenan SSDTs.

And the result is the same. Goes to sleep OK (machine shuts down), but upon waking it - either using the mouse/keyboard, or by pressing the power button - the machine quickly reboots, and the panic log indicates the same AppleACPI kernel panic as before.

It would be great if you could clarify exactly what you're seeing. You said "Display and mac os sleeps, but hardware not completely as it reawakens." Could you confirm if you see the PC power down, fans stop spinning etc? If not, then it's not actually going to sleep - it turns off the display and keeps trying to make the PC sleep, but it doesn't happen and macOS is still running the same as if no sleep attempt had been made.

If the PC is definitely shutting down properly, then I'd love to see your EFI because I can't currently recreate a situation where a successful sleep results in a successful wake. It's either no sleep at all, or else successful sleep followed by kernel panic on wake.

 

[TheBloke]

@byteminer you making any progress on anything?

This KP on wake issue is really beating me at the moment. I've tried a dozen things, and tried getting some expert advice, but I can't get past it.

When you have a minute could you confirm that:
a) With the SBUS DSDT not loaded your system goes to sleep OK,
b) but that it then kernel panics on wake?

Today I went back to dolgarrenan's original OC EFI, which I copied to a USB stick and used 100% without modifications. And it's exactly the same as described above: won't sleep at all with his SBUS DSDT in place, and with that removed it does sleep but then KPs every time on wake.

So I'm struggling to understand how he apparently had working sleep and wake. Unless there's some BIOS setting difference or something else I've not yet noticed, but I've tried a lot of them.

I guess I'll test on BIOS F3B because I know he used that more than F3C. But other than that, the only thing I know to be different is he patched his TB3. But I get the same KP even with TB3 disabled in BIOS, so it really seems unlikely that it's that.

And it doesn't seem like it could be changes in macOS, because I had the identical KP when I tested macOS 10.14.6.

Other than that, I don't know. I just checked the thread again, and he said multiple times he had sleep working. It's really confusing.

 

[byteminer]

Unfortunately I didn't have much time over the past few days. I did mess around with ACPI stuff as well, but came up empty, same as you. I still struggle to find what exactly causes this kernel panic.

What I can confirm is the same behavior you are seeing, as in being able to put the system to sleep, but never waking up (or rather, rebooting from a kernel panic).

I've tried some other EFI's from the german hackintosh forum, but none of them had sleep working either, so that was a dead end.

Will continue to research into this topic, but so far leads are sparse.

 

[TheBloke]

OK thanks. This is really weird and annoying.

I just flashed to BIOS F3B, loaded dolgarrenan's BIOS config from the OP, and booted with his OC EFI - unchanged except SBUS SSDT disabled, and putting my own SMBIOS details in.

His config does not have "Above 4G Decoding" enabled, and therefore gave me no working onboard USB and Ethernet just like before - which is another mystery, as clearly it caused no problems for him!

Without Above 4G, the only USB port I have working is the USB-C port on my case (via the USB 3.1 MB header). I put the mouse in that port and tried to sleep, but it wouldn't go to sleep - same symptoms as when the SBUS DSDT is in place.

I checked the logs, and it indicated the problem was: "kernel: (AppleACPIPlatform) System sleep prevented by HDEF"

Which suggests to me that lack of Above 4G is breaking more than just my USB and Ethernet.

So then I enabled "Above 4G Decoding", and then I was back to the usual problem: sleep works, KP on wake.

So how the hell did dolg have working sleep and wake?

The only things that are different, that I know of anyway, are:

1. He has/had 5700XT GPU; I have Vega 64, you have RX580
2. He has/had 10900 CPU, we have 10980XE
3. He flashed his TB3 FW.

From what I understand of the issue, none of those sound like they should be the cause of this.

1 & 2 we can't test. Well, I do hope to get a new GPU soon, a 6800XT, but it's far more likely than not that it'll be sold out so I might have to wait until 2021 for that.

3 I could test. I guess if I exhaust all other possibilities I'll give it a go. Right now it just seems like a lot of hassle for a very small chance of making any difference.

 

[TheBloke]

SLEEP AND WAKE!

SLEEP AND WAKE!

WORKING SLEEP AND WORKING WAKE!

I can't take any credit for fixing it - besides for the effort in re-reading the whole thread in case something popped out.

Something did pop out! Something wonderful!

Have you tried the quirk "AppleXcpmCfgLock; set to YES. That is the only way Sleep with work 100% on my GA Mobo.

Thank you, @Ellybz ! Working sleep and wake, no sweat.

This raises a lot of questions. Why didn't dolgarrenan need this? Why is it needed on this MB which apparently has unlocked CfgLock? Is there a proper/better way to achieve the same result, given it's meant to be a hack?

If in fact the CfgLock really IS locked in our MB (and there are some posts around page 25 suggesting maybe it actually is), then there is definitely a way to fix that: by patching the BIOS to unlock CfgLock using a special EFI shell, as detailed in the OpenCore documentation. I may well try that soon, after some more research.

So far all I've done is tweak that parameter and confirm it gives me a working wake. I've not checked anything else, eg to see if there's any problems established by using that parameter.

I need to go for dinner now, but I'll continue researching this tonight.

 

[byteminer]

Excellent news indeed!
The CFG Lock is a tad strange, given that NVRAM works (I tested it a few days ago). This would normally indicate that CFG Lock is not present. Very strange behavior for sure.

Edit: Just confirmed that CFG Lock is disabled using the verification tool in OpenCore.

Enabling the quirk also makes sleep work for me, so that's consistent.

 

[TheBloke]

OK sounds like you're in the same position as the rest of us then.

Regarding the RAM speed reset: this is an expected result of the boot failure issue, which happens if :
a) You boot OpenCore from the F12 boot menu, BIOS boot override menu, or after having been in the BIOS and then "Exit without saving"
and/or
b) You boot with two or more OpenCore bootloaders visible, for example one OpenCore partition on your NVMe and then a second on a USB drive. Possibly non-OpenCore bootloaders might also trigger it, eg Linux. But Windows does not appear to in my own testing.

Either scenario (and possibly others) will trigger the dreaded curse of this motherboard, which is that you will get an automatic shutdown 10 seconds after the boot starts (regardless of what is happening at that time), and then when the system comes back up your CPU and RAM will be at default frequencies. You'll only notice the difference regarding CPU if you were overclocking, but RAM is much more noticeable because most people enable XMP.

Once that's happened once, you can then continue to boot OpenCore even in the above conditions, until such time as you re-save BIOS settings with F10 in the BIOS. This means that your RAM will be stuck at non-XMP speeds.

So, to get your RAM working, first go into the BIOS and make sure you have XMP enabled, then re-apply your settings with F10. From that point onwards, make sure you follow these rules:

• Never boot OpenCore from the F12 boot menu or BIOS Boot Override menu.
• Any time you go into the BIOS, always either hit F10 to save, or else power down or hit the restart button; never exit the BIOS with "Exit Without Saving"
• When booting, do not have two or more OpenCore partitions visible to the BIOS at one time. Meaning that if you have one on your NVMe drive, make sure you don't also have a USB stick or another drive with another OpenCore partition.
  • Windows bootloader partitions do not trigger the issue, at least in my experience.

If you do need to temporarily boot from a second drive - eg booting OpenCore from USB because your main config got messed up, or because you're trying some new config - then you will get the boot failure the first time you try. The second time it will work, albeit with RAM at non-XMP speeds.

This means that booting temporarily from USB is a two-step process: Go into the BIOS and boot the USB from Boot Override; 10 seconds later it reboots; go back into the BIOS and boot USB from Boot Override again; this time it works; some time later, when you're done with the USB, go back into the BIOS and re-apply your settings with F10 to get XMP Working again; reboot, and now you can boot normally from your main NVMe drive.

This is all a major pain but there's currently no known fix, and my feeling is that there probably won't be a fix. It's a BIOS bug. Given it doesn't happen with Windows it's theoretically possible that some change to OpenCore could avoid it, but that's going to require help from an OpenCore dev and I'm not holding out my hopes that we'll be able to get that.

As mentioned in previous posts I'm working on an OpenCore config that will enable easy dual-boot of macOS and Windows, and won't trigger this issue. Once we have that, at least we'll have smooth dual booting of those OS and at that point the bug shouldn't really happen again, except if you ever find yourself needing to temporarily boot from USB for some fix or test.

I've been having some trouble getting all the SSDTs working right, and I diverted onto investigating sleep over the last 24 hours. But I'll be looking at SSDTs again tomorrow so hopefully I'll have an EFI to share in the next day or two.

In the meantime, here's the BIOS config I promised a while ago. This is for BIOS version F3C. It's very simple, and probably matches what you already have. But you can install this as a safe guard that you have things setup OK. It has the settings required for macOS boot and Thunderbolt, C-States Enabled on C6, and mostly everything else on Auto. Note that XMP will be disabled, so you'll need to manually enable that.