Probably. There are three drivers listed in the info.plist:
- AppleThunderboltHAL (for NHI types 1,2,3 Thunderbolt 1,2,3 discrete controllers)
- AppleThunderboltHALType4 (for NHI type 4 Ice Lake Thunderbolt 3 integrated controller)
- AppleThunderboltHALType5 (for NHI type 5 Apple Silicon USB4/Thunderbolt integrated controller)
Those are sub classes of a common parent class (use
ioreg -iw0 ):
- AppleThunderboltGenericHAL:AppleThunderboltIntelPCIHAL:AppleThunderboltHAL
- AppleThunderboltGenericHAL:AppleThunderboltHALType4
- AppleThunderboltGenericHAL:AppleThunderboltHALType5
Those classes create a child device for the NHI driver:
- IOThunderboltNHI:AppleThunderboltNHI:AppleThunderboltNHIIntelPCI:AppleThunderboltNHIType1
- IOThunderboltNHI:AppleThunderboltNHI:AppleThunderboltNHIIntelPCI:AppleThunderboltNHIType2
- IOThunderboltNHI:AppleThunderboltNHI:AppleThunderboltNHIIntelPCI:AppleThunderboltNHIType3
- IOThunderboltNHI:AppleThunderboltNHI:AppleThunderboltNHIIntelPCI:AppleThunderboltNHIType4
- IOThunderboltNHI:AppleThunderboltNHI:AppleThunderboltNHIType5
And there's a child of those:
- IOThunderboltController (Thunderbolt 1,2,3 discrete controllers)
- IOThunderboltController:IOThunderboltControllerType5 (Apple Silicon USB4/Thunderbolt integrated controller)
Instead of trying to squeeze one of those HAL's onto Maple Ridge, I think it would be better to make a sub class of those three drivers for Maple Ridge and then customize:
- AppleThunderboltGenericHAL:???:AppleThunderboltHALTypeHackUSB4
- IOThunderboltNHI:AppleThunderboltNHI:???:AppleThunderboltNHITypeHackUSB4
- IOThunderboltController:???:IOThunderboltControllerHackUSB4
You have to decide what the parent ??? class should be. In your current tests, it would be the Type4 classes. It should be a simple task to get the vtables (I have a Hopper script to generate those). And the constructors will tell you how big the class is so your sub class can reserve enough space for that.
Other things to include (NHIType5 has its own subclass of these so NHITypeHackUSB4 will probably also need a subclass - these are for probably for Thunderbolt IP and Thunderbolt Target Disk Mode and Thunderbolt Target Display Mode):
- AppleThunderboltNHITransmitRingManager
- AppleThunderboltNHITransmitRing
- AppleThunderboltNHIReceiveRingManager
- AppleThunderboltNHIReceiveRing
Other kexts may have classes that need a sub class.
- AppleThunderbolttDPInAdapter (has a type 5 variant)
- AppleThunderbolttDPOutAdapter (has a type 5 variant)
- AppleThunderboltPCIDownAdapter (has a type 5 variant)
- IOThunderboltConnectionManager (has a type 5 variant)
- IOThunderboltSwitch (has variants for type 1,2,3,4,5)
In any case, TypeHackUSB4 can't use any of the Type5 classes as a parent since those are compiled only for Apple Silicon.
Probably Maple Ridge has registers based on USB4 spec since the class code 0x0c0340 is from USB4 spec. You can read the USB4 spec. There's a document Alpine-Ridge_DP_1.03.pdf with all the discrete Thunderbolt registers (at least up to Alpine Ridge). Linux and UEFI drivers will list some of the registers.
https://github.com/tianocore/edk2-platforms
https://github.com/torvalds/linux/tree/master/drivers/thunderbolt
The AppleThunderboltNHI binary is a fat binary containing an x86 and an ARM image. Use the
file command to get a list of architectures that the binary contains.
The Hopper Disassembler lets you choose what architecture to disassemble. The ARM image only includes code for Type5 (plus the base classes of course). The x86 image does not include Type5.
You can also see the same thing with the
strings -arch arm64e and
strings -arch x86_64 commands.
So the EFI driver shares a lot of code like the kext drivers. But it doesn't mean the EFI driver or the kext driver covers the Maple Ridge case.
In the EFI driver, you can do stuff like this:
Code:
integrated = (productID == IceLake).
if (integrated) {
do integrated stuff with integrated registers.
} else {
do discrete stuff with discrete registers.
}
In the kext driver, to handle the differences in the controllers, sub classes are used to override a base class.
In the case of Maple Ridge, other changes probably need to be added:
Code:
if (integrated thunderbolt) {
do integrated stuff with integrated registers.
} else if (discrete thunderbolt) {
do discrete stuff with discrete registers.
} else if (usb4) {
do usb4 stuff with usb4 registers.
}
You can see some integrated and discrete Thunderbolt UEFI code at
https://github.com/tianocore/edk2-platforms . I haven't seen USB4 UEFI code yet.
For checking UEFI, I would run the attached
do_all.nsh script in the UEFI Shell to get all the drivers and devices and handles. It should show how the Maple Ridge is handled.
Code:
fs0:
mkdir do_all_test1
cd do_all_test1
..\do_all.nsh
This rom was discussed back in
#146
I believe it's a full rom but it's larger than it should be. Is that the size of the rom chip or does the rom reader just assume the size?
@vipermachine got his ROM from linux but it did not get the entire thing. I believe a newer linux kernel will read the Maple Ridge ROM properly now. I attached mine (note Linux doesn't include the 16K header of the ROM which determines if the active or inactive part is used - Linux only includes the part that you ask for - active in my case).
Code:
0x01) UID: 0x80871F7645FDBC00
0x0d) Version: 1 // TBT3
0x10) TBT3-Vendor ID: 0x31
0x12) TBT3-Device ID: 0x5013
0x14) TBT3-Model Revision: 0x1
0x15) TBT3-NVM Revision: 24
0x16) 1: 800280000000
0x1e) 2: 900180000000
0x26) 3: 800480010000
0x2e) 4: 900380010000
0x36) 5: 000000 // DP { Preferred Lane Adapter:0, Preference Valid:0 }
0x3b) 6: 500000
0x40) - 7:
0x42) 8: 200100640000000000
0x4d) 9: 80 // TBT3-PCIe Downstream Adapter xx:04.0
0x50) A: 500000
0x55) B: 500000
0x5a) 1: "ASUS" // ASCII Vendor Name
0x61) 2: "THUNDERBOLTEX 4" // ASCII Model Name
0x73) 9: 10044310f68724240000000001 // Product Descriptor { USB Spec:4.1.0, Vendor ID:0x1043, Product ID:0x87f6, Product FW Revision:24.2.4, TID:0x00000000, Product HW Revision:1 }
0x82) End
