Gigabyte X299X - Catalina Support

[TheBloke]

I've started the process of investigating booting Windows from OpenCore. What I learned is that SSDTs need to be edited so they only apply to macOS, because OpenCore will apply the ACPI folder to any and all operating systems it boots.

My first test was to boot Windows 10 from OpenCore using a config which disables all SSDTs. I expected this to boot OK, and then I'd re-enable the SSDTs one by one to confirm if they all needed to be edited.

But I immediately hit a problem: Windows still gave me an ACPI_BIOS_ERROR blue screen even with all SSDTs disabled.

So then I tried a test config in which I also removed all of the ACPI->Patches in dolgarrenan's config.plist, eg where _OSI is renamed to XOSI and PC00 to PCI0. These will also be applied to any and all operating systems.

And that worked, I got Windows booted from OpenCore. But of course this config would then fail completely with macOS.

I think that's why dolgarrenan was using n-d-k's fork of OpenCore, because it had special changes that meant it didn't apply any ACPI stuff to non-macOS operating systems. As far as I am aware, these features are not in OpenCore.

So now I'm investigating whether it's possible to remove the ACPI patches and replace them with SSDTs, which would enable adding the necessary If statement to make them run only for macOS.

I'd also like to understand what these renames are for exactly and whether they're all actually necessary.


Bottom line: it's definitely already possible to dual-boot macOS and Windows if you put up with only being able to load Windows via the BIOS Boot Override menu.

But I think it won't be possible to boot Windows from OpenCore without editing the SSDTs and the ACPI->Patches section. Or there's also the possibility of the BootCamp method, ie booting Windows as if you were booting a real Mac. There's details about that in the OpenCore guides but I've not investigated it myself yet.

If anyone has already done this work and managed a working OpenCore dual-boot using mainline OpenCore, I'd love to see your EFI.

EDIT : talked too soon, multiboot isn't working properly with windows... working to edit the ACPI so opencore passes them straight to windows.

Did you make any progress with this @Walterfilms?

 

[byteminer]

Great score! What are your overclock settings?

Currently running Mesh at 30, Core at 48, with a voltage of 1.19 and VCCIN of 2.0. LLC is Medium, so everything's quite close to what you've been experimenting with as well.
I briefly tried going 49, but I think that may require me to increase my LLC, which I currently don't want to do. Maybe something to check later.

can you try booting OpenCore after having accessed the BIOS?

Yeah, I'm seeing the same behavior as you, entering without "Save and Exit" or resetting leads to an OpenCore boot failure. Seems like the SMBIOS does not affect this particular behavior.

I didn't know about NVMEfix or itlwm. Should I install this kext if I already own a fenvi t919?

In my experience, itlwm is still in quite heavy development and not as stable as I'd want it to for daily use. It has several problems, i.e. 5GHz networks aren't particularly stable, it represents as an Ethernet device internally, things like that. It's good for testing stuff or getting a quick connection, but the Fenvi will be faster and more stable overall, for now.

 

[TheBloke]

Currently running Mesh at 30, Core at 48, with a voltage of 1.19 and VCCIN of 2.0. LLC is Medium, so everything's quite close to what you've been experimenting with as well.
I briefly tried going 49, but I think that may require me to increase my LLC, which I currently don't want to do. Maybe something to check later.

Nice, 4.8 at 1.19 is pretty good. Above average anyway, from what I've been told.

Out of interest, what's your concern regarding increasing LLC? Heat? I've not yet really got my head around the interactions of VCCIN and LLC with main vcore and its effect on overclock. Interesting that you're as high as 2.0 on VCCIN - did you try lower VCCINs and found 2.0 gave better results? I've not gone above 1.92 yet. There's one expert on overclock.net who sets his VCCIN to 1.74 - underclocking it - and uses minimal or no LLC, because he says some voltage droop is good. Then I found a guide on another site that set VCCIN to 3.0!

I have experimented with various VCCINs, but haven't yet spotted any clear pattern. High VCCINs didn't seem to enable lower VCore, which was the main thing I was hoping for, though I haven't yet tried as high as 2.0. And of course I'm quite limited until I get proper cooling; I've stopped experimenting with new overclock settings until I do.

I'm going to order the MO-RA3 radiator soon, maybe today. I'll likely get that TechN block as well, despite the lack of reviews, as I don't think I want to pay the high delivery prices that an Optimus would involve. It's working well for you so that's a good sign

Yeah, I'm seeing the same behavior as you, entering without "Save and Exit" or resetting leads to an OpenCore boot failure. Seems like the SMBIOS does not affect this particular behavior.

OK thanks. I'm thinking there must be some OpenCore setting that affects this.

Today I learned two three new things regarding this issue:

1. It happens the same when I boot Windows from OpenCore. Exactly the same: if I launch OpenCore having been in the BIOS, I get a shutdown and restart very early in the Windows boot process, and when it comes back up CPU and RAM are at stock. So it's definitely OpenCore in general and not macOS specifically.

2. It's not, as I thought before, specific to overclocking. I prepared a BIOS profile with all CPU and RAM frequencies and voltages at Auto, and it happened just the same. It wasn't a complete stock setup, eg I still had my power and current overrides in place, and a couple of other non-default settings in the Advanced CPU Options menu.

3. It even happens when I use the F12 Boot menu. So it's not specific to having accessed the BIOS. It happens in any scenario except normal straight-through booting.

I'm going to keep investigating it as it's a bit of a pain when testing other OpenCore settings using a USB stick. In that scenario it's very convenient to be able to just select the USB from the Boot Override or F12 menu rather than messing around with boot orders, and this reset issue rather gets in the way of that.

 

[TheBloke]

I think I'm starting to understand the parameters of this boot-from-BIOS problem, though sadly I'm no closer to finding a solution.

Firstly, to establish some terms: by "straight through" booting I mean any boot in which the user does not enter the BIOS and does not access the F12 boot menu. The system is powered up or restarted, and then the user leaves it to automatically boot the first entry in the boot order.

I have established that:

1. Booting OpenCore will fail in any boot that is not a straight-through boot. However having failed, subsequent non-straight-through boots will succeed, until the next time BIOS settings are applied with F10.
2. It happens with all BIOS settings I have tested, including when the BIOS has been reset to "Optimized Defaults".
3. Putting OpenCore into debug mode shows that there are no errors or other indicative messages printed by OpenCore at or before the reboot. So far as I can understand, the OpenCore debug logs are identical between a boot that triggers the problem and one that does not. The only things that change are a few hex values related to partition IDs and the like, but I think these change on every boot.
4. It appears to be based on a timer / timeout. Therefore it can happen at any stage of booting, including when sitting idle at the OpenCore/OpenCanopy boot menu (this is easily triggered if you increase the Timeout value in config.plist)
5. I timed multiple instances of boot-from-BIOS, timing how long it took from the moment I hit Enter on the Boot Override screen before the system rebooted. It was almost exactly 10 seconds every time. The stopwatch read eg 10.14 and 10.25, but this includes my reaction time to hit the button.
6. Therefore I believe it is the BIOS that is triggering the shutdown and reboot.
7. This feels to me like a BIOS-initiated shutdown after a timeout period has elapsed. This suggests to me that the BIOS is not seeing something it expects on the boot, so it aborts it after 10 seconds because it thinks it's a boot failure.
8. This could very well explain why the CPU and RAM frequencies are reset at the same time: thinking it's a boot failure, it resets settings to try to achieve a successful boot next time.

What remains a mystery to me is why, after one such boot failure, it will then work following the shutdown/reboot. This implies that whatever the BIOS resets also works to fix this problem. It will continue to work until the next time BIOS settings are applied with F10, at which point it'll then fail on the next non straight-through boot.

I've tried testing various OpenCore quirks related to booting, but nothing so far has made any difference.

This seems like a rather strange issue that definitely needs to be asked of the OpenCore devs, and I'll try and do that soon.

Unfortunately it seems quite possible that this is a BIOS bug unique to our motherboard, so whether there will be any resolution I don't know.

In the meantime, if you never boot OpenCore except with a straight-through boot it should work fine using the 0.6.3 EFI I posted earlier.

 

[byteminer]

Quick update from my end:

I can confirm the 10 second "non-straight-boot" issue exactly as you are describing. I tried a ton of different RTC-related stuff, including the RtcMemoryFixup approach, but no dice. Earlier in the thread it was mentioned that this did not succeed for another person either, so I guess we're following in the footsteps of those who came before us. So far I was unable to turn up anything usable that would remedy this reset issue.

While digging through the config file I did notice that native power management was unavailable because SSDT-PLUG-DRTNIA.aml was disabled. Enabling it also enables native power management and fixes that issue.
Originally I was looking at that section because I was trying to get sleep to work, which thus far I've been unsuccessful with.

I did manage to do a fresh install of Big Sur though, which works well, without any extra issues, which was a nice surprise.

The three items that now remain on my list are:
- Get sleep working (currently not working at all)
- Get ethernet working
- Fix the BIOS reset bug

For the second one I noticed that whether the ethernet ports worked largely came down to whether a butterfly was active in china at a given time or not, so I moved them to /Library/Extensions, which made my Catalina install extremely unstable. I'm probably going to stick with a Fenvi WiFi card and not bother with the Ethernet ports unless a better solution comes along for now.

In better news though, I got the Bluetooth portion of the integrated AX200 card to work and now have my Magic Keyboard and Trackpad connected wirelessly, which works well. WiFi is very iffy with that card on Big Sur though, so that's a no-go at the moment.

I'm gonna try figure out the sleep issues next, though currently I'm at a bit of a loss as to what's causing the inability to go to sleep.

 

[TheBloke]

While digging through the config file I did notice that native power management was unavailable because SSDT-PLUG-DRTNIA.aml was disabled. Enabling it also enables native power management and fixes that issue.
Originally I was looking at that section because I was trying to get sleep to work, which thus far I've been unsuccessful with.

OK interesting. Can you describe what you mean by "native power management unavailable", because I'm quite confused about how exactly we know if PM is working?

I had PLUG-DRTNIA disabled for two reasons:

1. Enabling it gave me a panic on boot when I tested it recently. Though I ran it in addition to SSDT-X299X-DESIGNARE10G-PR00 which I believe does the same thing.

2. I was pretty sure that enabling PM was already being done by dolgarrenan's SSDT-X299X-DESIGNARE10G-PR00. Basically, as I understand it, the purpose of PLUG-DRTANIA is to set plugin-type 1 on the first CPU, which enables native power management, and that's exactly what SSDT-X299X-DESIGNARE10G-PR00 is doing.

However, when I looked at Dortania's guide on power management, they showed a way to confirm if PM was working was to look at IoReg and check if X86PlatformPlugin was connected to the CPU. And for me, it was not.

But then on the other hand, I see my cores scaling in frequency from 1200Mhz up to 4600Mhz, and I see my package power going up and down, and I hear my fans spinning faster and slower. So if I don't have PM working, I'm not sure what would actually change if I did?

What actually is the definition of 'power management working'? Can you describe what you saw was missing that made you want to enable PLUG-DRTANIA, and what you noticed to be different afterwards?

Of course you're now on iMacPro 1,1 so this could be affecting it. As I understand it, dolgarrenan has set configuration to rename components (eg CPUs) to match a real Mac Pro. So if you're not emulating a Mac Pro, you may need different config. Though maybe CPUs are named the same on both systems, as they do both use the Intel Xeon W.

Could you share your EFI sometime so I can compare and contrast what you're doing?

The three items that now remain on my list are:
- Get sleep working (currently not working at all)

Yeah I have no sleep either. I can't recall anyone who has/had sleep working in this thread, except dolgarrenan himself. The two things I know he had different to most of us is that he flashed his Thunderbolt firmware, and he was using n-d-k's fork of OpenCore. Or in fact he was using Clover in the earliest pages.

I don't have sleep working even with TB3 disabled so it seems unlikely it's that, though I haven't gone as far as also removing all the TB3-related config (there's an SSDT, plus some config.plist entries related to TB3).

I've done USB port mapping which apparently can help with sleep, but it's not made any difference.

- Get ethernet working

Ethernet is working fine for me with SmallTree in /L/E. Two ports, stable. Not sure why this is different for you, unless it's iMacPro 1,1. Or because you're now on Big Sur?

Are you only testing Big Sur from now on, or do you have two installs?

In better news though, I got the Bluetooth portion of the integrated AX200 card to work and now have my Magic Keyboard and Trackpad connected wirelessly, which works well.

Yeah Bluetooth is working fine for me. No WiFi and I've not yet made any efforts to get it, eg iwltm. I might at some point but I've never used WiFi on my desktops as I have cabled 1G and 10GBe. So I'll only pursue WiFi to increase closeness to a real Mac Pro, in case any apps look for / expect a working WiFi adapter.

Actually that might be another thing that was different for dolgarrenan - he had working WiFi. I suppose it's possible that the system tries to interface with WiFi during sleep, and if it can't find a WiFi adapter it breaks sleep?

Then again @Walterfilms has working fenvi WiFi and he didn't have sleep working either.

 

[byteminer]

What actually is the definition of 'power management working'? Can you describe what you saw was missing that made you want to enable PLUG-DRTANIA, and what you noticed to be different afterwards?

It was largely the section you linked. If I see something that is misconfigured, I fix it if I can, and this was one of the things that was easily fixable. I haven't noticed much in terms of change, but I'm a firm believer in doing it properly when possible, so might as well. Initially I thought this may have been related to sleep, but so far no progress on that front.

I can't recall anyone who has/had sleep working in this thread, except dolgarrenan himself.

This person does seem to have managed, however they were on an X299X Aorus Master, but I'm hoping there's some stuff that translates to the Designare. Will investigate his EFI to compare and contrast.

Ethernet is working fine for me with SmallTree in /L/E. Two ports, stable. Not sure why this is different for you, unless it's iMacPro 1,1. Or because you're now on Big Sur?

Are you only testing Big Sur from now on, or do you have two installs?

It was unstable on Catalina already, which is one of the reasons I attempted the Big Sur install. The install became very unstable and it was very difficult to get it back to normal, even after uninstalling the kext. I don't like having /L/E kexts because that can shoot you in the foot with a 12 gauge shotgun real quick, so I'd rather avoid a solution such as this.
I will likely be going forward with Big Sur for now as everything else seems to work the same on it, as far as I was able to test up 'til now.

My plan for now is to do the following:
- Compare my EFI with the one guy who claimed to have sleep working
- Tweak my EFI according to the Dortania guide to see if I missed anything obvious
- Create an EFI from scratch using the Dortania guide, in case all else fails. Maybe that'll reveal an oversight or a hint as to what I'm currently missing
- Trawl OpenCore's GitHub for hints regarding sleep and bios resets

Will share my EFI over the weekend once I do a bit more testing.

 

[beltzak]

1)
dolgarrenan's WIFI is a Dell model, I know that because I purchased the same model and replaced with the one that comes in the motherboard.

BCM94350ZAE DW1820A 802.11AC 867Mbps M.2​

2)
The ethernet from first page:
Section 3.2: No need to use multiple kext to load the two Intel X550T 10GbE ports! Please find in attachments a modified version of the latest SmallTreeIntel8259x.kext to work with our cards . Remove all other kexts from C/K/O and install the modified version under /L/E using KextBeast or Hackintool, then rebuild kext cache with terminal command, KextUtility or Hackintool.

Slightly better results with SmallTree kext in correct location.

3)
There is some people that has Sleep working in this thread, I think that is related to the graphics card or USB devices. I have been with macOS Big Sur all the betas in a Macbook Pro 16" and I can verify that Sleep has been a nightmare, most of the betas didn't work, only the external monitor goes to sleep (my issue) but not the computer, the usb keyboard, tablet or de usb-c device. As now, with the macOS Big Sur Release Candidate, Version: 11.0.1 is working perfectly.

 

[TheBloke]

It was largely the section you linked. If I see something that is misconfigured, I fix it if I can, and this was one of the things that was easily fixable. I haven't noticed much in terms of change, but I'm a firm believer in doing it properly when possible, so might as well. Initially I thought this may have been related to sleep, but so far no progress on that front.

OK I've figured this out now. In order to get PM working as per the definition on the Dortania guide - ie that X86PlatformPlugin shows in IORegistryExplorer - I needed to (relative to dolgarrenan's config and the EFI I posted the other day):

1. Remove all of the CPU renames that dolgarrenan added, renaming CPxx to PRxx

2. Enable SSDT-PLUG_DRTANIA

I also disabled SSDT-X299X-DESIGNARE10G-PR00, which is dolgarrenan's SSDT intended to enable PM. Clearly it wasn't working for some reason.

Like you I've not actually noticed any major difference. My Cinebench scores are not improved, in fact first benchmark was down 150 points. I need to test that some more.

It's possible there's a bit more variance in the per-core frequencies; when I last checked this, using HWMonitorSMC2, I noticed that it seemed like some cores were 'sticking' to certain frequencies for a while. Like Core 27 or whatever might show it was at 4.2Ghz for many seconds, even a minute. Now they seem to all be bouncing around a lot more.

Anyway, according to the Dortania guide it's now configured right, so as you say that is likely a good thing.

I'm still trying to figure out exactly why dolgarrenan renamed the CPUs and various other ACPI components in config.plist using ACPI patches. I'm unclear whether he thought it was necessary, or if it was just to get the system more closely resembling a Mac Pro, or what.

I do know that having all those ACPI patches could be a major hurdle to dual-booting Windows using OpenCore, as OpenCore will apply them to all operating systems equally. That's why dolgarrenan used n-d-k's fork which has changes that make it only apply ACPI to macOS. But that fork is still on version 0.5.8 and hasn't been updated in months, so I have no interest in using it.

like having /L/E kexts because that can shoot you in the foot with a 12 gauge shotgun real quick, so I'd rather avoid a solution such as this.

I agree completely with regard to Hackintosh tools like Lilu, WEG, etc. But 'real' drivers I like to put where they're designed to go. If the hardware isn't found they won't load.

Have you tested installing them in /L/E and then updating kextcache? Because as I say ethernet is solid for me. And it sounds like our only differences are kext location and SMBIOS.

Interesting re sleep on the Aorus. That MB doesn't have TB3. Another possible scrap of evidence indicating thunderbolt could be the root of this issue.

I might give the TB3 flashing a go this weekend, which would put me on the same setup as dolgerrenan.

 

[TheBloke]

I've done some investigation on sleep, and I just got my first ever sleep!

It was still a failure, because on attempting to wake it rebooted instead. But it points to the general area of the problems: SSDTs.

Firstly I checked the logs after a failed sleep and found messages indicating the failure to sleep could be CPU related, or related to PCI devices; I suspected the latter more:

kernel: PMRD: sleep reason Software Sleep
kernel: PMRD: SleepWake UUID queued: 24191C6E-B4AB-4BF5-86A3-5769DFDB43BC
kernel: PMRD: tellChangeDown::userActivityAtSleep 0
kernel: PMRD: prevent idle sleep list: IODisplayWrangler- (0)
kernel: PMRD: tellChangeDown::userActivityAtSleep 0
kernel: PMRD: System sleep prevented by kPMCPUAssertion
kernel: (AppleACPIPlatform) System sleep prevented by SBUS
kernel: (AppleACPIPlatform) System sleep prevented by SBUS
kernel: PMRD: System sleep prevented by kPMPCIUnsupported
kernel: PMRD: display wrangler tickled1 1 lastSleepReason 103
kernel: PMRD: display wrangler tickled1 2 lastSleepReason 103
kernel: PMRD: prevent idle sleep list: IODisplayWrangler+ (1)
kernel: PMRD: idle sleep timer disabled
kernel: PMRD: display wrangler tickled1 3 lastSleepReason 103

The two lines that I think are most relevant are:

kernel: PMRD: System sleep prevented by kPMCPUAssertion
kernel: PMRD: System sleep prevented by kPMPCIUnsupported

And the latter feels more important to me, because it's last, and because we now think we have the CPU set up correctly.

Then I went through the dolgarrenan SSDTs and disabled a bunch of them. First I tried disabling the USB and Thunderbolt related SSDTs, but that didn't help. Then I disabled several more, including SBUS and X550T.

And then I got my first ever sleep on this system. Sadly my attempt to wake it up rebooted instead. But at least this is moving in the right direction.

I think it's time for me to go through these SSDTs - and the ACPI rename patches - one by one and try to understand exactly what they're intended to do, and whether they're doing that properly.

I have a feeling some of them are just cosmetic, eg ensuring that About This Mac shows the right entries under PCI.

Anyway, this is some progress at least. Next I'll try to narrow it down to which exact SSDTs are blocking sleep. And of course see if I can get it to actually wake up.