Hervé

Try the various Azul framebuffer layout-id values to get full graphics acceleration. You can find value details at RampageDev's blog in his Intel HD guide. When you specify the ig-layout-id in Clover (or in Chameleon to that effect), bear in mind that you enter the values in reverse order. For instance for ig-layout-id 0x0a260006, you'd enter: 0600260A.

According to Dell's specs, the variants are only on CPU. The E6330 supports Sandy Bridge i3 CPU with HD3000 graphics and Ivyy Bridge i3/i5/i7 with HD4000. The rest is the same. http://www.dell.com/downloads/global/products/latit/dell_latitude_e6330_spec_sheet.pdf

i3, i5 or i7 CPU (not chipset - a chipset includes memory controller, disk controller, etc.), it should make absolutely no difference in terms of installation process if the guides all apply to the exact same laptop. It's the same Intel QM77 chipset and same hardware accessories such as USB controller, LAN card or audio device. Only the SSDT (for CPU power management) is specific to each CPU. Maybe you followed guides for nVidia models. You may follow guides for other Ivy Bridge/HD4000-only laptops of the same family, .i.e. E6230, E6430 or E6530. Only the DSDT and SSDT will differ. You're not very specific regarding the troubles you've met, so difficult to say more until you do.

Of course there will be an alert on this kext signature, that's perfectly normal: the kext is patched to support Sandy/Ivy bridge CPU on the locked-MSR BIOS, therefore it's no longer vanilla! Without this patched kext, you'd need to use NullCPUPM (and obtain no CPU power management at all as a consequence) to avoid KP. However, unrecognized kext signature is not a problem in Yosemite as long as you use the boot option kext-dev-mode=1 and that's already included in the pack I posted. Bottom line is that this has nothing to do with your BOOT error, which is due to an incorrectly installed bootloader. Maybe you are facing the well-know 4K-sector HDD issue, in which case look it up to apply the fix.

You probably need some DSDT patches. Look at Rehabman's repository, he's got patches for LID fixes re: sleep & wake. They work fine and I use them on the E6440. I think I also posted details in my E6440 guide, look it up.

Patched the SNB framebuffer kext for VGA & HDMI. It's the same usual patch as described in Enabling VGA & HDMI on HD3000 thread. Edit - 19/08/2015: revisited the old SNB patch to add DVI output when docking the laptop to docking stations such as E-Port/E-Port plus. This now extends video output to DVI in addition to VGA and HDMI. For reference, patched code is as follows: 01 02 04 00 10 07 00 00 10 07 00 00 // Nb of connectors -> "04" 05 03 00 00 02 00 00 00 30 00 00 00 // Built-in LCD display 02 05 00 00 00 08 00 00 06 00 00 00 // HDMI output port 06 02 00 00 00 04 00 00 09 00 00 00 // VGA output port 04 06 00 00 00 04 00 00 09 00 00 00 // DVI output port located at offset 2B650. 10.11DB6_new-patch_AppleIntelSNBGraphicsFB.kext.zip

You'd also need to remove any sleepimage file in /var/vm.

AR9380 works OOB -> https://osxlatitude.com/index.php?/topic/2120-supportedunsupported-wireless-cards-inventory/ Ensure Wifi is enabled in BIOS and that wireless On/Off switch is not set to off position.

So far, I've not suggested any ways to fix sleep, I've merely asked you to check hibernation mode... This being said, hibernation must be disabled on a Hackintosh, i.e. you just run plain old sleep; currently it is on (hibernate mode set to 3), hence your trouble. Hibernation mode can be defaulted back by an OS X update. Fix sleep with the following Terminal commands: sudo pmset hibernatemode 0 sudo pmset hibernatefile /dev/null sudo rm -f /var/vm/sleepimage

Up to DB6 and, again, encountered trouble with the cache/prelinked kernel. Basically, FakeSMC kept getting omitted due to unsigned/unverified status. In the end, I had to reboot in single-user mode, load the kext manually and then, result normal boot. Once system was up and running, I was then able to manually fully rebuild the cache/prelinked kernel. 10.11DB6_patched_AppleIntelFramebufferAzul.kext.zip 10.11DB6_patched_AppleIntelHD5000Graphics.kext.zip 10.11DB6_patched_IOGraphicsFamily.kext.zip

What's the current hibernate mode? Check it out with Terminal command: sudo pmset -g You may also check presence of an hibernation file: ls -la /var/vm and, if found, delete it: sudo rm -f /var/vm/sleepimage

As far as I know, the Intel graphics kexts from 10.9 do not work in 10.10, so that would be a nae...

Since you need to boot without the cache (which is abnormal behaviour, even after a 10.10 update), once you're up and running, rebuild it manually with the following Terminal commands: 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 /

We need a raw IOReg + extracted raw DSDT. An existing patched DSDT file is of no use here.

Installed DP6 and met trouble at 1st reboot. Enoch would not boot 10.11 any more. Tried r2725 and r2737 without success. I had to revert to a Clover r3224 USB key to boot DB6 without kextcache and finalise its installation. Then, I could only reboot DB6 (with Enoch and/or Clover) after I actually deleted the kextcache altogether. Annoying thing, which happens also on the D630: 10.11 prompts me at every single reboot if I want to open Display menu & HWMonitor (both on autostart mode). Sigh... NB: DP6 not in my list of installed updates so I can only guess that, somehow, it did not go 100% well...

Behaviour verified and confirmed under Yos 10.10.4, 10.10.5 and El Capitan DB.

You're mistaken, there are no OS X drivers for Intel wireless cards. They're all unsupported. You'll have to replace it by a supported model or use a supported dongle. Please browse through the non-exhaustive list we've published in the R&D forum subsection.

As always, please search the forum before posting. All the answers are already there... As Jake indicated, 1st gen Intel HD graphics of those Arrandale-based E6x10 is only partially supported due to video interface. Nothing you can do about it. This makes this specific series mostly unsuitable to run OS X. There's plethora of threads on this matter on all hackintosh forums including this one... You'll find a good presentation on eDP (vs. LVDS) here. Same thing for your Broadcom card, it's unsupported: https://osxlatitude.com/index.php?/topic/2120-supportedunsupported-wireless-cards-inventory/. You'd have to replace it by a supported card or USB dongle.

Enoch has been supporting ElCapitan since r2725. I did successfully test versions r2725 and r2737 (latest packaged version published on IM at time of writing) and all was very good. Or was it? Those versions actually proved to be problematic for Haswell-based laptops with HD4200, HD4400 or HD4600 as they included a replacement of mobile GPU id by that of desktop id 0412. In the case of my mobile HD4600, this was a no-no and I could not use 10.11 compatible Enoch versions to boot my 10.10 and/or 10.11 partitions. They prevented full QE/CI! Fortunately, our good friend ErmaC has now repackaged a new version r2748 that no longer replaces those Haswell mobile GPU ids by that of desktop. This Enoch version is just perfect to boot 10.11 as well as previous OS X versions on Haswell-based laptops. My E6440 is very thankful for that! http://www.insanelymac.com/forum/files/file/71-enoch/ NB: Compared to the previous versions, r2478 has a little defect at Apple logo boot screen/progress bar, but that's just cosmetic.

For SMBIOS, try iMac14,1 or iMac14,2. If I were you, I'd try to temporarily remove the nVidia card just to get the system going with the built-in HD4400. Then, once that is sorted, out the nVidia back in the PC and try to switch graphics to the nVidia card.

Ok, 1st time for me I deal with external declarations and a separate SSDT for GPUs. Anyway, here are patched DSDT + SSDT-6 tables. Try to rename them as DSDT.aml and SSDT.aml and place them in EFI/CLOVER/ACPI/patched folder. DSDT_ALW.aml.zip SSDT-6_ALW.aml.zip You can 1st try with only your integrated Intel HD4400: in the "Graphics injector menu" mentioned before, simply activate "Inject Intel". The SSDT table contains the device id + default Azul framebuffer/ig-platform-id 0600260a. You may try to experiment with other framebuffer values if you do not get graphics acceleration with the HD4400. There are about 15 different values but many are for mobile versions of the GPU. If you want to try the PCIe Geforce GTX 745, I guess you'd simply have to activate "Inject nVidia". Again, the SSDT table contains the usual details for injecting an nVidia card, though I have not specified the amount of Video RAM it has on-board as I did not see that reported in the IOReg. You may have to enable or disable the nVidia card in BIOS where it may be referenced as PEG for PCI Express Graphics. Good luck. Can't guarantee it'll work.

I'll try and patch the DSDT for you, then you'll have to try the various Azul framebuffer/layout-id as I explained above in post #3.

Ok, so: PCI root id is 0, so that's cleared out of the way HD4000 is GFX0@2 with id 041e; ideally, should be renamed IGPU in a patched DSDT. No visible layout-id, so you must enter one out of the 15 or so possible value. You may try them one by one until you hot the correct one. GTX745 is PEGP@0 under PEG0@1 with vendor id 10de (nVidia) and device id 1382; ideally, should be renamed GFX0 in a patched DSDT. The graphics devices are defined in SSDT-6 raw table, not in the raw DSDT.

To edit a DSDT, you must 1st identify the relevant section of the table that corresponds to your hardware. To do that, use IORegistryExplorer and look at the whole list of devices. Hopefully, you'll find some data or text that leads you to the touchscreen. Once you've done that, you'll be able to identify the DSDT section you may eventually modify. Of course you would need to know what to modify and that's another story... There are several ways to modify (i.e. patch) a DSDT: you can decompile the .aml file using Chameleon Wizard app, then use a standard text editor (such as TextEdit) to modify the .dsl source file. You can then recompile the .dsl file with Cham Wizard again. You may also use a tool such as DSDTEditor or MaciASL to modify the .aml file directly and recompile the table.

Yep, that'll be fine.