Hervé

No idea. Are you sure you don't have a NullCPUPowerManagement lying around somewhere?

Should be Ok; those FakeSMC keys you've used are unusual for a MBP9,2 but should not cause any harm.

AR9565 has poor support under OS X/macOS. It's not the best choice, far from it. Details and info about other cards here.

Generate your CPU-specific power management SSDT. https://github.com/Piker-Alpha/ssdtPRGen.sh

We can't do much for a system that has a locked BIOS. You'll have to unlock it somehow... The only other alternative is using you internal disk on another machine, then tune the installation to your own system's specs. It'll be painful.

To install OS X or macOS on an MBR partition, one need to apply the MBR patch. You can look it up and check if it remains the same for High Sierra; I would assume so.

Forget the OSBundleLibraries part. This was mentioned alongside CFBundleIdentifier in order to highlight differences in kexts between 2 x versions of OS X in terms of kext name. These are just 2 x sections of kext Info.plist file where the kext name is clearly & directly referred. Now, I've never possessed such card, so no way for me to test a patch or confirm if Skvo's Yosemite patch still works in newer OS X/macOS versions. You'd have to try and contact him direct but he's not been around for over a year now... Or send me a card to test. All I can say now is this: if you see your card under the USB tree, it's a good start; at least the card is detected by the OS. you have to patch your 10.13 CellPhoneHelper kext (or add the patch to FakeSMC) according to a manner similar to what Skvo did for Yosemite but adjusted for High Sierra's own kext. once you've added your patch, you have to repair kexts permissions and rebuild your cache, then reboot. you have to initialise the card in QMI mode through AT commands, as described in Skvo's thread (linked above). Building on Skvo's original patch, I would say that the patch for High Sierra is as follows (within a IOKitPersonalities section, either in CellPhoneHelper or in FakeSMC): <key>0x0413c/0x81b1 DW5809e (Sierra Wireless EM7305) 4G/LTE Modem</key> <dict> <key>CFBundleIdentifier</key> <string>com.apple.driver.AppleUSBHostMergeProperties</string> <key>IOClass</key> <string>AppleUSBHostMergeProperties</string> <key>IOProviderClass</key> <string>IOUSBHostDevice</string> <key>IOProviderMergeProperties</key> <dict> <key>DeviceModemOverrides</key> <dict> <key>ConnectionPersonality</key> <string>Sierra GSM Personality</string> <key>ConnectionScript</key> <string>WWAN.ccl</string> <key>DeviceContextID</key> <string>1</string> <key>DeviceModel</key> <string>GSM</string> <key>DeviceVendor</key> <string>Sierra Wireless</string> </dict> <key>DevicePPPOverrides</key> <dict> <key>LCPMTU</key> <integer>1450</integer> </dict> <key>InfoCommands</key> <dict> <key>ATCommands</key> <dict> <key>DirectoryNumber</key> <string>+cnum</string> <key>IMEI</key> <string>+cgsn</string> <key>IMSI</key> <string>+cimi</string> <key>Manufacturer</key> <string>+cgmi</string> <key>Model</key> <string>+cgmm</string> <key>ModemSW</key> <string>+cgmr</string> <key>Serial#</key> <string>+gsn</string> </dict> <key>HiddenProperties</key> <dict> <key>CommandPortBaseName</key> <string>wwan</string> <key>ControlPortBaseName</key> <string>wwan</string> <key>DataPortBaseName</key> <string>wwan</string> <key>StatusType</key> <string>CellPhoneGSM</string> </dict> </dict> <key>Initializing</key> <true/> <key>InterfaceMapping</key> <dict> <key>0</key> <integer>wwanDM</integer> <key>2</key> <integer>wwanGPS</integer> <key>3</key> <integer>wwan</integer> </dict> <key>WWAN</key> <true/> </dict> <key>bcdDevice</key> <integer>6</integer> <key>idProduct</key> <integer>33201</integer> <key>idVendor</key> <integer>16700</integer> </dict> But, as stated above, I've no hardware and no way to verify this. You'll have to do the hard work... Sorry. In case you ask, you set the card's USB composition to QMI mode through a direct (serial) connection through Terminal or putty and by issuing the relevant AT command. In Skvo's example, QMI mode is set when USBCOMP(osition)=6. You therefore have to issue the AT command that sets this: at!udusbcomp=n where n is the value that corresponds to QMI mode (6 in Skvo's example). To check the active mode, issue the AT command at!udusbcomp?. To check the possible values applicable to the command, type at!udusbcomp=?. According to the literature I read, you should begin your card settings session by the commands atz (good old modem reset to default profile) and at!entercnd="A710" before anything else. Once you've set the QMI mode, reset the card through an at!reset command. https://techship.com/faq/category/cellular-modules-sierra-wireless/ http://www.embeddedpi.com/documentation/3g-4g-modems/raspberry-pi-sierra-wireless-mc7304-modem-qmi-interface-setup https://www.computerhope.com/atcom.htm God, haven't played with AT modem commands for 20 or 25 years !!! In that prehistoric time when 33.6k or 56k modems were all you got for dial-up access...

I suppose you need to read the replies I posted in that thread again...

According to edd1024, this M2./NGFF 4G/LTE card is supported under macOS. Advertised specs: Interface: USB2.0 Chipset: Qualcomm MDM9X15 LTE : 100Mbps download / 50Mbps upload HSPA+: 42Mbps download / 5.76 upload

One (internal) model to add to the list of supported WWAN cards. Thanks! Could you post the kext or a link to the package you used + typical bit rates you're getting out of it?

I guess you can look into the thread about the 7480 with TB16 posted in this very section.

Are you sure your BT module has dev id 8158? Because in post #17, you stated dev id 8156? Why don't you double check in IOReg, hmm? Better, post a zipped saved output from IORegistryExplorer, I'll do it myself.

You still didn't manage to get it right, so here's a Clover config file that you work... config.plist.zip To be able to read hardware info such as T°, your need FakeSMC's PlugIns. FakeSMC is obviously already installed (notably in your kexts folder, doh!) or you would not even be able to boot your Hackintosh. If your card reader already worked, then I understand even less why you would have attempted to load VoodooSDHC kext. Anyway, never mind. The boot artefacts patch (for Sierra) is already installed in Clover config file. I guess you have to make sure you're properly rebuilt your cache (see FAQ section for details). Regarding the on-board Bluetooth, this is a new issue, so you'll have to post a zipped IOReg (saved output from IORegistryExplorer will do) for us to check what's installed. If it's Dell's own DW380, my E6230 guide states what's required to get it working: patch the Broadcom transport kext to inject DW380's id; you may also add Rehabman's firmware patching kexts but not mandatory. BT will have limited functionalities though; don't expect AirDrop or Handoff to work.

You probably need to look into the manner in which the extra USB ports of the TB15 are handled. Check that out with IORegistryExplorer and a USB key that you'll plug ins & out of each port. May be you'll have to use the patch that removes USB ports limitation (in number) or something like that. Are you using a USB injector?

Try MacBookPro11,1 SMBIOS instead of MBA6,2. VRAM is not an issue, never has been on Haswell iGPUs.

For what's it's worth, no actual audio output on my E6440 if I reboot into OS X/macOS from Windows; all looks Ok but just no audio at all. If I shutdown the laptop and perform a cold boot, all is Ok.

Well, may be it's not supported in modern versions of macOS.

Sorted with following SNB patch: 01 02 04 00 10 07 00 00 10 07 00 00 // vanilla: nb of connectors -> "04" 05 03 00 00 02 00 00 00 30 00 00 00 // vanilla: laptop's own LCD display 02 05 00 00 00 08 00 00 05 00 00 00 // patched: HDMI, display port #5 (built-in port) 03 04 00 00 00 04 00 00 06 00 00 00 // patched: DP, display port #6 (docking-station port) 04 06 00 00 00 04 00 00 07 00 00 00 // patched: DVI, display port #7 (docking-station port)

Further to additional tests with forum member MikeGiff, the following SNB framebuffer patch supports direct DP output (tested out of docking station to DP screen): 03 04 00 00 00 04 00 00 06 00 00 00 The tests were validated with combinations of dual-screens setups: built-in LCD + DP built-in LCD + DVI DVI + DP 01 02 04 00 10 07 00 00 10 07 00 00 // vanilla: nb of connectors -> "04" 05 03 00 00 02 00 00 00 30 00 00 00 // vanilla: laptop's own LCD display 02 05 00 00 00 08 00 00 05 00 00 00 // patched: HDMI, display port #5 (built-in port) 03 04 00 00 00 04 00 00 06 00 00 00 // patched: DP, display port #6 (docking-station port) 04 06 00 00 00 04 00 00 07 00 00 00 // patched: DVI, display port #7 (docking-station port)

You'll have to find the correct settings for the Radeon HD5450 then. At least, it's properly detected so it should work. Oh, I think I know where you got your stuff from... http://www.insanelymac.com/forum/topic/312656-guide-macos-sierra-1012-dell-optiplex-780-760-755-790/

Try this one instead: config.plist.zip If it does not work, use latest Clover Configurator v4.55 to edit the config file and try the various AMD5000Controller offered. Remember to save the config file after each change.

Try this DSDT. DSDT.aml.zip Basically, I've moved the GFX0 device that was injected/declared under PCI0.PEG0 (i.e. a PCIe slot) to PCI0.CPI4, i.e. the PCI slot under which the card registers in IOReg. Let me know how it goes. Try the different AMD5000Controller FBs as/if required. Don't hesitate to post a zipped/compressed copy of your EFI Clover folder too so that we can check the Clover config too.

I don't think you read anything past my initial questions on X3000 accelerator kext in my previous answer.

Your IOReg screenshot shows exactly what you had to look for; so the card is seen and that's good news. You said you tried all the framebuffer settings but what about the card id in the accelerator kext? Was it already there? It not, did you add it? The thing is your DSDT contains what appears to be a valid patch for an HD5450 card and the patch fakes dev id 1002:68E0, i.e is the default one supported by the accelerator kext as shown below (extract of 10.13's X3000 accelerator kext): <key>AMDCedarGraphicsAccelerator</key> <dict> <key>ATIEnableWideBlitSupport</key> <true/> <key>ATIUseTearingWideBlit</key> <false/> <key>CFBundleIdentifier</key> <string>com.apple.kext.AMDRadeonX3000</string> <key>GpuDebugPolicy</key> <integer>0</integer> <key>IOClass</key> <string>AMDCedarGraphicsAccelerator</string> <key>IODVDBundleName</key> <string>AMDRadeonVADriver</string> <key>IOKitDebug</key> <integer>0</integer> <key>IOMatchCategory</key> <string>IOAccelerator</string> <key>IOPCIMatch</key> <string>0x68E01002</string> <key>IOProbeScore</key> <integer>200</integer> <key>IOProviderClass</key> <string>IOPCIDevice</string> <key>IOSourceVersion</key> <string>0.0.0.0.0</string> <key>IOVARendererID</key> <integer>16908288</integer> </dict> ` However, the DSDT patch is inserted in device PCI0.PEG0.GFX0. This can only work if it matches your IOReg device and I've got a feeling it does not... Save the output of IORegistryExplorer, zip it and attach it here so that we can check things out and adjust the DSDT patch if necessary. By the way, which version of OS X/macOS are you running?

It's because you inject those through the Clover EFI folder, not cache them through /L/E (or /S/L/E) which is better... This being said, there's nothing to worry about.