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

[joevt]

Only problem in that DROM is the CRC for the UID.

repairchecksums
dumpdrom
makedromdsl

0x01) UID: 0x0000554433221102
0x0d) Device ROM Revision: 1
0x10) Vendor ID: 0x1
0x12) Device ID: 0x10
0x14) Device Revision: 0x1
0x15) EEPROM Revision: 0
0x16)   1: 820282000000
0x1e)   2: 920182000000
0x26)   3: 820482010000
0x2e)   4: 920382010000
0x36)   5: 090100
0x3b)   6: 090100
0x40)   7: 
0x42)   8: 20
0x45)   9: 80
0x48) - A: 
0x4a) - B: 
0x4c)   1: "Apple Inc."
0x59)   2: "Macintosh"
0x65) End

    "ThunderboltDROM",
    Buffer (0x65)
    {
        /* 0x00     */  0x4f,                                           // CRC8 checksum: 0x4F
        /* 0x01     */  0x02, 0x11, 0x22, 0x33, 0x44, 0x55, 0x00, 0x00, // Thunderbolt Bus 2, UID: 0x0000554433221102
        /* 0x09     */  0x2d, 0xea, 0x01, 0xbd,                         // CRC32c checksum: 0xBD01EA2D
        /* 0x0D     */  0x01,                                           // Device ROM Revision: 1
        /* 0x0E     */  0x58, 0x00,                                     // Length: 88 (starting from previous byte)
        /* 0x10     */  0x01, 0x00,                                     // Vendor ID: 0x1
        /* 0x12     */  0x10, 0x00,                                     // Device ID: 0x10
        /* 0x14     */  0x01,                                           // Device Revision: 0x1
        /* 0x15     */  0x00,                                           // EEPROM Revision: 0
        /* 0x16   1 */  0x08, 0x81, 0x82, 0x02, 0x82, 0x00, 0x00, 0x00, 
        /* 0x1E   2 */  0x08, 0x82, 0x92, 0x01, 0x82, 0x00, 0x00, 0x00, 
        /* 0x26   3 */  0x08, 0x83, 0x82, 0x04, 0x82, 0x01, 0x00, 0x00, 
        /* 0x2E   4 */  0x08, 0x84, 0x92, 0x03, 0x82, 0x01, 0x00, 0x00, 
        /* 0x36   5 */  0x05, 0x85, 0x09, 0x01, 0x00, 
        /* 0x3B   6 */  0x05, 0x86, 0x09, 0x01, 0x00, 
        /* 0x40   7 */  0x02, 0x87, 
        /* 0x42   8 */  0x03, 0x88, 0x20, // PCIe xx:01.0
        /* 0x45   9 */  0x03, 0x89, 0x80, // PCIe xx:04.0
        /* 0x48 - A */  0x02, 0xca, 
        /* 0x4A - B */  0x02, 0xcb, 
        /* 0x4C   1 */  0x0d, 0x01, 0x41, 0x70, 0x70, 0x6c, 0x65, 0x20, 0x49, 0x6e, 0x63, 0x2e, 0x00, // Vendor Name: "Apple Inc."
        /* 0x59   2 */  0x0c, 0x02, 0x4d, 0x61, 0x63, 0x69, 0x6e, 0x74, 0x6f, 0x73, 0x68, 0x00, // Device Name: "Macintosh"
    },

 

[Bobby22]

@CaseySJ Hello mate it has been a few moments since I havent come here.
First I want to thank you for this wonderful post and the help you provide to everyone. Without you I would not have been able to do this fantastic Hackintosh.

Since the beginning I am experiencing some Boot/Shutdown issues

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

@CaseySJ Hello again Mate, Thank you for all what you've done. Everything is running smooth on my Hackintosh. However, I don't know If you can remember this problem ; https://www.tonymacx86.com/threads/success-gigabyte-designare-z390-thunderbolt-3-i7-9700k-amd-rx-580.267551/post-2093870 To sum...

www.tonymacx86.com

.

The computer still goes into Loop after each shutdown (Note : I press Shutdown, not sleep mode). Furthermore I just realized that the computer might not shutdown (shutdown problem) well which might be the cause of the loop ?
After each shutdown, IF I press the power button in front of the case (I can hear the click which confirm me the button is pressed), it would return nothing from the computer.
The second time I press it, it would just do a short loop of few seconds starting the power then shutting down few seconds later without even displaying the BIOS.
The 3rd time, it will enter into the BootLoop 2 times more before launching the bios, then clover and then booting.

I contacted Gigabyte which advised me to take back the battery, do a CMOS reset and try again. I did it 3 times without success (Setup back MSR 02 after each time).
I tried to turn off XMP profile, which gave me no success as well.

To sum up this is the Hardware I am using :
- Monitor : DELL P2415Q Displaying correctly 4K
- MotherBoard : Z390 Gigabyte Designare
- SSD : Samsung
-CPU : Intel I9900K
- GPU : Sapphire Nitro RT5700X 8G
- Ram: DDR4 Crucial Ballistix Sports 64 GO 3000Mhz-Cas 15
- Power : Corsair 750 RMx
- Wifi-Card : Fenvi T919
- SSD1 (MacOs One) : Samsung Pro 970 SSD 1TB
- SSD 2 (Windows One) :Sabrent 1TB SSD

For the Setup, i followed the "mini guide for Fresh installation of catalina 10.15.1 and newer".
SMBIOS : Imac19,1
Clover version : 5100
BIOS version : F9B + Set it up according to the configuration explained in your first post.
MacOs Version : Catalina 10.15.3
OcQuirks and FwRuntimeServices revision : 15.
Native NVRAM unlocked and working as well with MSR02.
Everything is setup according to the Pslit you provided (FixShutdown, FixIpic, FixHpet and so more).

Drivers version :
AppleALC.kext : Version: 1.4.4
IntelMausi.kext : Version: 1.0.2
Lilu.kext : Version: 1.4.0
SmallTreeIntel82576.kext : Version: 1.0.6
SMCProcessor.kext : Version: 1.0.9
SMCSuperIO.kext : Version: 1.0.9
USBInjectAll.kext : Version: 0.7.1
VirtualSMC.kext : Version: 1.0.9
WhateverGreen.kext : Version: 1.3.5

I just added those 3 hide Volume to only Display Mac and Windows Volume to boot on :
- Preboot
- Recovery
- Microsoft Basic Data

Boot Args : Booting aswell with Shikigva = 80.
Energy Saver :
- Prevent computer from sleeping : Checked
- Put Hard disk to sleep : Checked
- Wake for Network access : Unchecked
- Enable Power Nap : Unchecked

Any other idea how can I fix this ? Thank you sir <3

@CaseySJ
Hello Sir, I hope you are going well.
I still have this issue when I Start the computer.
This is the Video you Asked.

Streamable Video

Watch this video on Streamable.

streamable.com

Usually even if I clearCmos I have to remove Battery, and wait 4-6H.
Then it does POST test, goes through it. Then boot Back in, then Unlock Msr to make it work again. It appears not on restart but shutdown. It’s Harassing.

Where could it Came from ?

Save my PC and my life please lol, I’m fed up with this .

thank you

 

[CaseySJ]

@CaseySJ
Hello Sir, I hope you are going well.
I still have this issue when I Start the computer.
This is the Video you Asked.

Streamable Video

Watch this video on Streamable.

streamable.com

Usually even if I clearCmos I have to remove Battery, and wait 4-6H.
Then it does POST test, goes through it. Then boot Back in, then Unlock Msr to make it work again. It appears not on restart but shutdown. It’s Harassing.

Where could it Came from ?

Save my PC and my life please lol, I’m fed up with this .

thank you

Hello @Bobby22,

This may be a hardware problem. If you have already updated to latest BIOS (which has the effect of clearing CMOS and starting from a clean state) then the problem you describe is most likely hardware-related. Please describe the problem to Gigabyte. One of the components or one of the connections in the system may be flawed. Gigabyte will probably ask you to replace or disconnect/reconnect various components in order to localize the problem.

 

[Inqnuam]

Please see updated Thunderbolt DROM Decoded -- byte 0x0E is explained:

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

The latest decoding sounds really awesome and I can't wait till you guys can use it for pcie firmwares etc aswell. One step further to a perfect thunderbolt solution under macOS. You guys rock! @CaseySJ @Elias64Fr Hi @S1lla Thanks ! You mightn't have to burn your customised TDROM on the...

www.tonymacx86.com

View attachment 479233

Sir, I got that its from offset 0x0D to end! but I still don't know the method to calculate it, please explain me. I searched it everywhere but I can't find any information. Every time we change Vendor and Device name we should calculate 0x0E otherwise checksum 32C is calculated incorrectly...

 

[CaseySJ]

Sir, I got that its from offset 0x0D to end! but I still don't know the method to calculate it, please explain me. I searched it everywhere but I can't find any information. Every time we change Vendor and Device name we should calculate 0x0E otherwise checksum 32C is calculated incorrectly...

Byte 0x0E is simply the number of bytes from byte 0x0D to the end of DROM.

In the example below, look at byte 0x0E:

• Its value is 0x69, which is decimal 105
• So there are 105 total bytes from byte 0x0D (byte #13) to the end of the DROM
• If you count all the bytes from byte 13 to the end, you will get 105 bytes
• The last byte in the DROM has the address 0x65 + 0x11 = 0x76 or 118 decimal
• Then we subtract the first 13 bytes, so 118 - 13 = 105, which is 0x69 in hex
• In other words:
  • ( 0x65 + 0x11 ) - 0x0D = 0x69

Another way to count is like this:

 

[Inqnuam]

In other words:

• ( 0x65 + 0x11 ) - 0x0D = 0x69

OMG
I'm turning around this since yesterday, the only thing I missed is "-0x0D"
Thank you very much Sir!

 

[CaseySJ]

** Mini-Guide for Viewing, Editing and Verifying Thunderbolt DROM
with ThunderboltUtil **
Please do not quote this guide in its entirely. Post a link instead.
Credit: @joevt
​

Background:
Thunderbolt DROM is a small set of configuration bytes that specifies such properties as the Thunderbolt Bus ID, Vendor Name, Device Name, unique user ID (UID), and whether or not to enable Thunderbolt Switch (which macOS requires in order to enable Target Disk Mode and other features). Although it is applicable to both flashed and un-flashed Thunderbolt controllers, it is most often used with flashed controllers to enable Thunderbolt Switch on macOS.

Anatomy of DROM:
This post describes Thunderbolt DROM in more thorough detail, although a simple diagram is provided in the spoiler below.

Spoiler: Quick Overview of Thunderbolt DROM

Contents of Thunderbolt DROM are validated by macOS by dynamically computing two checksums and comparing them with the same two checksums that are statically provided in the DROM itself. This ensures that the DROM has not be tampered with, but it also means that changes to DROM are not straightforward. Every change made to DROM requires one of the two checksums to be recomputed.

What is ThunderboltUtil?
ThunderboltUtil is not a single command, but a script that encapsulates a set of commands used in Terminal to view, edit, verify, and export Thunderbolt DROM. These commands allow us to work with DROMs in a more seamless manner.

Downloading and Installing:

• ThunderboltUtil is a single file (but not a single command) that can be downloaded by clicking the Download Zip button at the top right of this page (click on the image to go to the download page):
  
• Unzip the file and rename the long parent folder to simply ThunderboltUtil as shown:
  
  

Activating ThunderboltUtil:

• ThunderboltUtil is not an executable to be run on the command line; instead, the script encapsulates a number of individual commands. It is these individual commands that are invoked on the command line.
• To make these commands available in Terminal, we source the script.
  • Open Terminal and source the file:

source ~/Downloads/ThunderboltUtil/ThunderboltUtil.sh

• Now the commands are ready for use. A good place to start is dromhelp, which displays all available commands and their syntax.

Spoiler: dromhelp command list

% dromhelp

Commands:
    Get DROM
        loadioreg
        loadstring hexstring [sourcename]
        loadfwfile filepath...
        loadamlfile filepath...
        loaddslfile filepath...
        loadioregfile filepath...
        loadhexfile filepath # for reverses xxd
        listdroms
        cleardroms

    Use DROM
        usedromnum numberfromlist
        usedromstring lowercasehexstring

    Modify DROM
        repairchecksums
        replacebytes bytepos lowercasehexstring [numbytestoreplace]
        setuid newuid
        setport 0xportnumber portcontents [-]
        deleteport 0xportnumber
        setstring 0xstringnumber stringvalue
        deletestring 0xstringnumber

    Files from DROM
        dumpdrom
        makedromdsl
        makedromdslall [folderpath]
        dumpdromall
        dumpdromalltofiles [folderpath]
  
    Misc
        extractfwfromexe exepath... # $(grep -l --include '*.exe' -R 'DROM' . )

    Variables
        dodump # Set to 1 to dump the DROM while changes are made to the DROM.
        debug # Set to 1 to output debugging info (uses stderr)
        ignoreuid # Set to 1 to replace all uids with 0x1122334455667788.
                  # DROMs with the same contents except UID will be considered identical.

    Help
        dromhelp

• A summary of that is shown here.
  
  

Usage / Workflow:
ThunderboltUtil offers a good selection of commands that cover many usage scenarios. We'll simplify the discussion in this guide to a subset of the commands that are most relevant to us. When we flash our Thunderbolt controller, we need to perform the following activities:

1. Get or enter Thunderbolt DROM
2. Specify a new unique UID
3. Enable Thunderbolt Switch
4. Optionally change the Vendor and/or Device name strings
5. Verify that the DROM is correct (i.e. it has correct checksums)
6. Convert DROM into an ACPI snippet that we can copy-and-paste into our Thunderbolt SSDT

In this section we'll show how to perform all of these tasks. The general workflow is as follows:

Task 1: Get or enter Thunderbolt DROM
There are several ways to load a Thunderbolt DROM into ThunderboltUtil. We'll cover the most pertinent methods.

Method 1: From a newly extracted Thunderbolt Firmware file

• When we read a Winbond or Macronix Flash ROM with an SPI reader, we obtain the complete firmware, which is a binary file typically 1MB in size. A default Thunderbolt DROM is located inside the file.
• We can use the following command to load the DROM directly from the firmware file using the command loadfwfile filepath:

Spoiler: Method 1

# example: If there's a space anywhere in the path name, use "\" before the space:
% loadfwfile ~/Downloads/Vision\ D/Vision-D-FW-1.bin

# we can also use quotes instead of backslash (do not put ~ inside the quotes):
% loadfwfile ~"/Downloads/Vision D/Vision-D-FW-1.bin"

% listdroms
1)
thedrom=71000000000000ed009a1ec570016800ed000dc0010208818002800000000882900180000000088380048001000008849003800100000585500000058650000002c70b88200100640000000000038980058a504000058b5040000b0147494741425954450010025a34393020564953494f4e2044000000000000000000000000000000000000000000000000000000000000000000
sources:
/Users/casey/Downloads/Vision D/Vision-D-1.bin:active:v50:nvm_v50.0:0x4200

• The command listdroms shows the DROM itself and the source information, which in this example is the file Vision-D-1.bin. We also see that DROM was read from the active partition, that its firmware version (NVM) is v50.0, and the DROM is located at file offset 0x4200.

Method 2: From IORegistry

• If we already have a Thunderbolt DROM in use, it will appear in IOReg. We can load it into ThunderboltUtil with the command loadioreg:

Spoiler: Method 2

# example: Load Thunderbolt DROM from IOReg
% loadioreg

% listdroms
1)
thedrom=71000000000000ed009a1ec570016800ed000dc0010208818002800000000882900180000000088380048001000008849003800100000585500000058650000002c70b88200100640000000000038980058a504000058b5040000b0147494741425954450010025a34393020564953494f4e2044000000000000000000000000000000000000000000000000000000000000000000
sources:
/Users/casey/Downloads/Vision D/Vision-D-1.bin:active:v50:nvm_v50.0:0x4200

2)
thedrom=14004fc2e997aa0000432b79fc016800ed000dc0010208818002800000000882900180000000088380048001000008849003800100000585500000058650000002870b88200100640000000000038980058a504000058b5040000b0147494741425954450010025a34393020564953494f4e204400
sources:
ioreg:/Root/iMac19,1/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/RP05@1C,4/IOPP/UPSB@0/IOPP/DSB0@0/IOPP/NHI0@0/ThunderboltDROM

• Notice that Thunderbolt DROM was loaded from IO Registry and added to list of loaded DROMs. We now have two DROMs in memory, which are labeled 1 and 2.
• If multiple Thunderbolt controllers are installed, loadioreg will load DROM from each one.
• The source information for DROM 2 shows that it's from ioreg at RP05.

Method 3: As a string of bytes

• If we already have a DROM string, it can be loaded directly using loadstring hexbytes [source name] as follows:

Spoiler: Method 3

# example: Load a DROM from hex bytes
% loadstring 71000000000000ed009a1ec570016800ed000dc0010208818002800000000882900180000000088380048001000008849003800100000585500000058650000002c70b88200100640000000000038980058a504000058b5040000b0147494741425954450010025a34393020564953494f4e204400 test-DROM

% listdroms
1)
thedrom=71000000000000ed009a1ec570016800ed000dc0010208818002800000000882900180000000088380048001000008849003800100000585500000058650000002c70b88200100640000000000038980058a504000058b5040000b0147494741425954450010025a34393020564953494f4e2044000000000000000000000000000000000000000000000000000000000000000000
sources:
/Users/casey/Downloads/Vision D/Vision-D-1.bin:active:v50:nvm_v50.0:0x4200
string:1

2)
thedrom=14004fc2e997aa0000432b79fc016800ed000dc0010208818002800000000882900180000000088380048001000008849003800100000585500000058650000002870b88200100640000000000038980058a504000058b5040000b0147494741425954450010025a34393020564953494f4e204400
sources:
ioreg:/Root/iMac19,1/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/RP05@1C,4/IOPP/UPSB@0/IOPP/DSB0@0/IOPP/NHI0@0/ThunderboltDROM

3)
thedrom=71000000000000ed009a1ec570016800ed000dc0010208818002800000000882900180000000088380048001000008849003800100000585500000058650000002c70b88200100640000000000038980058a504000058b5040000b0147494741425954450010025a34393020564953494f4e204400
sources:
test-DROM
string:2

• Notice that three DROMs are now in memory. The source information for item 3 is test-DROM because that was specified as the 2nd parameter to loadstring.

Method 4: From an existing SSDT in either .aml or .dsl format

• An existing Thunderbolt SSDT (Secondary System Descriptor Table) may be in either .dsl (Disassembled) text format or .aml (ACPI Machine Language) binary format.
• If Thunderbolt DROM is present in an existing SSDT, it can be read using the commands loadamlfile and loaddslfile followed by the file path.
• If the command returns Buffer is too small, it simply means that the length of DROM as specified in "Buffer (0x##)" is incorrect.
• An example of a correct Buffer statement is shown in the spoiler, along with sample use of the commands to load DROM from .aml and .dsl files.

Spoiler: Method 4

% loaddslfile SSDT-Z390-DESIGNARE-TB3HP-V4.dsl

% listdroms                              
1)
thedrom=7600C171C5BE4901000A9B60FA015E0001000C0001000881800280000000088290018000000008838004800100000884900380010000088500000000000003862003878002C80589500000058A50000002CB0D014170706C6520496E632E000C024D6163696E746F736800
sources:
SSDT-Z390-DESIGNARE-TB3HP-V4.dsl:\_SB.PCI0.RP05.UPSB.DSB0.NHI0._DSM:ThunderboltDROM

% usedromnum 1

% dumpdrom
0x01) UID: 0x000149BEC571C100
0x0d) Device ROM Revision: 1
0x10) Vendor ID: 0x1
0x12) Device ID: 0xC
0x14) Device Revision: 0x1
0x15) EEPROM Revision: 0
0x16)   1: 800280000000
0x1e)   2: 900180000000
0x26)   3: 800480010000
0x2e)   4: 900380010000
0x36)   5: 000000000000
0x3e)   6: 20
0x41)   7: 80
0x44) - 8:
0x46)   9: 500000
0x4b)   A: 500000
0x50) - B:
0x52)   1: "Apple Inc."
0x5f)   2: "Macintosh"
0x6b) End

% loadamlfile SSDT-Z390-DESIGNARE-TB3HP-V4.aml

% listdroms
1)
thedrom=7600C171C5BE4901000A9B60FA015E0001000C0001000881800280000000088290018000000008838004800100000884900380010000088500000000000003862003878002C80589500000058A50000002CB0D014170706C6520496E632E000C024D6163696E746F736800
sources:
SSDT-Z390-DESIGNARE-TB3HP-V4.dsl:\_SB.PCI0.RP05.UPSB.DSB0.NHI0._DSM:ThunderboltDROM
SSDT-Z390-DESIGNARE-TB3HP-V4.aml:\_SB.PCI0.RP05.UPSB.DSB0.NHI0._DSM:ThunderboltDROM

Now that one or more DROMs are loaded, we must always choose which one to work with. This is done with the usedromnum drom-number command. For example, to work with the third DROM in the list, we enter usedromnum 3.

---

Task 2: Specify a new unique UID
When a computer or a local area network has multiple Thunderbolt controllers, it is strongly recommended that each controller be assigned a unique ID or UID. This is done using the setuid command. UID consists of 8 hex bytes in the form 8877665544332211. These bytes will be reversed when the ACPI output is generated. The last byte (11 in this example) is also the Thunderbolt Bus ID. If a computer has multiple Thunderbolt controllers, each one should be assigned a different Bus ID.

Spoiler: Specify new unique UID

# this example selects DROM #3 and sets Bus ID to 02 and the rest of the UID to 7766554433221102
# for a total of 8 hex bytes

% usedromnum 3

# note that UID is specified in reverse byte order
# (Thunderbolt Bus ID 02 is the last byte)
% setuid 7766554433221102

% dromdump
0x01) UID: 0x7766554433221102
0x0d) Device ROM Revision: 1
0x10) Vendor ID: 0xED
0x12) Device ID: 0xC00D
0x14) Device Revision: 0x1
0x15) EEPROM Revision: 2
0x16)   1: 800280000000
0x1e)   2: 900180000000
0x26)   3: 800480010000
0x2e)   4: 900380010000
0x36)   5: 500000
0x3b)   6: 500000
0x40) - 7:
0x42)   8: 200100640000000000
0x4d)   9: 80
0x50)   A: 504000
0x55)   B: 504000
0x5a)   1: "GIGABYTE"
0x65)   2: "Z490 VISION D"
0x75) End

We use the command dumpdrom to show the modified DROM. Recall that listdroms displays the original unmodified DROMs. We can see that UID has been set to 0x7766554433221102. These bytes will be reversed when DROM is displayed in ACPI "dsl" format (see Task 6). The command dumpdrom also performs error checking. In this case no errors were found, so we can be assured that checksums have been appropriately updated.

---

Task 3: Enable Thunderbolt Switch
Thunderbolt Switch is disabled by default on most or all firmware. To use macOS features such as Target Disk Mode it is necessary to enable the switch. We do this in two steps:

Step 1: Determine the Port Number of Thunderbolt Switch

• This is easily accomplished by selecting a DROM and examining the output of dumpdrom, which produces a list of each 'port'. One of the ports will contain no values. We can see that in the example below where Port 7 has no data:

Spoiler: Port Data shown by 'dumpdrom'

% usedromnum 3

% dumpdrom
0x01) UID: 0x7766554433221102
0x0d) Device ROM Revision: 1
0x10) Vendor ID: 0xED
0x12) Device ID: 0xC00D
0x14) Device Revision: 0x1
0x15) EEPROM Revision: 2
0x16)   1: 800280000000
0x1e)   2: 900180000000
0x26)   3: 800480010000
0x2e)   4: 900380010000
0x36)   5: 500000
0x3b)   6: 500000
0x40) - 7:
0x42)   8: 200100640000000000
0x4d)   9: 80
0x50)   A: 504000
0x55)   B: 504000
0x5a)   1: "GIGABYTE"
0x65)   2: "Z490 VISION D"
0x75) End

• Port 7 has no data, but it does have a hyphen "-" just before the number "7". The hyphen indicates that Thunderbolt Switch is disabled.

Step 2: Enable the Switch

• We enable the switch by using setport 7 ""
• We disable the switch by using setport 7 "" -

Spoiler: Enable Thunderbolt Switch

% setport 7 ""

% dumpdrom
0x01) UID: 0x7766554433221102
0x0d) Device ROM Revision: 1
0x10) Vendor ID: 0xED
0x12) Device ID: 0xC00D
0x14) Device Revision: 0x1
0x15) EEPROM Revision: 2
0x16)   1: 800280000000
0x1e)   2: 900180000000
0x26)   3: 800480010000
0x2e)   4: 900380010000
0x36)   5: 500000
0x3b)   6: 500000
0x40)   7:
0x42)   8: 200100640000000000
0x4d)   9: 80
0x50)   A: 504000
0x55)   B: 504000
0x5a)   1: "GIGABYTE"
0x65)   2: "Z490 VISION D"
0x09) CRC32: 0x70c51e9a (expected: 0xfc792b43)
0x75) End

• We can see that the hyphen next to Port 7 has disappeared, confirming that Thunderbolt Switch is enabled.

---

Task 4: Optionally change the Vendor and/or Device name strings
Although not recommended, it is possible to change the two strings at the end of the DROM: the Vendor Name and the Device Name. Keep the new names under 35 characters even though they can be longer. Long names do not display well in dialog boxes.

• Use setstring 0x1 "new name" to change the Vendor Name
• Use setstring 0x2 "new name" to change the Device Name

Spoiler: Changing Vendor and/or Device Names

% usedromnum 3

% dumpdrom
0x01) UID: 0x7766554433221102
0x0d) Device ROM Revision: 1
0x10) Vendor ID: 0xED
0x12) Device ID: 0xC00D
0x14) Device Revision: 0x1
0x15) EEPROM Revision: 2
0x16)   1: 800280000000
0x1e)   2: 900180000000
0x26)   3: 800480010000
0x2e)   4: 900380010000
0x36)   5: 500000
0x3b)   6: 500000
0x40)   7:
0x42)   8: 200100640000000000
0x4d)   9: 80
0x50)   A: 504000
0x55)   B: 504000
0x5a)   1: "GIGABYTE"
0x65)   2: "Z490 VISION D"
0x75) End

% setstring 0x1 "Apple, Inc"
% setstring 0x2 "Hackintosh"

% dumpdrom
0x01) UID: 0x7766554433221102
0x0d) Device ROM Revision: 1
0x10) Vendor ID: 0xED
0x12) Device ID: 0xA207
0x14) Device Revision: 0x1
0x15) EEPROM Revision: 1
0x16)   1: 800280000000
0x1e)   2: 900180000000
0x26)   3: 800480010000
0x2e)   4: 900380010000
0x36)   5: 500000
0x3b)   6: 500000
0x40)   7:
0x42)   8: 200100640000000000
0x4d)   9: 80
0x50)   A: 504000
0x55)   B: 504000
0x5a)   1: "Apple, Inc"
0x67)   2: "Hackintosh"
0x74) End

• When we use setstring, the CRC32_C checksum is automatically recalculated.
• In this example we select DROM #2 and display the current settings with dumpdrom, where we see that Vendor ID is "GIGABYTE" and Device ID is "Z490 VISION D".
• Then we changed the Vendor ID to "Apple, Inc" and Device ID to "Hackintosh".

---

Task 5: Verify that the DROM is correct
We can use the dumpdrom command to display and verify that DROM is formatted correctly. If any errors are displayed, we can either (a) scrap the DROM or (b) use repairchecksums to fix both CRC8 and CRC32_C checksums.

---

Task 6: Convert DROM into an ACPI snippet
When all needed changes to DROM have been made and verified, we are ready to incorporate the new DROM into our SSDT. We begin by using the makedromdsl command and copy-pasting the result into the SSDT.

Spoiler: Creating ACPI snippet

% usedromnum 3

% makedromdsl
    "ThunderboltDROM",
    Buffer (0x74)
    {
        /* 0x00     */  0x86,                                           // CRC8 checksum: 0x86
        /* 0x01     */  0x02, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, // Thunderbolt Bus 2, UID: 0x7766554433221102
        /* 0x09     */  0x8f, 0x03, 0xb8, 0x6b,                         // CRC32c checksum: 0x6BB8038F
        /* 0x0D     */  0x01,                                           // Device ROM Revision: 1
        /* 0x0E     */  0x67, 0x00,                                     // Length: 103 (starting from previous byte)
        /* 0x10     */  0xed, 0x00,                                     // Vendor ID: 0xED
        /* 0x12     */  0x0d, 0xc0,                                     // Device ID: 0xC00D
        /* 0x14     */  0x01,                                           // Device Revision: 0x1
        /* 0x15     */  0x02,                                           // EEPROM Revision: 2
        /* 0x16   1 */  0x08, 0x81, 0x80, 0x02, 0x80, 0x00, 0x00, 0x00,
        /* 0x1E   2 */  0x08, 0x82, 0x90, 0x01, 0x80, 0x00, 0x00, 0x00,
        /* 0x26   3 */  0x08, 0x83, 0x80, 0x04, 0x80, 0x01, 0x00, 0x00,
        /* 0x2E   4 */  0x08, 0x84, 0x90, 0x03, 0x80, 0x01, 0x00, 0x00,
        /* 0x36   5 */  0x05, 0x85, 0x50, 0x00, 0x00,
        /* 0x3B   6 */  0x05, 0x86, 0x50, 0x00, 0x00,
        /* 0x40   7 */  0x02, 0x87,
        /* 0x42   8 */  0x0b, 0x88, 0x20, 0x01, 0x00, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00,
        /* 0x4D   9 */  0x03, 0x89, 0x80, // PCIe xx:04.0
        /* 0x50   A */  0x05, 0x8a, 0x50, 0x40, 0x00,
        /* 0x55   B */  0x05, 0x8b, 0x50, 0x40, 0x00,
        /* 0x5A   1 */  0x0d, 0x01, 0x41, 0x70, 0x70, 0x6c, 0x65, 0x2c, 0x20, 0x49, 0x6e, 0x63, 0x00, // Vendor Name: "Apple, Inc"
        /* 0x67   2 */  0x0d, 0x02, 0x48, 0x61, 0x63, 0x6b, 0x69, 0x6e, 0x74, 0x6f, 0x73, 0x68, 0x00, // Device Name: "Hackintosh"
    },

• This snippet can replace the existing Thunderbolt DROM in the SSDT.

 

[qthegaijin]

@CaseySJ @joevt @Elias64Fr

I am happy to report that the modified V50 firmware on the GC-TRv2 works. Still no Antelope audio devices working. One observation that can be seen in my screenshots is that even after changing the BUS ID in the DROM and ThunderboltConfig, it is showing my on-board alpine ridge and the TRv2 as Thunderbolt Bus 0.

 

[CaseySJ]

@CaseySJ @joevt @Elias64Fr

I am happy to report that the modified V50 firmware on the GC-TRv2 works. Still no Antelope audio devices working. One observation that can be seen in my screenshots is that even after changing the BUS ID in the DROM and ThunderboltConfig, it is showing my on-board alpine ridge and the TRv2 as Thunderbolt Bus 0.

View attachment 479421
View attachment 479422
View attachment 479423

I can check your Thunderbolt DROM if you send a copy by Private Mail (to safeguard your UID).

 

[qthegaijin]

I can check your Thunderbolt DROM if you send a copy by Private Mail (to safeguard your UID).

Awesome. Sent it to you!