- Nov 11, 2018
- Gigabyte Designare Z390
- RX 580
- Classic Mac
- Mobile Phone
I finally plan to test OpenCore because I'm intrigued by the inclusion of the DevicePath protocol. However, I wonder if that is different from DevicePathProperties. One of the obstacles for activating Thunderbolt Local Node and Thunderbolt Bus is the following:Hi CaseySJ,
Thank you for your reply.
Yes, I even used AptioMemoryFix.efi with Clover. I did not use AptioFixDrvFree2000, because one of the developers of AptioMemoryFix told me about it being "last resort", as it wasn't a good solution. I don't recall what the exact reason was for it. However, I remember the explanation to be quite technical. At that time AptioMemoryFix wasn't created. AptioMemoryFix is of course also focused on to fix the NVRAM issues people have had with the 100, 200 and 300 series boards. And if AptioMemoryFix.efi doesn't work alone, slide values can help with that. However, I'm not using any Slide argument.
Anyhow. To answer your question about Wifi+BT. I'm using an Apple WiFi card with BlueTooth. I disabled the motherboards onboard BT with uia_exclude=HS14 boot argument, as it was becoming a plague for pairing BT dependant HIDs.
- Apple's EFI firmware (BIOS) includes a large number of DXE Drivers. The drivers that we believe are instrumental in setting up Thunderbolt properly include, but may not be limited to, the following:
- The EFI firmware plays a crucial role in setting up or initializing various internal components such as the Thunderbolt controller.
- The EFI firmware sets up key parameters such as:
- These parameters are then passed to Apple's boot.efi, which starts macOS.
- So the Thunderbolt Kexts inside macOS do not set this up. They rely on these EfiDevicePathProperties to be passed in by the EFI Firmware.
- I am not sure whether the Clover Boot Loader includes the EFI protocol necessary for this type of handshake between Firmware and macOS.
- But the OpenCore source code includes the DevicePath protocol, which has me intrigued... Will this allow EfiDevicePathProperties created by the Firmware to be passed to the macOS kernel?
Edit (12 July 2019): After reading relevant parts of the UEFI Specification, I need to make some corrections:
- EFI Device Path protocol is standard; it's a fundamental part of the UEFI spec.
- Apple implements a custom AAPL,PathProperties protocol that is implemented in EfiDevicePathProperties.efi.
- Apple's ThunderboltNhi and ThunderboltXDomainDevice are EFI Boot Service drivers (SUBSYSTEM Type = 0x0B) instead of EFI Runtime Drivers. This means they are terminated sometime during the boot process. The macOS kexts no longer rely on them. But these EFI Boot Service drivers pass important Thunderbolt operating properties to the boot loader (via the custom AAPL,PathProperties protocol), which in turn passes them on to AppleACPIPlatform.kext for use by macOS.
- The EFI Boot Service drivers can initialize and configure the Thunderbolt controller, but the UEFI Spec requires the OS-level drivers to not make any assumptions, and to initialize and configure the controller by themselves.