Contribute
Register

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

If you have Clover greater than r5000, you can delete the "driversUEFI" folder. All drivers have to be in "drivers/UEFI"

OsxAptioFix2Drv-free2000.efi can be replaced with FwRuntimeServices.efi and OcQuirks.efi and OcQuirks.plist

EmuVariableUefi-64.efi can be replaced with EmuVariableUefi.efi

enabling native NVRAM is no problem, if you really follow the guide and don't type any wrong codes while opening MSR. Then you don't need EmuVariableUefi.efi anymore.

Here is my UEFI folder to copy from (Clover r5103 with emulated nvram)

Thanks,

it seems to work just fine!
Used the latest OCQuirks from Github + your EmuvariableUefi.efi

Edit: I just realized that I did not copy FwRuntimeServices.efi but it still runs completely fine???
 
...
Edit: I just realized that I did not copy FwRuntimeServices.efi but it still runs completely fine???
There is a rational explanation! Please post a screenshot of your CLOVER folder with drivers/UEFI expanded.
 
There is a rational explanation! Please post a screenshot of your CLOVER folder with drivers/UEFI expanded.
there must be :D

Bildschirmfoto 2020-02-02 um 23.33.31.png
 
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?
 
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).
 
Last edited:
@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.
 
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? ;)
 

Attachments

  • IMG_2846.jpg
    IMG_2846.jpg
    977.3 KB · Views: 114
@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

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
 
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.
 
Last edited:
Back
Top