Hervé

JakeLo beat me to it but here's your DSDT patched with: Minor syntax corrections (e.g.: renaming of "_T_x" to "T_x", renaming of "*pnpc13" to "PNPC13") EHCx USB2 controller devices renaming to EH0x (for USB2.0 ports) B0D3 device renaming to HDAU (for HDMI audio) GFX0 device renaming to IGPU (for integrated HD4600 GPU) _DSM method injection to IGPU device to fake desktop HD4600 id 0x0412 and inject Azul FB #12/layout id 0x0a260006 "Darwin" check injection to ensure XHC/USB3.0 controller native recognition IRQs 0,8,11 exclusion off HPET device to fix USB issues _DSM method injection to HDEF device to declare ALC292 audio codec There are probably a few more patches to inject to fix Sleep/Wake eventual issues, but you can already give that patched DSDT a try... DSDT.aml.zip When you 1st boot, use the following options and flags: KernelBooter_kexts=Yes -f -v CsrActiveConfig=3

Well, it's only a plist patch, not a full blown kext per sé. So you won't see it as a loaded kext indeed.

Sounds like you forgot to repair permissions before you rebuilt the cache. Look at the dedicated thread in the FAQ section.

Try and extract your BIOS tables so that we review them. This can be done in Windows with tools such as Aida64 (can't remember the extact version but I think Engineering should do) or Clover by pressing F4 (if you have a Clover bootable USB key; tables will then go to EFI ACPI/origin folder).

Use Clover Configurator app and read up the Clover wiki to learn on the tool, what it does and how it works. This glitch does not prevent booting the USB installer or the installed OS in any way. It's just that, a display glitch. If your system fails thereafter, you have an issue elsewhere, probably at graphics initialisation. Boot in verbose mode (-v flag) to see where the boot process hangs/fails. You can also follow my Enoch-based E6440 Sierra guide available in the Guides section.

Good old "2nd stage/final stage boot glitch". Fixed either by installing/injecting IntelGraphicsFixup.kext + Lilu.kext or by applying the following Sierra on-the-fly patch in Clover: Find: 0100007525 Replace by: 010000EB25 Target: IOGraphicsFamily kext -

The key difference between the E6220 and your E6420 is that the former is limited to LoRes 1366x768 LCD whereas your laptop has a HiRes 1600x900 LCD. As such, you absolutely need to set/activate/tick DualLink in your Clover config (or set this through DSDT) if you run on the HD3000 iGPU. Once you've done that, you'll find your screen will work fine.

In your Clover config: APCI section/tab: there's a reference to load a SSDT-6 table that's nowhere to be found SMBIOS section/tab: you use MacBookPro8,2, I think you should use MacBookPro8,1 (you have a dual-core i5-2520M, not a quad-core 2nd gen i7) Your DSDT injects SNB layout id 00010000 and Dual Link, so you should be Ok once you correct the above. If you still have issues with graphics, you could try to switch to MacBookPro8,3 SMBIOS and SNB layout id 00020000.

Look at the DSDT I posted in my E6230 guides. You'll see that there can be extra code to inject in addition to the PWR method.

Please consult the FAQ section. Thx.

re: instant wake on sleep, it's probably due to missing power-related ACPI code under the USB controllers in your DSDT. Did you check that out?

Guys, I just got in touch with Dinesh. He's busy on finalising the forum/server migration right now but he'll update us on this driver by the end of next week.

Dell Latitude E6440 with Kingston SA400S37/240G A400 240GB 2.5" 7mm SSD (SATA-III connection @6Gb/s):

I guess you need to inject the SNB platform id as suggested in my previous answer. But you can also try the following settings as mentioned here at IM: fake iGPU is 0x01168086 inject snb-platform-id 0x00010000 use SMBIOS iMac13,1 (you may also try iMac12,1 or iMac12,2)

A few comments: your Clover config fakes HD3000 iGPU id 0x01268086 but does not inject any HD3000 ig-layout-id. Your patched "System DSDT" does not either (and you load that table through Clover). why do you select "Load VBios" and "Patch VBios" in your Clover->Graphics settings? I don't think you'll manage to get graphics acceleration that way... If you look at the IOReg of a Mac Mini5,1 as availabe through the link posted here, you'll see that it's HD3000 iGPU@2 carries id 0x01268086 (which you've got covered) and uses snb-platform-id 0x10000300 (which you've not covered). -> inject ig-layout-id 03000010 in your Clover config.

I don't think you generated your CPU-specific SSDT for power management. This is done with Pike R Alpha's well-known SSDT generator tool. The resulting SSDT goes next to the DSDT in ACPI/patched Clover EFI folder. In case you no longer boot because Clover kext injection changed from "Yes" to "Detect", you should be able to overwrite this from Clover's default menu at boot time.

Seems to be AICPUPM related. Your Clover config showed you had applied the associated patch. Things you can do: In your Clover "System Parameters" section/tab, change "Inject kexts" from "Yes" to "Detect" Make sure you only run with the vanilla AppleIntelCPUPowerManagement (AICPUPM) kext (in /S/L/E) Repair your /S/L/E & /L/E permissions and rebuild your cache

Replace your current and older version of lilu kext by version 1.2.2 or 1.2.3 (latest at time of writing) Add AppleALC kext (it supports IDT 92HD93 of our Latitude E6x30 laptops) Add latest CodecCommander kext You should then have full audio running with vanilla AppleHDA. For Sleep, please consult the FAQ section of the forum.

Unless you do it through Clover, yes you need to inject layout 12 (0x0C) to HDEF device of your DSDT.

Why did you do that when you already moved them to /L/E? Where add-on kexts should go... Ever read the FAQ section?

What did you do to break it?

Ok, confirmed to work on ALC292 with: vanilla AppleHDA in /S/L/E layout 12 injected in HDEF DSDT device AppleALC v12.4 + Lilu v1.2.2 cached from /L/E So it must be a matter of layout in your case. You could also try to switch from EAPDFix to CodecCommander.

Well, I guess it's a matter of audio layout-id then. According to the AppleALC wiki, ALC293 works with layout 28 & 29 but I don't know if that's universal... Which do you use/inject (DSDT/SSDT/Clover config)? I'd have to check on my E6440 which is still running with good old dummy ALC292 and layout 1. AppleALC wiki states ACL292 works with layout 12, 18, 28.

Why don't you try to move those kexts from the Clover EFI folder to /L/E like some of your other add-on kexts. It's always better to cache kexts than inject them at boot time.

Try and repair full permissions through Disk Utility.