Contribute
Register

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

Unfortunately that is NVM18. I need NVM26 grr...

@CaseySJ I just need to confirm that my firmware for the EX3 (nvm18) works on an actual nvm18 card as I'm using nvm26 with no DSB2 devices (double grr!). I suspect it will.

@Loloflatsix, if your card is NVM18 you're welcome to try it. If so, I'll PM it plus my SSDT with the fully functional TBROM.
I have another Asus TBEX3 on my workstation : I will try tomorrow because I remember that it does not have the same device identifier on my IOReg.
 
I have another Asus TBEX3 on my workstation : I will try tomorrow because I remember that it does not have the same device identifier on my IOReg.
Holy cow thank you. I edited my post above with the SSDT and Firmware for a patched EX 3 on nvm18.

I would like to redo this patch scratch just to have it zipped up right. This is a patched...patch! I still see Hades Canyon in some of the information in system profiler. On mine it is fully functional except for USB and I fully believe thats because of the version difference. You two can confirm this whenever!

Maybe @Elias64Fr can help redo this later.
 
I want to thank you guys for all your hard work here!
 
Since there are some differences of the Gigabyte-AR DROM, I'm attaching the version (original, not modified) I read off and referenced earlier in this thread.

Perhaps it can be modified (I'm not so clever as you all to do this)?
Please try the two files in attached ZIP. Your firmware is slightly different from @StefanAM. There's no guarantee that either one will work, so please be ready to flash original firmware back.

If one of them works, please let me know which one that is.
 

Attachments

  • GC-Alpine-Ridge-NVM-20-rj510.zip
    293.3 KB · Views: 89
Holy Cow! Step away for half a day and things have been rolling fast!

@qthegaijin

"fud", is that what I think ? Firmware Updating tool from linux :confused:

I have no idea! All I know is that compared to most IOreg screenshots I have seen, those two options arent usually there. The strange thing is, this happens when I hotplug the Antelope to the computer without it being plugged in at boot. When I do that, then the AppleUserClient(sp) shows up and then reds out and the Antelope drivers dont activate in IOreg at all.

If I boot with the device plugged in, the drivers take but still throw the typical DMA loading errors I get almost every boot (either that or BAR0 errrors). When I boot like this, the UserClient and ThunderboltFamily options do not appear. Very strange indeed.

In this Quick Comparative Analysis we did a few days ago, we found that the first byte of ThunderboltConfig is the Bus ID. So if you change the Bus ID in ThunderboltDROM to 0x01 (byte #2 in red), please change byte #1 in ThunderboltConfig (green byte) to 0x01 as well, and see if you still see 4 ports.

I will attempt this shortly and report back. :headbang:

Report:
It does switch it back to 2 ports!
 
Last edited:
In this Quick Comparative Analysis we did a few days ago, we found that the first byte of ThunderboltConfig is the Bus ID. So if you change the Bus ID in ThunderboltDROM to 0x01 (byte #2 in red), please change byte #1 in ThunderboltConfig (green byte) to 0x01 as well, and see if you still see 4 ports.

Omg I missed this. This would explain so much of why I had a hard time for a minute. You, hooman, are pure gold.
 
Holy cow thank you. I edited my post above with the SSDT and Firmware for a patched EX 3 on nvm18.

I would like to redo this patch scratch just to have it zipped up right. This is a patched...patch! I still see Hades Canyon in some of the information in system profiler. On mine it is fully functional except for USB and I fully believe thats because of the version difference. You two can confirm this whenever!

Maybe @Elias64Fr can help redo this later.
@NorthAmTransAm
Let me know, where can I find your original firmware :) ?
 
@CaseySJ

As we are talking about an SSDT ready to play, I have prepared (not lunch but )a basic SSDT for enabling Link status to 0x101 (normal state) instead of 0x7 (disconnected) :


This can be used as a base of the final one.
We have to disabling _E17 to XE17 before use it but not tested if it is really required so I have it like that for now.
And also renaming RP05.PXSX to RP05.UPSB on our favourite boot loader :)
I've been experimenting with SSDT-TbtOnPch on the original un-flashed Designare. With P2TR register set to 0x0D (not 0x05), the system doesn't hang and Thunderbolt Bus appears as follows:

Screen Shot 2020-03-19 at 5.48.13 PM.png


This is with Apple Thunderbolt-to-Ethernet adapter connected via Apple TB3-to-TB2 adapter. The Ethernet port doesn't work, but the drivers do load.

Because DSDT already has RP05._DSM(), we cannot use the new DSM without first renaming the old one. Do you think this is important enough to try?
Code:
        Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
        {
            If ((Arg0 == ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b")))
            {
                Local0 = Package (0x02)
                    {
                        "reg-ltrovr",
                        Buffer (0x08)
                        {
                             0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00   // ........
                        }
                    }
                DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                Return (Local0)
            }

            Return (Zero)
        }
 
@NorthAmTransAm
Let me know, where can I find your original firmware :) ?


Why thank you! I'm still looking for nvm26 but here is NVM18 (linked above).

And for reference here is what we're using currently.

 
I've been experimenting with SSDT-TbtOnPch on the original un-flashed Designare. With P2TR register set to 0x0D (not 0x05), the system doesn't hang and Thunderbolt Bus appears as follows:

View attachment 455620

This is with Apple Thunderbolt-to-Ethernet adapter connected via Apple TB3-to-TB2 adapter. The Ethernet port doesn't work, but the drivers do load.

Because DSDT already has RP05._DSM(), we cannot use the new DSM without first renaming the old one. Do you think this is important enough to try?
Code:
        Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
        {
            If ((Arg0 == ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b")))
            {
                Local0 = Package (0x02)
                    {
                        "reg-ltrovr",
                        Buffer (0x08)
                        {
                             0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00   // ........
                        }
                    }
                DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                Return (Local0)
            }

            Return (Zero)
        }
@CaseySJ
I like your new code for reading more status data :)

As before we still have 0Gbps, thunderbolt device don't work but Link status seem to be good.

Have you experienced 20s disconnection without self-reboot ?
Does the classical error 0xe00002eb appears after one minute ?
Could you try a tbpatch dump after one minute on desktop ?

About adding _DSM, that's a RP05 property as defined on rMac DSDT. Nothing more, I don't know if it is required for speed link.
 
Back
Top