[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

[faithie999]

I've been carrying on tinkering with the SSDT-only approach to getting a full thunderbolt tree and have got as far as the very simple attached version which works great on built-in Alpine Ridge. It's based on the great work originally done by @Elias64Fr and @CaseySJ (all credit to them) and provides a full tree with working TBT and USB-C hot plug on cold and warm boot, TBT networking and target disk mode in the client computer. I was wondering if maybe we've been over-complicating things, might this work with built-in Titan Ridge as well? If you want to test it then you'll need to do a few things:

• Change the RP05 Root Port number throughout the SSDT to whatever yours is and change the address on the first line of the MMBA method using the (PCI address * 8)+x formula. My thunderbolt RP05 is at 1C,4 so its (1C * 8)+4 = E4. There are no power methods as hot plug seems to be 100% consistent without them.
• In the bios I have Force Power and ACPI RMV method enabled in the thunderbolt section. These might be hidden and so will need to be enabled using the grub approach. Note that I've removed DSB4 and only have one XHC2 SSP port as the AsRock Z370 itx/ac motherboard only has one thunderbolt port.
• The GPE._E2C method will also need to be renamed according to the value in your system. Just dump your system DSDT using MacIASL and search for "Method (TINI, 2, Serialized)". Immediately above it you'll find the hot plug event method which will be named "_Exx".
• The RP05._INI method in your DSDT will need to be renamed RP05.XINI using your OpenCore config.plist
• The _GPE._Exx method in your DSDT will need to be renamed _GPE.XExx using your config.plist

As far as I can tell functionality is just the same as when I tried patched firmware but with the added bonus of TBT working normally with other operating systems. This approach might only work with built-in Alpine Ridge but it's worth trying...

Unfortunately, no luck.

Before following your procedure, I flashed my GC-Alpine ridge AIC back to the original firmware.
I booted the system, the full boot sequence was visible on my Apple Thunderbolt Display, and at the end of the boot the desktop appeared as expected. However, no display peripherals worked (such as the camera, "display microphone", and "display sound"). The peripherals do work with Elias's V1 patched firmware.

Then I followed your procedure.
On my motherboard, the AR AIC attaches to RP21 at 1B,4.
In your SSDT, I did a global search and replace of RP05 with RP21.
I changed the address in the GPCB method to from E4 to DC.
I extracted my DSDT with F4 from the Clover screen.
In the DSDT, I renamed RP21._INI to RP21.XINI and I renamed _GPE._E17 to _GPE.XE17.
I have Force Power enabled in my BIOS but the Aorus Pro BIOS has no setting for the RMV method.

I rebooted, and I noticed no difference from booting without your modifications.

I have tried booting with and without the SSDT that CaseySJ created to inject DROM. with/without made no difference.

When I have tried Elias's patched AR firmware, IIRC the display and its peripherals attached to DSB4. Somewhere I think you said how to patch your SSDT to account for DSB4 but I can't find the message.

Attached is a screen shot of the RP21 portion of IOReg, and of system report--PCI. Also attached are my patched DSDT and your SSDT modified.

Thanks


UPDATE--it appears from MaciASL that the modded SSDT isn't loading.

Progress!!

I had stupidly forgotten to save the edited SSDT as .aml.

So:
there are a couple of lines in the verbose boot that indicate the display isn't going to work.

Thunderbolt DP--activating video path--SRC[0:0x0:0x9] DST [0:0x2:0xb]--req_bandwidth = 79
Thunderbolt DP--destroying video path--SRC[0:0x0:0x9] DST [0:0x2:0xb]
Thunderbolt DP--activating video path--SRC[0:0x0:0x9] DST [0:0x2:0xb]--req_bandwidth = 79
Thunderbolt DP--destroying video path--SRC[0:0x0:0x9] DST [0:0x2:0xb]
IOThunderboltSwitch<0>(0x2)::listenerCallback -Thunderbolt HPD packet for route = 0x2 port = 11 unplug = 1
Thunderbolt DP--activating video path--SRC[0:0x0:0x9] DST [0:0x2:0xb]--req_bandwidth = 79
Thunderbolt DP--destroying video path--SRC[0:0x0:0x9] DST [0:0x2:0xb]
Thunderbolt DP--activating video path--SRC[0:0x0:0x9] DST [0:0x2:0xb]--req_bandwidth = 79
Thunderbolt DP--destroying video path--SRC[0:0x0:0x9] DST [0:0x2:0xb]

I booted with a second display (DVI), and, unfortunately, the TB display doesn't light up at the end of boot. I tried hot unplug/replug to no avail.

However, the display mic, display sound, and the FaceTime camera all function. Just not the display screen.

Attached are a copies of IOReg and the Thunderbolt tree from system report--Thunderbolt.

Would the lack of DSB4 in the SSDT have anything to do with this?

Thanks!

 

[mcljot]

Hi Casey, I built my Hackintosh from this guide in February 2019 and came back over the weekend to update it. All the updates worked really smoothly, another testament to this phenomenal resource you've created and your continued efforts. Remarkable!

Done:
- Updated Clover to version 5115
- Updated 10.14.3 to 10.14.6 (not that interested in Catalina just yet)
- Overclocked to 4.8GHz
- Removed my custom Vega 56 fan control tweaks and am delighted with the native support in 10.14.6!
- Experimented briefly with RadeonBoost and didn't notice any performance increase, but my Vega 56 fans go crazy (going to experiment some more tonight)
- Unlocked the full 1.4GHz of the iGPU (amazing!!!)
- Installed new Lilu and WhateverGreen (and nothing broke!)
- Fixed my USB ports - for some reason during the steps above, I lost all USB ports except the two black ones on the motherboard. I think it could have been because the 'MatchOS' column for my USB remapping in Clover kext patching didn't match the values that the new Clover was looking for? Maybe! Anyway it works now.
- Maybe a few other things I forget

Still remaining to do:
- Replace OsxAptioFix2Drv-free2000.efi with the recommended OcQuirks-4.efi and FwRuntimeServices.efi. I don't have the EmuVariable efi in CLOVER/drivers/UEFI - will try OcQuirks anyway though. You mentioned a 'dire warning' about OsxAptioFix2 but I couldn't find any reference to the warning on the author's github. What was it?
- Update BIOS firmware. I'm on F4 at the moment, although I'm not sure if this is really necessary...
- Experiment with the native wifi driver

One question I have is about kext placement in /Library/Extensions vs. in CLOVER/kexts/Other. I've spent about 4 hours trying to find a source of truth - why does it matter where the kexts go, if they are all injected anyway? And is there a 'right' way to do it? At the moment my system has a mishmash of kexts in both places.

In Linux my Geekbench 5 scores are a bit higher than in macOS:

	Fedora 29	macOS
Single-core	1444	1272
Multi-core	8689	8407
Metal		56602
OpenCL		49436

 

[CaseySJ]

I did this and while my system still boots without an issue, trying to update results in the same kernel cache problem...

I think it's time to unlock MSR 0xE2 by clicking here. While this alone may not solve the problem, it eliminates one more variable between your system and systems that have successfully been updated.

 

[qthegaijin]

Hi Again @CaseySJ

As I have said I have direct contact with the Antelope guys. I have direct mail with RMA and Develop team.
Could be possible if we try to adapt or know what really happens? in my x299 in verbose seems to be detected but the communication seems to be wrong. Failing in sample rate.
If I could help with all the hackintosh that I have and my interfaces (I have some here Apogee, Focusrite,...) could be amazing to solve the situation. Or try to send the reports and problems to these guys. If we report exactly the problem they could fix in future versions...


I have the titan card flashed, lets test it

thanks guys!

Please let me know what Info you need!!! If you do a search for my posts here, you can find the log files I have posted for when the unit attempts to connect.

My main observation is:
There is a DMA error which happens causing a timeout between talking to the device. The system will see it fine, it shows all the correct device info, but the DMA error with the driver causes the driver to fail and the unit to not be seen as a useable device by macOS.

 

[lambusser]

Please try this:

• Undo the changes (i.e. re-enable the USB ports).
• Physically disconnect the Corsair device(s) from USB header.
• Reboot.
• Check if sleep works.

Hi @CaseySJ,

Did that a bit ago and it still is waking right up. Look like my three RME Audio Devices (one is connected via TB and the other two via USB) are very "chatty"...when I shut all three of those off sleep worked.

It's really not a great option for me to shut all three of those down every time I want to sleep and I can't "exclude" them via Clover. I think I just need to shut all USB wake down and focus on the power button only.

Thank you for your suggestions.

Lam

 

[CaseySJ]

...
Still remaining to do:
- Replace OsxAptioFix2Drv-free2000.efi with the recommended OcQuirks-4.efi and FwRuntimeServices.efi. I don't have the EmuVariable efi in CLOVER/drivers/UEFI - will try OcQuirks anyway though. You mentioned a 'dire warning' about OsxAptioFix2 but I couldn't find any reference to the warning on the author's github. What was it?

Hello again @mcljot,

Replacing OsxAptioFix2Drv-free2000 is very easy and should be done. It's just a matter of replacing that EFI with the two that you mentioned (OcQuirks4.efi and FwRuntimeServices.efi). The "dire warning" was a bit of an exaggeration in my opinion -- it was posted on a different site (not GitHub).

- Update BIOS firmware. I'm on F4 at the moment, although I'm not sure if this is really necessary...

No, not really necessary, but there are some security patches in the more recent firmware versions.

- Experiment with the native wifi driver

Just be very careful with this...

One question I have is about kext placement in /Library/Extensions vs. in CLOVER/kexts/Other. I've spent about 4 hours trying to find a source of truth - why does it matter where the kexts go, if they are all injected anyway? And is there a 'right' way to do it? At the moment my system has a mishmash of kexts in both places.

I'm not going to fuel this fire! But I will say that for easier upgrade to Catalina in the future, it would be good to install all third-party kexts in CLOVER/kexts/Other and remove them from /Library/Extensions. Be sure to run Kext Utility to rebuild kernel cache afterwards. If this utility is not available, open Terminal and type sudo kextcache -i / and reboot.

 

[jlr]

I think it's time to unlock MSR 0xE2 by clicking here. While this alone may not solve the problem, it eliminates one more variable between your system and systems that have successfully been updated.

You linked to the guide to Enable Native NVRAM; I've actually already unlocked MSR 0xE2 via this micro-guide. The output of setup_var_3 0x5c1 via the grub> prompt is 0x00. My BIOS version is F6.

I see that MSR 0xE2 unlocking procedure in the guide you linked to involves unchecking Kernel and Kext Patches --> KernelPM after unlocking MSR 0xE2. Should I go ahead and do that, since MSR 0xE2 is already unlocked?

 

[mcljot]

Hi!

I'm not going to fuel this fire! But I will say that for easier upgrade to Catalina in the future, it would be good to install all third-party kexts in CLOVER/kexts/Other and remove them from /Library/Extensions. Be sure to run Kext Utility to rebuild kernel cache afterwards. If this utility is not available, open Terminal and type sudo kextcache -i / and reboot.

Haha I seem to recall it being a bit of a fire. I have always preferred having them on the EFI - I think I got into trouble once before when I included something catastrophic in /S/L/E or /L/E and couldn't get back into the system to remove them. Not entirely sure though, it's been a while.

I will continue with RadeonBoost, and will exercise due caution with the wifi driver. Thanks!

I've also noticed a ~100 point drop in my single core GeekBench 5 score since doing these updates. I'm not overly concerned tbh, but would be nice to see the numbers get bigger, not smaller Having caught up on 100+ pages of this thread, I think it might be to do with the newer WhateverGreen version I installed (1.3.8). I see that yesterday, acidanthera has released 1.3.9. I will try it.

Thanks again!

 

[CaseySJ]

You linked to the guide to Enable Native NVRAM; I've actually already unlocked MSR 0xE2 via this micro-guide. The output of setup_var_3 0x5c1 via the grub> prompt is 0x00. My BIOS version is F6.

Good -- half the battle...

I see that MSR 0xE2 unlocking procedure in the guide you linked to involves unchecking Kernel and Kext Patches --> KernelPM after unlocking MSR 0xE2. Should I go ahead and do that, since MSR 0xE2 is already unlocked?

Yes please uncheck those two boxes. This may not solve the kernel cache problem, but it's worth doing anyway.

A more desperate option would be to add this to Boot Arguments at least temporarily and see what happens:

-f UseKernelCache=No

 

[mm2margaret]

So, @CaseySJ -

I have a GC-TitanRidge card with an NVM of 43. Do you think it would be worthwhile to flash it to NVM33 and then re-flash with one of the patches? Either from DSM2 or one of Elias64Fr's patches?

I'm getting the impression that NVM 33 has the best response so far, but then it sounds like it needs to be re-flashed and adjusted to get it work the best. Also, an SSDT must also be customized to work with it, correct?

Have I got that right?