Gigabyte X299X - Catalina Support

[TheBloke]

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.

 

[beltzak]

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.

 

[byteminer]

Update on the Ethernet situation: It works!

I grabbed my trusty Ubuntu 20.04 USB stick and booted from that.
Initial impression: Shock, because the ports didn't work there, either.
For a few moments I thought they were broken.

Then I did a basic sanity check, grabbed my debug router and connected my PC to that instead. Lo and behold, the ports started working! Connecting it back to my regular router also worked.

After shutting down and booting back into macOS, the ports started working there, too.

I believe they may have transitioned into some kind of bad state when I messed around with the SmallTree drivers on Catalina, where the installation became buggy after I installed them in /L/E. Booting Linux and forcing the connection to reset (by physically plugging into a different router) may have forced them to reset and return to a good state. This state has remained and they are both now working normally, with the SmallTree drivers in my OC EFI. No performance issues either.

This means that I now have:
- Big Sur
- Working Power Management
- Working Sleep
- Working Ethernet
- (Somewhat) Working native Intel Wifi
- Working Intel Bluetooth
- Working iServices

Save for the BIOS reset bug, everything appears to be in order now. I'm sure there's a few niceties that could still be tweaked, but at large it's now functioning properly.

One thing that is slightly annoying but not show-stopping is the fact that iStatMenus only reports upload speed for the ethernet ports. Download speed is always 0.00 KB/S. I have this same symptom on my Z390 build, but only on one of the ports. I assume this may be the driver's fault.

In tandem with the above, I discovered that there is an updated version of the SmallTree drivers available (3.6.0, compared to our 3.5.0), however they are not patched as dolgarrenan's are. Unfortunately he does not elaborate as to how and what he patched, exactly, so I am unable to replicate whatever he did to those drivers. If anybody has any insight on the patching method used, let me know and I can attempt to maybe replicate it on the updated version.

 

[TheBloke]

Wow, weird. Maybe the switch marked the ports as bad or unavailable or something, as a result of previous incorrect operation. Then replugging them reset the connection on the switch side.

Anyway good to hear it's working now.

One thing that is slightly annoying but not show-stopping is the fact that iStatMenus only reports upload speed for the ethernet ports. Download speed is always 0.00 KB/S. I have this same symptom on my Z390 build, but only on one of the ports. I assume this may be the driver's fault.

Ah, odd. I've not used iStatMenus for a long time. Little Snitch provides bandwidth monitoring in the menu bar and that's working in both directions. But it probably calculates it based on what's going through the firewall, rather than reading it from the NICs.

In tandem with the above, I discovered that there is an updated version of the SmallTree drivers available (3.6.0, compared to our 3.5.0), however they are not patched as dolgarrenan's are. Unfortunately he does not elaborate as to how and what he patched, exactly, so I am unable to replicate whatever he did to those drivers. If anybody has any insight on the patching method used, let me know and I can attempt to maybe replicate it on the updated version.

Yeah I don't know how he patched it either. But I might be able to figure it out if I compare the patched version to the unpatched, then apply the same to the new drivers. I'll have a look when I'm done with my SSDT update.

Have you tried changing the hardware ID for the NICs and then using the unpatched drivers? I know dolgarrenan couldn't get it working, hence him patching the drivers instead. But it might be worth trying given there's a new driver version now.

It worked perfectly for me on my X520 10GBe NICs, which use the same SmallTree drivers.

It's easily tested from a Linux boot so might be worth trying in the meantime.

 

[byteminer]

I think I got it, actually.

I compared the 3.5.0 version from the the OP with one downloaded from SmallTree's website and found that there was exactly one difference, somewhere in the middle of some binary garbage.

Searching for the original, unmodified value in the updated 3.6.0 binary netted me two results. I modified only the second result, since it was much closer to the position of the original change in the 3.5.0 version, and tada, it works!

The bundle itself still shows the version as 3.5.0, but it is in fact quite different from the 3.5.0 version, which can be verified by comparing the two binaries in i.e. HexFiend.

Still no download speed indicator, but hey, can't hurt to be on the latest version of the driver.

With this knowledge we are now able to reproduce dol's patch for new versions as well.

For the 3.5.0 version the patch is as follows:
Original Value: 39C990
New Value: 83F90A
Offset: 50465

For 3.6.0 the offset is 50752 while the patch remains the same.

 

[TheBloke]

Hehe great minds think alike. I've just done exactly the same thing, right down to using HexFiend also

I think you uploaded the old one by mistake though? The one you uploaded still shows 3.5.0 in the plist. Also the latest version is 3.8.6 not 3.6.0.

Here's the 3.8.6 patched which I'm booted with now and is working

tomj@Eddie ~/Hack/X299X-Eddie $ kextstat | grep -i small
   75    0 0xffffff7f844ee000 0x34000    0x34000    com.SmallTree.driver.SmallTreeIntel8259x (3.8.6) EAFD7A7F-28C6-3B0E-A839-5B92970C4D5E <34 13 6 5 3 1>

 

[byteminer]

That was actually the 3.6.0 version, the developers forgot to bump the version number, funnily enough. Binary diffing the file I uploaded will show that it's quite different from the 3.5.0 version. Alas, I didn't see the 3.8.6 version, so yours is newer anyway

 

[TheBloke]

Ahh OK sorry, I didn't follow what you said about the bundle.

Anyway yes it's great we can patch this for ourselves now. I'd still love to know how he patched it in the first place. Must have used a debugger or something I guess.

I noticed they list Big Sur as non supported, but clearly that's not the case as it worked even with 3.5.0. I guess they're waiting for it to go gold before declaring it officially supported.

I might still try the old method sometime, the one that involves updating the NIC in Linux. Just to see as much as anything, plus it's always nice to be able to use vanilla drivers if possible. Dolg said it didn't work on this motherboard/with these NICs so it probably doesn't, but can't hurt to try anyway.

 

[beltzak]

- (Somewhat) Working native Intel Wifi
- Working Intel Bluetooth

Do you guys have the original Intel and Bluetooth working in the Designare 10g? I had to change the device. I know they were patching it but I thought that could take some time.
Handoff or Continuity?
Sidecar (iPad as screen)?

 

[TheBloke]

My understanding is that Sidecar will never work because we don't have an iGPU. On non-iGPU Macs, the T2 chip is used to accelerate Sidecar, and we don't have a T2.