Hervé

You can create a script to execute that action at boot time.

IOReg output shows all the correct and expected info for the nVidia graphics. But I guess you still booted with nv_disable set since I'm not seeing any nVidia framebuffer loaded... If your wireless works with the patched DSDT, can you try and share your screen, reboot your Tosh and then try to access it via Screen Share?

Ok, try the attached revised DSDT. DSDT.aml.zip Building on your IOReg info, I basically applied the following patches: renamed device PXSX under RP01 @0x001C0000 to ARPT for compliance with Apple's own device naming injected DSM method described & detailed here into RP01.ARPT to declare compatibility of AR5B95 card with Atheros AR9380 chip Let's look at the graphics card now...

Yes, the BIOS version limit applies to all version of OS X so far.

Ok, now post a zipped copy of a saved output of IORegistryExplorer. The wireless AR5B95 should work with the DSDT patch specified in the wireless inventory thread and the screen may work with injection of the nVidia parameters.

Yes, you can try to remove the CellPhoneHelper kext via single user mode. Try and boot with -s flag, type the displayed mount command (you can ignore the fsck one) and run the following commands: rm -Rf /S*/L*/E*/CellPhoneHelper.kext chmod -Rf 755 /S*/L*/E* chown -Rf 0:0 /S*/L*/E* touch -f /S*/L*/E* kextcache -system-prelinked-kernel If you get an error 77, re-type the last 2 x commands. Once cache has rebuilt, just type: exit and the system should continue booting with the repaired cache.

Screen is detected as external, not built-in LCD. Try and post a zipped copy of your DSDT. Extract the raw one if necessary.

A text editor is perfectly Ok to patch the Info.plist file of CellPhoneHelper; that's what I use. The common mistake is to do a copy/paste of a patch that's not applicable to the given OS X version you run on your Hack. Apple modifies the syntax and parameters of this kext in almost every version of the OS... Where do you keep your add-on kexts such as FakeSMC and PS2 controller? You're using regular Chameleon so it's either /S/L/E or /L/E but if you attempt to boot without cache a system where critical add-on kexts such as FakeSMC are placed in /L/E, you will always fail because Yosemite and above ignore /L/E when you boot without cache. In that case, you may attempt to recover the situation by booting the USB installer up to the main installer screen and then try to fix your actual installation through Terminal. You could proceed as follows: 1) delete the patched CellPhoneHelper kext from /S/L/E: sudo rm -Rf /Volume/<OS X partition name>/S*/L*/E*/CellPhoneHelper.kext 2) manually repair permissions and rebuild the cache: sudo chmod -Rf 755 /Volume/<OS X partition name>/S*/L*/E* sudo chown -Rf 0:0 /Volume/<OS X partition name>/S*/L*/E* sudo touch -f /Volume/<OS X partition name>/S*/L*/E* sudo /Volume/<OS X partition name>/usr/sbin/kextcache -Boot -U /Volume/<OS X partition name>/ -K /Volume/<OS X partition name>/S*/L*/Kernels/kernel If you get an error at the end, repeat the last 2 x commands with line recall. Once you've recovered, I would advise you to migrate from good old Chameleon to Enoch. Reason for this is that recent versions of Enoch have improved features: to apply some limited number of kernel patches on-the-fly to call on kexts placed in /E/E and inject them through a special boot parameter. You can combine this to placing add-on kexts in /L/E (from where kexts are cached) so that if you screw up your cache, you can boot without cache whilst retaing add-on kexts injection from /E/E. It totally supports kexts experimentation.

People really should stop using those tools that provide no error log to their users. In addition the manual commands required have been listed all over this forum a trillion time; I don't know why they're not being used... Which bootloader do you use? Clover or Enoch? Depending on version, I understand the former may no longer booting with our cache, whilst you can with the latter. From you description, it seems you've indeed screwed up your cache, probably as a result of incorrectly acting your CellPhoneHelper kext. Once you clarify the situation re: bootloader and attach your missing screenshots (use "More Reply options" button to attach pictures), we'll be able to move forward and maybe make progress.

Booting normally to a black screen is often a sign of EDID issues. When you boot with nVidia disabled, does OS X show a built-in LCD in About This Mac->Displays ? If nothing is shown, try the following: go to the Sharing PrefPane and setup screen sharing take a note of the provided vnc connection details reboot normally to your black screen if you have another Hack of Mac on your network, go to Connect to Server..., then browse to see your Hack and select screen sharing access If you don't have another Mac or Hack on your network, use a PC on which you'll install VNC and access the Hack remotely using the details listed when you shared the screen You may then access your Hack and find you have full graphics acceleration. Check if the built-in screen is detected in About this Mac -> Displays If OS X reports no detected display, you'll have to retrieve your PC's EDID through, say, Windows and inject it through a modification of the Display Override profile applicable to your system.

Lookup my E6220 guide and use the FakeSMC kext provided in the Siera pack. It's specifically tuned in terms of SMC keys for Sandy Bridge platform MBP8,1. Last ting to look at would the your activated DSDT patches in Clover ACPI section. That's quite a few you've activated. May be you need to start from an empty list...

You can use the existing Clover installation guide published by JakeLo. it covers El Capitan and Sierra. For the HD4000-only model, everything works. Only the wireless card may not work if the laptop is fitted with an unsupported model. Swap it out for a supported model in that case. If you want narrower guidance, you can look at my Enoch-based E6230 guide. 99% of the provided material is reusable on the E6430. Simply retrieve the E6430's DSDT off an existing E6430 guide since you have the HighRes LCD screen (the E6230 is LoRes and will not inject the adequate Capri graphics layout-id).

Ok, well, I see 3 x other possible defects in your config.plist: you've activated P States and C States generation, which is only for C2D/C2Q/1st gen Core CPUs. Do not use that on Sandy Bridge platforms and later you're not injecting Intel graphics and SNB layout-id 0x01000300 for your HD3000 (you'll need to add DualLink if your LCD has a res of 1600x900 or higher) no SMBIOS profile defined; ideally you should use something like Sandy Bridge MBP8,1/8,2/8,3. NB: to begin with, you may remove the FakeSMC PlugIn sensor kexts and only use the "basic" FakeSMC kext.

I see some unexplained FakeCPUID in the config.plist. Is that normal?

For audio, you may try to install VoodooHDA + AppleHDADisabler, even if temporarily. DPCIManager may then show the specs of the Realtek audio.

Images attached after duly downsizing (from 4000x3000 @3+MB to 800x600 @100KB). Boot in verbose mode to see where things hang.

HDMI video output normally works OOB (at least with Chameleon/Enoch) but patching the SNB framebuffer is required to support HDMI audio. The patch is also better to set HDMI output with the proper connector type anyway. All details here. If your Clover config does not have this yet, simply add the necessary patches. Basically, your vanilla layout-id looks like this: Vanilla SNB framebuffer kext: 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 laptop display 02 05 00 00 00 04 00 00 07 00 00 00 // display port 03 04 00 00 00 04 00 00 09 00 00 00 // display port 04 06 00 00 00 04 00 00 09 00 00 00 // display port and you want to patch it like this: 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) 06 02 00 00 00 04 00 00 08 00 00 00 // patched: VGA, display port #8 (built-in + docking-station port) 04 06 00 00 00 04 00 00 07 00 00 00 // vanilla: DVI, display port #7 (docking-station port) In Clover config, this will translate into the following on-the-fly patch: Name: AppleIntelSNBGraphicsFB Find: 020500000004000007000000030400000004000009000000040600000004000009000000 Replace: 020500000008000005000000060200000004000008000000040600000004000007000000 -

Lion is still usable, absolutely (isn't Win7?), it may just look and feel a little old to some people. Less so than Snow Leopard I guess... Each OS X version had its X-Code variant. Lion had its own naturally.

I'm afraid you indeed have an incompatible platform... for future reference, please note that Sierra requires a SSE4-capable CPU. Your old Merom T5500 does not feature such instructions set. Only late Penryn C2D do and they're not compatible with your chipset. in 2012, Apple dropped support for obsolete GMA950 (and others) in Mountain Lion 10.8 along with a move to 64bit-only kernel/OS. These old graphic chips are last supported in Lion 10.7.5 and always in 32bit kernel mode because there are no 64bit versions of the necessary drivers. All versions of OS X/macOS are 64bit-only since ML. As such, don't waste any time with any OS X/macOS version beyond Lion on this old platform. Even if, technically, you could install Mountain Lion/Mavericks/Yosemite/ElCapitan, it would badly lag due to lack of graphics acceleration, you'd have constant graphics glitches and artefacts and no sleep. You should however be able to run Snow Leopard or Lion without problems. However the D630 (965GM chipset and nVidia graphics) is not the right model to look at, it's the D620 and D820 (or D430) models you need to turn to (Intel 945GM/PM chipset and GMA950 graphics). Use myHack to install OS X and, if your specs are close enough, grab stuff from those mentioned model's bootpacks: https://osxlatitude.com/index.php?/topic/8081-full-packs-for-d620d630-snow-leopard-lion-mountain-lion-mavericks-yosemite-el-capitan-sierra/ https://osxlatitude.com/index.php?/topic/8815-full-packs-for-d430-snow-leopard-lion-mlpf-mountain-lion/ https://osxlatitude.com/index.php?/topic/7719-older-version-v312-of-myhack-for-snow-leopard/ http://myhack.sojugarden.com

Hibernation works with Clover only. You can Google for it. http://www.insanelymac.com/forum/topic/299721-sleep-hibernation-how-it-works-and-how-to-use/ With Chameleon/Enoch, it's plain old sleep only.

It's the framebuffer layout-id; consider it like an index for tables that provide details about supported types of video output (LVDS, VGA, DVI, HDMI) and internal video port numbers. In the case of HD3000, there are several available layout-ids: for mobile versions and for desktop versions. More details here: http://www.rampagedev.com/?page_id=200&page=3

SysProfiler only shows kexts if they're cached, not injected... So it's not the definitive tool regarding "load" status of kexts, quite the contrary.

You could try and disable the nVidia dGPU via DSDT/SSDT _OFF function. That would normally force OS X onto HD3000

https://osxlatitude.com/index.php?/topic/2120-inventory-of-supported-and-unsupported-wireless-cards/

You don't appear to have graphics acceleration for that nVidia GPU under El Capitan... Can't you configure your BIOS to use only the integrated HD3000 for which there's a better chance to be able to obtain dual DVI output through SNB framebuffer patching. If the DVI outputs remain driven by the iGPU of course and they're not actually wired to the dGPU...