Hervé

Did you try all USB ports when attempting to boot your USB installer? Sure, you may need to use a USB injector kext, but you need to identify your USB ports 1st... You could try the USB injector I posted in my E6220 EC guide; it may bring life to some if not all your USB ports. It'll require that you also use the same names in your DSDT for EHCx devices + same SMBIOS plist. Otherwise, adjust the USB injector kext according to your system boot settings.

Try to unplug/replug your USB key or replug it in a different port.

I recommend you use only myHack + the appropriate D630 GMA X3100 full pack to Hack your D630. You clearly used another method... Follow our recommended process and I can pretty much guarantee you'll have your D630 running SL or Lion in 30mins and without any of those flags you posted, except -f -v that you may initially use to boot without cache and monitor boot process. You'll have a fully tuned system from the onset with graphics, audio, LAN, etc. fully working. Only your wireless may need additional adjustment depending on the installed card. Refer to the following threads: https://osxlatitude.com/index.php?/topic/7719-older-version-v312-of-myhack-for-snow-leopard/ https://osxlatitude.com/index.php?/topic/1868-bios-settings-d630/ https://osxlatitude.com/index.php?/topic/8081-full-packs-for-d620d630-snow-leopard-lion-mountain-lion-mavericks-yosemite-el-capitan/

I was just explaining what your pictured black screen was, then derived onto sleep/hibernation. Waking from hibernation is not a cold start. Maybe cold start would work too. Try and remove that hibernation file (/var/vm/sleepimage) and reboot OS X. I did ask in a previous post to try and put the laptop to sleep then wake it. Initially, you said it did not change anything, but now you're saying the screen is perfect after hibernation. To me this is indicative of an EDID-related issue.

From Terminal: sudo pmset -g I guess you've kept hibernation mode enabled (it's enabled by default). Hibernation did not use to be supported on Hackintoshes but recent Clover versions do now. You can look it up here if you want. If you want to disable hibernation and just use plain old sleep: sudo pmset hibernatemode 0 sudo pmset hibernatefile /dev/null sudo rm -f /var/vm/sleepimage

This is usually a hibernation wake screen... Check your power management settings.

Not sure it would improve anything but I noticed you did not disable SIP. You'd normally do this by adding the following 2 x parameters in the RTVariables section of your Clover config plist: CsrActiveConfig -> 0x03 (or 0x67) BooterConfig -> 0x28

Well spotted, I totally forgot that on! The VoodooTSCSync kext is indeed usually required on chipset GM945-based laptops. You'll find it in one of the D430/D620/D820 packs. Lack of it is probably the cause of your KPs.

There's a dedicated section to WWAN module on this forum. Look it up.

Ignore that part of RampageDev's guide, it's obviously incomplete. Regarding your DSDT _DSM Method, you could certainly do without the DualLink + device-id parts. I don't know what the graphic-options part does, I'm not familiar with it. Try without them 3 and save a revised DSDT under a different name than the default one so that you manually call it at boot time. That will allow you to revert to existing one by default if things went wrong with the new one(s) you test. Method (_DSM, 4, NotSerialized) { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package () { "AAPL,snb-platform-id", Buffer (0x04) { 0x00, 0x00, 0x01, 0x00 }, "model", Buffer (0x17) { "Intel HD Graphics 3000" }, "hda-gfx", Buffer (0x0A) { "onboard-1" } }) }

Correct me if I'm wrong or aren't all your above ids incorrect? Desktop HD4600 is vendor 8086 (Intel) -not 8085- and device 0412. As such, I believe the IntelGFX parameter should have been set to 0x04128086. No Azul FB kext patching would normally be required to get QE/CI unless the default ports do not support/match your rig of course (but I'd be surprised).

Maybe an EDID issue then... What happens when you put laptop to sleep then wake it? Did you try HDMI output? Regarding the SNB FB, it's probably injected in the DSDT. Post a zipped version and I'll double check or open up your DSDT and look at the _DSM Method of IGPU device defined at address 0x00020000. What you're after is a little piece of code that specifies a 4byte layout-id and it should look like this: "AAPL,snb-platform-id", Buffer (0x04) { 0x00, 0x00, 0x01, 0x00 }, More details at: http://www.rampagedev.com/?page_id=200&page=3

You did not specify your exact CPU model (other than i5), so I assume it's a Sandy Bridge model (i.e. i5-2xxxx) since you mentionned Intel HD3000 graphics. Sandy/Ivy Bridge platforms do not require KernelPm parameter (but setting it won't do any harm). Only AsusAICPUPM is required to avoid KP at startup. Unless you have a discrete nVidia GPU fitted to that Samsung, you should remove the parameter nv_disable=1 (not required on systems with iGPU only) You should set GraphicsEnabler to Yes (to auto-detect the iGPU) Do you inject the SNB framebuffer layout-id through DSDT? If not, you can inject it via Clover. Be careful not to re-use, as is, files/bootpack from the NP 900X3C/4C (for instance the DSDT) as these are IvyBridge-based and therefore a later generation than yours (different CPU and chipset family, different iGPU, different audio codec, etc.). Only some hardware accessories may be identical (like SD card reader, LAN card, etc.) and kexts would indeed be re-usable, but you have to check first.

Please do, I'm sure that can be of interest to other people. Post your zipped EFI folder with patched DSDT, Clover Config.plist and add-on kexts.

'could also be a side effect of an incorrectly decompiled DSDT table. Rehabman's always recommends to decompile with iasl line command and recompile with MacIASL. Version RM-1.31 (RM252.2) preferred and works always perfectly. Post your file(s) so we can have a look.

What resolution is your screen. You may need to add DualLink to your boot loader config if LCD is Greater or Equal to 1600x900.

No problem running Sierra on that rig. Same installation & tuning process as for El Capitan.

Dell systems are not subject to whitelisting.

I got hold of that old PC again so took another chance at sorting out the graphics. Radeon HD 5430 is handled through the following ATI/AMD controller and accelerator kexts under Mavericks: AMD5000Controller AMDRadeonX3000 The controller kext already contains the PCI id for the Radeon HD 5430 (1002:68e1) but not the accelerator. In order for the latter to load for the card, it is necessary to patch its Info.plist file to replace PCI id 1002:68e0 by 1002:68e1 under the AMDCedarGraphicsAccelerator personality, i.e. Before: <key>AMDCedarGraphicsAccelerator</key><dict> [...] <key>IOPCIMatch</key> <string>0x68E01002</string> [...] </dict> After: <key>AMDCedarGraphicsAccelerator</key><dict> [...] <key>IOPCIMatch</key> <string>0x68E11002</string> [...] </dict> ` Thereafter, one of the AMD5000Controller personalities can be called to try and reach full graphics acceleration. These are: Douc / Langur / Uakari / Zonalis / Alouatta / Hoolock / Vervet / Baboon / Eulemur / Galago / Colobus / Mangabey /Nomascus / Orangutan I won't go into explaining how ATI/AMD graphics works (because I don't master this) but AMD controller personalities basically define various models or profiles of graphics arrangements in terms of connector-type. I guess it's somehow similar to layout-ids of Intel HD iGPUs. There are excellent threads on the matter at InsanelyMac. These personalities contains a variable number of connector-type and the connector-type settings vary according to the personality. This HP G72 is fitted with 3 video outputs: built-in LCD (LVDS), VGA and HDMI. The target is therefore a personality with 3 x connectors. Decoding the AMD5000Controller kext using bcc9 tools reveals 4 x personalities with 3 x connectors: Personality: Baboon ConnectorInfo count in decimal: 3 Disk offset in decimal 1447248 0000000 04 00 00 00 14 00 00 00 00 01 00 00 01 02 01 03 0000010 00 08 00 00 00 02 00 00 00 71 00 00 22 05 02 01 0000020 10 00 00 00 10 00 00 00 00 01 00 00 00 10 00 02 0000030 Personality: Eulemur ConnectorInfo count in decimal: 3 Disk offset in decimal 1447296 0000000 04 00 00 00 14 00 00 00 00 01 00 00 01 02 01 04 0000010 00 08 00 00 00 02 00 00 00 71 00 00 12 04 04 02 0000020 10 00 00 00 10 00 00 00 00 00 00 00 00 10 00 01 0000030 Personality: Hoolock ConnectorInfo count in decimal: 3 Disk offset in decimal 1447136 0000000 00 04 00 00 04 06 00 00 00 01 00 00 21 03 05 01 0000010 00 04 00 00 04 06 00 00 00 01 00 00 11 02 04 02 0000020 04 00 00 00 14 02 00 00 00 01 00 00 02 04 01 03 0000030 Personality: Langur ConnectorInfo count in decimal: 3 Disk offset in decimal 1446864 0000000 00 04 00 00 04 06 00 00 00 01 00 00 21 03 04 02 0000010 00 04 00 00 04 06 00 00 00 01 00 00 11 02 01 01 0000020 04 00 00 00 14 02 00 00 00 01 00 00 02 04 05 03 0000030 ` Calling on any of those personalities and injecting LCD screen EDID does not bring life to the built-in LCD, nor graphics acceleration and access via ScreenSharing remained the only way to access the system. However, I noticed that if I plugged a screen to the HDMI port, I obtained graphics acceleration within ScreenSharing (despite a black screen too on HDMI display) I therefore started to look at patching one of the AMD5000Controller personalities. I picked up Eulemur and, using the IM threads/guides here and/or here as a reference, I extracted the AMD ROM, decoded the video ports info (LVDS: 10 00 01 07, HDMI: 21 03 02 01, VGA: 00 10 03 08) and patched the personality as follows: Before: 04 00 00 00 14 00 00 00 00 01 00 00 01 02 01 04 -> DVI 00 08 00 00 00 02 00 00 00 71 00 00 12 04 04 02 -> HDMI 10 00 00 00 10 00 00 00 00 00 00 00 00 10 00 01 -> VGA After: 02 00 00 00 40 00 00 00 08 01 00 00 10 00 01 07 -> LVDS or 02 00 00 00 40 00 00 00 09 00 00 00 10 00 01 07 -> LVDS 00 08 00 00 00 02 00 00 00 01 00 00 21 03 02 01 -> HDMI 10 00 00 00 10 00 00 00 00 01 00 00 00 10 03 08 -> VGA All I managed to obtained was good video output off the HDMI port (no black screen) with full graphics acceleration. Nothing on built-in LCD and nothing on VGA, both remaining dark with undetected display. Could try patching the other 3-port personalities but this remains an unfinished business...

I do not trust kext utility to rebuild the cache. Sometimes, rebuilding the cache fails and I doubt kext utility reports it. USB may not be fully functional because you need to tune your system for that under El Capitan... You gotta do things to the full and properly... How did you complete the CPU & GPU tuning? -> PM...

Neither mein General! It's long been recommended to keep /S/L/E as vanilla as possible. Kexts place in your Clover EFI/CLOVER/kexts/10.xx folder are not cached, only injected. That means slower boot time. I recommend you copy your add-on kexts to /L/E then repair permissions and rebuild cache. That's the optimal setup. From Terminal, enter the following line commands to repair perm + rebuild cache: sudo chmod -Rf 755 /L*/E* sudo chown -Rf 0:0 /L*/E* sudo touch -f /L*/E* sudo kextcache -Boot -U / -

I you have not done so, apply the FakeSMC & AGPM performance tuning. https://osxlatitude.com/index.php?/topic/2673-performance-tuning-with-fakesmc/ https://osxlatitude.com/index.php?/topic/7807-nvidia-gpu-performance-tuning-with-agpm/

Copy the package (~47Mo) found inside the mounted dmg on your desktop before you run it. Then ONLY select the IDT 79B2 patched AppleHDA, nothing else and make sure to have the vanilla AppleHDA in /S/L/E to begin with.

Well the poster of the kexts indicated that he did not test the kexts of his update! You should tell him it's not working... This being said, Yosemite and El Capitan will have audio perfectly working with an earlier patched AppleHDA. Look up the various E6400/E6500 threads of the forum for a copy or look for details of the patch and apply to your vanilla kext. What codec does BIOS or DCPIManager show? PokenGuyen's HVT tool has a patch for E6400's IDT codec 76B2. It's a simple matter of applying the patch (and only that). It'll patch your vanilla AppleHDA placed in /S/L/E (keep a backup somewhere safe beforehand). It works fine with Yosemite and should still work fine with EC. If not, you should be safe to re-use the patched Yosemite AppleHDA kext in EC.

According to Dell, audio controller is Realtek ALC3246 4ch HDA, i.e. codec ALC256. http://www.dell.com/support/manuals/us/en/19/latitude-13-7370-laptop/Latitude7370_OM/Audio-specifications?guid=GUID-86CA96C0-DE85-4BC6-81D0-424907F9A6D3&lang=en-us