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

[CaseySJ]

This is your SSDT from the Mini Guide for Thunderbolt DROM, with chechum "0x47, 0xDE, 0x1F, 0x21,"
Sorry this is what @joevt told me about the checksum for GIGABYTE Z390 DESIGNARE. so I modified your SSDT

I tried to do the checksum by myself with Sunshine's calculator following what @joevt said: "from byte 13 exclude to the end"

If the checksum of your SSDT
If the checksum @joevt said me is correct so this result is also correct because
0x211FDE47 = 0x47, 0xDE, 0x1F, 0x21,

My scripts converts Suneshins result to 0xFF then insert it in DROM

Yes that is correct. In fact, this post by @joevt helps to explain why @Elias64Fr and I were not getting the right CRC32_C value. Specifically, this is what we were doing wrong:

• Byte 0x0E of the DROM specifies the total length of the DROM.
• The length of DROM begins at offset 0x0D and includes everything from that point forward.
• MacOS seems to compute the DROM length by itself and compares it against byte 0x0E. MacOS also computes the "correct" CRC32_C checksum using the correct length value, so its checksum does not match our checksum.

Solution:

• Specify the correct DROM length in Byte 0x0E and compute CRC32_C from the sunshine2k.de website. This is based on all bytes of DROM starting with Byte 0x0D.

I will update the DROM Decoded post.

 

[Inqnuam]

Yes that is correct. In fact, this post by @joevt helps to explain why @Elias64Fr and I were not getting the right CRC32_C value. Specifically, this is what we were doing wrong:

• Byte 0x0E of the DROM specifies the total length of the DROM.
• The length of DROM begins at offset 0x0D and stops before the Vendor and Device strings.
• MacOS seems to compute the DROM length by itself and compares it against byte 0x0E. MacOS also computes the "correct" CRC32_C checksum using the correct length value, so its checksum does not match our checksum.

Solution:

• Specify the correct DROM length in Byte 0x0E and compute CRC32_C from the sunshine2k.de website. This is based on all bytes of DROM starting with Byte 0x0D.

I will update the DROM Decoded post.

This is what I was thinking too! ill write a script for that byte indicating the length

 

[Inqnuam]

Yes that is correct. In fact, this post by @joevt helps to explain why @Elias64Fr and I were not getting the right CRC32_C value. Specifically, this is what we were doing wrong:

• Byte 0x0E of the DROM specifies the total length of the DROM.
• The length of DROM begins at offset 0x0D and stops before the Vendor and Device strings.
• MacOS seems to compute the DROM length by itself and compares it against byte 0x0E. MacOS also computes the "correct" CRC32_C checksum using the correct length value, so its checksum does not match our checksum.

Solution:

• Specify the correct DROM length in Byte 0x0E and compute CRC32_C from the sunshine2k.de website. This is based on all bytes of DROM starting with Byte 0x0D.

I will update the DROM Decoded post.

on Sunshine what I should select before calculating?

ive also tried with 0xdb but the result is still incorrect, excepted result is 0x69 (for GIGABYTE Z390 DESIGNARE)

I'll look ThunderbolUtil to find the answer

 

[CaseySJ]

on Sunshine what I should select before calculating?
View attachment 479219

ive also tried with 0xdb but the result is still incorrect, excepted result is 0x69 (for GIGABYTE Z390 DESIGNARE)

I'll look ThunderbolUtil to find the answer

CRC8 is still calculated the same way as before. No change.

My previous post simply describes *my error*.

Good news for you: No change is needed to your code. Your DROM is correct. For all the motherboards and TB cards that your script supports, we just need to make sure that byte 0x0E has the correct length value. When you are done with these other boards, I can check all the DROMs once again.

 

[Inqnuam]

Okay Nice!

Your DROM is correct.

So Why in System Info I've still GIGABYTE Z390 DESIGNARE, in IOSReg too?

For all the motherboards and TB cards that your script supports, we just need to make sure that byte 0x0E has the correct length value. When you are done with these other boards, I can check all the DROMs once again.

But how we know that for Z390 DESIGNARE the byte 0x0E is 0x69? what is the method tu calculate it?

 

[CaseySJ]

Okay Nice!


So Why in System Info I've still GIGABYTE Z390 DESIGNARE, in IOSReg too?
View attachment 479225



But how we know that for Z390 DESIGNARE the byte 0x0E is 0x69? what is the method tu calculate it?

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

 

[yosoyoco]

Good improvements! Some comments/suggestions:

• I like the name!

View attachment 479163​

• After choosing a device from the menu, we should simplify the workflow:
  • First, the title "HackinDROM" becomes too small on this screen, so it should be same size as the home screen.
  • We should not display the SSDT right away. Instead:
    • Let user specify Vendor Name and Device Name
    • Then provide one Generate button
    • Then display the SSDT
    • Right above the SSDT, state the instructions (no need for STEP 2).

Here's an example:

• This is the current screen:

View attachment 479164​

• Proposal:
  • After user selects motherboard or Thunderbolt add-in-card from the main menu, then show them something like this:
• View attachment 479167​
• When user clicks Generate SSDT then show them this:
  
  View attachment 479168​

Also please note:

• If your webpage uses any of the functions in @joevt's ThunderboltUtil, please add an acknowledgement statement. Something like this:​
  • Uses 'ThunderboltUtil' by joevt.​
  • (notice that 'ThunderboltUtil' is hyperlinked to the gist.github source)​

Nice work !
It would be nice to have an option for the bus ID number !

 

[RumpelHumpel]

Thank you very much for your guide and your provided kexts.
I installed mac os 15.5.5 with your quick install guide for 15.5.4, except the preparation for the install usb stick (I used unibeast) but replaced all kexts with on my efi partition with yours.
Without any problems I installed macOS and it didn't worked like these in the whole time since I am using Hackintosh.
So thank you and gigabyte for the great board


Some questions:
- unlock with my watch worked only one time. Does someone has the "problem"? I am using a PCIe adapter with an apple wifi card
- sometimes my hackintosh awakes shortly after it's gone to standby. I didn't push any button or so.
- I read that it is better to put kext in s/l/e or l/e and not on the efi partition. Is that obsolet and you can leave them on the efi partition?
- I am using istat for hardware monitoring. I see the temperature of my graphic card (didn't work with my asus board) but cpu themperature isn't working. Any ideas?

 

[gprime]

I just followed the guide. So far everything that I have tested is working just fine (Bluetooth is via USB IOGear adapter). But worthy of note is that my Apollo Twin Duo Mk1 works with a Apple Thunderbolt TB2 to TB3 adapter.

I was totally expecting that it wouldn't work as it's a MK1, and so is supposed to be TB1 only. So that was a welcome surprise.

Hi, I got the exact same setup with Apple Adapter TB3-to-TB2 + Apollo Twin MK1 and it's not working at all.

How did you proceed ?

Best

 

[CaseySJ]

Thank you very much for your guide and your provided kexts.
I installed mac os 15.5.5 with your quick install guide for 15.5.4, except the preparation for the install usb stick (I used unibeast) but replaced all kexts with on my efi partition with yours.
Without any problems I installed macOS and it didn't worked like these in the whole time since I am using Hackintosh.
So thank you and gigabyte for the great board

Glad to hear it!

Some questions:
- unlock with my watch worked only one time. Does someone has the "problem"? I am using a PCIe adapter with an apple wifi card

I've seen this issue when doing multiple sleep/wake cycles. I believe this is a widespread issue, not just limited to your setup.

- sometimes my hackintosh awakes shortly after it's gone to standby. I didn't push any button or so.

Please see the Sleep Aid guide.

- I read that it is better to put kext in s/l/e or l/e and not on the efi partition. Is that obsolet and you can leave them on the efi partition?

Starting with Catalina, we should not install any Hackintosh kexts in /Library/Extensions. Instead, we install them only in CLOVER/kexts/Other.

- I am using istat for hardware monitoring. I see the temperature of my graphic card (didn't work with my asus board) but cpu themperature isn't working. Any ideas?

I believe we need to install Intel Power Gadget for Mac. Be careful with this, however. Specifically, make a full bootable backup before installing this and test your system for about two weeks. I encountered a significant issue that I think (not sure) was related to IPG for Mac, which required reinstalling macOS from scratch.

It's better to use HWMonitorSMC2 instead of iStat. HWMonitor can be downloaded from here:

Releases · CloverHackyColor/HWMonitorSMC2

Application for monitoring hardware health in macOS - CloverHackyColor/HWMonitorSMC2

github.com