Thunderbolt 4, modified firmware, Full Thunderbolt Bus tree

[Elias64Fr]

@CaseySJ
It's very curious that AppleThunderboltHAL (NHI) doesn't attach as device-id has been modified... 3 sec on looking what's wrong ... Oops, like done on all previous SSDT-Maple-Ridge, you have missed spoofed class-code to 0x88000 (00 80 08 00)

 

[etorix]

As in this modified SSDT (mind the '4')?

 

[CaseySJ]

@CaseySJ
It's very curious that AppleThunderboltHAL (NHI) doesn't attach as device-id has been modified... 3 sec on looking what's wrong ... Oops, like done on all previous SSDT-Maple-Ridge, you have missed spoofed class-code to 0x88000 (00 80 08 00)

Et voila!

This is Gigabyte GC-Maple Ridge in Gigabyte Z390 Designare motherboard running Sonoma 14.4.1.

Spoofing NHI0 device ID to 0x15EB is required. Thunderbolt Bus will not activate with Maple Ridge NHI0 device ID (0x1137). No other device ID spoofing is needed.

Setting class-code to 0x88000 is also required to enable Thunderbolt Bus.

 

[CaseySJ]

Some hot plug tests:

• Port 1: USB-C dock
• Port 2: Apple Thunderbolt to Gigabit Ethernet adapter

I should mention that Thunderbolt devices are currently hot plugging and unplugging reliably multiple times in a row.

But USB-C hubs will hot plug once, after which the XHC3 controller (in my screenshot) will not show HS01, HS02, SSP1, SSP2, and USB-C hub will not reconnect until system is rebooted.

 

[CaseySJ]

With @Elias64Fr's Maple Ridge Thunderbolt Bus solution, @joevt's updated ThunderboltUtil, and the looming possibility of using EFI shell app to flash modified firmware, it seems the stars are aligning once again….or at least the Sun, moon, and Earth.

Happy eclipse watching!

 

[etorix]

…if you rush to Québec or Vermont by Monday afternoon.

https://eclipsophile.com/

 

[CaseySJ]

…if you rush to Québec or Vermont by Monday afternoon.

https://eclipsophile.com/

I grew up in Buffalo. Didn’t realize it was going to pass right over the city! Too bad I’m not due to fly back there until May

They tell me classes have been canceled and students have been issued two pairs of eclipse glasses. Now that’s the spirit!!

 

[CaseySJ]

FYI, if we don't apply kernel patches shown in previous page of this thread, we get IOThunderboltSwitchUSB4 instead of IOThunderboltSwitchType6.

 

[CaseySJ]

Moving on to on-board Maple Ridge on my Asus Z690 ProArt Creator...

• Currently on BIOS 2004
• I have not disassembled the system yet (this will be tedious)
• I ran the command TbtNvmDrvShellUpdate.efi NVM.bin from OpenCore shell and got a message that the installed firmware is newer and therefore the operation cannot be performed
• The file NVM.bin contains NVM 31

• I'll boot into Linux to see which NVM version is currently installed

---

Just booted into Linux and I see that existing NVM is also 31. So that explains that...

One option would be to change 31 to 32, modify the three header bytes and also the DROM, then try flashing it with the same TbtNvmDrvShellUpdate.efi shell app...

 

[CaseySJ]

My understanding is that the signature check is done by the active firmware (the Linux documentation and osy's blog/tutorial seem to support this).

However, the firmware does allow downgrading. NVM firmware update support for Maple Ridge was missing in Linux but it can be enabled with a one-line patch (/sys/bus/thunderbolt/devices/0-0/nvm_non_active0/nvmem is missing without it). I was able to flash NVM 31 on my Z790-CREATOR which was previously running NVM 38. I haven't checked this, but I suspect ASUS added their own downgrade check in the driver that performs the firmware update (CCF23F50-F7C1-4F00-8E70-13643C37E8B0) and simply removed that check in BIOS 9901 for the Z690-CREATOR.

@racermaster,

The one-line change (to icm.c) is of course not included in the latest Linux kernel. Have you simply (if it can be called simple) compiled your own custom kernel?

Have you tried flashing a modified NVM firmware (without valid digital signature)?