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

[MACacOsX]

I need to order one. Amazon has deemed it non-essential so all the shipping times say mid to late April arrival.

@CaseySJ , @qthegaijin
Perhaps due to its type of configuration, Alpine Ridge could be the starting point...
I have here a TBEXIII Card from Asus and without SSDT i can see in IOReg the four pci-bridges (and the usb controller), but the operation with Antelope Devices is the same as with the Titan even without Local Node / Tbus.

However i have a problem to achieve local node / Tbus with it and the new Patched Firmware:
@NorthAmTransAm maybe you can know why ..
I can flash the NVM18 and NVM26 firmware, but although I can see the device populated under PC01 or PCI0 (slot depending), it doesn't show tree (looks like there is no TB chip, but the checksum of the Firmware reading after the flash and the .bin file is the same).
If i go back to the original Firmware, the card works well. (PCIe Devices populated and Hot Plug with SSDT and Without TB_Header), but no Local Node/TB Bus (obviously)

Could it be rev. dependent? My card is rev 1.00 with NVM18.
Where can you see if it is revision B or C? Maybe I have the first version and it needs to be patched otherwise?

By the way: CaseySJ, you are right -> with this card, the Windbond chip is more unstable in reading/writing (at least with the ch341a)

 

[CaseySJ]

...
- I can see at startup that the system tries to read the address of the device and fails. Therefore, the Antelope driver doesn't do its job well. Sometimes I think if it could be solved by injecting properties of the device itself, but I don't have a real mac on hand to compare..
-If I think about the network configuration, Antelope works with a local server running on port 2020 from the address obtained by DHCP (or 2021 / 2022 and so on if we restart the server) . The Antelope driver starts that server and is configured to recognize remote connections (or at least the local one), but maybe the reading is not working since it has not been able to read the device at startup (or we do not have the appropriate functions to capture the read events of the device in HotPlug).

I believe @qthegaijin has tested the Antelope with an on-board Alpine Ridge and a PCIe GC-Titan Ridge, but it continues to fail. I think there is pressure on Antelope to update their drivers.

Although LocalNode / TBus is enabled, there is no self-assigned address on Net / Thunderbolt Bridge (marked in red instead of yellow). (Althought Port7 is activated)

Add-in-cards so far are not performing nearly as well as on-board Thunderbolt controllers. I have a GC-Titan Ridge that has been flashed with various different modifications, but none of them works as well as the on-board controller on the Designare (and the Gigabyte Aorus Xtreme Z390). These two on-board controllers are virtually flawless, but I don't know if someone has attempted to connect an Antelope to them...

 

[NorthAmTransAm]

@CaseySJ , @qthegaijin
Perhaps due to its type of configuration, Alpine Ridge could be the starting point...
I have here a TBEXIII Card from Asus and without SSDT i can see in IOReg the four pci-bridges (and the usb controller), but the operation with Antelope Devices is the same as with the Titan even without Local Node / Tbus.

However i have a problem to achieve local node / Tbus with it and the new Patched Firmware:
@NorthAmTransAm maybe you can know why ..
I can flash the NVM18 and NVM26 firmware, but although I can see the device populated under PC01 or PCI0 (slot depending), it doesn't show tree (looks like there is no TB chip, but the checksum of the Firmware reading after the flash and the .bin file is the same).
If i go back to the original Firmware, the card works well. (PCIe Devices populated and Hot Plug with SSDT and Without TB_Header), but no Local Node/TB Bus (obviously)

Could it be rev. dependent? My card is rev 1.00 with NVM18.
Where can you see if it is revision B or C? Maybe I have the first version and it needs to be patched otherwise?

By the way: CaseySJ, you are right -> with this card, the Windbond chip is more unstable in reading/writing (at least with the ch341a)

Sounds TBROM related to me. Try these SSDT's and report back.

Both my cards say Rev 1.0 so I don't think that correlates to B or C.

 

[CaseySJ]

...
Could it be rev. dependent? My card is rev 1.00 with NVM18.
Where can you see if it is revision B or C? Maybe I have the first version and it needs to be patched otherwise?

If you look near the top, do you see: CAN ICES-3 ( B )/NMB-3( B )

By the way: CaseySJ, you are right -> with this card, the Windbond chip is more unstable in reading/writing (at least with the ch341a)

Yes, but if you use the modified circuit shown here, it should be able to read/write with no trouble.

 

[NorthAmTransAm]

If you look near the top, do you see: CAN ICES-3 ( B )/NMB-3( B )

Yes, but if you use the modified circuit shown here, it should be able to read/write with no trouble.

Woah, that means mine is actually a Rev B. That would mean AlpineRidgeEX3NVM26 works on any of the cards...?

 

[CaseySJ]

Woah, that means mine is actually a Rev B. That would mean AlpineRidgeEX3NVM26 works on any of the cards...?

I was only asking what is printed on his card. Maybe they all have the same inscription, but if not then we might be able to deduce something from the difference.

 

[qthegaijin]

Thank you @CaseySJ .
*ANTELOPE
-Same tree in IOReg that @qthegaijin for Antelope Orion32+ (Here this Device has the pci-1d4b,a090 identifier)
-Below driver: lines of IOAudio Strems, but missing IOAudioEngineUserClient and incomplete information properties due to incomplete driver loading:
- I can see at startup that the system tries to read the address of the device and fails. Therefore, the Antelope driver doesn't do its job well. Sometimes I think if it could be solved by injecting properties of the device itself, but I don't have a real mac on hand to compare..
-If I think about the network configuration, Antelope works with a local server running on port 2020 from the address obtained by DHCP (or 2021 / 2022 and so on if we restart the server) . The Antelope driver starts that server and is configured to recognize remote connections (or at least the local one), but maybe the reading is not working since it has not been able to read the device at startup (or we do not have the appropriate functions to capture the read events of the device in HotPlug).
Although LocalNode / TBus is enabled, there is no self-assigned address on Net / Thunderbolt Bridge (marked in red instead of yellow). (Althought Port7 is activated)

I completely forgot about checking the Antelope Server Ports! Am glad I am not the only user here now to test Antelope stuff out. Also glad you have a different piece of kit so we can make sure any progress works across multiple devices.

What do your boot logs look like?

log show --last boot --style compact --predicate 'senderImagePath contains "AntelopeUnifiedDriver"' --info --debug

 

[MACacOsX]

I believe @qthegaijin has tested the Antelope with an on-board Alpine Ridge and a PCIe GC-Titan Ridge, but it continues to fail. I think there is pressure on Antelope to update their drivers.

Add-in-cards so far are not performing nearly as well as on-board Thunderbolt controllers. I have a GC-Titan Ridge that has been flashed with various different modifications, but none of them works as well as the on-board controller on the Designare (and the Gigabyte Aorus Xtreme Z390). These two on-board controllers are virtually flawless, but I don't know if someone has attempted to connect an Antelope to them...

Yep!! Antelope, please, it's your turn ...

some log lines...
kernel: (AntelopeUnifiedDriver) AntelopeTBAudioDevice/882: error: error getting device info
kernel: (AntelopeUnifiedDriver) AntelopeTBAudioDevice/785: error: error failed to read device info
kernel: (AntelopeUnifiedDriver) AntelopeTBAudioDevice/924: error: no reply getting channel info
kernel: (AntelopeUnifiedDriver) AntelopeTBAudioDevice/791: error: error failed to read channel info
...and much more..

If we do not succeed with AIC, it will have to be tested with a Z390 Designare ...

 

[qthegaijin]

GA-Z170X-DESIGNARE ALPINE RIDGE FIRMWARE UPDATE:

After reflashing the onboard TB3 controller using Gigabytes TBTFlash app, I reripped the firmware and lo and behold, it appears to be different than the one I originally ripped from the chip in this post. Attached is 3 copies of the new firmware for the GA-Z170X-DESIGNARE board to check/modify.

@CaseySJ @Elias64Fr @NorthAmTransAm if you want to take a look please do!

 

[rj510]

This firmware seems to be from the ASRock Z370 Gaming-ITX/ac and has a particularly old NVM 14. Is this the right file?

View attachment 456757

It's definitely from a new in the box Z390 ITX. They must have re-cycled old firmware. I've built up 3 systems with it and this was one board that was not yet used.

No wonder TB didn't work so well on the builds (I had thread I'd started on the board last year).

Is it worth modifying or trying a newer version from a Z370?