最新版FakePCIID

## FakePCIID.kext The purpose of this kext is to attach to any IOPCIDevice so it can provide alternate PCI ID when another driver attached to the same device requests them. This technique can be used instead of patching binaries that may check for supported device-ids (or other PCI IDs) in their IOService::probe or IOService::start method. In order to attach FakePCIID to a given IOPCIDevice, an injector kext must be built that IOKit can use to match against. The FakePCIID.kext Info.plist has no built-in IOKitPersonalities, as it is generic and not built to suit a specific purpose. The distribution ZIP provide has four such injector kexts, which are described below. Custom injector kexts can be created for other devices. Note: FakePCIID_Intel_HD_Graphics.kext works for HD4400 mobile, HD4600 mobile, HD4200 mobile, and HD4600 desktop. In any case, a DSDT patch, FakeID configuration (Clover), or FakeProperties dictionary in the injector's Info.plist will be required to inject the properties that FakePCIID can read on the IOPCIDevice. The properties used by FakePCIID are described later in this post. The properties must be present on the PCIDevice that is being hooked (the direct parent of FakePCIID). ### Downloads: Downloads are available on Bitbucket: https://bitbucket.org/RehabMan/os-x-fake-pci-id/downloads/ ### How to Install In all cases, FakePCIID.kext must be installed with a kext installer (such as Kext Wizard). The Release build should be used for normal installs. It has a minimum of output to system.log. For troubleshooting, the Debug build can be used. The separate folder 'injectors' in the distribution zip contains two extra codeless kexts: - AppleIntelKBLGraphicsFramebufferInjector_3e9x.kext: Used for spoofing unsupported CoffeeLake as KabyLake - BroadcomWiFiInjector.kext: Used to load the native Broadcom WiFi kexts for unsupported devices. To be used with AirportBrcmFixup.kext as replacement for FakePCIID_Broadcom_WiFi.kext (both will work, but with AirportBrcmFixup.kext, full functionality of FakePCIID.kext is not needed) In order to cause the kext to be loaded against a particular device, you must also install the appropriate FakePCIID injector kext. Currently, seven injectors are provided: - FakePCIID_Intel_HD_Graphics.kext (formerly FakePCIID_HD4600_HD4400.kext): This kext will attach to `8086:0412`, `8086:0416`, `8086:0a1e`, `8086:041e`, `8086:0a16`, `8086:041a`, `8086:016a`, `8086:191d`, `8086:162a`, `8086:5917`, `8086:3e91`, `8086:3e92`, `8086:1626`, `8086:1616` - `8086:0412` is HD4600 desktop (now the only GT2 device supported in Yosemite as of 10.10.2) - `8086:0a16` is HD4400 mobile. - `8086:0416` is HD4600 mobile. - `8086:0a1e` is HD4200 mobile. - `8086:041e` is HD4400 desktop. - `8086:041a` is P4600 server. - `8086:016a` is P4000 server. - `8086:191d` is P530 server. - `8086:162a` is P6300 server. - `8086:1616` is HD5500. Some CPUs (i3-5005U for example), must spoof as 0x1626 to avoid hang at boot - `8086:5917` is HD620 KabyLake-R. - `8086:3e91` is UHD630 CoffeLake (typical 3e91 with i3 or other low-end CPUs) For HD4600, normally fake device-id of `8086:0412` will be injected for Yosemite, as Yosemite does not natively recognize `8086:0416`. `8086:0412` is the native device-id for HD4600 desktop. By injecting `0412`, `AppleIntelFramebufferAzul` and `AppleIntelHD5000Graphics` will load. And since, FakePCIID will also be attached to these devices, it will successfully fool both kexts that the device an Intel HD4600 Desktop IGPU (0412). For P4000 support, inject device-id 0166 (HD4000). For P530 support, inject device-id 1912 (HD530). For P6300 support, inject device-id 1622 (HD6200) For HD620 KabyLake-R, inject device-id 5916 (HD620) For UHD630 CoffeeLake, inject device-id 3e92 (UHD630) - FakePCIID_Intel_HDMI_Audio.kext: This kext will attach to `8086:0c0c`, `8086:9d70`, `8086:9d71`, `8086:9d74`, `8086:a170`, `8086:a171`, `8086:a2f0`, `8086:a348`, or `8086:9dc8` The purpose is to provide support for unsupported HDAU (native B0D3) or unsuppored HDEF (100-series, 200-series, 300-series) ) devices which provide HDMI-audio on Haswell(+) systems. `8086:0c0c` is one such unsupported ID. The other two `8086:0d0c`, and `8086:0a0c` are supported. This kext, AppleHDAController, loads by PCI class, so you normally would not inject device-id for it, but to allow FakePCIID to work, you may need to inject RM,device-id (one of the supported IDs). By default for Haswell HDAU, the kext injects RM,device-id=<0c 0a 00 00> (0x0a0c). For 100-series and later HDEF, the kext injects RM,device-id=<70 a1 00 00> or <70 9d 00 00> depending on HDEF device-id (refer to the Info.plist). You can override it with a DSDT edit or ACPI injection via SSDT. For example (_DSM patch for HDAU device for FakePCIID and HDMI audio, if you wanted 0x0d0c instead of 0x0a0c): ```c into method label _DSM parent_adr 0x00030000 remove_entry; into device name_adr 0x00030000 insert begin Method (_DSM, 4, NotSerialized)\n {\n If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }\n Return (Package()\n {\n "RM,device-id", Buffer() { 0x0c, 0x0d, 0x00, 0x00 },\n "hda-gfx", Buffer() { "onboard-1" },\n })\n }\n end; ``` In the case of Skylake 8086:9d70 or 8086:1a70, it is attaching to the HDEF device (usually called HDAS, but renamed to HDEF to match what Aple expects). Skylake HDMI/DP audio codec is on HDEF along with onboard audio. It injects RM,device-id=<70 a1 00 00> for 0x9d70 and RM,device-id=<70 9d 00 00> for 0xa170. In other words, with these two device-ids, it will reverse them. Try it if you have everything set correctly for HDMI/DP audio, but it is not working. This was discovered by noting that Skylake HDMI audio works on the NUC6i7KYK (Skull Canyon), but not the other NUC6 devices. It is quite system dependent. Some computers need them swapped, others do not. So test both with and without. This kext won't fix other problems/mistakes you may have with your HDMI/DP setup (eg. missing "hda-gfx", mismatched "layout-id" injection, incorrect or wrong framebuffer patches, or missing ACPI renames). - FakePCIID_AR9280_as_AR946x: This kext will attach to `168c:0034` or `168c:002a`. This particular application of FakePCIID.kext is used in a situation where you have an AR9280 re-branded as some other device. For example, with the Lenovo u430, it is useful to rebrand an AR9280 ias an AR946x as that device is allowed by the BIOS whitelist where AR9280 is not. By using FakePCIID, we can remap the PCI IDs back to AR9280 (`168c:002a`) even though the device itself is reporting `168c:0034`. - FakePCIID_Broadcom_WiFi.kext (formerly FakePCIID_BCM94352Z_as_BCM94360CS2.kext) This kext will attach to `14e4:43b1`, `14e4:4357`, `14e4:4331`, `14e4:4353`, `14e4:432b`, `14e4:43ba`, `14e4:43a3`, or `14e4:43a0`. And also `106b:4e`, `14e4:4312`, `14e4:4313`, `14e4:4318`, `14e4:4319`, `14e4:431a`, `14e4:4320`, `14e4:4324`, `14e4:4325`, `14e4:4328`, `14e4:432c`, `14e4:432d`. Originally created for BCM94352Z, this particular application of FakePCIID.kext is used to emulate an authentic Apple Airport Extreme, when using a variety of supported Broadcom WiFi devices. - FakePCIID_BCM57XX_as_BCM57765.kext: This kext will attach to numerous unsupported BCM57XX Ethernet devices in order to make the native drivers work for a wider variety of BCM Ethernet chipsets that are compatible, but not supported due to probe testing of PCI device-id/subdevice-id values. Further details here: http://www.tonymacx86.com/network/155984-fakepciid-broadcom-bcm57xx-network-oob.html - FakePCIID_Intel_GbX.kext: This kext will attach to a number of Intel Ethernet devices in an attempt to make the Small Tree drivers for Intel chipset based cards work. Further details here: http://www.tonymacx86.com/network/156135-intel-network-adapters-os-x-small-tree-drivers.html