Hervé

Well... I would not put my family jewels in the vice on it and say "squeeze!", but I guess it must be the same device and that linked product is a pretty safe buy.

Here's a 1st patched version where all I've done was: rename device GFX0 to IGPU to reflect the HD4600 integrated GPU nature inject desktop HD4600 device id (0412) inject Azul FrameBuffer #12 (0a260006), the one that normally gives full QE/CI on mobile HD4600 GPU E6540_DSDT_01.zip With this DSDT in place (you can place it in /Extra folder under the name DSDT.aml) and the attached 2 FakePCIID kexts (from Rehabman) placed in /Extra/Extensions, you should immediately gain full graphics acceleration. Make sure to remove the kext called AppleIntelFramebufferAzul.kext from /E/E, you won't need it at this stage. FakePCIID.kext.zip FakePCIID_HD4600_HD4400.kext.zip If the E6540 behaves exactly like the E6440, you will also have to remove the AppleHPET kext from /S/L/E (you may keep a backup if you wish) as that interferes with USB ports (most notably the USB3.0 ones) and internal USB devices. I also recommend you use Chameleon-Enoch r2760 as bootloader.

Ok, will start looking into it. Could you also extract your raw IOReg with a tool such as IORegistryExplorer? Just save the output file, zip it and post it. That will help me identify some of the hardware components such as SD card reader for instance.

I must have misread your 2nd post (or maybe you edited it) because I thought you had mentionned SSDT in your 1st point when I clearly see DSDT now. I've updated my response to that effect. Generally speaking, it's never a good idea to use a DSDT from a different computer model, unless the systems really are of identical specs. It may be the case for the E6440/E6540, but I would still recommend you post your raw/extracted DSDT so that I can compare. As this stage, I do not know if the specs are 100% identical even though they most probably are (LAN, audio, SD card reader, etc.). Indeed, I have listed and/or detailed the patches applied to my E6440 DSDT and if/when I made a reference to existing ones, you may of course referto the actual source to grab them from. I sure won't mind looking at your DSDT and patch it if you want... For AppleHDA, you must replace the vanilla kext in /S/L/E, so the kext provided in /E/E really is for retrieval only. You may also opt to copy the patched AppleHDA to /Library/Extensions and delete the vanilla kexts from /S/L/E.

-> Same link as provided by Jake on the 11th... Just look at the whole thread from the beginning.

1. It may, but I would recommend you extract your raw table, then patch it. 2. You may use whichever bootloader you fancy (we advocate Chameleon/Enoch + Clover here) 3. Yes, as stipulated in the guide

The D630 EC guide may also be consulted as I've detailed the installation procedure with a bit more details. If you choose Enoch in preference to Clover, make sure to use r2760 and set CsrActiveConfig parameter to 3.

Having switched to Enoch some time ago, I have now updated to r2760 which does provide some really nice and fancy features like on-the-fly kernel/AICPUPM patches that were, until now, exclusive to Clover. The devs have done some excellent work here. All versions available off InsanelyMac download area. One of the most useful parameters is the CsrActiveConfig that caters notably for kext signing and file system protection. Some details on this are available here.

You can possibly follow and adapt the method I used on the D630. Details posted here.

I've hardly looked into this actually... I just played with CsrActiveConfig on my freshly updated E6440 this afternoon, having noticed your previous post and installed Enoch r2760 on my E6220 last night. Indeed, a value of 1 would be the absolute minimum -to disable kext signing- and a value of 3 probably preferred to support kexts full deletion/easy replacement from/in /S/L/E. cDock works much better with FileSystem protection disabled!

I guess that setting CsrActiveConfig to 1 only disables kext signing but not FileSystem protection, i.e. if you delete a kext from /S/L/E, you still have trouble emptying the trash, right? There should be no such restrictions if you set CsrActiveConfig to 3 or 7 for instance. Having played around with various values after noticing the verbose 7bit info when booting with Enoch r2760, I believe SIP configuration is arranged as follows (sorry, I have not done much reading or research on this yet): nibble: (4) 3 2 1 | (4) 3 2 1 bits: (X) - - - | (X) - - - N/A | | | N/A | | | | | | | | | | | | | | | | | \ | | | | \ Apple Int. | | \ \ DTrace Rest. | \ Kext Sig. NVRAM Prot. \ FS Prot. Debug Rest. On the basis/assumption that Apple Internal seems disabled by default (bit set to 0) and that 4th bit of each nibble is unused, you would therefore set CsrActiveConfig to: -000x011 in binary (where x is set to 0 or 1), i.e. 0x03, i.e 3 in decimal to disable kext signing and filesystem protection -110x111 in binary (where x is set to 0 or 1), i.e. 0x63 or 0x6F, i.e 103 or 111 in decimal to disable everything If I boot 10.11DB8 with CsrActiveConfig=103, here's the result in Terminal: E6440:~ admin$ sudo csrutil status System Integrity Protection status: enabled (Custom Configuration). Configuration: Apple Internal: disabled Kext Signing: disabled Filesystem Protections: disabled Debugging Restrictions: disabled DTrace Restrictions: disabled NVRAM Protections: disabled This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

There are ways to create a USB installer from Windows but I've never attempted it myself. I don't have any links readily available and the name of tool to use eludes me, but you should find details of the method through a Google search. The alternative is to use a Virtual Machine.

Whether i5 or i3, You can install recent OS X versions on the Sandy bridge-based E6220. You can follow the guides posted here (there are a few - click on my signature link for instance), only the SSDT file used to manage CPU power management is specific to the CPU; as such, if you don't find a pre-existing one for your i3-2310M, you can very easily create one using the well-know generator tool.

Pending Apple's re-publishing of 10.11GM, I finally updated to DB8. No particular issues to report. I had 1st updated Enoch to latest version 2760 (at time of writing) to test CsrActiveConfig parameter. Having had a few words with Rehabman recently, I also took the opportunity of this update (and consequential return to vanilla graphics kexts) to test the FakePCIID kexts solution on the E6440 to retain graphics acceleration on my mobile HD4600. Again, and as anyone would expect, no problems on that front: it's a simple matter of copying the 2 kexts FakePCIID + FakePCIID_HD4600_HD4400 to /L/E (followed by usual permissions repair + cache rebuild) and patching the DSDT to IGPU device-id 0412 (Desktop HD4600). It is a lot simpler that having to rematch the Azul+HD5000+IOGraphics kexts + OpenCL library all the time, even though those patches do fully work. Device (IGPU) { Name (_ADR, 0x00020000) Method (_DSM, 4, NotSerialized) { Store (Package (0x08) { "AAPL,slot-name", "Built-in", "device-id", Buffer (0x04) { 0x12, 0x04, 0x00, 0x00 // -> Desktop HD4600 id }, "AAPL,ig-platform-id", Buffer (0x04) { 0x06, 0x00, 0x26, 0x0A }, "hda-gfx", Buffer (0x0A) { "onboard-1" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } .... } And, again as usual, AppleHPET + AppleHDA kexts need to be removed from /S/L/E for USB ports to work and patched AppleHDA to be loaded from /L/E.

Bronya having released a few 10.10.5 AMD kernels for some time now, I finally decided to give them a try on the old lady. I've tested RC1, RC2 and RC3 and all work perfectly... as usual! Again, IOPCIFamily kext replacement is required to avoid white screen issue with the nVidia GeForce 9800GT. No replacement of pthread kext required. Works as well after Security update 2015-006. However, I must admit that system performance is quite poor and laggy. Can't say it's a surprise on a 10yr+ old system...

GM was pulled out by Apple; must be for a reason... If 10.11GM does not boot to completion, try: boot without cache in verbose mode check if FakeSMC loads or not if it does not, try and boot in single-user mode and load it manually FakeSMC not loading is usually due to incorrect location of the kext

Look at my E6440 guide in this section. Generally speaking, please use the forum search facility before posting.

No, he's (somehow) wrong and you're right. you can perfectly install Windows on an existing GPT/GUID HDD/SSD. Just create a new/second partition for Windows and format it DOS/FAT. Your Windows installer wiil then see it and will be able to reformat it NTFS during 1st steps of installation. Your OS X partition will remain your 1st disk partition, Chameleon bootloader is then perfectly able to handle both partition and offer you to boot OS X or Windows. You may just have to play with Windows DISKPART utility (from a DOS/Command window) to modify the active partition so that you can boot OS X through Chameleon again. Please search the forum, this has been covered in full details several times before.

The old Lion RTC patch should be considered ineffective on recent OS X versions such as Mavericks and/or Yosemite for which the patch is actually slightly different. See here for instance.

Intel not supported. Replace it. https://osxlatitude.com/index.php?/topic/2120-supportedunsupported-wireless-cards-inventory/

Ho ho... if you read the guide with all due attention, you should notice that it's not a simple matter of dragging and dropping kexts from the pack to replace vanilla ones... There are Terminal commands to follow. It's a pretty standard thing that part, nothing new really: it's the kexts permissions repair + bootcache/prelinked kernel update process. Did you do that?

Yes, the SLE folder inside the bootpack means the kexts inside actually go to /S/L/E to replace the vanilla kexts. Otherwise, they do not work, as you've experienced with AppleHDA. Once you've replaced the vanilla AICPUPM kext in /S/L/E by the patched version, you can remove NullCPUPM from /E/E to keep it aside. You'll then be able to run full native CPU speedstep. DisableTurboBoostBattery and IOAHCIFamily really are optional. The former is to disable CPU turbo boost mode when laptop is running on battery to save it, the latter was used up to 10.10.3 to support TRIM on non-Apple SSD. From 10.10.4, Yosemite provides a built-in command to handle that, so it's no longer required. Enjoy that little machine, it makes for a great Hackintosh, very fast & responsive, especially with a SSD.

To summarize things: Unmodified DSDT at discrete GPU level (device (VID) under Device (AGP)) MacBookPro5,1 profile Recent Kozlek's FakeSMC kext tuned with 1.33f8/smc-mcp SMC parameters AGPM kext patched with new MBP5,1 entry for Vendor10deDevice06eb with Control-id set to 18 and adjusted idle loads -> Full native CPU SpeedStepping + NVS 160M GPU throttling at all times, including after sleep.

No need to patch AICPUPM for Arrandale CPUs, it's only required for Sandy/Ivy Bridge CPUs. Just make sure to have a tuned up FakeSMC kext, the right SMBIOS profile and P+C States generation activated. If you use NullCPUPM, well... its name should be self-explanatory...

Yep, you can read reports/results of some other 10.11 installations in the R&D->Other research forum subsection.