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 0xD
to register 0x54C
and then polls 0x548
until 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.ICMS
ACPI method dumped from an iMac for setting up ICM on Bootcamp. By replicating the ICMS
ACPI method and masking out the REG_FW_STS_ICM_EN_CPU
flag, we can disable the ICM firmware.MODU
to return the current cable state.RTPC
to signal that it is ready to be turned off. Then it enters D3 PCI power state and waits.MUST
is invoked whenever the cable plug state changes. This change will be reported by MODU
when the XHCI driver queries it. The NHI driver calls its own RTPC
when it is ready to be turned off and then it also enters D3._PSx
ACPI method (x
is the state number). In the _PS3
handler for the port where the Ridge attaches to, if it detects that RTPC
was 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._PS0
is 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 _PS0
handler, we do the actual ICM reset.