Hervé

You Clover setup is incorrect and your config therefore needs to be revisited and adjusted. In particular, remove that "Drop OEM" for SSDT and remove those "Generate P states" + "ASPN" + "APLF". These are not applicable to a Haswell laptop. In addition, there should be no need to apply "Patch APIC" + "DisableASPM" + "FixIPIC" + "FixSATA". On the other hand, unless you've patched your DSDT to that effect, you'll need "FixDarwin7" to have USB3 working. God only knows what else may need revisiting... NB: Please don't quote messages to post direct replies; use the Reply box at the bottom of the pages; thank you.

So, you wake to a dark screen. It's therefore a wake issue, not a sleep issue. It really is necessary to be specific when dealing with Hackintosh matters you know... 3 x things: you could wait up to 5mins and see if the screen lits up (I experienced this on my E6440 when I still had it) experiment with darkwake=n boot arg to your config (where n=no|1|2|3|4|8|10) add boot arg igfxonln=1 to your config

According to Dell's own documentation, Haswell E5540 is fitted with regular (not I2C) Alps Touchpad; as such: try Dr Hurt's VoodooPS2Controller R6 to begin with add the SSDT-BRT6 to your config in parallel

The BRT6 ACPI patch, whether implemented as a DSDT patch or a dedicated patched SSDT, has worked on all my recent Dell Hackintosh laptops: E6230, E6440, E7250 and 7490. I would therefore expect it to be applicable to your Haswell E5540 too. It's totally unrelated to USB ports (you posts were moderated to that effect in order to avoid all possible confusion) and it's not related to the PS2 kext used either; why? Because, if I use/used DrHurt's R6 kext on my E6230/E6440/E7250, I had to use a different kext on the I2C-based Latitude 7490 and the BRT6 patch was still effective.

EFI appears a little odd: you use the EC SSDT patched table for a laptop rather than desktop you apply the IOHIDFamily patch for -SingleUser function which usually only applies to OpenCore on legacy BIOS systems Anyway, please describe what the sleep issue is exactly. For instance: computer does not engage any sleep action at all (everything stays as is) or computer tries to go to sleep, screen goes off but computer wakes immediately; things like that.

2 x comments: Microphone is under the control of the audio driver, whether you use AppleALC (which works with AppleHDA) or VoodooHDA (which disables AppleHDA). Then, it's down to a matter of the kexts having the correct definitions for the Codec. No such thing as a "microphone EFI". Please search the forum before posting as your issue has already been reported and addressed here.

@Nhật An Would you please detail what you did? Would be most useful for the community...

I experienced the same issue on a couple of my Hackintoshes (the Haswell Toshiba laptop and the old Penryn Vostro desktop): no update to Big Sur 11.2.1 offered on either system, despite using a Big Sur compatible/supported SMBIOS downloaded the 12GB Big Sur package from the AppStore on the Toshiba Hack and re-installed, only to end up with same 11.2 build 20D64 as before So, I started experimenting and, to me, it's related to OpenCore. I'm yet to establish whether it's related to the version of OpenCore, some incorrect settings in the config or some side effects from using OCC (or a mix of them all) but I can tell that the 11.2.1 update was offered to me on one the Haswell Toshiba Hack after reverting from OC 0.6.6 to OC 0.6.3. This is what I did: made a backup of active OC 0.6.6 EFI folder in the ESP took the original OC 0.6.3 EFI folder of my Ivy Bridge Latitude E6230 and replaced its ACPI tables + kexts by those required for the Toshiba Hack (as used with OC 0.6.6) replaced OCC v2.27.0.0 by v2.16.0.0 and adjusted the OC config with OCC to reflect what was required for the Toshiba laptop (ACPI/DeviceProperties/Kernel/PlatformInfo) as per what was used with OC 0.6.6 replaced the OC 0.6.6 EFI folder on the ESP of the Toshiba Hack by the modified OC 0.6.3 EFI folder (of E6230 origin) Rebooted into Big Sur 11.2 with this OC 0.6.3 setup and... Bingo! The update went ahead when I launched it and the Toshiba Hack is now running Big Sur 11.2.1.

Well done, I guess the boot arg was the key!

E6440 is fitted with Alps TouchPad that works perfectly with Dr Hurt's VoodooPS2Controller set of kext. Use version labelled R6 by Bronxteck as available in the dedicated thread in our R&D forum section.

For audio, just use AppleALC which is a plugin of Lilu. Look up the various layouts to try out on the AppleALC wiki and experiment. Google for AppleALC kext and you'll find all you need. You would only need to update Clover if you wanted, say, a bug fix or to run a more recent macOS version that requires a minimum version of Clover. Here too, you can look it up on the Web at places like Did's Github repo for instance.

1st of all, you should disable hibernation as explained in our FAQ section. 2nd, not much can be said without knowing the details of your setup (OS version, bootloader, zipped EFI folder, etc.)

New version v2.4 released. Aims to improve sleep/wake behaviour with RTS5227 reader.

https://osxlatitude.com/forums/topic/9966-how-do-i-disable-hibernation-for-sleep/?tab=comments#comment-71887

Nothing weird with having no Bluetooth working if that's what you meant. Would be a Qualcomm Atheros module too and those were also finicky when not plain unsupported. https://wikidevi.wi-cat.ru/Qualcomm_Atheros_QCNFA435 Replace that unsupported QCA card by a supported Broadcom model.

Correct. Maybe you can check if the freeze on wake still happens under 11.2 and OC. I suppose I'll have to try it out again with OC 0.6.6.

You're using an old Clover setup with old kexts and some incorrect settings, though none that would normally prevent proper macOS installation. Refresh all kexts to their latest versions.

follow the kextcache command with: sudo kcditto

Catalina now, so split to separate thread... I can't understand why your system would load (and crash) Broadcom wireless drivers when you stated you have an Intel wireless card in your Big Sur thread... If you want further assistance, please post a zipped copy of the EFI folder you use. Indicate which boot loader you use and which version.

As long as your i3 is fitted with HD4000 iGPU not HD2500, you're good to go up to current Big Sur. See our FAQ section re: making USB installer without a Mac or a Hack; then look up any existing guide for Ivy Bridge Latitude E5x30 or E6x30 laptops.

macOS normally runs perfectly and totally stable on these Broadwell laptops with all hardware fully supported.

Issues with disks in Media Bay have been discussed in the past, mostly for E6x30 if I recollect properly. Did you check these out? Basically, you need to patch AppleAHCIPort kext. You'll find details on the forum in threads such as these: https://osxlatitude.com/forums/topic/12639-solved-e6430-catalina-new-install-2nd-hdd-in-media-bay-not-readable https://osxlatitude.com/forums/topic/13202-solved-e6330-successful-upgrading-to-catalina-but-major-problems/ Can't say if the patch remains the same in Big Sur but look it up.

I don't usually use GB5 but I just got about the same results as you: 774 & 1703. I'm not sure there is much to say or conclude about those benchmarks. Here's what I obtained with GB4.4.4: Catalina/Clover: 3705, 7500 Big Sur/OpenCore: 3809, 7401 Big Sur/Clover: 3821, 7460 Strange about those graphics glitches you encounter in Mojave and Catalina. Not seen/experienced those. Did you have the Capri framebuffer memory patch in place? Anyway, water under the bridge if you're happy with Big Sur and it's fully functional with Clover

Can't see why the ALC293 audio of the E7450 wouldn't work with layout #11 like it does with ALC293 of the E7250. Try and add CodecCommander kext to work alongside Lilu + AppleALC. Make sure those are the latest versions too. Looking at your OC config, I see that you have arguable ACPI patches in place; for instance, you inject SSDT-EC.aml table (which is good) but you also apply the ACPI patch that renames device ECDV to EC; you should only use the former, not the latter which is now deprecated, especially as you end up with 2 x EC devices, so potentiel conflictual situation, wouldn't you say? Check your other ACPi patches too!