Contribute
Register

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

There is no rush to update to 10.15.4. You can safely stay on 10.15.3 until the system is reliable.


Ok I 'm waiting i hope it is possibe soon for me
 
Here is another stock TB firmware from a mobo for mods and later placement in your repository. It is from ASRock Z390 Ph-Gam ITX mobo. It was read 3 times with identical results.

For anyone later using, there are two Macronix MX25L8006E (which ASRock seems to prefer over Winbond) chips on the back of the mobo. The image in the spoiler has the arrow pointing to the correct chip.

ASRock-Z390-PhGam-ITX-Back.jpg

[\SPOILER]
 

Attachments

  • ASRock-Z390-PhGam-ITX-original.bin.zip
    105.3 KB · Views: 88
Here is another stock TB firmware from a mobo for mods and later placement in your repository. It is from ASRock Z390 Ph-Gam ITX mobo. It was read 3 times with identical results.

For anyone later using, there are two Macronix MX25L8006E (which ASRock seems to prefer over Winbond) chips on the back of the mobo. The image in the spoiler has the arrow pointing to the correct chip.

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

Screen Shot 2020-03-24 at 3.11.43 PM.png
 
Hello @JimSalabim,
[…]
  • Let's start by examining the case where a Thunderbolt SSDT is used.
    • Can you please post the Thunderbolt SSDT you're using? If it contains a private UID, you may send it by private message (PM).
    • Also check the system boot log as follows:
      • log show --last boot | grep Thunderbolt <<-- Do you see any Thunderbolt errors?
      • log show --last boot | grep ACPI <<-- Do you see any ACPI errors such as 'table not loaded' or other errors?
  • Note also that the original Gigabyte firmware can be flashed back as a last resort.
  • The red line through IOThunderboltFamilyUserClient is normal. Every time we close and reopen System Information and then go to the Thunderbolt page, one of these will be created and deleted.
Thanks very much for explaining! I have attached my Thunderbolt SSDT and the results of the boot log concerning Thunderbolt and ACPI. There are indeed some errors in both of them, but I can’t really figure out what they mean. Perhaps you can help?
 

Attachments

  • ACPI Log.txt
    49 KB · Views: 89
  • Thunderbolt Log.txt
    19.7 KB · Views: 77
  • SSDT-TBOLT3-RP05-PORT7-Z390-DESIGNARE.aml
    2 KB · Views: 65
I have UAD Apollo Twin Reverb MkII with cable Apple Thunderbolt and USB-c Apple adapter.

But, when i update macOS, I power off my UAD.

Yes, it is working now. But, if I connect a SSD external USB-c when my computer is off.

i have a freeze i need to restart my computer on macos 10.15.3 sometimes
 
Last edited:
Thanks very much for explaining! I have attached my Thunderbolt SSDT and the results of the boot log concerning Thunderbolt and ACPI. There are indeed some errors in both of them, but I can’t really figure out what they mean. Perhaps you can help?
  • ACPI log looks fine. A small number of \_TZ.TZ10 errors are benign (they are due to a minor ACPI bug in Gigabyte's firmware).
  • Both DTPG and Thunderbolt SSDT were loaded.
  • But Thunderbolt log shows No DROM found as shown below:
Screen Shot 2020-03-24 at 3.21.02 PM.png

  • This might be due to a mismatch between your SMBIOS (iMacPro 1,1) and the DROM (but that doesn't seem likely). The DROM is coded for iMac 19,1 in bytes 13-21 (see Thunderbolt DROM Decoded):
    Screen Shot 2020-03-24 at 3.28.30 PM.png
  • We're still learning about DROM and ThunderboltConfig.


Does anyone own a real iMac Pro 1,1?

If so, can you please run IORegistryExplorer, scroll down to the Thunderbolt section, click on NHI0 and post a screenshot showing the full ThunderboltDROM? You may blank out the first 9 bytes. See screenshot:


Screen Shot 2020-03-24 at 3.35.08 PM.png
UPDATE: Thanks @NorthAmTransAm!
 
Last edited:
Re: Boot lag induced by Thunderbolt (GC-AR in my case)

I may be a slow learner, but what am I missing?

why not just edit your DSDT and remove the "offending" lines?

I have an Aorus Pro, and there are two instances (2 lines per instance) of \_GPE.TINI (Zero, RPS0, RPT0, Arg0).

this one is in \RWAK:

Code:
If (LEqual (TBTS, One))
            {
                If (LEqual (RPN0, One))
                {
                    Acquire (OSUM, 0xFFFF)
                    \_GPE.TINI (Zero, RPS0, RPT0, Arg0)
                    Release (OSUM)
                }

                If (LEqual (RPN1, One))
                {
                    Acquire (OSUM, 0xFFFF)
                    \_GPE.TINI (Zero, RPS1, RPT1, Arg0)
                    Release (OSUM)
                }

this one is in _SB.PCI0.PTIA._INI:

Code:
If (LEqual (TBTS, One))
            {
                If (LEqual (RPN0, One))
                {
                    Acquire (OSUM, 0xFFFF)
                    \_GPE.TINI (Zero, RPS0, RPT0, Zero)
                    Release (OSUM)
                }

                If (LEqual (RPN1, One))
                {
                    Acquire (OSUM, 0xFFFF)
                    \_GPE.TINI (Zero, RPS1, RPT1, Zero)
                    Release (OSUM)
                }

                Signal (WFEV)
            }

so, I opened MacIASL--New from ACPI--DSDT. saved it as DSDT.dsl to a convenient location, removed the four GPE.TINI lines, and saved as DSDT.aml.

placed the edited DSDT into Clover/ACPI/Patched. config.plist already has an entry to load DSDT.aml.

rebooted, and the several-second delay is gone (which was happening right after the "executing 45 lines of ACPI code" in verbose boot).
 
Re: Boot lag induced by Thunderbolt (GC-AR in my case)

I may be a slow learner, but what am I missing?

why not just edit your DSDT and remove the "offending" lines?

I have an Aorus Pro, and there are two instances (2 lines per instance) of \_GPE.TINI (Zero, RPS0, RPT0, Arg0).

this one is in \RWAK:

Code:
If (LEqual (TBTS, One))
            {
                If (LEqual (RPN0, One))
                {
                    Acquire (OSUM, 0xFFFF)
                    \_GPE.TINI (Zero, RPS0, RPT0, Arg0)
                    Release (OSUM)
                }

                If (LEqual (RPN1, One))
                {
                    Acquire (OSUM, 0xFFFF)
                    \_GPE.TINI (Zero, RPS1, RPT1, Arg0)
                    Release (OSUM)
                }

this one is in _SB.PCI0.PTIA._INI:

Code:
If (LEqual (TBTS, One))
            {
                If (LEqual (RPN0, One))
                {
                    Acquire (OSUM, 0xFFFF)
                    \_GPE.TINI (Zero, RPS0, RPT0, Zero)
                    Release (OSUM)
                }

                If (LEqual (RPN1, One))
                {
                    Acquire (OSUM, 0xFFFF)
                    \_GPE.TINI (Zero, RPS1, RPT1, Zero)
                    Release (OSUM)
                }

                Signal (WFEV)
            }

so, I opened MacIASL--New from ACPI--DSDT. saved it as DSDT.dsl to a convenient location, removed the four GPE.TINI lines, and saved as DSDT.aml.

placed the edited DSDT into Clover/ACPI/Patched. config.plist already has an entry to load DSDT.aml.

rebooted, and the several-second delay is gone (which was happening right after the "executing 45 lines of ACPI code" in verbose boot).

For fun of course!

If you're booting with your DSDT and you make another change, then you have to remove the DSDT, make the change, then add a new DSDT.

Edit: so many commas, wow.
 
The edited DSDT.aml loaded from Clover/ACPI/Patched still gets patched by whatever patches you have in config.plist.

I double-checked just now. The only patch in my config.plist is the SAT0 to SATA patch. An extract of my DSDT via MacIASL shows the patch having been applied.

Anyway, I did it this way because I think my board has a slightly different code for the GPE.TINI statements than the Designare, and the config.plist patch that you used didn't work for me. I'm not smart (or patient) enough to figure out what the patch needed to be for my board!

So, I guess "six of one, half dozen of another". haha.

As for your commas, I'm the king of the run-on sentence. My 7-th grade English teacher rolls over in her grave every time I write an overly-long sentence.

Thanks.
 
Back
Top