Hervé

Black screen issues gets solved by using the above SMBIOS.

I guess you meant the CPU-specific generated SSDT, not the DSDT, because the latter would not vary according to CPU.

These error messages indicate incorrect permissions... Did you check your PM?

Guys, if the Clover method appears to be so troublesome, why don't you switch to Enoch with BIOS in legacy mode? When I see the ton of recent posts on getting Clover to work in UEFI mode in these laptops, I can't understand why people stick to a method they clearly don't fully master.

I've updated the D620/D630 pack thread with the ML 10.8(.5) pack. Tested and verified with a USB2.0 myHack v3.3.1 installer all the way through, so you can use it in full confidence. If you use a USB3.0 key and get USB-related error messages followed by "Still waiting for root device", just unplug your USB3.0 installer and replug it; the installation will then continue. When you create your USB installer, proceed as follows with myHack v3.3.1: 1) create ML10.8 installer 2) install myhack utilities 3) install Extra (my own, pointing to downloaded ML10.8.5 pack) 4) remove problematic extensions 5) install Chameleon

USB issues under El Capitan are well-known and the fixes well-documented. You'll find the necessary information through a Google search or a search on the forum.

Remove those kexts added to /S/L/E and copy them to /Library/Extensions. Then repair permissions and rebuild your cache with following commands: sudo chmod -Rf 755 /Volumes/<USB installer name>/S*/L*/E* sudo chmod -Rf 755 /Volumes/<USB installer name>/L*/E* sudo chown -Rf 0:0 /Volumes/<USB installer name>/S*/L*/E* sudo chown -Rf 0:0 /Volumes/<USB installer name>/L*/E* sudo touch -f /Volumes/<USB installer name>/S*/L*/E* sudo touch -f /Volumes/<USB installer name>/L*/E* sudo /Volumes/<USB installer name>/usr/sbin/kextcache -Boot -U /Volumes/<USB installer name> -K /Volumes/<USB installer name>/S*/L*/Kernels/kernel This assumes you've copied the appropriate Yosemite kernel file to /S/L/K.

Seems you're not using boot option kext-dev-mode=1; that's mandatory with Yosemite.

Sounds like you have no graphics acceleration. You're going to have to tell us more if you hope to get some support. post your system's specs detail how you installed OS X specify the boot loader you're using post your pack

Copy your add-on kexts to /Library/Extensions, repair permissions and rebuild your cache. Chameleon will not inject or load kexts from /E/E if i remember well...

The Qualcomm Atheros BT module may not actually be CSR based (CSR was only acquired by Qualcomm last year). You could undo the CSR kext patch and do the same for the IOBluetoothControllerUSBTransport kext.

Oh! I think you kinda screwed the CSR controller transport kext with your patch there! My guide says to add a new entry by copying and modifying an existing entry, not to wipe out everything! Anyway, try the attached patched kext instead. Simply overwrite the existing PlugIn kext inside IOBluetoothFamily kext, repair permissions, rebuild cache and reboot: sudo chmod -Rf 755 /S*/L*/E* sudo chown -Rf 0:0 /S*/L*/E* sudo touch -f /S*/L*/E* sudo kextcache -Boot -U / (or sudo kextcache -system-prelinked-kernel) Good luck. CSRBluetoothHostControllerUSBTransport.kext.zip

No reason why you these latest BIOS would not work. I would not use a MacPro SMBIOS profile on this machine but an iMac one instead. iMac 10,1 would look good to me. It's a machine of similar specs to my old Vostro 200, so you should be able to re-use some of the settings used on that system. But I never use Clover of course...

This Clarksfield i7-740QM CPU bears no integrated 1st gen Intel HD graphics, so you need to get that ATI Firepro M7820 supported. As stated by Bronxteck, it's indeed very similar to the Radeon HD 5870. You may have to use boot option GraphicsEnabler=No and safe mode (i.e. -x flag) to begin with and basically boot without graphics support. You may then try to get graphics acceleration by experimenting with various ATI framebuffers and settings as described by RampageDev for the ATI 5000 Series. I've read reports of people reaching success with Nomascus framebuffer and ports set to 3. Identify your graphics card PCI ids, you may have to patch the AMD kexts with them.

First of all, we recommend that you use myHack with the D630n bootpack. Should the available bootpack posted on the compatibility chart turn out invalid, I invite you to use the Mavericks pack I posted here. You'll have to add the SL 10.6.8 ACPIPlatform kext (v1.3.6) as that is required for Lion and ML. The kext is available in the Lion full packs I posted at the same place.

Can you check your BT module PCI ids in SysProfiler. In IOReg, I see vendor 0x13d3 and device 0x3362. That would make it Atheros AR3012 (part of some AzureWave device?).

Can you please post your full /Extra folder?

Please post your DSDT.

Correct, that's how one should proceed. You start with the minimal possible pack then add things one by one. It's timely, it's frustrating, it's exhausting but it's the only way to get things right.

Ok, here's a (very recent!) guide. Follow the same method: identify your BT module's chip and patch the appropriate kext accordingly.

The BT4.0 module of the Intel Advanced-N 6235 (ven:dev id = 8087:07da) is supported OOB under OS X. However, it cannot be turned on or off by default. As usual, this requires patching of the appropriate Bluetooth controller transport kext. Here's what to do (illustrations under El Capitan 10.11.3): Patch attempts of the generic IOBluetoothHostControllerUSBTransport kext lead nowhere. However, on looking for the hardware specs of the BT device, it turns out to be a CSR-based module (Google is our friend!). The CSR controller transport kext can then be patched. PlugIns of OS X El Capitan 10.11.3's IOBluetoothFamily kext are as follows: E6440:~ admin$ cd /System/Library/Extensions/IOBluetoothFamily.kext/Contents/PlugIns/ E6440:PlugIns admin$ ls -la total 0 drwxr-xr-x 9 root wheel 306 Mar 11 21:49 . drwxr-xr-x 8 root wheel 272 Jan 20 15:25 .. drwxr-xr-x 3 root wheel 102 Nov 14 05:31 BroadcomBluetoothHostControllerUSBTransport.kext drwxr-xr-x 3 root wheel 102 Nov 14 05:31 CSRBluetoothHostControllerUSBTransport.kext drwxr-xr-x 3 root wheel 102 Nov 14 05:31 CSRHIDTransitionDriver.kext drwxr-xr-x 3 root wheel 102 Nov 14 05:31 IOBluetoothHostControllerUARTTransport.kext drwxr-xr-x 3 root wheel 102 Nov 14 05:31 IOBluetoothHostControllerUSBTransport.kext drwxr-xr-x 3 root wheel 102 Nov 14 05:31 IOBluetoothSerialManager.kext drwxr-xr-x 3 root wheel 102 Nov 14 05:31 IOBluetoothUSBDFU.kext E6440:PlugIns admin$ Here, the kext to patch is CSRBluetoothHostControllerUSBTransport. It's a simple matter of editing the Info.plist file of the kext and add a new entry based on an existing profile. In this case, a copy of the ApplePortableModule entry can be pasted and edited as follows: <key>Intel-N6235</key> <dict> <key>CFBundleIdentifier</key> <string>com.apple.iokit.CSRBluetoothHostControllerUSBTransport</string> <key>IOClass</key> <string>CSRBluetoothHostControllerUSBTransport</string> <key>IOProviderClass</key> <string>IOUSBHostDevice</string> <key>idProduct</key> <integer>2010</integer> <key>idVendor</key> <integer>32903</integer> </dict> NB: 0x07da (hex) = 2010 (dec). 0x8087 (hex) = 32903 (dec) The modded kext can then be placed back in the PlugIns folder of the IOBluetoothFamily kext, permissions repaired and the cache rebuilt. On reboot, the CSR USB Transport kext is loaded and the BT module can be turned on or off through the Finder's bar icon (and it switches the BT led on or off too, well at least on my E6440): An alternative to patching the vanilla kext is to add the entry to FakeSMC's Info.plist. It's also sustainable to updates within a given OS X/macOS version. NB: Only the Bluetooth module of this card is supported, the wireless module remains of course unsupported in OS X/macOS as per all Intel cards.

Since Bluetooth appears to work OOB, you should be able to turn it On and Off through the BT Finder's bar icon once you've patched the associated Bluetooth controller transport kext. Look in your SysProfiler for the module's PCI ids, identify the BT chip it is based on and patch the associated controller kext. It's always worked for me on the Latitude D and E Series for CSR devices. I've posted several posts on this matter but that was ages ago and can't remember where or when. Try a search on the forum.

Sounds like you need to patch the Capri FrameBuffer. I did some work on that specific matter for my HD3000-based E6220 recently: https://osxlatitude.com/index.php?/topic/7914-dell-latitude-e6220-with-intel-i5-2520m-hd3000-and-1366x768-lcd-mavericksyosemite/&do=findComment&comment=52237 The same principles will apply to IvyBridge iGPU. Start from Dinesh's detailed HD4000 topic. Please note that some display outputs may only be available through the iGPU (VGA and DVI for instance) whilst others may only be available through discrete GPU (HDMI for instance). You'll probably find out by trial and error. I'll be getting an IvyBridge E6230 again soon and will be able to renew the exercise, but that'll only apply to integrated HD4000, not discrete nVidia which the E6230 does not possess.

You could envisage the existing ALC233 patch available in HackintoshVietnamTool.

I've just looked at the specs available on Dell's web site and the Inspiron 1720 is indeed of similar architecture as the D630 nVidia: FSB667/FSB800 C2D CPUs, Intel GM965 chipset, ICH8M I/O controller, integrated GMA X3100 or discrete nVidia GeForce 8400M G (128Mo)/8600M GT (256Mo) graphics. As such, I'm not expecting this AICPUPM kernel panic pictured above. There's no need for NullCPUPM on a C2D CPU. @griftopia: please explain method used to create USB installer, specify the Chameleon version used and post a compressed copy of your full /Extra folder (bootpack). If you can include your raw DSDT, even better.