Contribute
Register

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

Some days I have three monitors some days I do not and yes they are all there every time I boot up. I do not have a Thunderbolt monitor though. I have two 4k monitors one on DP from the GPU one on DP from the Titan, and one 1080 on USB-C to HDMI from the Titan. Yes I can plug them all into the GPU not really sure why I have them routed this way. The monitor that is lit up for the boot up is the one from the Titan on the DP.

The Pike R patch might not work for Vega VII but if you have Pike R black screen patch you do not need WEG or at least I do not. Without Pike R patch I do not have multi monitor.
I think the key to your config working is having your 4K plugged directly into GPU. I haven’t had time to test this, but that was the case in my previous monitor config. Hoping to get a longer DP cable soon to test this.

@CaseySJ- a little more info on testing. When I enabled CSM support, the system was KP’ing. I discovered this later on reboots. That’s a new symptom, as I’ve had issues with my previous monitor setup when CSM was enabled, but it was oriented around detecting the monitor. Never KP’d. Will continue testing.
 
I've done lots of testing/experimenting with this the last couple of days. I think we are getting closer but not there yet.

You said to look for a checksum error in Hackintool-->logs by searching for DROM. no error shown. Output attached.

Wrong log in Hackintool, you need Logs > System not Logs > Boot

Finally, you said to run gfxutil to see if NHI0 was properly configured. It shows as
PCI0.RP21.UPSB.DSB0.NHI0 = PciRoot(0x0)/Pci(0x1b,0x4)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)
I don't know if that means I need to change the path in Devices--property from Pci(0x1c,0x4) to Pci(0x1b,0x4). But ,when I do so, I never get a boot with the peripherals working. To get back to Pci(0x1c,0x4) in DROM properties, I usually need to do a CMOS reset. Output attached.

You do need to use this path: PciRoot(0x0)/Pci(0x1b,0x4)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)

Sorry for the long message. But I wanted to supply as much info as possible.
@faithie999 It's best not to mix and match from other sources just stick to the ThunderboltDROM from your unpatched firmware. I changed 2C5 in the DROM to 285 to activate IOThundernboltPort5 but this will cause a CRC32 checksum error which needs to be fixed. If you look in the sleep/wake working IOreg you'll see that the ThunderboltDROM property isn't there under NHI0, which means it hasn't been loaded. I think you'll find that when you check the correct log it will show that there was an error with loading the DROM from IORegistry. Upload the output of the 'DROM' System log search when you've had time to do it, along with the relevant section of your Clover config.plist... Don't give up!!
 
Last edited:
that wake behavior had been my experience with my flashed AR card, so I was ready to give up on the AIC approach.

then I tried @dgsga's SSDT-only approach for Alpine Ridge (see post 19,995). after help from @dgsga and @CaseySJ, and a few fits and starts, I have that approach working (see post 20,687)--but for some reason, successful wake only works when the Apple TB display is attached to TB port 2 on my AR card. when attached to port 1, I get the behavior you describe.

Would you mind making a consolidated post with your methods and files attached? i am very interested in testing with this method and making hopefully minor adjustments to get it working on some older machines and client machines (with both built-in AR and AR AIC) since it should require minimum modification to those systems. As far as i know you are the first one to have this working with an AIC.

Also do you have an AR rev1 or rev2 card? And do you have the card header connected or jumpered? BIOS thunderbolt settings?

Assuming i can get this working on various systems with your (slightly modified) files i can re-post all updated files for a variety of motherboards and configurations.

Thank you!
g\
 
Hi there,

Thanks for amazingly thorough build! My question is... do you think this build would work with the new Intel i9-10980XE chip?

 
Would you mind making a consolidated post with your methods and files attached? i am very interested in testing with this method and making hopefully minor adjustments to get it working on some older machines and client machines (with both built-in AR and AR AIC) since it should require minimum modification to those systems. As far as i know you are the first one to have this working with an AIC.

Also do you have an AR rev1 or rev2 card? And do you have the card header connected or jumpered? BIOS thunderbolt settings?

Assuming i can get this working on various systems with your (slightly modified) files i can re-post all updated files for a variety of motherboards and configurations.

Thank you!
g\
@genzai, it's well worth trying this approach as it works a treat in my system (built-in AR). Here's a quick summary of the approach (all credit to @Elias64Fr and @CaseySJ for their original work)
  1. Use the attached SSDT as a base
  2. Change RootPort (RPnn) number to correct value for the motherboard (in my case RP05)
  3. Change the address in the first line of the MMBA method to the correct value. If the RootPort PCI address is 1x,n, the correct value is (1x *8)+n. So for my RP05@1c,4 its (1c*8)+4 = E4
  4. Adjust the UPSB section as required. My mobo only has 1 TB port so no DSB4 device and only one XHC2 SSP/HS port pair. If you have two TB ports then add DSB4 and a second pair of XHC2 devices
  5. Adjust the _GPE.E2C hotplug method to the correct values for the motherboard. In a DSDT dumped directly from the bios there is a method under _GPE called YTBT. In a booted system the name of this method changes to _Exx where xx is a hex number. So in my system Method (YTBT) becomes Method(_E2C). Also change the XE2C value to XExx
  6. In the ACPI section of your config.plist add search and replace values to rename RPnn._INI to RPnn.XINI and _Exx to XExx (see attached config.plist from OpenCore for an example). These changes ensure the original ACPI code is used for operating systems other than macOS.
  7. Inject the ThunderboltDROM value from the unpatched AR firmware via Device Properties in your boot loader config.plist, using gfxutil to find the correct DevicePath for NHI0. The two byte sequence for IOThunderboltPort5 (02C3) needs to be changed to 0283 so the port is activated. Note that your byte values here might be different but the C needs to be changed to an 8. This will cause a CRC32 error and cause the DROM not to be processed correctly by macOS. Fortunately a Hackintool > Logs > System search for 'DROM' will show you the correct CRC32 value so byte-reverse it and replace the existing CRC32 bytes (bytes 10 to 13). So in my case:
Code:
75                                                CRC8
00 00 00 00 00 00 49 18                Thunderbolt UID
74 20 31 2B                                  CRC32
01 51 00 49 18 04 00 66 04
08 81 80 02 80 00 00 00
08 82 80 02 80 00 00 00
02 83                                            BYTES TO ACTIVATE IOTHUNDERBOLTPORT@5
0B 84 20 01 00 3C 00 00 00 00 00
05 85 50 00 00...

I hope this helps...
 

Attachments

  • TBTfiles.zip
    33 KB · Views: 182
Last edited:
Hi there,

Thanks for amazingly thorough build! My question is... do you think this build would work with the new Intel i9-10980XE chip?

The i9-10980XE uses an LGA2066 socket and is aimed at high-end desktops and workstations. However, it will work with @dolgarrenan's thread on Gigabyte Designare X299X.
 
@genzai, it's well worth trying this approach as it works a treat in my system (built-in AR). Here's a quick summary of the approach:
  1. Use the attached SSDT as a base
  2. Change RootPort (RP) number to correct value for the motherboard (in my case RP05)
  3. Change the address in the first line of the MMBA method to the correct value. If the RootPort address is 1x,n, the correct value is (1x *8)+n. So for my RP05@1c,4 its (1c*8)+4 = E4
  4. Adjust the UPSB section as required. My mobo only has 1 TB port so no DSB4 device and only one XHC2 SSP/HS port pair. If you have two TB ports then add DSB4 and a second pair of XHC2 devices
  5. Adjust the _GPE.E2C hotplug method to the correct values for the motherboard. In a DSDT dumped directly from the bios there is a method under _GPE called YTBT. In a booted system the name of this method changes to _Exx where xx is a hex number. So in my system Method (YTBT) becomes Method(_E2C). Also change the XE2C value to XExx
  6. In the ACPI section of your config.plist add search and replace values to rename RPnn._INI to RPnn.XINI and _Exx to XExx (see attached config.plist from OpenCore for an example)
  7. Inject the ThunderboltDROM value from the unpatched AR firmware via Device Properties in your boot loader config.plist, using gfxutil to find the correct DevicePath for NHI0. The two byte sequence for IOThunderboltPort5 (02C3) needs to be changed to 0285 so the port is activated. This will cause a CRC32 error and cause the DROM mot to be processed correctly by macOS. Fortunately a Hackintool > Logs > System search for 'DROM' will show you the correct CRC32 value so byte-reverse it and replace the existing CRC32 bytes (bytes 10 to 13). So in my case:
Code:
75                                                CRC8
00 00 00 00 00 00 49 18                Thunderbolt UID
74 20 31 2B                                  CRC32
01 51 00 49 18 04 00 66 04
08 81 80 02 80 00 00 00
08 82 80 02 80 00 00 00
02 83                                            BYTES TO ACTIVATE IOTHUNDERBOLTPORT@5
0B 84 20 01 00 3C 00 00 00 00 00
05 85 50 00 00

I hope this helps...
Quite helpful. I'll add a link to this guide in the Quick Reference spoiler in post 1.
 
I think the key to your config working is having your 4K plugged directly into GPU. I haven’t had time to test this, but that was the case in my previous monitor config. Hoping to get a longer DP cable soon to test this.

@CaseySJ- a little more info on testing. When I enabled CSM support, the system was KP’ing. I discovered this later on reboots. That’s a new symptom, as I’ve had issues with my previous monitor setup when CSM was enabled, but it was oriented around detecting the monitor. Never KP’d. Will continue testing.

No having the monitor plug directly into the GPU is irrelevant at least for me. I think there is a deeper problem with your setup. I blame that you have IGPU enabled but that's just my opinion, if their was a Anti-IGPU club I would be the president.

All my monitors work no matter how I plug them in though normally I only run the two 4k monitors. The monitor that lights up during boot is not plug into the GPU its the one plugged into the DP on the Titan. Though I have a feeling that if I moved the cables around any of them would light up if plugged into the correct port. In addition I swiped my GF monitor that is also a 4k monitor and plug it in from cold boot... All three 4k Monitors booted without issue, 1 of them was plugged into the Titan USB-C, I also tried it directly plugged to the GPU; one on the Titan DP; one on the GPU DP; technical that means they are all plugged into the DP on my GPU. I do have in the bios under security video pass threw selected though I think I turned off and it made no difference. I also have CSM off because that is what it should be set for if using Opencore at least a few releases ago currently I am on 0.5.7!
 
No having the monitor plug directly into the GPU is irrelevant at least for me. I think there is a deeper problem with your setup. I blame that you have IGPU enabled but that's just my opinion, if their was a Anti-IGPU club I would be the president.

All my monitors work no matter how I plug them in though normally I only run the two 4k monitors. The monitor that lights up during boot is not plug into the GPU its the one plugged into the DP on the Titan. Though I have a feeling that if I moved the cables around any of them would light up if plugged into the correct port. In addition I swiped my GF monitor that is also a 4k monitor and plug it in from cold boot... All three 4k Monitors booted without issue, 1 of them was plugged into the Titan USB-C, I also tried it directly plugged to the GPU; one on the Titan DP; one on the GPU DP; technical that means they are all plugged into the DP on my GPU. I do have in the bios under security video pass threw selected though I think I turned off and it made no difference. I also have CSM off because that is what it should be set for if using Opencore at least a few releases ago currently I am on 0.5.7!
You may be right about the IGPU being the problem. That’s an easy one to test, and I completely overlooked it. I don’t think I have video pass thru as an option. You have that under TB security settings in BIOS?
 
Back
Top