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

[vicantu]

If I had a NUC 7 or 8 I would be more than happy to keep trying, but if Osy86's own SSDT doesn't work on NUC, then I'm not sure whether it's worthwhile to put any more time into it (without having a unit myself).

By the way, Osy86 developed the SSDT for NUC-Hades Canyon. Which one is that? NUC 7 or NUC 8?

Edit: Hades Canyon is NUC 8. Let me modify it for your NUC... Uno momento.

My NUC8 is a Bean Canyon ...gracias

 

[CaseySJ]

@vicantu @NCMacGuy

Please try the attached SSDTs:

• NUC 7 (Hades Canyon?)
  • Rename RP01:_INI to RP01:XINI
  • Rename _E20 to XE20
  • Use file: SSDT-TbtOnPCH-NUC-7-OSY86.aml
• NUC 8 (Bean Canyon)
  • Rename RP05:_INI to RP05:XINI
  • Rename _E40 to XE40
  • Use file: SSDT-TbtOnPCH-NUC-8-OSY86.aml

 

[vicantu]

@vicantu @NCMacGuy

Please try the attached SSDTs:

• NUC 7 (Hades Canyon?)
  • Rename RP01:_INI to RP01:XINI
  • Rename _E20 to XE20
  • Use file: SSDT-TbtOnPCH-NUC-7-OSY86.aml
• NUC 8 (Bean Canyon)
  • Rename RP05:_INI to RP05:XINI
  • Rename _E40 to XE40
  • Use file: SSDT-TbtOnPCH-NUC-8-OSY86.aml

for the flashed or the unflashed?

 

[CaseySJ]

for the flashed or the unflashed?

Unflashed.

 

[vicantu]

@NCMacGuy

Please try the attached SSDTs:

• NUC 7 (Hades Canyon?)
  • Rename RP01:_INI to RP01:XINI
  • Rename _E20 to XE20
  • Use file: SSDT-TbtOnPCH-NUC-7-OSY86.aml
• NUC 8 (Bean Canyon)
  • Rename RP05:_INI to RP05:XINI
  • Rename _E40 to XE40
  • Use file: SSDT-TbtOnPCH-NUC-8-OSY86.aml

I'm a little bit confused, in the repository for NUC8 you said:


"Because the DSDT for these boards calls PINI(), we do not need to rename the RP05 --> _INI() method. Instead, the Thunderbolt SSDT implements PINI() instead of _INI()."

then, which Find/Replace HEX values should I need to put on conflig.plst for the Rename RP05:_INI to RP05:XINI

Attached is my NUC8 untouched DSDT.aml

Thanks

 

[CaseySJ]

@NCMacGuy

Please try the attached SSDTs:

• NUC 7 (Hades Canyon?)
  • Rename RP01:_INI to RP01:XINI
  • Rename _E20 to XE20
  • Use file: SSDT-TbtOnPCH-NUC-7-OSY86.aml
• NUC 8 (Bean Canyon)
  • Rename RP05:_INI to RP05:XINI
  • Rename _E40 to XE40
  • Use file: SSDT-TbtOnPCH-NUC-8-OSY86.aml

I'm a little bit confused, in the repository for NUC8 you said:


"Because the DSDT for these boards calls PINI(), we do not need to rename the RP05 --> _INI() method. Instead, the Thunderbolt SSDT implements PINI() instead of _INI()."

then, which Find/Replace HEX values should I need to put on conflig.plst for the Rename RP05:_INI to RP05:XINI

Attached is my NUC8 untouched DSDT.aml

Thanks

Yes you’re right.

I am out of the house right now but try the following:

Open the SSDT in MaciASL and find _INI. Then change it to PINI and save the file. Reboot.

 

[scottkendall]

I've been swamped at work and I've finally had time to sit down and do more testing. I've had a bit of a breakthrough. I updated my MB to the latest beta BIOS and now my monitors are detected at boot. This has been a big hurdle and confirms the main issue has been local. While the config of DP to GPU and one pass through over TB is working consistently, I'm still trying to get to both monitors over TB. I share my workspace with a rMBP and if I want to work off the laptop with my monitors and dock, I would like to just plug in one cable and be done. Also, I am using the THB_C header.

After many different tests, CSM is definitely a problem and needs to remain disabled. I have had some success booting with both monitors running over TB, but it never survives a reboot. The machine boots to the desktop, but remains black. System profiler sees all TB devices including the UltraFine monitor and all of its properties- Sound Options, USB ports... but under Graphics/Displays- nothing. I started reading up on WEG to see what options are available, and documentation there suggests CSM is a problem for multiple monitors, AND defining ports and connectors of the GPU can help with black screen problems. I am becoming more and more convinced that it is in fact an issue with my Radeon VII and detecting ports/connectors and their priorities. This would make sense as your Vega 64 has better support in MacOS. So what I'm wondering, is there a way to inject these extra properties into Clover or perhaps the Radeon Boost SSDT? This might prevent WEG from detecting (incorrectly) priority of the ports and connectors.
Also, is there anyone willing to help me do this?

The thing with the VII is that they are all reference cards so the ports and connectors should not really be an issue. Yes the Vega has better support but I am not sure the VII is far off. I use Radeon Boost Kext and SSDT but the SSDT as far as I can tell most handles proper rename for the video card. I would believe that your ports are injected correctly because it is a Reference card with a Default port layout. I do not have the technical knowledge to help you with what you are asking.

 

[scottkendall]

if you have the GC-Alpine Ridge card rev 2 I have that firmware

I do, and I am still waiting for you to post it.

 

[gandem]

The thing with the VII is that they are all reference cards so the ports and connectors should not really be an issue. Yes the Vega has better support but I am not sure the VII is far off. I use Radeon Boost Kext and SSDT but the SSDT as far as I can tell most handles proper rename for the video card. I would believe that your ports are injected correctly because it is a Reference card with a Default port layout. I do not have the technical knowledge to help you with what you are asking.

What I keep going back to is if I restore unpatched firmware to the Titan Ridge card, everything works monitor wise. I have not tried that with the UltraFine monitor, but I'm relatively sure it would work. So if I take that as a given, the firmware must be altering how the ports and/or connectors are being routed in MacOS. What's interesting is that the best physical port config for me is that if I use the two outside DP's on the GPU and send them to the DP in's of the TR card, I can use the TB Monitor but I have to connect my Ultra 4K to the DP on the TR card. So instead of going directly into the middle DP port on the GPU, I leave that empty and use the TR card for all the connections. That sounds similar to how you're using it. So far, this is the only configuration that survives reboots, cold boots and warm boots.

 

[scottkendall]

What I keep going back to is if I restore unpatched firmware to the Titan Ridge card, everything works monitor wise. I have not tried that with the UltraFine monitor, but I'm relatively sure it would work. So if I take that as a given, the firmware must be altering how the ports and/or connectors are being routed in MacOS. What's interesting is that the best physical port config for me is that if I use the two outside DP's on the GPU and send them to the DP in's of the TR card, I can use the TB Monitor but I have to connect my Ultra 4K to the DP on the TR card. So instead of going directly into the middle DP port on the GPU, I leave that empty and use the TR card for all the connections. That sounds similar to how you're using it. So far, this is the only configuration that survives reboots, cold boots and warm boots.

I have one monitor that I leave plugged directly into the GPU, and it is plugged into the DP next to the HDMI port. The other two display ports are plugged into the Titan.