Issues while generating own UID and ThunderboltDROM

[Mork_vom_Ork]

This Topic is dedicated to @CaseySJ , @Elias64Fr , @NorthAmTransAm and @S1lla

First of all i want to thank you for all the effords you guys did on making Thunderbolt fully working on our Hackintosh Machines. It was a pleasure to read all your documentary about implement Thunderbolt native to Hackintosh macOS. I have to make the following things first clear:

- i use GC Titan Ridge PCIe Card flashed with Elias64FR Firmware NVMe23 postetd here.
- i studied posts about how to generate a valid UID here and here
- i studied posts about how to generate valid ThunderboltDROM in the same posts.

While studying these posts, some issues came to my mind about generating valid UID and ThunderboltDROM's for a GC TitanRidge PCIe card.
Let me explain, what happens or what is not really clear to me:

For generating a valid UID, you guys posted this:

------- First 22 bytes -------
71 -- CRC-8 (cyclic redundancy check for entire 8-byte UID below)
00 00 00 00 00 00 ED 00 -- UID (first byte = Thunderbolt Bus ID)

When veryfying the CRC-8 code with your Micro-Guide on how to do this here, i get the same CRC-8 Code 71.
But on the same page of your Micro-Guide "Thunderbolt DROM Decoded" at the bottom of that post, you try to explain on how to "color-code" the ThunderboltDROM with this example:

So the above DROM can be color-coded like this:

03 02 11 22 33 44 55 00 00 2d ea 01 bd 01 58 00 01 00 10 00 01 00 08 81 82 02 82 00 00 00 08 82 92 01 82 00 00 00 08 83 82 04 82 01 00 00 08 84 92 03 82 01 00 00 05 85 09 01 00 05 86 09 01 00 02 87 03 88 20 03 89 80 02 ca 02 cb 0d 01 41 70 70 6c 65 20 49 6e 63 2e 00 0c 02 4d 61 63 69 6e 74 6f 73 68 00

Green = CRC-8 for the red UID
Red = UID (first byte of UID "02" is Thunderbolt Bus ID)
Blue = CRC-32C for all the remaining bytes (yellow and black)
Yellow = Fixed/Pre-Defined 9 bytes for each Mac Model

As you can see, the first byte should be the CRC-8 Value for the following bytes: 02 11 22 33 44 55 00 00
But: if we try to generate the value as explained in your Micro-Guide you will get the following CRC-8 value: 4F
Maybe your "03" is just a syntax error cause the rest of that example works as explained. But there is another "But:":
If you post the whole bytes of your example to ThunderboltDROM entry in SSDT, save it and restart, the DROM-Entry seems to be valid anyway, cause the UID gets valid and we have an Entry in IORegExplorer for IOThunderboltPort@7!

The same issues mentioned above did i find for generating the CRC-32 value for ThunderboltDROM on this example of your Micro-Guide:

"ThunderboltDROM",
Buffer (0x76)
{
0x88, 0x00, 0x11, 0x11, 0x11, 0x11, 0x11, 0x00,
0x00, 0xbf, 0x6b, 0xda, 0x44, 0x01, 0x58, 0x00,
0x01, 0x00, 0x0d, 0x00, 0x01, 0x08, 0x08, 0x81,
0x80, 0x02, 0x80, 0x00, 0x00, 0x00, 0x08, 0x82,
0x90, 0x01, 0x80, 0x00, 0x00, 0x00, 0x08, 0x83,
0x80, 0x04, 0x80, 0x01, 0x00, 0x00, 0x08, 0x84,
0x90, 0x03, 0x80, 0x01, 0x00, 0x00, 0x05, 0x85,
0x50, 0x00, 0x00, 0x05, 0x86, 0x50, 0x00, 0x00,
0x02, 0x87, 0x0B, 0x88, 0x20, 0x01, 0x00, 0x64,
0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x89, 0x80,
0x05, 0x8A, 0x50, 0x40, 0x00, 0x05, 0x8B, 0x50,
0x40, 0x00, 0x0B, 0x01, 0x47, 0x49, 0x47, 0x41,
0x42, 0x59, 0x54, 0x45, 0x00, 0x11, 0x02, 0x47,
0x43, 0x2D, 0x54, 0x49, 0x54, 0x41, 0x4E, 0x20,
0x52, 0x49, 0x44, 0x47, 0x45, 0x00
},
CRITICAL WARNING:
Do not copy and paste the text above into MaciASL. Instead, copy-and-paste from the spoiler below. Failure to do so will be catastrophic.

Spoiler: Copy and Paste from Here

"ThunderboltDROM",
Buffer (0x76)
{
0x88, 0x00, 0x11, 0x11, 0x11, 0x11, 0x11, 0x00,
0x00, 0xbf, 0x6b, 0xda, 0x44, 0x01, 0x58, 0x00,
0x01, 0x00, 0x0d, 0x00, 0x01, 0x08, 0x08, 0x81,
0x80, 0x02, 0x80, 0x00, 0x00, 0x00, 0x08, 0x82,
0x90, 0x01, 0x80, 0x00, 0x00, 0x00, 0x08, 0x83,
0x80, 0x04, 0x80, 0x01, 0x00, 0x00, 0x08, 0x84,
0x90, 0x03, 0x80, 0x01, 0x00, 0x00, 0x05, 0x85,
0x50, 0x00, 0x00, 0x05, 0x86, 0x50, 0x00, 0x00,
0x02, 0x87, 0x0B, 0x88, 0x20, 0x01, 0x00, 0x64,
0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x89, 0x80,
0x05, 0x8A, 0x50, 0x40, 0x00, 0x05, 0x8B, 0x50,
0x40, 0x00, 0x0B, 0x01, 0x47, 0x49, 0x47, 0x41,
0x42, 0x59, 0x54, 0x45, 0x00, 0x11, 0x02, 0x47,
0x43, 0x2D, 0x54, 0x49, 0x54, 0x41, 0x4E, 0x20,
0x52, 0x49, 0x44, 0x47, 0x45, 0x00
},

Reboot.

Check if Thunderbolt Port 7 is activated.

In this example the CRC-32 value seems to be invalid, cause if i take the following bytes:

0x01, 0x58, 0x00, 0x01, 0x00, 0x0d, 0x00, 0x01,
0x08, 0x08, 0x81, 0x80, 0x02, 0x80, 0x00, 0x00,
0x00, 0x08, 0x82, 0x90, 0x01, 0x80, 0x00, 0x00,
0x00, 0x08, 0x83, 0x80, 0x04, 0x80, 0x01, 0x00,
0x00, 0x08, 0x84, 0x90, 0x03, 0x80, 0x01, 0x00,
0x00, 0x05, 0x85, 0x50, 0x00, 0x00, 0x05, 0x86,
0x50, 0x00, 0x00, 0x02, 0x87, 0x0B, 0x88, 0x20,
0x01, 0x00, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00,
0x03, 0x89, 0x80, 0x05, 0x8A, 0x50, 0x40, 0x00,
0x05, 0x8B, 0x50, 0x40, 0x00, 0x0B, 0x01, 0x47,
0x49, 0x47, 0x41, 0x42, 0x59, 0x54, 0x45, 0x00,
0x11, 0x02, 0x47, 0x43, 0x2D, 0x54, 0x49, 0x54,
0x41, 0x4E, 0x20, 0x52, 0x49, 0x44, 0x47, 0x45,
0x00

and paste them to the CRC-32 generator, it generates the following CRC-32 value: 0x91F7ED1B, which will be reversed

0x1B, 0xED, 0xF7, 0x91

And here is the same issue: if i copy all of the bytes in your example to my SSDT into ThunderboltDROM, save SSDT and restart, everything seems to be ok. Valid UID, valid ThunderboltDROM and an Entry in IORegExplorer for ThunderboltPort@7 !

If i use the generated CRC-32 value and change your CRC-32 value from example with the generated CRC-32 value, we will get NO valid UID, NO valid ThunderboltDROM and NO entry in IORegExplorer for ThunderboltPort@7 !

But WHY is this ? What ever i tried, i was NOT able to generate my own VALID ThunderboltDROM. So here is my Question: Is anyone of you guys willing to help me out with this? I would love to get a little feedback from you.

I would love to get THIS ThunderboltDROM valid:

aa 00 84 90 03 80 01 00 00 10 e3 f3 71 01 5e 00 01 00 0c 00 01 00 08 81 80 02 80 00 00 00 08 82 90 01 80 00 00 00 08 83 80 04 80 01 00 00 08 84 90 03 80 01 00 00 05 85 50 00 00 05 86 50 00 00 02 87 0b 88 20 01 00 64 00 00 00 00 00 03 89 80 05 8a 50 40 00 05 8b 50 40 00 0b 01 47 49 47 41 42 59 54 45 00 11 02 47 43 2d 54 49 54 41 4e 20 52 49 44 47 45 00

With kindly regards...
Mork vom Ork

 

[CaseySJ]

To answer your questions:

1. In the post Thunderbolt DROM Decoded, the sample DROM at the end of the post is meant only for illustrative purposes. The bytes in red were intentionally altered for privacy (as stated in that post), hence their checksum does not match byte 1.
2. We initially though that the 4-byte checksum was a CRC-32C checksum, but it turns out it's not that straightforward. We cannot use any of the online CRC-32 calculators because it seems macOS computes this is some as yet unknown way.
   • Fortunately we start by entering 4 random hex values knowing that they are wrong.
   • Then we reboot.
   • Now we check the system log: log show --last boot | grep IOThunderboltFamily
   • Hopefully there will be a log message indicating the incorrect 4-byte checksum and what the correct 4-byte checksum needs to be.
   • Then we copy the correct 4-byte checksum from the log and paste it into the DROM.
   • Not all systems will contain this log. I have 3 Hackintoshes running the same version of Catalina, but only one of them (my Asus X99 Deluxe II) contains this information in its log.