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

[Inqnuam]

Fresh SSDT with bus id 2 has been placed into ./ACPI/.

System Information doesn't show Bus 2, however. I also added the IOReg info in case that might be of help.
View attachment 480866


For the crash reported in post 23765 I'll keep an eye out for it again. I unfortunately don't know how to reproduce it.

EDIT: If I have two Thunderbolt controllers, should they be using RP05 and RP21 separately?

Have you changed RP05 to RP21 inside .aml generated file?
Try this and let me know please
Replace All

 

[Inqnuam]

I'm still curious about the extra 3 pin header. What its functionality is and whether it needs to be shorted like the 5 pin? I have a 5 pin header on my motherboard, but no 3 pin.

Preparation of Card:

• If motherboard contains a compatible 5-pin Thunderbolt header (THB_C), connect the GC-Titan Ridge to motherboard with a Thunderbolt header cable that is supplied with the GC-Titan Ridge.
• If motherboard does not contain a Thunderbolt header, connect pins 1 and 3 with a simple female/female breadboard jumper wire, as follows:
  • Hold the GC-Titan Ridge vertically so the PCIe pins are pointing down to the floor.
  • On the back of the card, locate the 5-pin vertical header (J1).
  • Pin 1 is the top pin
  • Pin 3 is the middle pin
  • Connect the top pin and middle pin

 

[gandem]

I believe this in reference to the 5 pin header, but I'm inquiring about the additional 3 pin header on rev 2.

 

[Inqnuam]

@roastable

• The attached SSDTs may be used, but they are configured for PCI0.RP05. Adapt the SSDT for the actual PCIe path for your system. If you have questions about this, just ask.
• Both SSDTs should be copied to CLOVER/ACPI/patched or for OpenCore users, OC/ACPI

This part of Thunderbolt DROM is not implanted into HackinDROM. I'm waiting for @CaseySJ for more informations about this and if necessary I'll implant it to HackinDROM

 

[roastable]

Have you changed RP05 to RP21 inside .aml generated file?
Try this and let me know please
Replace All
View attachment 480867

@roastable

This part of Thunderbolt DROM is not implanted into HackinDROM. I'm waiting for @CaseySJ for more informations about this and if necessary I'll implant it to HackinDROM

Good to know! Changing RP05 to RP21 in the HackinDROM generated .aml allows for the correct bus id to show. It also seems to detect duplicate dummy Thunderbolt ports but the AIC is confirmed working despite this.


Thanks for taking the time to help me take a look at this!

 

[Inqnuam]

Good to know! Changing RP05 to RP21 in the HackinDROM generated .aml allows for the correct bus id to show. It also seems to detect duplicate dummy Thunderbolt ports but the AIC is confirmed working despite this.
View attachment 480868

Thanks for taking the time to help me take a look at this!

This is nice!
You're not the first one whit this duplicated ports. I think because there is a conflict between your on-board controller and the AIC. Maybe wee need to change PCI port for AIC. Sure @CaseySJ knows the answer.

Try this and let me know please. (PCI port to where your AIC is connected)

EDIT: dont do that.

 

[CaseySJ]

@roastable @Inqnuam

Several comments:

• For the un-flashed Thunderbolt controller on the motherboard (RP05) we should keep the original Thunderbolt SSDT.
• When installing the GC-Titan Ridge or GC-Alpine Ridge add-in-card with a flashed firmware, then HackinDROM should be used to create a new Thunderbolt SSDT (RP21 if that's where the add-in-card is installed).
• Thus there will be 2 separate Thunderbolt SSDTs, one for each controller.
• The kernel panic you reported may not be the result of either the SSDT or the DROM contained within. If the kernel panic occurs again, please let us know. But in the meantime it's okay to just continue using the SSDT generated by HackinDROM.
• Regarding the four Receptacles that appear when we change Bus ID, the extra two appear to be harmless, but I am currently trying to find a solution.

 

[Inqnuam]

then HackinDROM should be used to create a new Thunderbolt SSDT (RP21 if that's where the add-in-card is installed).

Should I implant this to HackinDROM?
and how we know where the controller is installed? what means 05 09 21 root paths, sorry for my question.

 

[roastable]

This is nice!
You're not the first one whit this duplicated ports. I think because there is a conflict between your on-board controller and the AIC. Maybe wee need to change PCI port for AIC. Sure @CaseySJ knows the answer.

Try this and let me know please. (PCI port to where your AIC is connected)

View attachment 480870

Changing PCI0 to PCI1 made for what seems to be some un-ideal results, but the ports still work.

@roastable @Inqnuam

Several comments:

• For the un-flashed Thunderbolt controller on the motherboard (RP05) we should keep the original Thunderbolt SSDT.
• When installing the GC-Titan Ridge or GC-Alpine Ridge add-in-card with a flashed firmware, then HackinDROM should be used to create a new Thunderbolt SSDT (RP21 if that's where the add-in-card is installed).
• Thus there will be 2 separate Thunderbolt SSDTs, one for each controller.
• The kernel panic you reported may not be the result of either the SSDT or the DROM contained within. If the kernel panic occurs again, please let us know. But in the meantime it's okay to just continue using the SSDT generated by HackinDROM.
• Regarding the four Receptacles that appear when we change Bus ID, the extra two appear to be harmless, but I am currently trying to find a solution.

Great! So I'll continue forward with the setup I have as you've outlined (original SSDT for the Designare and HackinDROM SSDT for the AIC with a modification to accommodate for RP21).

I'll be sure to report back with any kernel panics. Related to the four receptacles, I've also been wondering about the Speed; how does 20Gb/s x2 differ from 40Gb/s x1 as seen in some other configurations? And is the 40Gb/s x0 for the four receptacle layout just a cosmetic issue? Is one of these more desirable or does it not matter?

Should I implant this to HackinDROM?
and how we know where the controller is installed? what means 05 09 21 root paths, sorry for my question.

As I was trying to figure out what I might try and change "PC0" to, I found this in Windows. I'm sure it's been mentioned before, but HWinfo was able to display what looks to be the correct install location for each controller (Port #21 for the AIC and Port #5 for the Designare).



Thank you very much to the both of you for your help and research.

 

[CaseySJ]

** Solution for Removing Duplicate Thunderbolt Port Entries **​

@roastable @Inqnuam

Finally we have a solution to the problem of duplicate Port entries in System Information --> Thunderbolt.

Background:
On a system with multiple Thunderbolt controllers, we assign a unique Thunderbolt Bus ID to each one. This is done by changing the first byte of UID (in DROM) to BusID and optionally changing the first byte of ThunderboltConfig to BusID. Unfortunately, this results in duplicate ports as shown below for Bus ID 2:

Solution:
Using ThunderboltUtil by @joevt, we can see that the first 4 ports (0x81, 0x82, 0x83, 0x84) in green (see below) have the values shown in red and blue.

To change Bus ID properly, not only do we modify the first byte of UID (orange), but we must also modify the least significant 4 bits of those red values. Currently, we can see that the least significant 4 bits of all eight red numbers are 0. These values appear to be the Bus ID as well.

"ThunderboltDROM",
Buffer (0x7B)
{

/* 0x00 */ 0x27, // CRC8 checksum: 0x27​

/* 0x01 */ 0x02, 0x67, 0x66, 0x70, 0x13, 0x27, 0x00, 0x00, // Thunderbolt Bus 2, UID: 0x0000271370666702​

/* 0x09 */ 0x5C, 0xF4, 0xA8, 0xBC, // CRC32c checksum: 0xBCA8F45C​

/* 0x0D */ 0x01, // Device ROM Revision: 1​

/* 0x0E */ 0x6E, 0x00, // Length: 110 (starting from previous byte)​

/* 0x10 */ 0x01, 0x00, // Vendor ID: 0x1​

/* 0x12 */ 0x0D, 0x00, // Device ID: 0xD​

/* 0x14 */ 0x01, // Device Revision: 0x1​

/* 0x15 */ 0x00, // EEPROM Revision: 0​

/* 0x16 1 */ 0x08, 0x81, 0x80, 0x02, 0x80, 0x00, 0x00, 0x00,​

/* 0x1E 2 */ 0x08, 0x82, 0x90, 0x01, 0x80, 0x00, 0x00, 0x00,​

/* 0x26 3 */ 0x08, 0x83, 0x80, 0x04, 0x80, 0x01, 0x00, 0x00,​

/* 0x2E 4 */ 0x08, 0x84, 0x90, 0x03, 0x80, 0x01, 0x00, 0x00,​

/* 0x36 5 */ 0x05, 0x85, 0x50, 0x00, 0x00,​

/* 0x3B 6 */ 0x05, 0x86, 0x50, 0x00, 0x00,​

/* 0x40 7 */ 0x02, 0x87,​

/* 0x42 8 */ 0x0b, 0x88, 0x20, 0x01, 0x00, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00,​

/* 0x4D 9 */ 0x03, 0x89, 0x80, // PCIe xx:04.0​

/* 0x50 A */ 0x05, 0x8a, 0x50, 0x40, 0x00,​

/* 0x55 B */ 0x05, 0x8b, 0x50, 0x40, 0x00,​

/* 0x5A 1 */ 0x0b, 0x01, 0x47, 0x49, 0x47, 0x41, 0x42, 0x59, 0x54, 0x45, 0x00, // Vendor Name: "GIGABYTE"​

/* 0x65 2 */ 0x16, 0x02, 0x5A, 0x33, 0x39, 0x30, 0x20, 0x47, 0x43, 0x2D, 0x54, 0x69, 0x74, 0x61, 0x6E, 0x20, 0x52, 0x69, 0x64, 0x67, 0x65, 0x00, // Device Name: "Z390 GC-Titan Ridge"​

},

So we must add Bus ID to these 8 red values. If the new Bus ID is 02, the eight red values become the following:

0x80 + 2 = 0x82, 0x80 + 2 = 0x82
0x90 + 2 = 0x92, 0x80 + 2 = 0x82
0x80 + 2 = 0x82, 0x80 + 2 = 0x82
0x90 + 2 = 0x92, 0x80 + 2 = 0x82

And the new Thunderbolt DROM (with new CRC_32C checksum) becomes:

"ThunderboltDROM",
Buffer (0x7B)
{

/* 0x00 */ 0x27, // CRC8 checksum: 0x27​

/* 0x01 */ 0x02, 0x67, 0x66, 0x70, 0x13, 0x27, 0x00, 0x00, // Thunderbolt Bus 2, UID: 0x0000271370666702​

/* 0x09 */ 0xd3, 0x4a, 0x5d, 0xdb, // CRC32c checksum: 0xDB5D4AD3​

/* 0x0D */ 0x01, // Device ROM Revision: 1​

/* 0x0E */ 0x6E, 0x00, // Length: 110 (starting from previous byte)​

/* 0x10 */ 0x01, 0x00, // Vendor ID: 0x1​

/* 0x12 */ 0x0D, 0x00, // Device ID: 0xD​

/* 0x14 */ 0x01, // Device Revision: 0x1​

/* 0x15 */ 0x00, // EEPROM Revision: 0​

/* 0x16 1 */ 0x08, 0x81, 0x82, 0x02, 0x82, 0x00, 0x00, 0x00,​

/* 0x1E 2 */ 0x08, 0x82, 0x92, 0x01, 0x82, 0x00, 0x00, 0x00,​

/* 0x26 3 */ 0x08, 0x83, 0x82, 0x04, 0x82, 0x01, 0x00, 0x00,​

/* 0x2E 4 */ 0x08, 0x84, 0x92, 0x03, 0x82, 0x01, 0x00, 0x00,​

/* 0x36 5 */ 0x05, 0x85, 0x50, 0x00, 0x00,​

/* 0x3B 6 */ 0x05, 0x86, 0x50, 0x00, 0x00,​

/* 0x40 7 */ 0x02, 0x87,​

/* 0x42 8 */ 0x0b, 0x88, 0x20, 0x01, 0x00, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00,​

/* 0x4D 9 */ 0x03, 0x89, 0x80, // PCIe xx:04.0​

/* 0x50 A */ 0x05, 0x8a, 0x50, 0x40, 0x00,​

/* 0x55 B */ 0x05, 0x8b, 0x50, 0x40, 0x00,​

/* 0x5A 1 */ 0x0b, 0x01, 0x47, 0x49, 0x47, 0x41, 0x42, 0x59, 0x54, 0x45, 0x00, // Vendor Name: "GIGABYTE"​

/* 0x65 2 */ 0x16, 0x02, 0x5A, 0x33, 0x39, 0x30, 0x20, 0x47, 0x43, 0x2D, 0x54, 0x69, 0x74, 0x61, 0x6E, 0x20, 0x52, 0x69, 0x64, 0x67, 0x65, 0x00, // Device Name: "Z390 GC-Titan Ridge"​

},

These changes can be made using ThunderboltUtil as follows:

% source ThunderboltUtil.sh

% loadioreg
% usedromnum 1

% replacebytes 0x18 820282
% replacebytes 0x20 920182
% replacebytes 0x28 820482
% replacebytes 0x30 920382

% repairchecksums

% makedromdsl

The result is now correct: