Contribute
Register

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

<CPU kernel panic>
I wonder if this is related to the 10 Gbps Ethernet port. Because Clover is still working, please do this:
  • Compare Clover and OpenCore settings:
    • Kernel patches
    • ACPI (SSDT) files
    • Kexts
    • UEFI drivers
  • Or compress and upload both the CLOVER and OC folders, but remove serial numbers from both.
 
Running Opencore 0.6 with a designare and a MSI RX580 I am running into the problem that when my screens wake up on my large screen 3440x1440, I have to disconnect the HDMI connection and reconnect for the screen to reappear. Is there any change I can do for this to disappear? It happens on both the hdmi and displayports and doesn't happen on a 1080p screen. It's probably due to WhateverGreen but I don't know where. Thanks
Some clarifications:
  • Are you using one monitor?
  • Is the problem happening after wake from sleep?
  • What is the make/model of the monitor?
If you're using WhateverGreen:
  • Which version are you using?
  • Have you tried disabling it in the OpenCore Configurator --> Kernel section? MacOS supports the RX580 natively, so this is worth a shot.
 
So I've done some further reading, and I came across a post on a different site mentioning that certain 5700 XT cards need framebuffer patching, but all I can come across here on Tonymac is your guide for the frame buffer patching for the onboard HDMI.

Im going down this path now, in hopes to just run my third monitor with my onboard HDMI - but it has me thinking I could potentially get my additional ports on my 5700 XT working with a patch - however, I am inexperienced in figuring out what to patch.

Can you please point me toward some documentation on graphic card port patching?

Thanks!
Also try disabling WhateverGreen (if using OpenCore) or removing it from CLOVER/kexts/Other (if using Clover), and reboot. Enabling the on-board HDMI port is not recommended because numerous applications fail to start and Safari misbehaves (it's for short-term use until an AMD GPU is installed).
 
Finally got the power-on -> Apple login screen under a minute (57s). After removing the 10G card, then CMOS reset there was no change. So I decided to update the BIOS to F9g.

Took me some time to figure out where the critical BIOS changes were located. Went to turn on -v boot option and noticed that the Boot Debug option was on. I compared all the setting to a backup config file and found a few we're different. I must have forgot to revert a few changes when I was hacking the 10G card. As soon as I corrected the Clover config then boot time was much faster. Screwed up a few times with Bios settings and the GPU card swap and few other bone head mistakes, but now the boot time is amazing.
Oh yes, that old debug flag in Clover... Glad you found it and unchecked it.
 
Hi Casey,

EDIT: BEFORE YOU READ ON. I fixed the issue. It was the SSDT-RX 5700 XT-Version 1.0-ORIGINAL.aml all along. After a heap of trial and error, removing this and the associated patch fixed the Blue Screen issue and now I can select Windows 10 at the OC Picker menu and all boots perfect. Below are some other questions I am unsure of as well as all the clean-up I did of my setting and config.plist.
Glad to hear it!
I found several discrepancies in the ACPI section of OC Configurator, not sure if this is what's causing my booting into Windows from OC issue however I am about to test it.

Basically I found that I had SSDT-SBUS-MCHC.aml & SSDT-GPRW.aml as enabled in the ACPI section when in fact I didn't have them in the OC/ACPI Folder. Now, I noticed that in the mini guide for installing OC 0.6.0 for Z490 Vision D is says this ACPI --> SSDT-SBUS-MCHC (Fix AppleSMBus support in macOS) is this applicable to the Z390 Aorus Xtreme or Designare as well?? If so, I will download the SSDT, add it to the ACPI folder and re-enable it in the config.plist.
SSDT-SBUS-MCHC is not strictly necessary on either platform. Doesn't hurt to try it, though.
Also, I had the PATCH: ACPI --> PATCH --> Change Method(GPRW,2,N) to XPRW, pair with SSDT-GPRW.aml enabled in the PATCH's however, I did not physically have the SSDT in the OC/ACPI folder. I have now removed that patch and disabled the SSDT in the ACPI section. Is this the Disable Wake from USB / Bluetooth fix (Only wake from Power Button)? If so, I will re-enable this and add the relevant SSDT into the ACPI Folder. (Then retest my dual boot)
Yes, this disables wake-from-USB (hence it disables wake from Bluetooth as well because Bluetooth is connected via USB). Only power button will wake the system. This is not necessary unless the system is experiencing chronic insomnia.
So far, this is what I have found. I am hoping that tidying some of these little discrepancies up may fix my dual boot issue. Fingers Crossed

View attachment 487120

Just a few more things.

As you can see in my screenshot below, I have AAPL,ig-platform-id value as 0300983E, although on the OpenCore website it says for a headless profile I should have value as 03009B3E. Have they made a mistake here and got their 8 and B mixed up? Anyways Im leaving mine as is until told otherwise.
View attachment 487125

You can see below that even the Sanity Checker believes I got it wrong. Im pretty sure my Value has come from the Z390 Designare Mini Guide.
Ha! The sanity checker is wrong. But more specifically, the sanity checker is a generic checker that does not necessarily produce the right results for a specific motherboard. It's a very nice tool, but the output should not be taken as gospel.
View attachment 487126

I have also deleted the below Driver from the Drivers folder and removed from the UEFI --> Drivers section as the Sanity Checker stipulated this is to be removed.

View attachment 487127

I hope all of the above makes sense, if you see anything you think I have done and should not have please let me know or if there is anything I SHOULD do :)

Thanks Again.

I hate little issues like my dual booting issue but i'm determined to get to the bottom of it.
Same as last comment -- these warnings from the sanity checker should not be taken as gospel. The settings in OpenCore 0.6.0 Mini-Guide are correct. There is always wiggle room for individuals to individualize their settings, but the standard settings in that guide are fine.
 

Can I theoretically follow this to upgrade from 10.15.2 to 10.15.4(6?) - and will the MSR unlock work similarly on my Xtreme mobo since its still a gigabyte?
Because you're on an early build of Catalina, the best guide to update to latest Catalina is this:

Screen Shot 2020-09-06 at 4.31.04 AM.png
 
2 years ago, I did a real life test with the gear(Z170x/i7) I had then. Here are the results:

Project with 1 mono vocal channel/1 mono bass channel/1 mono guitar channel/1 Pianoteq VI/1 Superior Drummer 3 VI, my band during a live jam, with plug ins on the channels(guitar amps, eq, compressors, reverb)

88.2 kHz SR/64 samples buffer

Logic
Metric Halo ULN-8/2d: 4 mS
Lynx Aurora(-n) 3,9 mS

ULN-8 via FireWire, Aurora via Thunderbolt.

This also worked:

Lynx Aurora(-n) Cubase 9.5.21 128 samples/88.2 kHz 32 track recording met gate comp eq, 4 mS rtl

A more modern interface with DSP mixer has a couple of mS more latency to account for the console stuff.

Pro Tools couldn't keep up with these high SR/low buffer examples at all. Logic felt a little bit less stressed out than Cubase.

You can get less latency if you don't go through your DAW and use the DSP console for monitoring. But then you'll miss out on the VST/CoreAudio plug ins and virtual instruments.

On my current Z390 in Logic, I get 9.3 mS RTL with MH ULN-8 3D... Same project @ 88.2 kHz/64 samples. So that's quite a bit more latency(but greater routing and mixing flexibility up to 128 I/O) than 2D/Firewire.n
My ULN-8 3D is connected via ethernet, last time I tried connecting it via USB latency was 2 mS shorter.
Will check this later after a reboot.

Allright, MH ULN-8 via USB is 6.8 mS RTL(88.2 kHz/64 samples)

I should bring a current Lynx Aurora(-n) with Thunderbolt to see what it does. Much less latency, I think, it has fast converters(not necessarily better sounding) and a simple mixer without plug ins.

Nice. Those Z170 systems were the shizzle for TB2 interfaces. There were none to be had when I built my Z370. If I ever switched interfaces, I'd shop for a Lynx PCIe system or a Metric Halo (and probably the ULN-8) just so I don't ever again have to be extremely limited on mobo choice because of a Thunderbolt requirement. Dante doesn't seem like a choice because AVB isn't working on these hacks.

FWIW, I'm routing everything going into Pro Tools through the UAD console. I use the virtual returns and aux channels for bus compressors, reverb, and delay. UAD + Pro Tools (now on 2020.9) is great for tracking, even for MIDI tracking to a VEP 7 node. It was incredibly tedious to make and fine tune a 40 channel orchestral template. I don't add any plugins directly in Pro Tools unless I'm mixing.

I only use my c2000 Mackie 1202VLZ Pro as a returns mixer before it hits the monitors. I often use a couple hardware limiter just for monitoring safety. Everything going to Pro Tools (or sometimes Logic) goes into the Apollo first, even the Fractal. The Z390 is a much better machine than any G4, G5, MP 6,1, iMac 19,2 (i9, full BTO spec!) or Mac Mini 18,2 (i7, full BTO spec!) that I've used over the years besides the Z370 8700K that build I just gave to my daughter.
 
A quick update for anyone following along. After much work I found both a hardware issue (monitor DP port partially defective - odd, would not work on real MacPro, would work at degraded refresh rate on one Hackintosh with 5700) and potential software problem. The system is working well now. Since I had everything apart, I used it as an opportunity to cannibalize parts from a spare system and build Casey’s z490 configuration that is remarkably quiet. Thanks @CaseySJ - once again your build guide was straightforward and the machine is working well on all fronts.
 
Nice. Those Z170 systems were the shizzle for TB2 interfaces. There were none to be had when I built my Z370. If I ever switched interfaces, I'd shop for a Lynx PCIe system or a Metric Halo (and probably the ULN-8) just so I don't ever again have to be extremely limited on mobo choice because of a Thunderbolt requirement. Dante doesn't seem like a choice because AVB isn't working on these hacks.

FWIW, I'm routing everything going into Pro Tools through the UAD console. I use the virtual returns and aux channels for bus compressors, reverb, and delay. UAD + Pro Tools (now on 2020.9) is great for tracking, even for MIDI tracking to a VEP 7 node. It was incredibly tedious to make and fine tune a 40 channel orchestral template. I don't add any plugins directly in Pro Tools unless I'm mixing.

I only use my c2000 Mackie 1202VLZ Pro as a returns mixer before it hits the monitors. I often use a couple hardware limiter just for monitoring safety. Everything going to Pro Tools (or sometimes Logic) goes into the Apollo first, even the Fractal. The Z390 is a much better machine than any G4, G5, MP 6,1, iMac 19,2 (i9, full BTO spec!) or Mac Mini 18,2 (i7, full BTO spec!) that I've used over the years besides the Z370 8700K that build I just gave to my daughter.

Dante is not AVB. Dante is great, works fine on Hacks. It only needs a working ethernet port and standard switches, unlike AVB. There's a slight(1-2 mS) overhead compared to the fastest of TB/PCIe interfaces.

But Dante is overkill in my situation, as a bedroom composer with a provisional voice-over booth(I sold my studio a long time ago)

UAD stuff is great for small/personal setups. UAD is also quite reliable. But i chose Metric Halo 15 years ago, and I am basically still happy with my ULN-2 and ULN-8, and Metric Halo as a company.

For bigger systems, Dante rules. No need for miles of expensive analog cables(that will generate noise nevertheless) Very flexible. Reliable. Clean.

So you are always listening through your Mackie mixer? Hm. I would connect my monitors straight to the Apollo.
 
So I've done some further reading, and I came across a post on a different site mentioning that certain 5700 XT cards need framebuffer patching, but all I can come across here on Tonymac is your guide for the frame buffer patching for the onboard HDMI.

Im going down this path now, in hopes to just run my third monitor with my onboard HDMI - but it has me thinking I could potentially get my additional ports on my 5700 XT working with a patch - however, I am inexperienced in figuring out what to patch.

Can you please point me toward some documentation on graphic card port patching?

Thanks!
AMD Framebuffer patching via Clover: https://www.tonymacx86.com/threads/...ebuffers-for-high-sierra-using-clover.235409/
 
Back
Top