Contribute
Register

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

...
In my case, the issue is headless mode. I can boot with iGPU enabled with standard BIOS DVMT and none of the other fixes if I don't use headless mode. The settings from your OC 0.6.0 mini-guide work fine for this.

I had previously thought it might be headless mode, but then it didn't make sense that turning off the iGPU outright worked,
Some clarification needed:
  • Does this mean that turning off the iGPU in BIOS provides the best compatibility for LG Ultrafine 5K?
  • Or does it mean that iGPU can be enabled, but Platform ID should be 0x3E9B0007 (non-headless)?
 
...
@CaseySJ Have you tried to make a full install of this version to your "not installable" Z390 Designare?
I updated to Public Beta 2 on the Z490 Vision D yesterday. I can try a fresh install on Designare Z390 later today.
I'm happy to report that a direct installation of Big Sur Public Beta 2 was successful on the same Z390 Designare where Public Beta 1 could not be directly installed.
Screen Shot 2020-08-21 at 11.31.44 AM.png
 
Some clarification needed:
  • Does this mean that turning off the iGPU in BIOS provides the best compatibility for LG Ultrafine 5K?
  • Or does it mean that iGPU can be enabled, but Platform ID should be 0x3E9B0007 (non-headless)?

Either one works. I prefer the 0x3E9B0007 option I got working today though, as it leaves the iGPU enabled for other OS, and with iGPU off entirely I was using iMacPro1,1 SMBIOS since I've usually had issues in the past with iMac19,1 without an iGPU.
 
It's a Unitek USB3.1 Type C to dual SATA HDD with offline clone.
I did not have it on the previous build.
I've tried it in various 3.1 ports directly on the rear IO and hub.
@CaseySJ What do you reckon's the problem?
 
@CaseySJ What do you reckon's the problem?
Okay, some interesting updates. Always good to have such a device in the house!
  • There appears to be a problem in Apple's implementation of IOUSB-to-IOSCSI.
  • When we insert one drive, it mounts.
  • When we insert a second drive, everything ejects first and then both drives mount. This leads to a "Disk Not Ejected Properly" warning.
  • When we safely eject one of the two drives, the ejected drive remains in IOReg. It's as if the drive was not ejected.
  • When we safely eject the second drive as well, still both drives remain in IOReg.
  • When we then physically pull a drive out of the dock, both drives disappear from IOReg, but the drive that was not physically removed gets reconnected and remounted.
So in summary:
  • MacOS seems to be treating these dual-bay docks as a single-bay dock when it comes to eject and mount.
  • The only way to avoid the warning is to mount both drives before powering on the system and to eject both drives before physically removing either one.
  • We can also mount one drive, then eject it (but not physically remove it), then insert the second drive. Now both drives will appear on the desktop without warning.
This was tested on an Apple MacBook Pro 13" 2020 model.

Two Disk Dock.jpg


The same behavior is seen on Z390 Designare:
Screen Shot 2020-08-21 at 1.55.19 PM.pngScreen Shot 2020-08-21 at 1.58.22 PM.png
 
Last edited:
I'm happy to report that a direct installation of Big Sur Public Beta 2 was successful on the same Z390 Designare where Public Beta 1 could not be directly installed.
View attachment 485195
lets hope that we will dont have problems like this in official releases, Congrats
 
Hi Casey and all contributors,

Thank you so much for your wonderful work that sheds light on the resolution of Thunderbolt issues!

Recently, I tried to adapt your approach to my laptop, XPS 15 9560, but had difficulties fixing the Thunderbolt bus. I would like to discuss it here in case you have anything to comment on.
  • First, the Tthunderbolt controller is Alpine Ridge, and the device name is shown as Thunderbolt 3 (1575) in Windows. My Thunderbolt dock works if connected before booting into macOS, and under system information -> Thunderbolt, it said that either no hardware found or no drivers are loaded.
  • I tried and modified osy's Thunderbolt reset kext and his SSDTs (replacing the PCI name and level trigger to the correct ones), but the best I can achieve is partial hot-plug: the dock fully works when the first time it connects, but after hot-plugging only the DisplayPort part works.
  • Then I found this thread: I followed osy's guide patching NVM, dumped the controller's firmware, and did patching on it. Next, I created an SSDT with the Web GUI Method in this post (X1's SSDT has chosen) and loaded into OpenCore, but the system continues to complain that no drivers are loaded, and the hot-plugging is still partially working.
  • I did the rename patches and analyzed the boot log -- all SSDT applied above should be correctly loaded.
Questions:
  1. I found a strange thing: after patching my NVM firmware, my TB3 dock still works under Windows -- but osy mentioned that the controller should be in a **safe mode** and only usb-c devices would work. Is this an expected behavior? Otherwise, should I explore more on firmware patching?
  2. If you believe I could continue working on this issue, would you please clarify if your patching approach is the same with osy's one?
  3. I saw you mentioned that firmware patching cannot be applied if OS X complains that no drivers are loaded. Does it mean that I cannot make the TB controller work on my laptop?

I attached the following stuff here:
  • IOreg dumps after booting, unplugging, and re-plugging my TB3 dock.
  • My TB3 controller dumped from the WINBOND chip and after my patching, with the Apple TB3 firmware used.
  • My OpenCore configuration.
  • Screenshots of my PCI devices under system informations.
Screen Shot 2020-08-20 at 11.07.53 PM.png

Screen Shot 2020-08-20 at 11.07.56 PM.png



I appreciate any hint you could give. Thank you again for your time!
 

Attachments

  • after_boot.ioreg
    12.7 MB · Views: 64
  • after_replug.ioreg
    12.1 MB · Views: 48
  • after_unplug.ioreg
    12 MB · Views: 48
  • tb3-firmwares.zip
    554.9 KB · Views: 57
  • OC.zip
    9.4 MB · Views: 60
Last edited:
Yes we have to remove all macOS drives before installing Windows. Once you're comfortable capturing USB traffic for the ITE Tech device (RGB Fusion 2), it should be straightforward to do the same for Thermaltake Riing Plus.

Hi Casey,

In regards to the Thermaltake Riing fans, It should be possible to do this now as I know the TT RGB Plus software works and controls my fans using a Windows 10 VM. Ill start up my Windows10 VM now through Parallels and install TT RGB Plus and also Wireshark. :)
 
Hi Casey,

In regards to the Thermaltake Riing fans, It should be possible to do this now as I know the TT RGB Plus software works and controls my fans using a Windows 10 VM. Ill start up my Windows10 VM now through Parallels and install TT RGB Plus and also Wireshark. :)
It is better to work on Gigabyte RGB Fusion first because the driver already exists and it may require just a little bit of work to support the AORUS Xtreme.

ThermalTake Riing support will need a brand new driver.
 
hey Casey, getting back in the rhythm of things here again since getting the rig going. anyway I installed Big Sur on an external drive and copied my EFI folder over and got it up and running. so far so good. but as I said, a lot has changed since I've been away.

what tweaks from page 1 should be done now? :
radeon boost
usb (says optional)
would love to get the native wifi and bluetooth working but directions are for clover. can they be used in OC? what paths should they be in?
I also see drivers (from the bluetooth micro guide) for cases. I don't have a fractal, but what do these do?
am I missing anything?

if I can get this drive working, I may just blow away Catalina and just use BS. with a premade EFI folder the install should be pretty easy
 
Back
Top