Contribute
Register

Gigabyte X299X - Catalina Support

Status
Not open for further replies.
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.
 

Attachments

  • F3CmacOSAuto.zip
    2 KB · Views: 54
Last edited:
I'm still having some trouble getting the ethernet ports to work, unfortunately.

@TheBloke, when you put the SmallTree drivers into your EFI folder, how exactly did you do that? Simply put them in and add them like any other kext?
I did the same and for the life of me I can't get them to function properly. They do not pick up any wired connections, no blinkenlights and no connection of any kind displayed in macOS.

It's rather strange, because I managed it once before, however after that they never appeared to load properly. They also do not show up in Hackintool under the tab for loaded kexts.

I have a Broadcom WiFi card that works just fine, but getting ethernet working would be very nice, too.

Not sure what I'm doing differently, given that putting them into the EFI worked for you. Is there a specific load order we need to observe?
 
@byteminer First thing to be sure of : you do have Above 4G Decoding = Enabled? Because without that, both Ethernet ports failed for me also.

So, I've tried installed the drivers in two ways, both of which work fine:

1. /L/E : Mounted / read-write, then copied the kext to /L/E and updated the cache. I used Hackintool to do the / mount and the kext update. It also has a kext installer but I've not yet tried it.

2. EFI: Copied the kext to /Volumes/EFI/EFI/OC/Kexts, added it in the config.plist using the same format as all the other kexts, enabled it.

That's all I've done. Either method works fine for me, and I use method 1 by preference. There's no such thing as a defined load order in config.plist or /L/E, as far as I'm aware.

If that's not working, then I would:

1. Check the kext is actually loading, eg with kextstat:
Code:
tomj@Eddie ~ $ kextstat | grep -i small
  123    0 0xffffff7f8488b000 0x2e000    0x2e000    com.SmallTree.driver.SmallTreeIntel8259x (3.5.0) 8E38DEAB-C6D9-3986-926F-F1018AB0C605 <34 13 6 5 3 1>

2. Check your logs for SmallTree messages, see if anything stands out, eg with:
Code:
tomj@Eddie ~ $ sudo log show --predicate "processID == 0" --start "$(date "+%Y-%m-%d")" | grep -i smalltree
Password:
2020-11-09 00:15:12.656296+0000 0x76a8     Default     0x0                  0      0    kernel: (SmallTreeIntel8259x) SmallTreeIntel8259x getNVM b2d0f1: Mac address: b4:2e:99:a6:28:4c
2020-11-09 00:15:12.674499+0000 0x76a7     Default     0x0                  0      0    kernel: (SmallTreeIntel8259x) SmallTreeIntel8259x getNVM b2d0f0: Mac address: b4:2e:99:a6:28:4a
2020-11-09 00:15:14.712002+0000 0x76a8     Default     0x0                  0      0    kernel: (SmallTreeIntel8259x) Initializing SmallTreeIntel8259x: Version 3.5.0 Built Feb 15 2019 10:26:24 Build: 2515M
2020-11-09 00:15:14.757793+0000 0x76a7     Default     0x0                  0      0    kernel: (SmallTreeIntel8259x) Initializing SmallTreeIntel8259x: Version 3.5.0 Built Feb 15 2019 10:26:24 Build: 2515M
2020-11-09 00:15:15.156498+0000 0x76a8     Default     0x0                  0      0    kernel: (SmallTreeIntel8259x) SmallTreeIntel8259x b2d0f1 start: NVM Checksum incorrect
2020-11-09 00:15:15.173433+0000 0x76a8     Default     0x0                  0      0    kernel: (SmallTreeIntel8259x) SmallTreeIntel8259x checkLinkStatus b2d0f1: Link is DOWN
2020-11-09 00:15:15.264739+0000 0x76a7     Default     0x0                  0      0    kernel: (SmallTreeIntel8259x) SmallTreeIntel8259x b2d0f0 start: NVM Checksum incorrect
2020-11-09 00:15:15.290746+0000 0x76a7     Default     0x0                  0      0    kernel: (SmallTreeIntel8259x) SmallTreeIntel8259x checkLinkStatus b2d0f0: Link is DOWN
2020-11-09 00:15:23.078247+0000 0x317      Default     0x0                  0      0    kernel: (SmallTreeIntel8259x) SmallTreeIntel8259x checkLinkStatus en1: Link is DOWN
2020-11-09 00:15:26.101118+0000 0x317      Default     0x0                  0      0    kernel: (SmallTreeIntel8259x) SmallTreeIntel8259x checkLinkStatus en1: Link is UP
2020-11-09 00:15:27.900197+0000 0x317      Default     0x0                  0      0    kernel: (SmallTreeIntel8259x) SmallTreeIntel8259x checkLinkStatus en0: Link is DOWN
2020-11-09 00:18:30.010686+0000 0x6a61     Default     0x0                  0      0    kernel: (SmallTreeIntel8259x) SmallTreeIntel8259x getNVM b2d0f0: Mac address: b4:2e:99:a6:28:4a
2020-11-09 00:18:30.017495+0000 0x6a62     Default     0x0                  0      0    kernel: (SmallTreeIntel8259x) SmallTreeIntel8259x getNVM b2d0f1: Mac address: b4:2e:99:a6:28:4c
2020-11-09 00:18:32.107620+0000 0x6a61     Default     0x0                  0      0    kernel: (SmallTreeIntel8259x) Initializing SmallTreeIntel8259x: Version 3.5.0 Built Feb 15 2019 10:26:24 Build: 2515M
2020-11-09 00:18:32.107677+0000 0x6a62     Default     0x0                  0      0    kernel: (SmallTreeIntel8259x) Initializing SmallTreeIntel8259x: Version 3.5.0 Built Feb 15 2019 10:26:24 Build: 2515M
... etc

3. Do you have ROM filled out in config.plist -> PlatformInfo? I don't know if this is important or not, but I read that it should be set to your MAC address and so I set it like that. Maybe if you don't have one, or have an invalid one, it could affect things?

Personally I wouldn't use /S/L/E. It'll probably work fine, but standard practice is for non-Apple kexts to go into /L/E, not /S/L/E. So there's always the chance that future updates make remove or break kexts installed in /S/L/E.
 
I suppose one more thing to do is double check your kext is OK. Here's what the full contents should look like:
Code:
tomj@Eddie ~ $ ls -alR /Volumes/EFI/EFI/OC/Kexts/Other/SmallTreeIntel8259x.kext  
total 4
drwxrwxrwx  1 tomj  staff   512B 21 Oct 12:12 .
drwxrwxrwx  1 tomj  staff   1.0K  9 Nov 14:26 ..
drwxrwxrwx  1 tomj  staff   512B  7 Nov 15:12 Contents

/Volumes/EFI/EFI/OC/Kexts/Other/SmallTreeIntel8259x.kext/Contents:
total 11
drwxrwxrwx  1 tomj  staff   512B  7 Nov 15:12 .
drwxrwxrwx  1 tomj  staff   512B 21 Oct 12:12 ..
-rwxrwxrwx  1 tomj  staff   2.6K 26 Nov  2019 Info.plist
drwxrwxrwx  1 tomj  staff   512B  7 Nov 15:12 MacOS
drwxrwxrwx  1 tomj  staff   512B  7 Nov 15:12 Resources
drwxrwxrwx  1 tomj  staff   512B  7 Nov 15:12 _CodeSignature

/Volumes/EFI/EFI/OC/Kexts/Other/SmallTreeIntel8259x.kext/Contents/MacOS:
total 501
drwxrwxrwx  1 tomj  staff   512B  7 Nov 15:12 .
drwxrwxrwx  1 tomj  staff   512B  7 Nov 15:12 ..
-rwxrwxrwx  1 tomj  staff   249K 26 Nov  2019 SmallTreeIntel8259x

/Volumes/EFI/EFI/OC/Kexts/Other/SmallTreeIntel8259x.kext/Contents/Resources:
total 3
drwxrwxrwx  1 tomj  staff   512B  7 Nov 15:12 .
drwxrwxrwx  1 tomj  staff   512B  7 Nov 15:12 ..
drwxrwxrwx  1 tomj  staff   512B  7 Nov 15:12 English.lproj

/Volumes/EFI/EFI/OC/Kexts/Other/SmallTreeIntel8259x.kext/Contents/Resources/English.lproj:
total 3
drwxrwxrwx  1 tomj  staff   512B  7 Nov 15:12 .
drwxrwxrwx  1 tomj  staff   512B  7 Nov 15:12 ..
-rwxrwxrwx  1 tomj  staff    92B 26 Nov  2019 InfoPlist.strings

/Volumes/EFI/EFI/OC/Kexts/Other/SmallTreeIntel8259x.kext/Contents/_CodeSignature:
total 8
drwxrwxrwx  1 tomj  staff   512B  7 Nov 15:12 .
drwxrwxrwx  1 tomj  staff   512B  7 Nov 15:12 ..
-rwxrwxrwx  1 tomj  staff   2.6K 26 Nov  2019 CodeResources

So make sure your kext has all those files.

Here's my config.plist entry, which has nothing special, but just for reference:
Code:
 <dict>
    <key>BundlePath</key>
    <string>Other/SmallTreeIntel8259x.kext</string>
    <key>Comment</key>
    <string>SmallTree X550T NIC Drivers</string>
    <key>Enabled</key>
    <false/>
    <key>ExecutablePath</key>
    <string>Contents/MacOS/SmallTreeIntel8259x</string>
    <key>MaxKernel</key>
    <string></string>
    <key>MinKernel</key>
    <string></string>
    <key>PlistPath</key>
    <string>Contents/Info.plist</string>
    <key>Arch</key>
    <string>x86_64</string>
</dict>

Change enabled to true of course.
 
Hmm, I did fill in the ROM before (but double-checked it was actually set to my first MAC address, which it was), however what I did notice was that my interfaces were not enumerated en0 and en1 but instead en3 and en4. I reset them according to the OpenCore guide, which reinstated the proper names, but they are still not functional.

The kext appears as loaded when running kextstat, but no log output is generated in the log show command pertaining to this kext. Quite peculiar.
 
No logs is very odd given the kext is loaded

Are you able to do a test in Windows or Linux to double check that the NICs are actually functional? Rule out any general problems eg the NICs are broken somehow, or disabled, or whatever.

My first thought was that maybe it was because you're running Big Sur. But I've just upgraded a secondary SSD from Mojave to Big Sur, and the NICs appear to work.

I say appear because I seem to have a problem on Big Sur: the update went fine, and the first boot seemed to be going fine, right up to the point where the verbose logs disappear and the final Apple progress bar appears. It's then got stuck at about 95% on that progress bar.

I know the NIC is working because I can ping its IP from a second machine. However I can't login via SSH because sshd apparently hasn't loaded - I'm getting connection refused. Possibly because boot hasn't completed.

Did you need to change any config when you moved to Big Sur? Any different boot arguments or anything like that?

Anyway I would do a double check to confirm your NICs definitely work in another OS. And also re-download the SmallTree kext if you haven't already, just to rule out anything weird like a file gone missing or something.

As a last resort you could also try resetting CMOS on your BIOS and reconfiguring it - perhaps starting from the known-good F3C config file I uploaded the other day. Just in case there's some weird BIOS issue going on.

If none of that works, maybe share your EFI and I'll try it on my Catalina and Big Sur installs, see if I can replicate the problem. Which would point to it being some config difference between our EFIs.
 
Last edited:
Yeah, checking on Linux might be the best option for now.
One thing to note regarding Big Sur though: I did a fresh install. Any upgrade installs I've done have resulted in broken systems after one or more boots, likely due to the APFS migration shenanigans that Big Sur brings with it.
Currently I would not advise upgrading to Big Sur from an existing installation.

The APFS stuff can get so bad that you won't even be able to wipe a Big Sur drive from a Catalina Recovery Partition, because it can't understand the new APFS stuff. You must use diskutil via the Terminal for this, as I've learned from experience. As such, a fresh install was the only way I could get it to work reliably, personally.
You can, however, do a migration after the fresh install is done.
 
Jeez I see what you mean!

It occurred to me that I might well have some kexts that could cause problems in Big Sur, especially as I'd upgraded direct from Mojave, as that's what I had on my secondary SSD. Stuff like the Little Snitch firewall, where I'd not yet been able to upgrade to the latest versions with Big Sur support, due to not yet being on Catalina.

So I booted in safe mode, intent on uninstalling such kexts and then trying a normal reboot.

It booted in safe mode fine, and then asked me to create a new account. Bit weird I thought, but I did it. At which point I found that all of /Applications was empty, all the kexts were gone from /Library/Extensions, and the system appeared to have been basically wiped clean.

My normal user folder still exists in /Users, but it didn't prompt to login is as that user, and aside from that it's more or less like a new install!

So I'll wipe that disk and forget about Big Sur for now. I was only trying it to double check the network worked fine, and to get a feel for whether everything else would work. I'll go back to my original plan and wait for Big Sur to be gold, maybe even until 11.0.1 or .2 is gold, and then try again upgrading, but this time from 10.15.7.
 
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!



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.
Wow AweSome!!!!

I can't wait to try it lol.
 
Status
Not open for further replies.
Back
Top