Gigabyte X299X - Catalina Support

[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.

 

[TheBloke]

Quick follow up on AirportItlwm: I'm so far completely unable to get any kind of Continuity stuff working.

I have an iPad Air running iOS 12.4.9. I barely ever use it but I got it out to test this.

Both macOS and the iPad are logged into the same iCloud account, they're on the same WiFi network and both at 5Ghz, they both have Bluetooth enabled, and they can see each other and connect to each other over BT. Both have Handoff enabled in Preferences.

But the shared clipboard isn't working, and I don't see the Handoff option in any app, eg Safari.

I've no idea how one debugs this, and to be honest it's not something I particularly care about given I never use the iPad anyway.

I also had one failure with AirportItlwm: on one occasion I booted macOS and Airportitlwm failed to properly initialised or load.

I briefly saw a message in the verbose boot log indicating that it had failed to apply the firmware, and then in macOS I couldn't establish a WiFi connection. WiFi Preferences indicated that WiFi was disabled, but clicking "Turn On" did nothing.

Since then I've rebooted multiple times, including dual booting back and forth between Windows and macOS, and it's worked every time. So I'm not quite sure what caused that one failure.

Right now I'm not sure if I could generally recommend AirportItlwm, given I can't get the Continuity stuff to work which is its main point versus itlwm. If you just want a working WiFi connection and don't want to buy Broadcom, I'd think that the standard itlwm is probably more reliable and certainly a bit easier to get going.

 

[beltzak]

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.

Thanks for the info. Did not know that, I gave away my ipad air 2 (mum) so I am not using now.

I have Continuity and Handoff working but not very reliable. I don't care thou don't find it much need of it as I do completyl different workflow in a computer than idevices. Thank you for the work, trouble and testing you have been doing man. I can't wait to get home and start testing everyhting ;P

Cheers