Contribute
Register

Thunderbolt 4, modified firmware, Full Thunderbolt Bus tree

Hmm, I wonder if it's the firmware of your ASRock card. I'll try flashing that soon.
Alas that did not help.

With ASRock firmware flashed to GC-Maple Ridge, Thunderbolt and USB-C devices connect and work. But system enters sleep for 2 seconds then spins up (in dark wake) until key is pressed.

Screenshot 2024-04-07 at 2.23.33 PM.png
Screenshot 2024-04-07 at 2.23.19 PM.png
 
Now is the time to bring out the heavy weapon ... Thunderbolt debug detailed log.. :rolleyes:

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
----------------------------------------------------------------------
Here are some results of the Thunderbolt debug log.

Test Conditions:
  • Tests performed on Gigabyte Z390 Designare
  • macOS 14.5 public beta
  • On-board Titan Ridge controller disabled in BIOS
  • GC-Maple Ridge flashed with ASROCK NVM 28 firmware from Post 1
If we search for IOPlatformSleepAction -> AppleThunderboltHAL to signal the start of sleep process, we find that both log files are mostly the same, except for the last part. The differences in the last part are interesting, so I've extracted them below.

(IOThunderboltFamily) 79343602us IOThunderboltDispatchQueue<<private>>::stop
(IOThunderboltFamily) 79343622us IOThunderboltControlPath<<private>>::sleep
(IOThunderboltFamily) 79343624us IOThunderboltControlPath<<private>>::stop
(IOThunderboltFamily) 79343625us IOThunderboltReceiveQueue(0)::stop
(IOThunderboltFamily) 79343732us IOThunderboltTransmitQueue(0)::stop
(IOThunderboltFamily) 79343777us IOThunderboltController(0)::lateSleep - return - fIsAsleep = 1
(IOThunderboltFamily) 79343780us IOThunderboltSwitch<<private>>(0x0)::needsEarlyWake - fMaxPortNumber = 13
(AppleThunderboltDPInAdapter) 79343785us AppleThunderboltDPInAdapter<<private>>::needsEarlyWake - needs_early_wake = 0
(IOThunderboltFamily) 79343787us IOThunderboltSwitch<<private>>(0x0)::needsEarlyWake - port = <private> port number = 5 needs early wake = 0
(AppleThunderboltDPInAdapter) 79343790us AppleThunderboltDPInAdapter<<private>>::needsEarlyWake - needs_early_wake = 0
(IOThunderboltFamily) 79343792us IOThunderboltSwitch<<private>>(0x0)::needsEarlyWake - port = <private> port number = 6 needs early wake = 0
(IOThunderboltFamily) 79343796us IOThunderboltSwitch<<private>>(0x0)::needsEarlyWake - port = <private> port number = 8 needs early wake = 0
(IOThunderboltFamily) 79343799us IOThunderboltSwitch<<private>>(0x0)::needsEarlyWake - port = <private> port number = 9 needs early wake = 0
(AppleThunderboltDPOutAdapter) 79343802us AppleThunderboltDPOutAdapter<<private>>::needsEarlyWake - fReactivateOnWake = 0
(IOThunderboltFamily) 79343804us IOThunderboltSwitch<<private>>(0x0)::needsEarlyWake - port = <private> port number = 10 needs early wake = 0
(AppleThunderboltDPOutAdapter) 79343806us AppleThunderboltDPOutAdapter<<private>>::needsEarlyWake - fReactivateOnWake = 0
(IOThunderboltFamily) 79343808us IOThunderboltSwitch<<private>>(0x0)::needsEarlyWake - port = <private> port number = 11 needs early wake = 0
(AppleThunderboltNHI) 79343812us AppleThunderboltGenericHAL::disableMMIOAccess - enable = 1
(AppleThunderboltNHI) 79343814us AppleThunderboltIntelPCIHAL::mmioWorkaround - fMMIOReadCount = 26544
(AppleThunderboltNHI) 79343816us AppleThunderboltNHI::disableMMIOAccess - before fPCIProvider->protectDevice( kIOPCIConfigSpace, VM_PROT_NONE )
(AppleThunderboltNHI) 79343818us AppleThunderboltNHI::disableMMIOAccess - after fPCIProvider->protectDevice( kIOPCIConfigSpace, VM_PROT_NONE )
(AppleThunderboltNHI) 79343825us AppleThunderboltNHIType3::lateSleep - SXFP status = 0xe00002bc
(AppleThunderboltNHI) 79343827us AppleThunderboltNHIType3::waitForOk2Go2Sx
(AppleThunderboltNHI) 79343830us AppleThunderboltNHIType3::waitForOk2Go2Sx - ok2go2sx done, retries = 0
(AppleThunderboltNHI) 79343832us AppleThunderboltNHIType3::waitForOk2Go2Sx - offset = 0x54c write value 0x00000000
(AppleThunderboltNHI) 79343835us AppleThunderboltNHIType3::waitForOk2Go2Sx - retries = 0
(AppleThunderboltNHI) AppleThunderboltNHIType3::waitForOk2Go2Sx - retries = 0
(AppleThunderboltNHI) 79343838us AppleThunderboltNHIType3::platformReset - enable = 1
(AppleThunderboltNHI) 79343840us AppleThunderboltGenericHAL::lateSleep - complete - took 854 milliseconds
(AppleThunderboltNHI) AppleThunderboltGenericHAL::lateSleep - complete - took 854 milliseconds
IOPlatformWakeAction -> AppleThunderboltHAL
(AppleThunderboltNHI) 79359201us AppleThunderboltGenericHAL<<private>>::callPlatformFunction - early wake done

(IOThunderboltFamily) 304730174us IOThunderboltDispatchQueue<<private>>::stop
(IOThunderboltFamily) 304730175us IOThunderboltControlPath<<private>>::sleep
(IOThunderboltFamily) 304730176us IOThunderboltControlPath<<private>>::stop
(IOThunderboltFamily) 304730177us IOThunderboltReceiveQueue(0)::stop
(IOThunderboltFamily) 304730257us IOThunderboltTransmitQueue(0)::stop
(IOThunderboltFamily) 304730313us IOThunderboltController(0)::lateSleep - return - fIsAsleep = 1
(IOThunderboltFamily) 304730315us IOThunderboltSwitchType6(0x0)::needsEarlyWake - always perform early wake scan
(AppleThunderboltNHI) 304730317us AppleThunderboltGenericHAL::disableMMIOAccess - enable = 1
(AppleThunderboltNHI) 304730318us AppleThunderboltIntelPCIHAL::mmioWorkaround - fMMIOReadCount = 26668
(AppleThunderboltNHI) 304730320us AppleThunderboltNHI::disableMMIOAccess - before fPCIProvider->protectDevice( kIOPCIConfigSpace, VM_PROT_NONE )
(AppleThunderboltNHI) 304730322us AppleThunderboltNHI::disableMMIOAccess - after fPCIProvider->protectDevice( kIOPCIConfigSpace, VM_PROT_NONE )
(AppleThunderboltNHI) 304730329us AppleThunderboltNHIType3::lateSleep - SXFP status = 0xe00002bc
(AppleThunderboltNHI) 304730331us AppleThunderboltNHIType3::waitForOk2Go2Sx
(AppleThunderboltNHI) 304730338us AppleThunderboltNHIType3::waitForOk2Go2Sx - ok2go2sx done, retries = 0
(AppleThunderboltNHI) 304730339us AppleThunderboltNHIType3::waitForOk2Go2Sx - offset = 0x54c write value 0x00000000
(AppleThunderboltNHI) 304730342us AppleThunderboltNHIType3::waitForOk2Go2Sx - retries = 0
(AppleThunderboltNHI) AppleThunderboltNHIType3::waitForOk2Go2Sx - retries = 0
(AppleThunderboltNHI) 304730344us AppleThunderboltNHIType3::platformReset - enable = 1
(AppleThunderboltNHI) 304730346us AppleThunderboltGenericHAL::lateSleep - complete - took 855 milliseconds
(AppleThunderboltNHI) AppleThunderboltGenericHAL::lateSleep - complete - took 855 milliseconds
IOPlatformWakeAction -> AppleThunderboltHAL
(AppleThunderboltNHI) 307193965us AppleThunderboltGenericHAL<<private>>::callPlatformFunction - early wake done
 

Attachments

  • tblog-3.txt.zip
    45.5 KB · Views: 2
Last edited:
** It is done and it works **

So I threw caution to the wind and pushed the button...(must follow on-screen warning to disconnect all Thunderbolt devices before flashing).

May I present... Maple Ridge Thunderbolt Local Node on built-in controller of Asus Z690 ProArt Creator. No external flasher needed!
  • macOS Sonoma 14.5 public beta
  • Asus ProArt Z690 Creator WiFi
  • On-board Maple Ridge controller
The shell command TbtNvmDrvShellUpdate.efi does not check for valid digital signature!
View attachment 581092View attachment 581093View attachment 581094

OMG! Is it possible to enable TH Bus on Gigabyte Z690 Aero D with built-in thunderbolt? I offer to do any necessary tests
 
OMG! Is it possible to enable TH Bus on Gigabyte Z690 Aero D with built-in thunderbolt? I offer to do any necessary tests
Some questions and comments:
  • You raise a good question, one that came up a couple days ago in an earlier post in this thread
  • If you have done a few BIOS updates on this board, have you ever seen a message stating that Thunderbolt firmware is being upgraded?
  • We could examine a BIOS file for this board
  • If Gigabyte BIOS does not upgrade Thunderbolt firmware, the question then is whether the EFI drivers and application from Asus BIOS could be injected into non-Asus boards and whether this would work…
But right now we are faced with a potentially serious problem: The inability of all flashed systems (except Elias’ :)) to sleep.
 
If you have done a few BIOS updates on this board, have you ever seen a message stating that Thunderbolt firmware is being upgraded?
I'm using the latest BIOS F28. Never seen any message or alert about Thunderbolt being upgraded.
Let me know about any testing needed, I'll follow the thread closely.

But right now we are faced with a potentially serious problem: The inability of all flashed systems (except Elias’ :)) to sleep.

I'm sure you guys can figure it out.
 
But system enters sleep for 2 seconds then spins up (in dark wake) until key is pressed.
Hi @CaseySJ
have you tried waiting system switching from DarkWake to Sleep or something else ? 1mn, 5mn, 10mn ?

(IOThunderboltFamily) 304730315us IOThunderboltSwitchType6(0x0)::needsEarlyWake - always perform early wake scan
I have inspected disassembled code... nothing interesting about this message.. When I made thunderbolt LOG, I was on SwitchOS not on SwitchType6.
 
Last edited:
Hi @CaseySJ
have you tried waiting system switching from DarkWake to Sleep or something else ? 1mn, 5mn, 10mn ?
Yes, it just cycles from dark wake to sleep then back to dark wake.

However, I just disabled the Thunderbolt SSDT and now the system sleeps normally. I can create a minimal SSDT, see if sleep still works, then keep adding more content to it until sleep breaks.
 
@CaseySJ @gandem
I have attached GC-Maple Ridge firmware with port@C & port@D enabled (2 Downstream USB4 ports)... like on my firmware.. We could have another behaviour on Sleep ?!
 

Attachments

  • GC-MapleRidge-modified_C_D_enabled.zip
    225.2 KB · Views: 15
Yes, it just cycles from dark wake to sleep then back to dark wake.

However, I just disabled the Thunderbolt SSDT and now the system sleeps normally.
Without SSDT we do not have attached kext drivers for NHI... That mean Sleep issue is under this device, not on XHC3 :)

I can create a minimal SSDT, see if sleep still works, then keep adding more content to it until sleep breaks
Good idea.. minimal mean at least thunderbolt property on UPSB & device-id/class-code/TBTFlags properties on NHI.

You also can try moving TBTFlags from 0x8 to 0xF.
 
Back
Top