Hervé

You had initially listed this: Can't you remove the useless entries through the "Delete Boot Option" button any more? Can't you reset BIOS to default settings?

I find it strange that you're unable to set boot order in BIOS; unless it's locked of course and you do not have the password... On my E6220/E6230/E6440 systems, I can set the disks boot order in BIOS. For instance, in my E6440, I have a regular 3.5" SATA HDD (with Windows) + an mSATA SSD (with multiple OS X Partitions + Enoch bootloader). In BIOS, I can set 1st boot device from the displayed list of media (SATA HDD, mSATA SSD, USB, CD/DVD, floppy). If I set 1st boot disk to 3.5" SATA HDD, I'll always boot Windows directly (because that's all the system sees) but if I set 1st boot disk to the mSATA SSD, then Enoch allows me to boot any of the installed OS X partitions or Windows from the SATA HDD, since it's listed too. Ok, this is all legacy mode, but... I can also manually overwrite this by pressing F12 at the BIOS POST logo to get a list of boot device to choose from. This is how people usually boot their USB installer (Press F12, select USB media). I'm surprised you cannot do the same with your E6430.

I'm quite confident you can achieve good results with the right settings. Reason for this is that both the NVS 3100M of the E6410 and the GT 330M of MBP6,1/6,2 are based on same architecture GT2xx. http://www.notebookcheck.net/NVIDIA-Quadro-NVS-3100M.24738.0.html http://www.notebookcheck.biz/NVIDIA-GeForce-GT-330M.27335.0.html Info.plist of AGPM kext shows the following nVidia ids for MBP6,1/6,2: Vendor 10de, Device 0029 -> GeForce GT 330M = chip GT216 Vendor 10de, Device 0a34 -> GeForce GT 240M = chip GT216 As far the Dell Latitude E6510 dGPU: Vendor 10de, Device 0a6c -> NVS 3100M = chip GT218 So, they are close cousins. Inject the section for Vendor10deDevice0029 of MacBookPro6,1 or 6,2 entries to your FakeSMC and adjust the thresholds to test: <key>Threshold_High</key><array> <integer>57</integer> <integer>70</integer> <integer>80</integer> <integer>100</integer> </array> <key>Threshold_High_v</key> <array> <integer>1</integer> <integer>3</integer> <integer>98</integer> <integer>100</integer> </array> <key>Threshold_Low</key> <array> <integer>0</integer> <integer>68</integer> <integer>75</integer> <integer>94</integer> </array> <key>Threshold_Low_v</key> <array> <integer>0</integer> <integer>2</integer> <integer>4</integer> <integer>99</integer> </array>

Ok, so you have throttling between 4 states (0, 1, 2, 3) -which is good news- but I guess the current threshold values are not adequate. You need to play with those until you find settings that are good in terms of performance on screen. For instance, you'll see in my guide that I adjusted the default MBP5,1 threshold values from: <key>Threshold_High</key> <array> <integer>57</integer> <integer>65</integer> <integer>82</integer> <integer>100</integer> </array> <key>Threshold_Low</key> <array> <integer>0</integer> <integer>68</integer> <integer>75</integer> <integer>95</integer> </array> to: <key>Threshold_High</key> <array> <integer>57</integer> <integer>65</integer> <integer>74</integer> <integer>100</integer> </array> <key>Threshold_Low</key> <array> <integer>0</integer> <integer>40</integer> <integer>60</integer> <integer>75</integer> </array> That was done over a period of time, setting values and testing/evaluating graphics performance of my NVS 135M until I felt satisfied, the aim being mostly of minimising the delays for throttling GPU core/RAM speeds up and down according to graphics demand/load. As I said, I've no direct and/or straight method to set those threshold values according to GPU model. It's purely a manual "set and test" method. In your case, you should start from the MBP6,1/6,2 default settings of one or the other nVidia entries (vendor 10de). You may also experiment with control-id value, i.e. 17 or 18. I would not refer to the threshold of the Intel 1st gen HD iGPU (8086:0046).

That's exactly it: instead of patching the AGPM kext in /S/L/E, something one would require re-doing after each OS X update, FakeSMC can instead be used to inject the same patch. FakeSMC never gets replaced or overwritten at OS X updates, so the patch remains effective throughout. Make sure you start from your original AGPM Info.plist code, do not copy the code I posted to illustrate my thread because it may not match the vanilla AGPM version.

The tuned FakeSMC is essentially targetting native CPU SpeedStep. For GPU throttling, you have to look at the AGPM tuning and experiment as mentioned in the guide. I've no straight answer for any given GPU model... The guide mentions how to log GPU throttling behaviour, so use that to verify actual GPU state changes and then experiment with threshold levels.

https://osxlatitude.com/index.php?/topic/2673-performance-tuning-with-fakesmc/ https://osxlatitude.com/index.php?/topic/7807-nvidia-gpu-performance-tuning-with-agpm/ Afaik, NVS 3100M CPU clocks up to 600MHz and the RAM up to 800MHz.

Revert/swap the disks boot order. Clover is obviously on your OS X disk, not on the Windows disk. So make sure that the boot order 1st points towards the disk that has OS X on it. Ain't that logical?

OS X supports VGA but it depends on GPU model or OS X version, sometimes a mix of both. For instance, VGA is unsupported with mobile Haswell HD4600 whereas I've seen it work OOB on HD4400-based laptops. IvyBridge HD4000 supported VGA output in ML but not since Mavericks. On my old Latitude D630, the nVidia NVS Quadro 135M supports VGA output all the way from SL to Sierra. With your discrete ATI board, it should depend entirely on the framebuffer settings, i.e. the ATI Config personality you'll go for. The personality may also require binary patching.

Re: BIOS settings, I recommend: 1) Ethernet = Enabled (rather than enabled w/PXE - you're not going to boot via a LAN image, are you?) 2) display: I would statically define iGPU (Intel HD) or dGPU (ATI Radeon HD) but not set the primary display to auto. Hackintoshes do not support GPU switching.

Mmm, never went that high With Chameleon; always had issues with versions above 2500... Can you downgrade Chame to r2468 for instance, otherwise try the latest Enoch?

I give up.

'never ever seen such a KP before. I have absolutely no idea! You should be using MacBookPro6,1 SMBIOS (Arrandale) though, not MBP8,1 (SandyBridge...). What version of Chameleon did you install on that USB installer?

If you copy the file to the EFI partition, it's the right place. If you copy the file to the OS X partition, it's wrong. Upload a zipped copy of your entire EFI folder.

I'm trying to help, but it's difficult... I don't think you're saving or copying your config.plist to the right place. Maybe you'll enlighten us on that.

You didn't save the config.plist in French, did you?

He's killing me! If you really want to, you can try the following commands: cd / sudo rm -Rf *

Did you see any?

'better not have a prolonged power outage, eh?

The update for macOS Sierra 10.12 is now available.

If we could stick to the thread's topic... or else edit its title... ALC292 works with: 1) injection of layout 1 to DSDT HDEF device Device (HDEF) { Name (_ADR, 0x001B0000) // _ADR: Address [...] Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Store (Package (0x12) { "codec-id", Buffer (0x04) { 0x92, 0x02, 0xEC, 0x10 }, "layout-id", Buffer (0x04) { 0x01, 0x00, 0x00, 0x00 }, "AAPL,clock-id", Buffer (One) { 0x01 }, "built-in", Buffer (One) { 0x00 }, "AAPL,current-available", 0x0834, "AAPL,current-extra", 0x0898, "AAPL,current-extra-in-sleep", 0x0640, "AAPL,max-port-current-in-sleep", 0x0834, "AAPL,device-internal", 0x02 }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } 2) installation of the attached ALC292 kext in /L/E (with usual permissions repair and cache rebuild) AppleHDA_ALC292.kext.zip 3) patching of El Capitan's 10.11.6 vanilla AppleHDA kext (in /S/L/E) Find: 8319D411 Replace by: 00000000 Find: 8419D411 Replace by: 9202EC120 Find: 8508EC10 Replace by: 00000000 NB: There are 2 x occurrences of each replacement. If required, I attach the patched kext of 10.11.6 (15G1004): 10.11.6(15G1004)_patched_AppleHDA.kext.zip As usual, 'can be configured as on-the-fly patch in Clover config.plist to avoid binmod of the kext file after each update.

Follow what Rehabman wrote: copy BrcmFirmwareRepo + BrcmPatchRAM2 to /S/L/E, then repair permissions and rebuild your cache: 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 / If you get an error message ('happpens frequently), re-enter last 2 commands (touch + kextcache). Reboot and you'll be done. Basically, follow the instructions...

Mobile Haswell iGPUs are subject to same treatment when it comes to Hackintoshes, whether it be HD4200, HD4400, HD4600 or Iris. Apple only supports Desktop HD 4600 (dev id 0412) so that needs to be faked for the mobile versions to be supported. Injection of the appropriate Azul framebuffer layout is also necessary and that usually (but not always) is 0x0600260a (specified in reverse order). Consider that a framebuffer layout defines or corresponds to a particular set of Video RAM and output ports arrangements (types, numbers). You can read more about getting Haswell graphics support here. Open up your config.plist with Clover Configurator and look at each tab/page, especially that for graphics and kext patches. You will find everything and, hopefully, catch things. HDMI output and cable hot-plugging will be fully supported once you apply the little patch I listed in my previous post; you actually had it in your original config.plist. What you required was to remove the other Azul framebuffer patches. Afaik, you don't need them. Yesterday, I uploaded a revised version of your original config.plist where the only Azul Framebuffer patch is that as posted. Why don't you try it? If you prefer a pre-patched kext, use the attached one: 10.11.6(15G1004)_HDMI-patched_AzulFB.zip The patched kext goes to /S/L/E where it replaces the vanilla version (keep a copy somewhere), followed by permissions repair + cache rebuild via Terminal: 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 / If you get errors, repeat the last 2 x commands. If you use the pre-patched kext, you should remove the Clover on-the-fly patch entry programmed in the config.plist, but considering your current skills, I strongly suggest you keep the easy route, i.e. the Clover config one...

I think you're on the wrong path and I very much doubt that CPU and chipset are your actual issue. It's all Haswell generation for which you need to activate the "kernelPm" patch to handle the CPU power management done at kernel level on those platforms. At worst, you may have to fake your CPU id due to unkown ES sample identification. It'll have more to do with the settings of your config plist and/or the kexts you use. Upload a zipped copy of your EFI folder.

You have the (usual) BCM20702A0-based DW380 fitted to E6x30 laptops ('got it in my E6230). You should see it listed in SysProfiler->USB devices. Either you patch the Broadcom BT USB controller kext using the method detailed in several threads of the R&D->Bluetooth section or you use Rehabman's kexts. I recommend the latter. Good reading.