Contribute
Register

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

Looks like certain Fenvi WiFi cards and Corsair Vengeance LPX DIMMs are exhibiting unusually high number of issues, although all six of my Fenvi cards have never failed. And although I primarily use G.Skill, Silicon Power, and Team Force DIMMs, I do have a couple pairs of Corsair Vengeance LPX modules that have been just as reliable. Alas, failures do occur and the laws of statistics guarantee that failures will continue to occur on just about every product. Failures can be due both to manufacturing issues and operational issues.

So far I am only aware of one issue my Fenvi has. If I have to hard restart (for example, due to all these constant RAM bugs), sometimes upon logging into macOS the Bluetooth won't work unless I reboot. Easily fixed and doesn't have any other problems. Odd that it works fine at the FileVault 2 login screen though when this happens.

I've had the same happen to a native card in an adapter so I consider that an OS bug due to some weird power state than anything wrong with the device.

I'm going to run a test on my other PC that has Corsair Vengeance LPX in it. Especially since I'm going to need to borrow one of those modules after I ship out the bad RAM for RMA.
 
Did you tried the trick in the first post: https://www.tonymacx86.com/threads/...olt-3-i7-9700k-amd-rx-580.267551/post-2118036

«Disabling wake from USB». Only wake by power button.


Hello.

I tried this morning switching to OpenCore, from my actual Clover configuration.
The sleep/wake issue is still there.

I followed the instructions of this guide in relation to my sleep/wake problem, and it works!
Thx again, @brousseau6933!

Two considerations:

At the ACPI section, I left the first column empty. At the guide nothing is mentioned.
I had also to enable it. It's disabled by default.

Screenshot 2020-08-23 at 08.23.34.png


And for adding the .aml file, I'm not sure what's that section screen for. I added here the file (browse button), but it was not really updated or sent to the specific folder at the EFI drive. I had to do it manually.


Screenshot 2020-08-23 at 08.22.56.png
 
I am wondering if these cards had 3.3V on pin 3 before or after flashing them? My cards do not (revision 1.0 GC-ALPINE RIDGE). I have not flashed my cards.
@joevt Thanks to the pioneering work of osy86 and Ruytenberg I've discovered that you can unhide Alpine Ridge controller AIC's in macOS with two simple original firmware edits. At offset 0x800 change 19 to 18 (this switches security mode to SL0 as in all Mac built-in controllers), and replace FFFFFFFF at offset 0x4BA0 with the byte reversed vendorID:deviceID of your alpine ridge chip eg 8680D315. It's not the full blown edit that gives you the thunderbolt tree but allows for full cold boot / hot plug functionality in both Windows and macOS (with the correct SSDTin the latter case).This might be worth trying with your MacPro cards....
 
Last edited:
@joevt Thanks to the pioneering work of osy86 and Ruytenberg I've discovered that you can unhide Alpine Ridge controller AIC's in macOS with two simple original firmware edits. At offset 0x800 change 19 to 18 (this switches security mode to SL0 as in all Mac built-in controllers), and replace FFFFFFFF at offset 0x4BA0 with the byte reversed vendorID:deviceID of your alpine ridge chip eg 8680D315. It's not the full blown edit that gives you the thunderbolt tree but allows for full cold boot / hot plug functionality in both Windows and macOS (with the correct SSDTin the latter case).This might be worth trying with your MacPro cards....
Because offset 0x800 lies in the scratch area, are you sure that is the correct offset?
 
Reminder:

Please do not refer to Big Sur public beta builds as "Developer Beta 4" or "Developer Beta 5". Developer betas are subject to non-disclosure agreements (NDA) and such posts will be removed.

Currently we have:
  • Big Sur Public Beta 1
  • Big Sur Public Beta 2
Because public beta builds are not subject to NDA, discussion of them is ethical and allowed.
 
Hi @CaseySJ,

Thank you so much for pointing out those pitfalls I made during testing!
I tried both of these firmware but failed observing the difference between them. Specifically,
  1. Disabled hotpatches, replaced SSDTs, and checked that all SSDTs are correctly loaded.
  2. I flushed Mod-1, cleared NVRAM, and rebuilt the kext cache.
  3. Boot into macOS with TB3 dock connected -> it didn't work at all despite my laptop was charging; reconnect it -> nothing happened.
  4. Boot into macOS without TB3 dock connected -> similarly not working; connect it -> nothing happened.
  5. Then, I flushed the second firmware, cleared NVRAM, rebuilt kextcache etc..
  6. Nothing changed. Basically I got the same result as in step 3/4.
I can see a thunderbolt bus in system information as the screenshot shows below:

(mod-1)

(mod-2)

Occasionally, when I switch to the thunderbolt tab in system information, it freezes with the following interface; several seconds later, a different thunderbolt bus w/o port appears:

It looks great under PCI tab -- the thunderbolt controller is loaded and functioned.

However, in IORegExplorer I cannot spot any difference before/after the TB3 device is connected. I will attach all IOReg dumps here.

Thanks,
mistw
Okay, feel free to try the software-only approach as follows:
  • Flash the original Thunderbolt firmware back to the Winbond chip.
  • Boot the system to ensure that Thunderbolt is back to 'normal' behavior.
  • Then replace previous Thunderbolt SSDT with attached version.
  • Also enable the two ACPI renames shown in the screenshot:
    Screen Shot 2020-08-23 at 4.25.24 AM.png
However, please note:
  • This SSDT may not work because some assumptions were made.
  • If you provide a copy of the DSDT.aml (maciASL --> File --> New from ACPI --> DSDT) I can check/update the SSDT.
 

Attachments

  • SSDT-TbtOnPCH-GA-Z170-UD5TH.aml
    4.9 KB · Views: 68
I have the ASRock Thunderbolt 3 AIC so I can try to extract and modify its firmware. It's only possible to flash the modified firmware with an external SPI Flash ROM reader/writer such as Raspberry Pi running flashrom. The procedure might seem scary (and it should!), but it's quite straightforward on an add-in-card, especially so if the simple resistor/capacitor circuit is used.
that would be great, yes I have an SPI flash tool and a raspberrypi so only missing the modified firmware. (flashed some bioses in the past too
 
Because offset 0x800 lies in the scratch area, are you sure that is the correct offset?
It’s either 0x800 or 0x1800 depending on whether the pointer to the active region is at 0x0 or 0x1000 respectively...
 
Hi guys - my system has been running great here for a while now, but I've noticed that every time it shuts down, it restarts immediately.

Has anyone experienced this? Is there a fix?

Running 10.15.5 with the config files from the thread.
Native NVRAM
 
Last edited:
Hi guys - my system has been running great here for a while now, but I've noticed that every time it shuts down, it restarts immediately.

Has anyone experienced this? Is there a fix?

Running 10.15.5 with the config files from the thread.
Native NVRAM
Hello @Isoparm,

What remedial steps have you attempted so far?
 
Back
Top