Hervé

Maybe because it was compiled with another tool such as DSDTEditor or the file is corrupt.

BIOS upper limit for OS X should be around same version as for the E6230, i.e. A11. It could be A12 of course but I don't think you can go much higher... Do a Search on the forum on "E6330 BIOS" and see what you find... Failing that, best way to know is to try until your graphics go bad, then reverse to oldest possible version like A02 and upgrade again to the highest safe version. I'd bet money on A11.

No, you're missing the point totally. You won't be able to boot your installed system unless you copy the /Extra folder and the necessary kexts to your freshly made OS X installation. Reboot your USB installer, go to the main installer screen and run Terminal from Tools menu. Then copy the Extra folder from your USB key to your freshly made OS X volume/partition. diskutil list -> to identify the name of your freshly made OS X volume/partition cp -Rf /Extra /Volumes/<name of identified OS X partition> ` I can only advise you to read my Chameleon/Enoch-based Yosemite/ElCapitan/Sierra guides posted here to familiarise yourself with the actual installation process. Until you fully understand it, you will probably not succeed. This being said, you must have managed to copy something to be able to boot OS X. Maybe you're actually using distros... But if you've not copied the Extra folder, you're missing the DSDT so you'll have to manually set DualLink through Chameleon boot option EnableDualLink=Yes. You may add Injectntel-ig=00000100 but that's probably not necessary with HD3000. If in doubt, type "?" at Chameleon prompt and you'll see some help on the boot flags and options.

Cards based on AR9285 Atheros chip require either a patch of the Atheros40 kext or a simpler DSDT patch as published in the wireless card inventory thread. It's a simple matter of identifying your wireless device in IOReg through tools like IORegistryExplorer, then apply the patch to that device in DSDT. You can more or less copy/paste the published patch but all you need is the "compatible" statement.

Erm... did you copy/install the /Extra folder of your USB installer to your HDD partition? Seems to me that you did not...

If you did read the thread, you must have noticed you need a patch...

https://osxlatitude.com/index.php?/topic/8696-is-my-wireless-card-compatible-with-os-x/

No need to activate "Drop SSDT" in the o.c.B.plist; it's not necessary. Same for "Enable DualLink", it's already set in the DSDT (see IGPU section). This being said, can't see why you'd still have graphics issues. But I do wonder how you boot your Yosemite USB installer, namely which Chameleon version are you using and how do you load kexts from /E/E, especially FakeSMC? Please note that the pack is a little outdated and that you should no longer require the patched AppleSDXC kext since a little DSDT patch suffice for the SD card reader. What's the LAN card on a E5420 by the way?

Are they both on the same BIOS A11? Which i3 CPU are we talking about here? Please post a zipped copy of your EFI/Clover folder.

The custom EDID you've injected does not match the 128bytes value extracted. That's a 1st problem. To begin with, leave that blank and just tick the "Inject EDID" box. If you still don't get the screen working, you may then add the correct 128bytes EDID.

No and remove the o.c.B setting, it's not needed. All you need is: 1) the IDT definition/dummy kext copied in /L/E from where it'll be cached 2) patched AppleHDA copied in /S/L/E where it overwrites the vanilla kext 3) permissions repaired on /S/L/E + /L/E and cache rebuilt Assuming you run Sierra 10.12.3, please use the following files: AppleHDA_IDT92HD93.kext.zip Patched_AppleHDA_111D-76DF.kext.zip To repair permissions and rebuild your cache, use the usual Terminal commands: sudo chmod -Rf 755 /S*/L*/E* sudo chown -Rf 0:0 /S*/L*/E* sudo chmod -Rf 755 /L*/E* sudo chown -Rf 0:0 /L*/E* sudo touch -f /S*/L*/E* sudo touch -f /L*/E* sudo kextcache -Boot -U / If you get an error message ".... 77", retype the touch + kextcache commands. Ignore the message if it says "... 17". NB: My E6230 guide was not clear enough in the respect of patched AppleHDA, so I've just updated it to that effect.

For DP output, connector #2 (port #6) should be kept (as expected). The pipe lower byte just needs to be set to 0x12. The patch is as follows: 0600 260A 0103 0303 0000 0002 0000 3001 0000 6000 0000 0060 D90A 0000 D90A 0000 0000 0000 0000 0000 0000 0800 0200 0000 ; connector index #0/port #0, connector-type LVDS 3000 0000 0105 1200 0008 0000 8700 0000 ; sets connector-type to HDMI 0204 1200 0004 0000 8700 0000 FF00 0000 ; sets port pipe to 0x12 0100 0000 4000 0000 0F00 0000 0101 0000 0400 0000 0000 0000 0E00 0000 0000 0000

Ethernet needs to be 1st interface en0, wifi secondary interface en1. You can verify this through Terminal command ifconfig. If you can make them out, check their respective MAC address through the Network PrefPane (displayed in each interface's Hardware tab). The necessary process to set this up properly has been detailed a dozen times so look it up. That'll work for AppStore and FaceTime. For iMessage, that's far more complicated due to Apple's increased security restrictions over the last few years. Google for it and you'll understand.

Please read-up the FAQ! Then use Google where you should find that a cat lover is your friend... Anyone is expected to make a minimum effort...

https://github.com/Piker-Alpha/ssdtPRGen.sh If you download the complete zip archive and install it according to the published instructions, you'll be able to add your own CPU's specs to the database file. The database files are located in your home directory, under Library/ssdtPRGen: The CPU characteristics database files are plain text and can therefore be edited with vi through Terminal or with TextEditor. Just gather your CPU's specs off the web (ARK Intel, cpu-world, etc.). The specs you need to inject are listed at the top of each file.

Disable SIP. Google it up if you don't know what it means. Before you ask, Intel wireless will have to be replaced.

Read through the Bible on 1st gen Intel HD graphics. This should sort you out, one way or the other.

The HDMI patch usually applied to HD3000 (for HDMI audio) may indeed not be applicable to the nVidia model.

The mobile HiRes framebuffer 0x01660004, used for laptops with built-in LCD with a resolution greater or equal to 1600x900, only carries 1 x LVDS output port by default. It must therefore be patched to support additional video outputs and HDMI audio: In the case of Sierra 10.12, the vanilla framebuffer 0x01660004 is defined as follows: 04006601 01030101 00000002 // 1 x display output port 00000001 00000060 10070000 10070000 00000000 60290400 00000000 00000000 00000000 05030000 02000000 30020000 // LVDS port 00000000 01000000 40000000 00000000 01000000 40000000 00000000 01000000 40000000 00000000 00000000 00000000 and, building on the patch for LoRes FB 0x01660003, it can be patched to this: 04006601 01020402 00000004 // /!\ patch: 4 x display output port 00000001 00000060 10070000 // *** unmodified *** 10070000 00000000 60290400 // *** unmodified *** 00000000 00000000 00000000 // *** unmodified *** 05030000 02000000 30020000 // *** unmodified *** LVDS 02050000 00080000 07040000 // /!\ patch: HDMI (for audio) 03040000 00040000 81000000 // /!\ patch: DP/DVI (untested) 04060000 00040000 81000000 // /!\ patch: DP/DVI (untested) 00000000 00020011 00000000 // /!\ patch The patch is not a mirror copy or copy/paste of the contents of the LoRes FB. In particular, it's critical to leave the LVDS port definition unchanged (code line starting with 05030000...). In a nutshell, the AppleIntelFramebufferCapri patch consists of: Find: 040066010103010100000002 Replace: 040066010102040200000004 + Find: 0503000002000000300200000000000001000000400000000000000001000000400000000000000001000000400000000000000000000000 Replace: 0503000002000000300200000205000000080000070400000304000000040000810000000406000000040000810000000000000000020011

It appears you're confusing things so let's get some facts right to begin with... All E6x30 models, including the E6430s are IvyBridge. The corresponding integrated Intel GPU is HD4000. Under OS X, HD4000 graphics is handled by the Capri framebuffer. The associated kext is AppleIntelFramebufferCapri.kext. As its name actually implies, AppleIntelSNBGraphicsFB is a SaNdyBridge iGPU framebuffer. For SandyBridge, we're talking about Intel HD3000. Whilst VGA output is supported under HD3000 through binary patching of the SNB frame buffer kext, it's regretfully not the case for HD4000 Capri framebuffer kext. So, no VGA output for E6x30 laptops with HD4000 graphics. DP and DVI outputs are supported OOB off Dell's docking station PR03X. HDMI output is normally supported OOB but Capri framebuffer binary patching is usually required to obtain HDMI audio. E6x30 models with LoRes LCD ( E6x30 models with HiRes LCD (1600x900 and higher) use Capri FB #4 (0x01660004) with DualLink enabled HD4000 supports up to 3 x concurrent displays but that can only include a laptop built-in display if it is fitted with an eDP connector. Regretfully, our Dell E6x30 use an LVDS connector for the built-in screen... This being said, to get multiple external displays working, you need to patch your Capri framebuffer accordingly. You may consult the following threads/posts for guidance: https://osxlatitude.com/index.php?/topic/2945-guide-for-enabling-vga-and-hdmi-in-intel-hd4000-gpu/ https://osxlatitude.com/index.php?/topic/9601-e6430-1600x900-intel-hd4000-gpu/page-2&do=findComment&comment=67699 https://osxlatitude.com/index.php?/topic/7914-dell-latitude-e6220-with-i5-2520m-hd3000-and-1366x768-lcd-mavericksyosemiteel-capitansierra/&do=findComment&comment=57882 (HD3000 but good examples of display tracking through IORegistryExplorer ) I use the following CapriFB patch on my LoRes 1366x768 HD4000 Latitude E6230 under Sierra: Basically, I modified the kext layout 0x01006603: from this 03006601 01020402 00000004 // Vanilla: 4 x outputs ports 00000001 00000060 10070000 10070000 00000000 00000000 00000000 00000000 00000000 05030000 02000000 30000000 // Vanilla: LVDS 02050000 00040000 07040000 // Vanilla: DP/DVI 03040000 00040000 81000000 // Vanilla: DP/DVI 04060000 00040000 81000000 // Vanilla: DP/DVI to this 03006601 01020402 00000004 // Vanilla: 4 x outputs ports 00000001 00000060 10070000 10070000 00000000 00000000 00000000 00000000 00000000 05030000 02000000 30000000 // Vanilla: LVDS 02050000 00080000 06000000 // Patched: HDMI 03040000 00040000 81000000 // Vanilla: DP/DVI 04060000 00040000 81000000 // Vanilla: DP/DVI ` By default layout 0x01660003 defines 4 x display outputs. 2 x key elements to understand are: 1) framebuffers (as seen in IOReg) 2) connector-type Framebuffers (as seen in IOReg): 0503 -> Framebuffer #0 (port 0) 0205 -> Framebuffer #1 (port 5) 0304 -> Framebuffer #2 (port 6) 0406 -> Framebuffer #3 (port 7) Connector types: 0200 0000 -> LVDS 0002 0000 -> DVI 0004 0000 -> DP 0008 0000 -> HDMI Note that DVI often works on DP connector-type 0004 0000. When connecting displays to the PR03X, I see the following in IORegistryExplorer (looking where an external display called "display0" appears): HDMI -> Framebuffer #1, connector-type 0008 0000, port 0x5 DP -> Framebuffer #2, connector-type 0400 0000, port 0x6 DVI -> Framebuffer #3, connector-type 0400 0000, port 0x7 Here with HDMI output connected: Here with DVI output connected: Here with DP output connected (DP-to-HDMI adaptor): Here with DP and DVI outputs connected (built-in LCD off): Here with DVI and HDMI outputs connected:

HDMI video output is normally supported OOB on the E6x20 Series. Try to temporarily disable the SNB patches on you Clover config.plist. They look Ok but they apply to all instances of the Hex sequences, not just to the series of ports under 01020400 10070000 10070000. If it works Ok, then we'll known whether it's the SNB patches or, say, the DSDT. I could not see anything wrong under the IGPU section of your DSDT.

You may want to switch to Clover and activate the "Inject EDID" option...

Ok, so your EDID would be: 00,FF,FF,FF,FF,FF,FF,00,36,7F,25,00,00,00,00,00,2D,0C,01,04,A0,2F,1A,00,EA,A8,E0,99,57,4B,92,25, 1C,50,54,00,00,00,01,01,01,01,01,01,01,01,01,01,01,01,01,01,01,01,40,38,80,A0,70,38,4B,40,34,36, 99,05,DC,0C,11,00,00,18,38,31,80,40,71,38,2D,40,6A,6A,FF,00,DC,0C,11,00,00,18,00,00,00,FC,00,4E, 76,69,64,69,61,20,44,65,66,61,75,6C,00,00,00,FC,00,74,20,46,6C,61,74,20,50,61,6E,65,6C,00,00,DB You can try to inject that in DSDT through "AAPL00,override-no-connect" or "AAPL00,override-no-edid" parameter in a DSM attached to your active GPU.

Mario, you're sure of that compiled kext? Looks very small...

You'll need 10.8.5 installation app because its kernel has support for the Haswell platform. Previous kernels don't. If you've already purchased or downloaded ML from AppStore in the past through your account, it'll be there again to download and you'll obtain the last version 10.8.5. Failing that, you can still purchase it for about $/€20... http://www.apple.com/shop/product/D6377Z/A/os-x-mountain-lion