0xFFFFFFFF. This is because most code that detects if a PCI device exists will read the PID register and check that it is NOT
0xFFFFFFFF. Effectively, the Ridge is cloaking itself when it is powered on without any devices attached. I can only speculate that it is for some weird compatibility reasons. For the PID to show up properly, the CPU uses a pair of undocumented registers in the PCI configuration space at offset
0x54C. It writes
0x54Cand then polls
0x548until bit 0 is set. According to the openboard UEFI source, these are mailbox registers for communicating with the Ridge host controller. The NUC's ACPI code will do this handshake automatically on init through a method called
OSUP. This OSUP command seems to be a way for the CPU to indicate to the Ridge that it is out of BIOS/DXE mode and is in the OS proper and therefore is safe for it to come out and declare its PID to the world.
ICMSACPI method dumped from an iMac for setting up ICM on Bootcamp. By replicating the
ICMSACPI method and masking out the
REG_FW_STS_ICM_EN_CPUflag, we can disable the ICM firmware.
MODUto return the current cable state.
RTPCto signal that it is ready to be turned off. Then it enters D3 PCI power state and waits.
MUSTis invoked whenever the cable plug state changes. This change will be reported by
MODUwhen the XHCI driver queries it. The NHI driver calls its own
RTPCwhen it is ready to be turned off and then it also enters D3.
_PSxACPI method (
xis the state number). In the
_PS3handler for the port where the Ridge attaches to, if it detects that
RTPCwas called for both XHCI and NHI, then it will power off the Ridge. If any device needs to wake up, then OSX would first have to wake up the PCI bridge to D0 and call
_PS0, which can re-assert the force power.
_PS0is called, everything below it is still in D3 state. Therefore, we can set a flag indicating that we need to reset ICM as soon as the NHI device is up. Then in the NHI's
_PS0handler, we do the actual ICM reset.