@CaseySJ I had an interesting experience with thunderbolt today. For the hell of it I copied the thunderbolt Device Properties from an iMac 19,2 dump to my EFI and changed the the PCI path to my EX3 card location.
Previous behavior with DTDG+TBTHotplug: IOReg showed our desired DSB0, DSB1, etc... setup. No hot plug. If I restarted my UAD Apollo I would need to shut down, unplug, turn on, replug power, boot.
Behavior with this device property: No hot plug. But if I restart it reconnects. Not sure if this is a path you've already been or is helpful but I figured I'd drop it here and also on the Hot Plug Thread.
Nice to see the initiative!
I am still a bit skeptical about manually injecting device properties that are supposed to be injected by Apple's EFI driver (ThunderboltNHI.efi). Let's look at this:
We can disassemble the
ThunderboltNHI.efi driver using any of several disassemblers such as
Hopper. We can see that the binary EFI file is separated into code segments and text segments (just like any other binary executable file). If we look at the text segments (the green section of the horizontal bar along the top) look what we find:
- tbt-scc-offset
- tbt-options
- pathcrumbsv2
- pathcr
- sccOffset
- ThunderboltDROM
- ThunderboltUUID
- TBTDPLowToHigh
- And a few others...
Your
plist file is inserting the ones boldfaced above. The disassembler also produces both assembly code and C-like pseudo-code. The pseudo-code is still difficult to read, but better than nothing. Here's an example of the pseudo-code for a subroutine (or function) that injects
ThunderboltDROM,
ThunderboltUUID, and
TBTDPLowToHigh:
While some of these properties are simple data types (such as
ThunderboltUUID and
TBTDPLowToHigh), others are arrays of hex values such as
ThunderboltDROM, pathcr, and
pathcrumbsv2. The values in these arrays may not be conducive to a simple copy-and-paste.
This is just the EFI side of the equation. The other side consists of the various ACPI methods and objects in the Thunderbolt SSDT that we are unable to duplicate because our DSDT does not contain equivalencies. For example, on a MacBook Air 7,1 with Falcon Ridge Thunderbolt 2 controller, the native Thunderbolt-on-PCI SSDT references a number of GPIO registers that simply don't exist in the DSDT of the Asus X99 Deluxe II. We could try to fake them, but it's not that simple because each GPIO on a real Mac is physically tied to a circuit element, and we would have to determine if those circuit elements also exist on our motherboard and where to find them in the ACPI structure.
All of this might sound discouraging, but it is also a nice challenge. And we can make stepwise progress rather than an all-or-nothing outcome. For example, I've been able to port a subset of the ACPI methods related to Thunderbolt Power Conservation, and the boot log confirms that power conservation is enabled. I've also attempted to port huge chunks of the SSDT, but with very mixed results. A proper solution, I believe, involves both (a) EFI drivers, and (b) ACPI methods/objects.
