After getting the basics running I came across a few things:
- AppleLPC
SSDT-LPC included in the guide did not include my device-id as-is (0x9d4e, not sure about @bozma88) and adding it causes an warning issued from AppleLPC.kext on load
When comparing with the IORegistry from a MacBookPro14,1 it looks like AppleLPC.kext is not loading on a real MacBook. SSDT-LPC does not seem needed.
- Thunderbolt / USB-C
For me USB-C / Thunderbolt was not operational after going through the guide. After coming across @goodwin_c post about thunderbolt WMI and https://patchwork.kernel.org/patch/9941155/, I made the following small SSDT:
SSDT-TBFP.dsl:
Code:
DefinitionBlock("", "SSDT", 2, "hack", "TBFP", 0)
{
External(_SB.WTBT.TBFP, MethodObj)
Scope(_SB.WTBT)
{
Method(_DSM, 4)
{
TBFP(One)
Return (Buffer (One) { 0x00 })
}
}
Fix for kernel crash on bootup due to recursive ACPI:
Code:
<dict>
<key>Comment</key>
<string>Rename XTBT to YTBT</string>
<key>Disabled</key>
<false/>
<key>Find</key>
<data>
WFRCVFRCU0VDUEdO
</data>
<key>Replace</key>
<data>
WVRCVFRCU0VDUEdO
</data>
</dict>
This makes both the Thunderbolt and USB-C adapter show successfully when booting with a USB-C device is plugged in:
Additionally un-plugging & hot-plugging USB-C devices works fine. Sadly I do not have any Thunderbolt 3 devices to test with.
Staying with
@RehabMan logic of less is more, I believe the SSDT/DSDT changes should be as limited as possible.
For the USB / Thunderbolt devices to work you need to remove the DropTable xh_rvp07 and PtidDevc from the Clover config.plist allowing the tables to load.
I've been looking to do the following things which some of you might have experience with:
- If TBFP is indeed a solid method to keep the Thunderbolt Alpine Ridge controller enabled, write a IOWMIController driver interfacing with the Thunderbolt force-power guid 86CCFD48-205E-4A77-9C48-2021CBEDE341 to force on Thunderbolt in stead of the SSDT. Because of the WMI guid, this would be compatible across BIOS versions and brands irregardless of the ACPI device naming.
- Force _SB.PCI0.RP01.PXSX to be powered on even without a device in it through DSDT patches.
However in the DSDT code I can see the PCI memory space being read and the variable VDID used to check the vendor device ID against 0xFFFFFFFF (i.e. no device present), not sure what the best way to deal with this is.
Additionally there is a PowerResource defined at _SB.PCI0.RP01.PXSX.WRST, but I've never encountered PowerResource objects in ACPI before.
- Alternatively write a driver which attaches to _SB.PCI0.RP01.PXSX to manipulate the powerstate.
On certain MacBooks I've spotted the IOPowerManagement property "PowerOverrideOn", which could help with this.
Attached are the decompiled DSL files from BIOS 2.3.1 for reference. Ideas on the above on how to get the USB-C / Thunderbolt hub to show on initial boot without a device plugged in are welcome.
