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

CaseySJ · Feb 2, 2020

Pollodivienna said:
there must be

View attachment 448053

In the words of Mr. Spock, "fascinating!" There is no memory driver present, which likely means that the default boot device in BIOS may have changed. You might be booting from a different drive? This can be checked by entering BIOS Setup and looking at the Boot section. You'll find a list of boot volumes listed in order of priority. Is the internal macOS SSD the first one on the list?

Pollodivienna · Feb 2, 2020

CaseySJ said:
In the words of Mr. Spock, "fascinating!" There is no memory driver present, which likely means that the default boot device in BIOS may have changed. You might be booting from a different drive? This can be checked by entering BIOS Setup and looking at the Boot section. You'll find a list of boot volumes listed in order of priority. Is the internal macOS SSD the first one on the list?

oh. could that be because of the hard coded Clover entry I made to make my dual boot Windows not destroy may Mac partition?

I did it with this guide
https://www.tonymacx86.com/threads/...ing-when-installing-windows-and-linux.272807/
(UEFI shell method)

Since then, I have clover bootloader show up separately in the boot devices (first place), but as I understand it should be using the EFI from my boot/system drive?

Addition: re-checked, no other boot drives connected (aside the Win10 disk).

Elias64Fr · Feb 2, 2020

CaseySJ said:
@Elias64Fr,

Finally found some time to continue testing Thunderbolt. Here are some observations:

TNODE/TBUS will appear under these circumstances:

Device Path Properties:

ThunderboltDROM must be specified. When booting without a valid ThunderboltDROM, TNODE/TBUS never appeared in many attempts.

ThunderboltConfig must be specified. When booting without ThunderboltConfig, TNODE/TBUS never appeared in many attempts.

Both of these parameters must be specified. They are being specified currently in config.plist.

ThunderboltConfig:

If an invalid ThunderboltConfig is specified, TNODE/TBUS will not appear.

This means macOS is parsing and using the information in ThunderboltConfig.

The following byte arrays have been tested:

00021C00 02000503 01000400 05030200 03000503 01000000 03030200 01000200

Result: Causes TNODE/TBUS to appear if SSP1=UsbCPortNumber 0x01 and SSP2=UsbCPortNumber 0x02.

1C might be referring to root port (RP05@1C,4)

01 and 02 seem to correspond to UsbCPortNumber for SSP1 and SSP2

If SSP1 is set to UsbCPortNumber 0x01 and SSP2 is set to UsbCPortNumber 0x02, then TNODE/TBUS will appear only if last 4 bytes of ThunderboltConfig are 01000200.

But if we intentionally reverse this by setting SSP1 to 0x02 and SSP2 to 0x01, but leave the last 4 bytes as 01000200, this causes a mismatch and TNODE/TBUS do not appear.

But if now we only change last 4 bytes of ThunderboltConfig to 02000100, then TNODE/TBUS will appear.

0002FFFF 04000301 01000400 05010200 03000301 01000000 03010200 02000100

Result: This also causes TNODE/TBUS to appear, but only if:

SSP1 UsbCPortNumber is 0x02

SSP1 UsbCPortNumber is 0x01

Conclusion:

ThunderboltConfig is important, and it is being used by macOS.

Strong correlation between last 4 bytes of ThunderboltConfig and UsbCPortNumber for SSP1/SSP2.

We may have to figure out what the other bytes mean, and set them correctly...

When above 2 conditions are satisfied, then we can make TNODE/TBUS appear every time by doing this:

Either hot-plug or hot-unplug a Thunderbolt device (not a USB-C device).

Wait for system to freeze (in about 2-3 seconds).

Press physical Reset button to reboot.

When system starts up again, just login to macOS.

TNODE/TBUS will not appear (a) at cold boot with or without TB3 device, (b) warm boot with or without TB3 device.

Instead, we must first hot-plug or hot-unplug a TB3 device, then press Reset button to reboot.

From this point onwards, TNODE/TBUS will appear with every reboot (even if we do not hot-plug or hot-unplug a device).

This means that after a hot-plug/hot-unplug event, the state of Thunderbolt registers/devices changes in such a way that TNODE/TBUS will appear from this point onwards.

So a hot-plug or hot-unplug is triggering something that then allows TNODE/TBUS to appear.

Can we figure out what this trigger is?

Open IORegistryExplorer and you will see TNODE/TBUS.

But system will freeze after about 10 seconds.

I am trying to comment-out various parts of NHI0 ACPI methods to see if this can be isolated. Will provide more details on this soon.

UPDATE: Removing the call to CTBT() from inside NHI0._PS0() consistently prevents the hot-plug/hot-unplug hang. However, this does not necessarily mean that the freeze is happening inside CTBT(). Instead, the freeze can be happening inside the Thunderbolt kext after it calls or returns from CTBT().

Here's an example of TNODE/TBUS appearing this morning at 4:51am, but system hanged after 10 seconds.
View attachment 448029

Hi @CaseySJ, Nice test !

Device Path Properties would probably be required on Titan Ridge set-up, I didn't experienced this on Alpine Ridge !

So.. I wouldn't like break the fun .. About ThunderboltConfig, I tried to verify on two rMac that I have IOReg files. It is not verified on 2/3:
On MacBookPro15,1 that include two Titan ridge controller :
<00 02 ff ff 02 00 05 03 01 00 04 00 05 03 02 00 03 00 05 03 01 00 00 00 03 03 02 00 02 00 01 00>
>> SSP1 has UsbCPortNumber = 0x2 VERIFIED
>> SSP2 has UsbCPortNumber = 0x1 VERIFIED
<01 02 ff ff 02 00 05 03 01 00 04 00 05 03 02 00 03 00 05 03 01 00 01 00 03 03 02 00 04 00 03 00>
>> SSP1 has UsbCPortNumber = 0x3 NOT VERIFIED
>> SSP2 has UsbCPortNumber = 0x4 NOT VERIFIED

On iMac19,1 that also include one Titan ridge controller :
<00 02 1c 00 02 00 05 03 01 00 04 00 05 03 02 00 03 00 05 03 01 00 00 00 03 03 02 00 01 00 02 00>
>> SSP1 has UsbCPortNumber = 0x2 NOT VERIFIED
>> SSP2 has UsbCPortNumber = 0x1 NOT VERIFIED

I modestly think if that property is included on NHI0, it might be limited to this part of device; two last bolded data might be thunderbolt port number that we can find on System Profiler / Thunderbolt... but that's only speculation.

It isn't easy to make correlation between ThunderboltConfig bytes and datas included on IOREG for each part of NHI0.

rankrotten · Feb 2, 2020

faithie999 said:
NVRAM on Z390 Aorus Pro:

I needed to use ocquirks/fwruntime services instead of aptiofree2000. now working fine.

I have a question for the few of you with this motherboard--I upgraded to BIOS f11 some time ago, but I didn't take a good look at the BIOS setup screen at the time. I can't find anywhere to select iGPU enabled or not either using "easy" or "advanced" setup. What am I missing?

Thanks.

Hiding in plain sight?

Elias64Fr · Feb 3, 2020

@CaseySJ

I found this code on Linux website for kernel 5.5.1 ( one of the last) Here :

Code:

        if (tb_route(sw) == 0) {
        /*
         * Apple's NHI EFI driver supplies a DROM for the root switch
         * in a device property. Use it if available.
         */
        if (tb_drom_copy_efi(sw, &size) == 0)
            goto parse;

        /* Non-Apple hardware has the DROM as part of NVM */
        if (tb_drom_copy_nvm(sw, &size) == 0)
            goto parse;

        /*
         * The root switch contains only a dummy drom (header only,
         * no entries). Hardcode the configuration here.
         */
        tb_drom_read_uid_only(sw, &sw->uid);
        return 0;
    }

This might explain why we have only 0xED00000000.. for UID, we can choice out UID by customizing this part of ThunderboltDROM property... but require adapted CRC to be validated by macOS driver.

And here, on same website page, content description :

Code:

    struct tb_drom_header {
    /* BYTE 0 */
    u8 uid_crc8; /* checksum for uid */
    /* BYTES 1-8 */
    u64 uid;
    /* BYTES 9-12 */
    u32 data_crc32; /* checksum for data_len bytes starting at byte 13 */
    /* BYTE 13 */
    u8 device_rom_revision; /* should be <= 1 */
    u16 data_len:10;
    u8 __unknown1:6;
    /* BYTES 16-21 */
    u16 vendor_id;
    u16 model_id;
    u8 model_rev;
    u8 eeprom_rev;
} __packed;
} __packed;

CaseySJ · Feb 3, 2020

Elias64Fr said:

@CaseySJ

I found this code on Linux website for kernel 5.5.1 ( one of the last) Here :

Code:

        if (tb_route(sw) == 0) {
        /*
         * Apple's NHI EFI driver supplies a DROM for the root switch
         * in a device property. Use it if available.
         */
        if (tb_drom_copy_efi(sw, &size) == 0)
            goto parse;

        /* Non-Apple hardware has the DROM as part of NVM */
        if (tb_drom_copy_nvm(sw, &size) == 0)
            goto parse;

        /*
         * The root switch contains only a dummy drom (header only,
         * no entries). Hardcode the configuration here.
         */
        tb_drom_read_uid_only(sw, &sw->uid);
        return 0;
    }

This might explain why we have only 0xED00000000.. for UID, we can choice out UID by customizing this part of ThunderboltDROM property... but require adapted CRC to be validated by macOS driver.

And here, on same website page, content description :

Code:

    struct tb_drom_header {
    /* BYTE 0 */
    u8 uid_crc8; /* checksum for uid */
    /* BYTES 1-8 */
    u64 uid;
    /* BYTES 9-12 */
    u32 data_crc32; /* checksum for data_len bytes starting at byte 13 */
    /* BYTE 13 */
    u8 device_rom_revision; /* should be <= 1 */
    u16 data_len:10;
    u8 __unknown1:6;
    /* BYTES 16-21 */
    u16 vendor_id;
    u16 model_id;
    u8 model_rev;
    u8 eeprom_rev;
} __packed;
} __packed;

Thank goodness for Linux open source!

A couple of days ago I booted the system without specifying (a) ThunderboltDROM, (b) ThunderboltConfig, (c) pathcr. And I saw the following:

Screen Shot 2020-01-31 at 7.07.10 PM.png

This occurred only once. When NHI0 device path properties are specified, we usually get this:

Screen Shot 2020-01-27 at 4.47.32 AM.png

CaseySJ · Feb 3, 2020

Elias64Fr said:
Hi @CaseySJ, Nice test !

Device Path Properties would probably be required on Titan Ridge set-up, I didn't experienced this on Alpine Ridge !

So.. I wouldn't like break the fun .. About ThunderboltConfig, I tried to verify on two rMac that I have IOReg files. It is not verified on 2/3:
On MacBookPro15,1 that include two Titan ridge controller :
<00 02 ff ff 02 00 05 03 01 00 04 00 05 03 02 00 03 00 05 03 01 00 00 00 03 03 02 00 02 00 01 00>
>> SSP1 has UsbCPortNumber = 0x2 VERIFIED
>> SSP2 has UsbCPortNumber = 0x1 VERIFIED
<01 02 ff ff 02 00 05 03 01 00 04 00 05 03 02 00 03 00 05 03 01 00 01 00 03 03 02 00 04 00 03 00>
>> SSP1 has UsbCPortNumber = 0x3 NOT VERIFIED
>> SSP2 has UsbCPortNumber = 0x4 NOT VERIFIED

On iMac19,1 that also include one Titan ridge controller :
<00 02 1c 00 02 00 05 03 01 00 04 00 05 03 02 00 03 00 05 03 01 00 00 00 03 03 02 00 01 00 02 00>
>> SSP1 has UsbCPortNumber = 0x2 NOT VERIFIED
>> SSP2 has UsbCPortNumber = 0x1 NOT VERIFIED

I modestly think if that property is included on NHI0, it might be limited to this part of device; two last bolded data might be thunderbolt port number that we can find on System Profiler / Thunderbolt... but that's only speculation.

It isn't easy to make correlation between ThunderboltConfig bytes and datas included on IOREG for each part of NHI0.

~~Yes, many of our assumptions are proving untrue!~~ Referring to Linux source code is a good idea.

Elias64Fr · Feb 3, 2020

CaseySJ said:
Thank goodness for Linux open source!

A couple of days ago I booted the system without specifying (a) ThunderboltDROM, (b) ThunderboltConfig, (c) pathcr. And I saw the following:
View attachment 448067
This occurred only once. When NHI0 device path properties are specified, we usually get this:
View attachment 448068

@CaseySJ
If this UID is different from each booting, probably randomly fixed by macOS like Domain UUID if not defined as property.

z4k · Feb 3, 2020

CaseySJ said:
*** OpenCore 0.5.4 Experimental Setup for Designare Z390 ***
(Please do not quote this guide in its entirety. Post a link instead.)

Thank you for all your contributions. I'm currently making a very similar build:
-Z390 Designare
-32GB RAM (2x16 3600MHz)
-i9-9900K
-RX580 Nitro+ Special Ed
-970 EVO Plus 1TB drive
-Fractal Define R5 case
-Going for Mojave 10.14.16 (audio/video production)

I've been trying to setup OpenCore, and, thank God, I stumbled upon your prepared EFI. I've educated myself a lot on it the last week or so, and it looks promising to me. But it's still quite difficult to get exactly right. I only have a couple of questions:

1.Why do you specify that Ii shouldn't use this for macOS Installation?
2.Do I have to change anything else in config.plist because of slight differences in our builds? Concerning USB mapping, CPU, NVMe drive.
3.What is your current preference for SMBIOS? iMac19,1 vs iMacPro1,1?
4.Would you suggest i go for Standard vs NDK Fork in my case?
5.Any particular stability/crashing issues up to now with your project?

Thank you so much once again!! Once i get this running the best i can i'm going to test every bit of hardware i have on it and report back with whatever worked or caused any trouble.

m.figueras · Feb 3, 2020

gandem said:
I too have been having issues with native NVRAM. The only consistent way for me to avoid the memory allocation errors has been to disable iGPU.

Thank you @gandem I'll try that some time this week and report back. For a disabled igpu, I think it will make sense to experiment with imac pro smbios and/or removing stuff in the bios that causes trouble with the memory map, and calculate a slide value.

Search

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

CaseySJ

Moderator

Pollodivienna

Elias64Fr

rankrotten

Attachments

Elias64Fr

CaseySJ

Moderator

CaseySJ

Moderator

Elias64Fr

z4k

m.figueras

Forum

Guides

Downloads