Hervé

Your patched DSDT injects layout 2, so that's incorrect and clearly clashes with your other audio settings: Device (HDEF) { Name (_ADR, 0x001B0000) // _ADR: Address [...] Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { [...] Return (Package (0x0C) { [...] "layout-id", Buffer (0x04) { 0x02, 0x00, 0x00, 0x00 }, [...] }) } } Remove that from your HDEF _DSM, clear the item counter of the Return Package line (or reduce it from 12 to 10), recompile the DSDT and you will be good to go. Re: DW1510, did you consult our wireless cards inventory ? Because the answer is there...

Audio works with Lilu + AppleALC + injection of layout 12. The stuff you posted shaw that you do, so there could be an issue with your patched ACPI tables (not provided). Wireless depends entirely on the card you use. Refer to our FAQ section and wireless cards inventories.

Yes, that's a well-known boot glitch we all encounter. The old IOGraphicsFamily patch used to take care of that but WEG now does (and I can confirm this on my E6230). If it's not the case for you which would surprise me, you could always try to re-instate the old patch but you'd have to check if Catalina would use the same one as Mojave for instance. Your kext set is very messy and contains numerous kexts that are irrelevant, not required and contradictory. Those will impact the usability and operation of your E6530 Hackintosh. I'm talking about kexts related to irrelevant chipsets (Series 200, x99, nForce, Via), CPU power management (NullCPUPM), audio (patched AppleHDA vs. AppleALC), etc. I suggest you look into (and use) the Clover packs available in our various recent E6x30 guides to address this as well as patched ACPI tables so that you have a fully and properly working Hack (with USB3 functionality).

Updated to BIOS A20 and all runs Ok (with A19 patched DSDT).

Just updated BIOS to A20 and all is working perfectly with Cover patches and patched A19 DSDT. This being said try and adjust your Clover config with Clover configurator app to compare: ACPI config remove PluginType Add Drop SSDT CpuPm Add Drop SSDT Cpu0Ist

You should open up your own thread and post your debug package. This thread is now getting seriously off-topic, being about Mojave 10.14.2...

Booting straight into Sleep usually is a sign of incorrect settings for CPU power management but you seem to have all in order. I see a CPU-specific SSDT for an i5-3320M matching your signature so I presume you generated it yourself since it appears it was compiled under 10.15.1. Everything indicates you used my E6230 Clover boot pack so I think it's fair to say you also followed my guide. Did you install any kexts in /S/L/E or /L/E for caching too are are you just injected kexts from Clover? The only obvious thing that differs between our individual setups (outside the Bluetooth kexts which, imo, are irrelevant to your predicament) is the BIOS version; I run A19 when you're still on A11. I would most certainly recommend you update to A19 too. A new version A20 got out since since I myself updated but I've not proceeded to install it; maybe it's time I do...

Are you still using that Niresh distro? If you do we can't help you. If you now use a vanilla macOS installation package and follow the guidance available in those links Jake Lo provided you with, no reason why it would fail beyond typical things like defective USB key or incorrect BIOS settings. If in doubt re: BIOS settings, Jake Lo's guides usually advise to reset BIOS settings to factory default and set set disk mode to AHCI among a few other things. Looking at his E7240/E7440 guide, it certainly is the case. I will now close and archive this Niresh-related thread.

Follow the E7x70 guide available in our Guides section. CPU model is irrelevant.

I had detailed it in my old E6440 guide; have a look there, the patch remains identical; or look up the Darwin injection in lt E6230 guide; it's the line where OSYS is set to a specific value when the OS is Darwin or Windows 2006.

Did you inject Darwin, either in DSDT or through Clover? That's usually necessary on Ivy Bridge platforms to enable USB3 controller.

Yes, sorry for my mistake, I was writing about CPU PM in relation to Sandy + Ivy Bridgers and wrote "Sandy" instead of "Ivy." All E6x30 are of course 3rd gen Ivy Bridge, not 2nd gen Sandy bridge. JakeLo's guide does indeed mention a version of BIOS that, for years, was not to be exceeded but subsequent versions can actually be used if you apply the Capri FB memory size patch. I can vouch for it, I'm using BIOS A19 on my E6230 that, for years, was said not to be updated beyond BIOS A11 or A12 to avoid graphics corruption and garbled screen. Since you're on a highest BIOS version, it's not as if you have anything to lose by applying the patch anyway. I'm pretty sure you'll find it works and that'll save you the hassle of downgrading BIOS which requires a 2 phase approach: 1) downgrade to the lowest possible BIOS (eg: version A01/A02/A03) 2) upgrade to BIOS A11 For the rest, yes, you can follow Jake Lo's guide since you probably did not use his Clover pack in the 1st place.

That would be surprising but you could check in IOReg with IORegistryExplorer. Note that if your M4800 has USB3 and USB2.0 ports as I expect it does since it's a Haswell platform, you should probably install Rehabman's latest FakeCPIID + FakePCIID_XHCIMux kexts to gain USB multiplexing and get all the USB hubs properly reported.

-> Moving to the correct Dell support section. Please make every effort to post in the correct sections in the future. Guides sections are clearly labelled "No support here"... You need to apply the Capri framebuffer memory size patch; details are available in my E6230 guide posted in the Guides section. Then there are a few things that need to be looked up and adjusted in your Clover config: 1) Devices: I suggest you remove that very incorrect entry; there is absolutely no need to fake any iGPU with the iGPU of the E6x30 Series 2) Graphics: remove "inject intel" + the ig-layout-id you currently inject. Lilu + WEG take care of that and the layout-id you inject through Clover contradicts what you already inject in DSDT, i.e. the HiRes layout 0x01660004 which is accompanied with DualLink boolean set to true. I presume you have a HiRes screen... 3) Patches: KernelPm patch is for Haswell and later platforms for which CPU power management got transferred to the kernel. Your E6530 is Ivy Bridge and therefore CPU power management is managed by the AppleIntelCPUPowerManagement kext. You need to enable AppleIntelCPUPM patch instead which applies to Sandy Bridge and Ivy Bridge platforms. IOGraphicsFamily patches are obsolete now and WEG takes care of everything. You can remove this. You're mixing direct cached kext references with com.apple.xxxxx; If, at some point in the past, the 2nd got mandatory, things reverted back to what they initially were and I'm not sure the com.apple.XXXXX still works these days. But I guess you can tell us if that's the case or not.

Sorry but we can't support Niresh, we've no idea what's been included in that distro. As a general rule, it's best to stay off these things. If you want to keep using it, I suggest you seek support at their forum.

Arf, BIOS 1.12.2 posted today !!! Anyway, you probably don't run it yet...

My guides include clear instructions with regards to Clover: version + installation settings. If you choose to copy an existing EFI folder from a different computer and build, I cannot vouch you'll be in the verified working conditions and, therefore, cannot really assist more. I'm sure you'll understand that I'm not prepared or willing to troubleshoot an installation that was not done by following the detailed instructions I posted. If you run the same version of BIOS (at time of writing, latest remains 1.11.0 afaik), the DSDT is the same; it does not differ according to CPU model. If it did, Dell would provide different BIOS for different laptop models! As such, there's nothing to do on the matter; it's just that some people cannot boot with my patched DSDT for reasons I cannot comprehend. This being said, the patched DSDT serves 1 purpose only: activate brightness control through Fn-F11/Fn-F12. Jake Lo posted SSDT alternatives, so you can use that instead rather than my patched DSDT. All you really need for Catalina compared to Mojave is: add the ECDV to EC renaming in your Clover config; rest of the config is identical update Lilu kext and Plugins to latest versions

These days, you'd start with Rehabman's USBInjectAll kext and once macOS is running you can fine tune USB ports with Hackintool app which scans and detects all the USB ports on your computer. Hackintool can then generate 2 things: a table called SSDT-UIAC.aml which is to be used with USBInjectAll and a kext USBPorts which is to be used on its own (i.e. without USBInjectAll and SSDT-UIAC). This being said, you can check if your USB-internal webcam is detected through SysInfo; if it is, it'll be listed in the USB section where you'll see its PCI ids (vendor + device). It would look fairly similar to this with, additional USB hubs for USB2.0:

Best is probably to use a DW1560 if you want wireless working.

What's the model? Its PCI id? Is it USB or PCIe?

What's the model?

If you cannot disable the nVidia card and/or can only run on it, you'll be limited to High Sierra since that's the last version with Web Drivers available. GTX 1070 is Pascal and that's only supported with Web Driver; no such driver since Mojave and there won't be (you can Google for the whole story between nVidia and Apple). You'd only be able to run Mojave or Catalina on the Intel iGPU and have the nVidia chip disabled through DSDT/SSDT patching in order to save battery life. Then Catalina needs renaming of the Embedded Controller ACPI device and you're not doing that. See our thread entitled Minimum requirements for Catalina. It's pinned to the Our Picks column on the forum main page.

If this relates to the Latitude E6420, JakeLo posted a High Sierra guide here and Clover packs here. With regards to these Olarila builds, I would suggest you 1st inquire about them on the Olarila forum.

The lspci exec of the above package is 32bit and therefore cannot be run in Catalina. I'll try and post a 64bit version asap. Meantime, a quick alternative is the dspci 64bit exec provided with DPCIManager v1.5 package.

Please consult our inventories available in R&D->Wireless & Bluetooth forum section. If, as I presume, you need an M.2 card, DW1560 is your best shot. Alternatively, DW1830 if your slot can physically take the card and you have 3 x antenna wires at your disposal.