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

[zipb]

Please enable verbose to determine the cause of the prohibited sign. Is it "Couldn't Allocate Runtime Area"?

Yes, "Couldn't Allocate Runtime Area" and then halt.

 

[mysticmerlin]

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.

You were absolutely right. Disabling WhateverGreen in Kernel made the problem disappear. Of course , since the RX580 is native is doesn't need WhateverGreen to connect. I thought that WEG was needed. The issue was with a LG HDR WQHD at 3440x1440. I am using also a NEC EX231W on the 2nd HDMI port. I am using WhateverGreen 1.4.1 that came with your efi.

 

[mysticmerlin]

I've been going straight from interface to speakers for 20 years now. No problems, better sound.

Soundwise your Mackie is probably the weakest link in your chain. I would definitely test with and without the Mackie, and see if you can hear a difference. Also depends on your monitors of course, if you have something like $200 KRK's then don't bother.
IMO, the whole audio chain should be balanced quality wise, eg getting a Benchmark DAC to drive your Apple earbuds is not a smart idea.

Those Mackies sound terrible. Their op amps are dirty. I go straight into my ATC50's from the converter. You could also use the TC Pilot X if you need to control the level which is dirt cheap and does the business very well.

 

[PTuser]

Hi - when it works - all that is working and has been all along - I have a caldigit3 dock , the focusrite and a blackmagic mini monitor on the tb bus plus usb3.1 stuff...

so here is an apple crash report when it does the restart on restart - im not proficient enough to understand it

 

[zipb]

Yes, "Couldn't Allocate Runtime Area" and then halt.

My old EFI from a backup works fine. So it's not the BIOS, but something in the EFI folder. I'll compare the two to see if something is obviously wrong.

 

[zipb]

My old EFI from a backup works fine. So it's not the BIOS, but something in the EFI folder. I'll compare the two to see if something is obviously wrong.

these are different(in the not working EFI):
OcQuirks.efi
OpenRuntime.efi

In the working EFI:
OcQuirks-4.efi
FwRuntimeServices.efi

Not working EFI: Clover 5122
Working EFI: 5119

 

[CaseySJ]

these are different(in the not working EFI):
OcQuirks.efi
OpenRuntime.efi

In the working EFI:
OcQuirks-4.efi
FwRuntimeServices.efi

Not working EFI: Clover 5122
Working EFI: 5119

On Mojave we've had a Jekyll and Hyde relationship between OcQuirks/OpenRuntime and OcQuirks-4/FwRuntimeServices. It seems the latter is better suited for Mojave.

 

[CaseySJ]

You were absolutely right. Disabling WhateverGreen in Kernel made the problem disappear. Of course , since the RX580 is native is doesn't need WhateverGreen to connect. I thought that WEG was needed. The issue was with a LG HDR WQHD at 3440x1440. I am using also a NEC EX231W on the 2nd HDMI port. I am using WhateverGreen 1.4.1 that came with your efi.

By default we use WhateverGreen for all AMD GPUs. In some specific cases that we cannot anticipate ahead of time, it's better to disable WEG.

 

[CaseySJ]

so here is an apple crash report when it does the restart on restart - im not proficient enough to understand it

The first kernel extension in the backtrace is the Focusrite driver, but the crash report does not tell us much more. Unfortunately, even if it did, most likely we would not be able to provide a solution for the specific components in your system. If you already have a newer Hackintosh (i.e. with a newer motherboard, preferably Z370 or later) please try moving the GC-Titan Ridge over to that.

 

[c0c0p0ps]

Interesting...

• The file SSDT-Z390-RP05-SLOT4-TB3HP.aml is identical to the one we use on Designare Z390 and Z490 Vision D. It's the original "KGP" version.
• The file SSDT-MR-TR.aml is based on an abbreviated version originally developed by "Nico" and posted by "DSM2" on MacRumors and elsewhere.

The main differences are:

• The original KGP version is attached to RP05 as @Inqnuam mentioned. The HackinDROM version is attached to RP21. So that by itself makes a world of difference.
  • If your controller is on RP05, we need to change RP21 to RP05.
  • I've done this in the two attached files.
• The original KGP version is taken from Apple's own SSDT and slightly modified.
  • It contains extended sub-devices for DSB1 and DSB4 to allow for daisy-chained devices.
    • But even Apple has since removed these extended sub-devices.
  • It contains additional fields in the NHI0 _DSM(device specific method):
    • "Built-in"
    • "TBTDPLowToHigh"
    • "ThunderboltUUID"
    • "sccOffset"
    • "TBTFlags"
  • In the new SSDT, we did not think these fields were necessary. However, it might be a good idea to add these fields back and see if reliability is improved.
    • I've made these changes in the attached file: SSDT-MR-TR-CASEY.aml
    • I've also changed RP21 to RP05 in the standard file: SSDT-MR-TR.aml
    • Feel free to try each one (one by one)

Just wondered... Has anyone done any tests yet to see if these additional fields make any difference to reliability or performance for the SSDT?