Gigabyte Z490 Vision D (Thunderbolt 3) + i5-10400 + AMD RX 580

[sam.brett]

Yes.

Thanks for the fast responses. I'll re-create my plist file with OpenCore 64 and see where I go from there. I suspect I'm going down the fresh install route with all the half installs and dodgey EFI values.

 

[CaseySJ]

Thanks for the fast responses. I'll re-create my plist file with OpenCore 64 and see where I go from there. I suspect I'm going down the fresh install route with all the half installs and dodgey EFI values.

Those OpenCore warnings mean that your config.plist is from OpenCore 0.6.4 but OpenCore itself is an earlier version. In other words, there's a mismatch between config.plist and the OpenCore version.

 

[Higgie]

I managed to pick up an RX6800 (I know - amazing!) and I know it won’t work in MacOS Catalina, so in the meantime I’d like to hide the 6800 in PCI-E slot 1 in macOS, and then disable the RX580 in Windows. Can anyone tell me what happens with regard to the card that isn’t being used? My PSU is a Corsair RM650, and 650w is the min. requirement for the 6800, so just wondering if I need to upgrade my PSU seeing as I will only be running one card at a time.

 

[checksum]

Hi,

I have a success story using Gigabyte Z490 Vision D / i10850k / RX 5500XT and 0.6.3 guide.

You have to use kernel patch from https://github.com/acidanthera/bugtracker/issues/901

Then I updated to 0.6.4 and tried to update to Big Sur. It worked perfectly, but... Now I have random freezes after successful startup (looks the same as in this post: https://www.tonymacx86.com/threads/...olt-3-i5-10400-amd-rx-580.298642/post-2192263)

@MusicMac have you found any other way than disabling iCloud to fix this problem?

Reply to self - instability was caused by XMP Profile #1. I have selected XMP Profile as in @CaseySJ guide but I did not change the voltage. Maybe the guide could emphasise that voltage should be set separately? I am on BIOS ver. 7B.

Funny thing is that it worked on Catalina smoothly but Big Sur was freezing even on the login screen.

@MusicMac Do the memtest, maybe DRAM voltage settings are causing your problems as well.

 

[sam.brett]

Those OpenCore warnings mean that your config.plist is from OpenCore 0.6.4 but OpenCore itself is an earlier version. In other words, there's a mismatch between config.plist and the OpenCore version.

It turned out to be a calamity of errors, all of which would have been solved by not doing things when tired or frustrated.

1. I copied OC64 to the wrong volume, I have two Samsung drives, and I used the wrong one
2. In effect my "stable" OC64 EFI was just my old OC61 one.
3. My boot order got screwed up some how (probably the CMOS reset) and was loading the EFI from a backup that wasn't valid

I've added a "NOT_HERE.txt" file to the other Samsung drive to prevent me from derping again.

So good news, I have Big Sur installed, all my data is fine and I've learnt something.

Thanks to @CaseySJ and @P1LGRIM for pointing me in the right direction. You guys are great.

 

[austinmrs]

Hi @CaseySJ I have a problem you might be able to help me.
Like I told you I have an ASRock Z490 ITX Phantom Gaming AC/TB3 that has the JHL7540 tb3 chip.

I have one SSDT that makes Thunderbotl3 work, including hot plug etc, I can even use an external GPU on the TB port like a Razer Core X. The problem is, with this SSDT, the thunderbolt controller appears with XHC name on it, the same as the normal USB controller, and because of this I get that weird icon on the status bar meaning the thunderbolt chip is not recognized, even tho it is working. So I suspect this SSDT that is working, has the name of chip incorrect?

Then I have another SSDT that thunderbolt doesnt work, when I connect Razer Core X it crashes... but this one has the name of the chip correctly set, it appears as XHC5 on the type of the chipset, and the icon on the status bar does not appear meaning the tb3 chip is being recognized.

My question is, are you able to edit the SSDT that works and has the naming incorrect, to rename the type of the TB3 chipset from XHC to XHC5 and the name of the ports too?

Basically I need to take the naming of the ports/type of the controller name from the one that does not work, and change the one that works to use that naming instead.

I tried but was not able to...

 

[CaseySJ]

Hi @CaseySJ I have a problem you might be able to help me.
Like I told you I have an ASRock Z490 ITX Phantom Gaming AC/TB3 that has the JHL7540 tb3 chip.

I have one SSDT that makes Thunderbotl3 work, including hot plug etc, I can even use an external GPU on the TB port like a Razer Core X. The problem is, with this SSDT, the thunderbolt controller appears with XHC name on it, the same as the normal USB controller, and because of this I get that weird icon on the status bar meaning the thunderbolt chip is not recognized, even tho it is working. So I suspect this SSDT that is working, has the name of chip incorrect?

Then I have another SSDT that thunderbolt doesnt work, when I connect Razer Core X it crashes... but this one has the name of the chip correctly set, it appears as XHC5 on the type of the chipset, and the icon on the status bar does not appear meaning the tb3 chip is being recognized.

View attachment 500895

My question is, are you able to edit the SSDT that works and has the naming incorrect, to rename the type of the TB3 chipset from XHC to XHC5 and the name of the ports too?

Basically I need to take the naming of the ports/type of the controller name from the one that does not work, and change the one that works to use that naming instead.

I tried but was not able to...

There are several errors in the statements above:

• XHC does not refer to the Thunderbolt controller. Thunderbolt consists of at least three protocols:
  • USB
  • DisplayPort
  • PCIe
• XHC refers to the USB protocol controller. Because USB itself contains multiple protocols (USB 2.x, USB 3.x), the USB protocol controller defines child nodes such as HSxx to refer to USB 1.x/2.x ports and SSPx to refer to USB 3.x ports.
  • In some motherboards, USB 1.x/2.x protocol is handled by the chipset itself (i.e. a companion controller), whereas only USB 3.x is handled by the Thunderbolt controller's USB protocol controller.
  • In this case we will only see SSPx devices listed under the Thunderbolt device tree.
• The Thunderbolt controller itself resides on a Root Port (RP) such as RP05, RP09, RP21, etc.
• One of the SSDTs you posted (the one marked "not working") assumes that the Thunderbolt controller is on RP21. The other SSDT (marked "working") assumes that the Thunderbolt controller is on RP05.

To clear up this confusion, please:

• Disable all Thunderbolt SSDTs
• Reboot the system
• Run IORegistryExplorer and post the IOReg file

 

[zedoc]

Just updated to Big Sur with success! on OC 0.6.4+Wifi+Bt (secureboot back to "default" after update)
Quick question:
How can i rename Catalina and Catalina-Data HD properly to Big Sur and Big Sur-Data? (without messing with OC boot picker...)
Also, i've read that we should keep the "com.apple.os.update snapshot" for future updates?

 

[CaseySJ]

Just updated to Big Sur with success! on OC 0.6.4+Wifi+Bt (secureboot back to "default" after update)
Quick question:
How can i rename Catalina and Catalina-Data HD properly to Big Sur and Big Sur-Data? (without messing with OC boot picker...)
Also, i've read that we should keep the "com.apple.os.update snapshot" for future updates?

Please refer to the Troubleshooting / FAQ section in Post 1, namely this item:

 

[austinmrs]

There are several errors in the statements above:

• XHC does not refer to the Thunderbolt controller. Thunderbolt consists of at least three protocols:
  • USB
  • DisplayPort
  • PCIe
• XHC refers to the USB protocol controller. Because USB itself contains multiple protocols (USB 2.x, USB 3.x), the USB protocol controller defines child nodes such as HSxx to refer to USB 1.x/2.x ports and SSPx to refer to USB 3.x ports.
  • In some motherboards, USB 1.x/2.x protocol is handled by the chipset itself (i.e. a companion controller), whereas only USB 3.x is handled by the Thunderbolt controller's USB protocol controller.
  • In this case we will only see SSPx devices listed under the Thunderbolt device tree.
• The Thunderbolt controller itself resides on a Root Port (RP) such as RP05, RP09, RP21, etc.
• One of the SSDTs you posted (the one marked "not working") assumes that the Thunderbolt controller is on RP21. The other SSDT (marked "working") assumes that the Thunderbolt controller is on RP05.

To clear up this confusion, please:

• Disable all Thunderbolt SSDTs
• Reboot the system
• Run IORegistryExplorer and post the IOReg file

Thank you for the knowledge! I will do that when I have time and report back, currently out of the house.

I think BIOS 1.4 the Thunderbolt port is on RP05.
But with bios 1.42 BETA they changed it to RP21 for some reason, I don't know why.