Gigabyte Z490 Vision D (Thunderbolt 3) + i5-10400 + AMD RX 580

[CaseySJ]

Hey Casey,

I got AppleVTD working! I'm now trying to get hotplugging to work, as stated earlier I have the Z490 UD and the Titan Ridge controller. Is the SSDT-DTPG.aml specific for the Vision D? If so, how can I generate one for my board?

Thanks!

Fortunately SSDT-DTPG is common to all boards.

 

[suren6791]

I have often had display issues like that with various Hackintoshes, if you un/re plug the cable does the display come back? I realize that's not an ideal permanent solution, especially for a TV, but it might help you narrow down the problem. What I have done at times when I could not fix it was get those short cable extensions and have it hang below the monitor for easy access.

I have not tried that, will give it a go

 

[CaseySJ]

I started to build out my OC EFI in anticipation of having this new flashed thunderbolt controller. I have generated and compiled via HackinDROM the SSDT-TB3-DROM-HOTPLUG.aml and also downloaded the SSDT-DTPG.aml

I noticed the Opencore 0.7.2 already has a SSDT-DTPG.aml I assume I need to replace this.

I also see another SSDT is active by default that says it enables HOT-PLUG for thunderbolt called SSDT-TB3HP.aml Should this stay or should I disable?

Once this is done all I'll need to do is tear down the machine. Im not sure I can wait till this weekend

View attachment 526389

Because you created a custom Thunderbolt SSDT (which we highly recommend), simply use that and disable/uncheck SSDT-TB3HP.

 

[jimbojingle]

Please check if APFS Min Date & Min Version are set to 0 or -1 in APFS section of config.plist. This can be done with OpenCore Configurator. Both Min Date and Min Version should be -1.

View attachment 526331

Thanks for this.

I have somehow made things worse. My Catalina NVMe and my Backup Catalina SSD both now hang at the Apple Logo with an empty Progress Bar. This is a step backwards! I have also observed HackinDROM reporting as OC Beta during my messing around with my OC setup. Perhaps I need to create a new config.plist from scratch.

Please advise and thanks again.

 

[CaseySJ]

Thanks for this.

I have somehow made things worse. My Catalina NVMe and my Backup Catalina SSD both now hang at the Apple Logo with an empty Progress Bar. This is a step backwards! I have also observed HackinDROM reporting as OC Beta during my messing around with my OC setup. Perhaps I need to create a new config.plist from scratch.

Please advise and thanks again.

For the time being we should not use the auto-upgrade feature of HackinDROM. Instead, we can use the “Create EFI” feature of HackinDROM or we can download the EFI zip folder from the mini-guide, rename “config-AMD-GPU.plist” to simply “config.plist” and copy PlatformInfo credentials into it (serial num, system UUID, board serial num, ROM). These should be copied into PlatformInfo —> DataHub tab in OpenCore Configurator.

The Create EFI function in HackinDROM does this automatically. If you visit the HackinDROM mini-guide, you’ll find the usage information for “Create EFI”.

I’ll add this message to the OC 0.7.2 mini-guide soon.

 

[stvatore]

Fortunately SSDT-DTPG is common to all boards.

Awesome!! I have hotplugging now! Interestingly it also fixed my issue of not being to daisy chain my Apollo Twin at sample rates higher than 88.2. However it requires me to start the Apollo ONLY after booting the computer. I think if I flash my Titan Ridge controller it should fix the issues with higher sample rates. Before I do so, I have a few questions.

1. Are there any known cons to flashing the Titan Ridge V2 controller? I also am successfully using the LG Ultrafine 4K Display with the ambient light sensor working, speakers and brightness controls. I believe they are all working due to me mapping out the USB C ports. I don't want to lose that functionality of course after flashing.

2. Are there any recommended USB prebuilt flashers to use with flashrom?

3. Finally out of curiosity, how was the firmware for the Titan Ridge controller made? Is it a rip from a real mac?

Thanks as always!

 

[CaseySJ]

Awesome!! I have hotplugging now! Interestingly it also fixed my issue of not being to daisy chain my Apollo Twin at sample rates higher than 88.2. However it requires me to start the Apollo ONLY after booting the computer. I think if I flash my Titan Ridge controller it should fix the issues with higher sample rates. Before I do so, I have a few questions.

1. Are there any known cons to flashing the Titan Ridge V2 controller? I also am successfully using the LG Ultrafine 4K Display with the ambient light sensor working, speakers and brightness controls. I believe they are all working due to me mapping out the USB C ports. I don't want to lose that functionality of course after flashing.

2. Are there any recommended USB prebuilt flashers to use with flashrom?

3. Finally out of curiosity, how was the firmware for the Titan Ridge controller made? Is it a rip from a real mac?

Thanks as always!

Please have a look at Tech Talk --> Thunderbolt in Post 1 of this thread. It has pointers/links to several mini-guides and provides a wealth of information. If you still have unanswered questions, please ask.

 

[Justcurious1]

For the time being we should not use the auto-upgrade feature of HackinDROM. Instead, we can use the “Create EFI” feature of HackinDROM or we can download the EFI zip folder from the mini-guide, rename “config-AMD-GPU.plist” to simply “config.plist” and copy PlatformInfo credentials into it (serial num, system UUID, board serial num, ROM). These should be copied into PlatformInfo —> DataHub tab in OpenCore Configurator.

The Create EFI function in HackinDROM does this automatically. If you visit the HackinDROM mini-guide, you’ll find the usage information for “Create EFI”.

I’ll add this message to the OC 0.7.2 mini-guide soon.

I did use the auto-upgrade and it worked fine. I didn't see the start of this thread so I don't know if this is specific to something or in general. How long will this issue persist as I have a video going out on this. Also, it looks like using fakePCIID for i225-V networking might not be necessary based on this info from the OC site:

2.5 Gbps Intel LAN. This works out of the box with AppleIntelI210Ethernet but requires a device-id injection of <F2150000> and a kext patch. This is all the same as with the CML boards. Additionally, with macOS 11.4 Beta 1, Apple has opened up AppleIntelI210Ethernet to supporting a larger array of devices including the i225-V NIC found on most higher-end boards. This requires no device-id injection or kext patch.

Is this coming here? Thanks.

 

[CaseySJ]

I did use the auto-upgrade and it worked fine. I didn't see the start of this thread so I don't know if this is specific to something or in general. How long will this issue persist as I have a video going out on this.

When HackinDROM updates our config.plist it looks for differences between the XML schema of the current and new versions of OpenCore. If some attributes were added or deleted, or the "type" (i.e. Boolean, String, Data) of some attributes was changed, HackinDROM can manage those changes quite well.

But when we change the value of an existing attribute (an attribute whose 'format' is exactly the same in the current and new versions of OpenCore), HackinDROM does not accommodate that change. Instead, HackinDROM assumes that you, as the owner, changed the value for a good reason and you wish to keep the value that you currently have.

Unfortunately, when we enabled AppleVTD, we changed the value of an existing attribute, DisableIoMapper, from Checked-ON to Checked-OFF. Because all of us already have this attribute and it is set to Checked-ON, HackinDROM assumed that we wanted to keep it on. So it did not change it. And hence, the upgrade failed to enable AppleVTD.

This is not really the fault of HackinDROM because it worked as it was designed to work. So instead, this is something we overlooked in the design. We are still discussing a solution, but in the near term the burden will lie on me to make these changes clear to our users. The mini-guide will need to include a Post-Update Procedure to manually adjust such attributes.

Also, it looks like using fakePCIID for i225-V networking might not be necessary based on this info from the OC site:

2.5 Gbps Intel LAN. This works out of the box with AppleIntelI210Ethernet but requires a device-id injection of <F2150000> and a kext patch. This is all the same as with the CML boards. Additionally, with macOS 11.4 Beta 1, Apple has opened up AppleIntelI210Ethernet to supporting a larger array of devices including the i225-V NIC found on most higher-end boards. This requires no device-id injection or kext patch.

Is this coming here? Thanks.

We have actually commented out the injection of device-id, but the mini-guide asks Catalina users to un-comment that line because the native device ID 0x15F3 is not supported in Catalina, but it is supported in Big Sur and Monterey. Catalina users have to spoof the device ID back to 0x15F2.

 

[taconugget]

The firmware chip on the Gigabyte motherboard itself is much harder to read/write. Everyone will struggle with it. We must be patient. We must always attach and detach the SOIC clip gently. If you are naturally near-sighted (or have perfect 20/20 vision without any corrective lenses) then you have an advantage. Attaching and detaching the clip requires very near sighted work.

If you are near-sighted and use corrective lenses to see distant objects, remove those corrective lenses so you don't experience any eye strain when focusing on very near objects.

Because the Gigabyte motherboard has a lot of components (and has memory modules, GPU, WiFi/BT card, etc.) it makes it much more difficult for the SPI Flash ROM reader/writer to properly power the Thunderbolt firmware chip. We end up back-powering other devices on the motherboard. This is why flashrom will often be unable to detect the firmware chip.

No joke... It's much harder on the board. I have a good solid connection with the chip/clip but its not seeing the ROM. I must be back-powering. Im going to remove everything from the board and then try again later this weekend when I have more time to spare. I was relieved to see an open spot in my case to the chip directly, however after three attempts putting on the clip and the RasPI not reading, I decided not to press my luck...

Only documenting this so others know the struggle. Don't think Ive seen anyone but CaseySJ talk much about the difficulty on board.

Another note... By disabling the SSDT-TB3HP.aml in my EFI I was able to use the eGPU just fine w/ Cinema4D/Octane GPU rendering. No hotplug ability, or the extra goodies of a flashed thunderbolt though... a decent workaround for my needs though until successful flash.