Contribute
Register

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

tpep said:
@jleahy2 My story so far. Got a Sapphire Radeon VII (used) on Ebay. Unfortunately the card was faulty and couldn't even post! Had to return it. At least got my money back. Since then I've tried to find another Sapphire Radeon VII but was unlucky. It is very hard if not impossible to get one now days. So I am contemplating whether a choice of going with an XFX or Gigabyte (or any other of the available brands) is too risky OR is it safer going with something more trustworthy like the Sapphire Vega64?
Click to expand...
This is the first AMD card I've had success with. About a year ago, I had a Sapphire Vega64, but it was bad. Crashed all the time, even under Windows. It seemed to work well when it was running and I've read really good things about them though, I guess I just had a fluke/bad card. I had nothing but problems with my RX 5700 XT too, but that one only gave me problems under OSX, it ran perfect under Windows so I know that wasn't the card's fault.


I was on the fence between trying another Sapphire Vega64, and trying this XFX Radeon VII. I honestly was wanting to go with the Vega64, but I was hesitant over having a prior bad experience with it once before (I still think it was just a fluke/bad card given how many people have run them with no problems). Either way, assuming you have a beefy enough PSU to handle the card, I honestly don't think you're going to have problems going with either of those. They are both solid choices, and seem to have most of the issues ironed out with them now. I'd choose the one that falls best in line with your price and requirements for use.
 
Main Audio/Software Production Box
Z390 DESIGNARE |  i9 9900K |  Radeon Other
Elias64Fr said:
@CaseySJ

As we are talking about an SSDT ready to play, I have prepared (not lunch but )a basic SSDT for enabling Link status to 0x101 (normal state) instead of 0x7 (disconnected) :


This can be used as a base of the final one.
We have to disabling _E17 to XE17 before use it but not tested if it is really required so I have it like that for now.
And also renaming RP05.PXSX to RP05.UPSB on our favourite boot loader :)
Click to expand...
@Elias64Fr,

To clarify...
  • This should be "used as a base of the final one". This means we should merge these changes into the main TbtOnPch SSDT?
  • Does it matter if Method _GPE() is at scope \_SB.PCI0.RP05, or should _GPE() be at root scope?
  • This SSDT is adding functionality to PXSX because you're not deleting and replacing PXSX. Instead, you're only renaming it.
Because I have two Designare systems, one with original firmware and the other with flashed firmware, I can certainly test this on the original firmware.
 
@Elias64Fr @NorthAmTransAm @qthegaijin @augustopaulo

Can you please type the following in Terminal and then compress and send the output file called TB3.txt that will be created in your Documents folder?
Code: 
log show --last boot | grep Thunderbolt > ~/Documents/TB3.txt
@qthegaijin, It would be helpful to do this on both of your builds.
 
Elias64Fr said:
@NorthAmTransAm @CaseySJ
On your log, I can see that you don't have our damn error 0xe00002be but like on my previous screenshot :

IOThunderboltEEPROM::getDROM - Error getting DROM from I/O Registry (0xe0000001)
​
Same error description BUT different error code :confused:
Click to expand...

Good catch. Post edited!
 
CaseySJ said:
@Elias64Fr,

To clarify...
  • This should be "used as a base of the final one". This means we should merge these changes into the main TbtOnPch SSDT?
  • Does it matter if Method _GPE() is at scope \_SB.PCI0.RP05, or should _GPE() be at root scope?
  • This SSDT is adding functionality to PXSX because you're not deleting and replacing PXSX. Instead, you're only renaming it.
Because I have two Designare systems, one with original firmware and the other with flashed firmware, I can certainly test this on the original firmware.
Click to expand...
  1. If you want to have the last discovery ... you can also take what you want if you think it interesting :)
  2. It doesn't matter if you have \_SB instead of _SB (like on terminal command \ is root).. idem for GPE
  3. Yes I were like this for long time (on my AIO SSDT)
  4. Dont think it will work on original firmware, you have to reconfigure RP05, UPSB, DSB0 register to get NHI0 access like done on previous story :)
 

Attachments

  • TB3.txt
    17.1 KB · Views: 129
Bobby22 said:
Thank you very much for your help. As a Doctor, I haven't much time to spend on it on these times... Hopefully you are here <3.
Click to expand...
Completely understand; my brother has been temporarily assigned to work in ER/ICU. This is the new global 9-11.
1) I Used a Flathead Screwdriver to Reset the Bios and got the message "Bios has been reset". I loaded Optimized Defaults and then Setup the Bios again as advised (Running F8 Firmware).
2) But, The Bios settings were still saved (Got my Profile 1 still saved).
3) I tried to Boot on the USB EFI (MSR EFI) To change the MSR 0xE2 with the guide you gave us : which I did in the past to enable Native Nvram.
This was unsuccessful I can't boot on the UEFI USB (MSR-EFI one) : it just reloads the "Select Boot Device Screen".
(I double checked and everything is at the right position on the USB EFI partition). Can't boot whether I put CSM on or OFF, Whether I Put WinOs/Other Os.

4) I tried removing the Motherboard Battery, then CMOS reset (FlatScrew), then putting back the Battery. When I Put back the Battery the bios settings are still saved (Windows Boot Manager still appear/Clover Boot Manager also (which I added with EasyUEFI on Windows) (how ??? do I have to wait 12h without the Motherboard's Battery ?).
So I tried again to Load Optimized Default, set everything in the bios. Can"t boot on the USB (MSR UEFI one) again. (Tried to Boot on the EFI part, then on the non UEFI part : nothing works)

I Still can boot on windows and cloverBootManager but not on the MSR EFI.

Do i have to Flash the Bios ?
Thank you very much.
Click to expand...
Let's clarify the problem:
  • After installing the Windows NVMe in top M2M slot, you were able to select the option to boot macOS, but it resulted in "++++++++++++", which often means memory allocation error. Reseting CMOS is the first step. If this doesn't work, we examine the CLOVER/drivers/UEFI folder and possibly switch to a different memory driver.
  • Because you enabled NVRAM in the past, it is necessary to do oneof the following:
    1. Unlock MSR 0xE2 once again.
    2. Enable the checkboxes for KernelPM and AppleIntelCPUPM in Clover Configurator --> Kernel & Kext Patches.
  • The best long-term option is #1 (unlock MSR), but option #2 is viable for the short term.
  • To unlock MSR:
    • Are you using the same USB disk as you used before?
    • Does the USB disk contain an EFI partition? Can you mount that partition and check whether it contains an EFI/BOOT folder?
 
Last edited:

Attachments

  • TB3.txt
    9.3 KB · Views: 92
Elias64Fr said:
  1. If you want to have the last discovery ... you can also take what you want if you think it interesting :)
  2. It doesn't matter if you have \_SB instead of _SB (like on terminal command \ is root).. idem for GPE
  3. Yes I were like this for long time (on my AIO SSDT)
  4. Dont think it will work on original firmware, you have to reconfigure RP05, UPSB, DSB0 register to get NHI0 access like done on previous story :)
Click to expand...
Question 2 was this:

Which one of these two is right? Notice that first one is at scope SB.PCI0.RP05. The second one is at root scope.
  • \_SB.PCI0.RP05._GPE()
  • \_GPE()

Question 4 was this:
  1. Original firmware means original Thunderbolt firmware on Winbond chip.
  2. Modified firmware means new flashed firmware on Winbond chip.
So this test (the new SSDT) should be performed on system #1?
 

Attachments

  • TB3.txt
    26.4 KB · Views: 224
You must log in or register to reply here.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top