Thunderbolt 4, modified firmware, Full Thunderbolt Bus tree

[CaseySJ]

Some questions come to mind about TbtNvmDrvShellUpdate.efi:

• Because this was extracted from the BIOS file of Asus ProArt Z690 Creator, will it only work on this board?
• Will it work on non-Asus boards?

Update:

• According to Post 3 in this thread, the EFI app checks Vendor Name in DROM for “ASUS”
• We can, however, modify non-ASUS NVM DROMs to use vendor name ASUS

The EFI application TbtNvmDrvShellUpdate.efi can be obtained from GUID 5EDCCC1A-F4CA-42F4-8D3E-CA4C0B396BF7 in a whole bunch of Asus firmware (BIOS) files, including these:

• Asus Z690 ProArt Creator
• Asus Z790 ProArt Creator
• Asus X670E Gene (AMD)
• Asus Z670E ROG Crosshair Hero (AMD)
• Asus Z690 Hero Maximus
• Asus Z790 Hero Maximus

In all of these cases, the application is identical. This means the same version of TbtNvmDrvShellUpdate.efi can be used across at least the above mainboards.

 

[gandem]

Thanks for helping with this.

• Attached is the firmware that I flashed gc-maple-1-modified.bin, which incorporates all the required changes
• Also attached are two SSDTs:
  • One is for root port PEG1 SSDT-TB3-PEG1-PEGP.aml
  • One is for root port RP21 SSDT-TB3-RP21.aml

Simply pick one of the SSDTs and modify root port to accommodate the specific slot you'll be using.

I also bridged the top and middle pins of the vertical 5-pin J1 header. This forces the card to power on.

Instructions for flashing via 3.3V CH341a USB programmer:

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

Can you elaborate a little more about which ones were giving you problems, thx! This was mostly me doing CYA as I didn't want to claim that everything worked since I haven't tested them all just yet. The ones that I use the most all appear to be working, which largely come from: -...

www.tonymacx86.com

Hi @CaseySJ.
I have flashed my GC-Maple Ridge, but I am having problems getting it recognized.
This could be user error, but here's what I've done.

1. Successfully flashed patched firmware.
2. Shorted pins.
3. Installed in bottom slot of Z690 Pro Art Wifi.
4. Updated SSDT-TB3-RP21.aml to a RP of 09.
5. Added kernel patches for Ventura.
6. I have tried with on-board TB turned on and off.

I'm not getting anything recognized when plugging into the TB ports, nor is local bus appearing.
I have not plugged in a USB cable to the internal header of the card.

 

[CaseySJ]

Hi @CaseySJ.
I have flashed my GC-Maple Ridge, but I am having problems getting it recognized.
This could be user error, but here's what I've done.

1. Successfully flashed patched firmware.
2. Shorted pins.
3. Installed in bottom slot of Z690 Pro Art Wifi.
4. Updated SSDT-TB3-RP21.aml to a RP of 09.
5. Added kernel patches for Ventura.
6. I have tried with on-board TB turned on and off.

I'm not getting anything recognized when plugging into the TB ports, nor is local bus appearing.
I have not plugged in a USB cable to the internal header of the card.

View attachment 581139 View attachment 581140

Because the device tree is not named correctly in IOReg, my immediate suspicion falls to the SSDT. Let’s have a look at it.

 

[CaseySJ]

…

@CaseySJ have modified Tbt firmware from 31 to 32 because of current version 31 included on BIOS.
On your config, you have to modify from 31 (extracted from previous BIOS) to 37 because of current version 36 included on BIOS

I spent a couple of hours trying to patch the EFI shell app to skip NVM version checking, but it is trickier than I expected. Will continue tomorrow.

I would really like to get this done before flashing any other boards because it will be a failsafe mechanism to restore older firmware without constantly having to increment NVM version number.

 

[racermaster]

I spent a couple of hours trying to patch the EFI shell app to skip NVM version checking, but it is trickier than I expected. Will continue tomorrow.

The version check is done by the driver that implements the EFI_FIRMWARE_UPDATE_PROTOCOL for Thunderbolt NVM upgrades (CCF23F50-F7C1-4F00-8E70-13643C37E8B0). You can patch it out by making the following jump instruction unconditional:

875: 77 0f                         ja  0x886 <.text+0x626>
877: 48 bb 19 00 00 00 00 00 00 80 movabsq $-9223372036854775783, %rbx # imm = 0x8000000000000019 // EFI_INCOMPATIBLE_VERSION

Patched version:

875: eb 0f                         jmp 0x886 <.text+0x626>
877: 48 bb 19 00 00 00 00 00 00 80 movabsq $-9223372036854775783, %rbx # imm = 0x8000000000000019 // EFI_INCOMPATIBLE_VERSION

The offsets might differ depending on your BIOS version.

You can replace the original driver with UEFITool (with the old engine). I don't think EZ Flash will let you flash modified firmware, but it is possible to do so with USB BIOS Flashback.

 

[Elias64Fr]

Now is the time to bring out the heavy weapon ... Thunderbolt debug detailed log..

You can add the two following boot-args : tbdebug tblog=1

I use this terminal command to extract theses logs :
sudo log show --style syslog --last boot | grep Thunderbolt > LOG_Thunderbolt01.txt

I have attached my thunderbolt debug logs with a system sleep at time 09:35:26.40 and a Sleep call at 09:35:25.53

On this LOG file, you can see multiple initialisation phases :

----------------------------------------------------------------------
IOThunderboltSwitch<<private>>(0x0) - Phase 1 (Discover Switch) begin
----------------------------------------------------------------------
----------------------------------------------------------------------
IOThunderboltSwitch<<private>>(0x0) - Phase 2 (Discover Ports) begin
----------------------------------------------------------------------
----------------------------------------------------------------------
IOThunderboltSwitch<<private>>(0x0) - Phase 3 (Resolve Micros) begin
----------------------------------------------------------------------
...
----------------------------------------------------------------------
IOThunderboltSwitch<<private>>(0x0) - Phase 9 (Register New) begin
----------------------------------------------------------------------

 

[gandem]

Because the device tree is not named correctly in IOReg, my immediate suspicion falls to the SSDT. Let’s have a look at it.

Here you go.

 

[CaseySJ]

The version check is done by the driver that implements the EFI_FIRMWARE_UPDATE_PROTOCOL for Thunderbolt NVM upgrades (CCF23F50-F7C1-4F00-8E70-13643C37E8B0). You can patch it out by making the following jump instruction unconditional:

875: 77 0f                         ja  0x886 <.text+0x626>
877: 48 bb 19 00 00 00 00 00 00 80 movabsq $-9223372036854775783, %rbx # imm = 0x8000000000000019 // EFI_INCOMPATIBLE_VERSION

Patched version:

875: eb 0f                         jmp 0x886 <.text+0x626>
877: 48 bb 19 00 00 00 00 00 00 80 movabsq $-9223372036854775783, %rbx # imm = 0x8000000000000019 // EFI_INCOMPATIBLE_VERSION

The offsets might differ depending on your BIOS version.

You can replace the original driver with UEFITool (with the old engine). I don't think EZ Flash will let you flash modified firmware, but it is possible to do so with USB BIOS Flashback.

Awesome! I suspected as much after having mutilated all the compare and jump instructions one by one. I was hoping to avoid BIOS flashback, but for the purposes of downgrading NVM this approach seems reasonable.

 

[CaseySJ]

Here you go.

Please try this version in which PCI0 has been replaced with PC00.

 

[CaseySJ]

Now is the time to bring out the heavy weapon ... Thunderbolt debug detailed log..

You can add the two following boot-args : tbdebug tblog=1

I use this terminal command to extract theses logs :
sudo log show --style syslog --last boot | grep Thunderbolt > LOG_Thunderbolt01.txt

...

Is the ASRock Thunderbolt 4 card installed in your MSI Z490 system?

Is it easy to go back to standard DSDT and 'standard' OpenCore configuration? Might be good to see if this causes the same sleep issue that we're experiencing.

If it does, then we can examine the differences in an effort to isolate the root cause.