Hervé

Try and update the card to the latest Bluetooth firmware from Windows using the Dell drivers. I think the required driver is mentioned somewhere in the defunct DW1820a general troubleshooting thread now located in the Archive.

What's the origin of this kext? I can see it contains older versions of the Broadcom PlugIns but I've not verified which macOS version they came from. Can the Atheros40 PlugIn be added to 10.15.4's IO80211Family kext or is this entire revised IO80211Family version need to replace the vanilla one? Did you test this revised IO80211Family kext in /L/E whilst keeping 10.15.4's vanilla kext in /S/L/E?

If it's different from 4096, that is good. That shows that the kexts do load a FW to the module. My DW1820a Bluetooth shows FW v5799 but I had updated it in Windows using one of those Win10 drivers. How does BT behave after you put your 7490 to sleep and wake it?

@Tubardus, Bluetooth module of DW1820a should be fully functional if you use acidanthera's latest kexts (version v2.5.2 at time of writing). There are 2 x ways to use them: if you cache kexts from /L/E, use BrcmBluetoothInjector + BrcmFirmwareRepo + BrcmPatchRAM3 if you inject kexts from Clover's E/C/k/O, use BrcmBluetoothInjector + BrcmFirmwareData + BrcmPatchRAM3 That's what I use (I cache kexts from /L/E) and I don't use AirPortBrcmFixup kext (therefore no use of brcmfx-country boot parameter either) since I found no need for it with my DW1820a, the properties injected through Clover's configuration being totally sufficient. Bluetooth is fully operating with these kexts in Catalina 10.15.4.

And you forgot to state what wireless card you use.

it's a Latitude 5491, not an E5491 which does not exist... Qualcomm card not supported -> to be replaced by a supported model. For the rest, your Clover setup (config & kexts set) is very messy. ACPI renaming contains stuff for Z390 desktop motherboard. Your Clover Kernel & Kexts patches section contains all sorts of irrelevant and inappropriate patches (eg: BDW + SKL + KBL patches). Remove those You selected MacBookAir8,1 SMBIOS, i.e. that of an Amber Lake platform with UHD617 graphics Amber lake model when you have Coffee Lake CPU with UHD630 graphics. Use MBP15,2 instead. Graphics: you inject layout id 12345678, i.e. a fake layout used for troubleshooting graphics in VESA mode. You cannot get any graphics acceleration with this. Replace this fake layout value by one of a UHD630 layout or don't inject anything in Graphics section and, instead, inject any required properties such as layout id (eg: 0x3E9B0000) and iGPU id (but native id should be Ok) in Devices section for device PciRoot(0x0)/Pci(0x2,0x0). Then rely in Lilu + WEG kexts. Get rid of all those XHCI and SATA kexts, they're not required TouchPad will undoubtedly be I2C so you'll need to add the VoodooPS2 I2C kexts and probably the I2C SSDT tables too. Refer to existing Coffee Lake/Latitude 5490/Latitude 5400/Latitude 7490/Latitude 7400 threads for guidance and do a search on UHD630.

You can look at the models for which we've published benchmarking results here. There's only a couple but the best you can do is Google for NVME SSDs compatible with Mac. Example here.

Doesn't 4K require WEG's -cdfon boot parameter to enforce HDMI-2.0 properties? https://github.com/acidanthera/WhateverGreen I would suggest you look into implementing the necessary patch(es) through Hackintool app.

Yes, you may change id if you want to. What do you expect to gain by doing that?

the disablegfxfirmware parameter is only to be used if there is an issue during installation or update to 10.15.4. Once 10.15.4 is running, there is no need for it. For Catalina, you're supposed to use PatchRam3, yes.

No need to use the rm command to delete kexts from /L/E. But I recommend you cache kexts from /L/E rather than inject them from Clover's folder. Caching kexts is the natural mode of operation. Re: headphones noise, make sure you cache CodecCommander kext from /L/E (that one just won't inject). For BT, there's a pinned thread here where you'll find kexts that worked for my DW1820a. I don't use BT much but handoff certainly works between my iPhone and my 7490 with those kexts. In Catalina, you need to use the BT injector kext too, not just the Data/Repo + PatchRAM kexts.

As you said yourself, these are simple warnings and can be totally ignored.

Seems like Tosh is trying to sleep but immediately wakes. So you probably need to sort out Sleep on this laptop.

Should all be sorted now. This 7490 is fitted with a DW1820a wireless card for which the required properties were not injected.

Sorted; laptop is fitted with a DW1820a wireless card and the properties injection were missing. Once they were added, everything worked as expected.

PSU seems big enough to me. The only other thing I can think of is the multiple overclocking you have in place.

It's a boot parameter you specify in Options->Boot Args menu at Clover main screen. Press [ENTER] on the Boot Args field and type the parameter in (caution, keyboard will probably be in QWERTY mode at that stage).

Your Clover setup looks ok (kexts, SMBIOS, general settings). However, it's interesting that you've not need to activate "Inject nVidia"; I'd add that, it cannot cause any harm. What's the purpose of those 2 x shiki boot parameters you use in your Clover config? Did you try without them?

How long did you wait when you get the Apple logo on screen? It can take a couple of mins or more to complete and reach the macOS language menu before the main installation screen. Re: Catalina 10.15.4, bear in mind the following requirements: Clover r5107 latest Lilu + WEG + AppleALC probably need to boot with -disablegfxfirmware boot options (I had to use that to complete my 10.15.4 update) rest of the installation process is unchanged. Out of interest, how do you build your USB installer?

Which BIOS version do you run? You may want to update to latest if you run on an old one. Are your 7490 hardware specs identical or close to mine's? I know the patched DSDT I posted/included in the pack has given trouble to some people in the past so you may want to remove it to begin with or, at Clover main menu, go to Options->ACPI patching and select BIOS.aml rather than DSDT.aml for the DSDT (that effectively bypasses the patched DSDT to call on the BIOS native table).

We have guides for these ageing Sandy Bridge E6x20 models. I've stated it numerous times: HD3000 is glitchy on those laptops (and many others too) after Yosemite in which I found it last worked properly. Forcing VRAM to 2GB (with 8GB+ of RAM) does help in a way but it's not definitive and glitches will still occasionally occur. HD3000 is not great, that's all. This being said, there's no reason why your E6320 would regularly freeze under High Sierra so your setup must be wrong. Check your BIOS settings and adjust according to the recommended settings I posted for the E6220 in this very E6xxx forum section. Consult our existing E6x20 guides (I recommend my own E6220 guide) to check the installation process you followed and the files you used (patched tables, config files, kexts). Post a zipped copy of your Clover EFI folder, I'm sure there is stuff to adjust in it.

A few of us with old C2D/C2Q platforms (mostly desktop) experienced CMOS reset since updating to 10.15.4. During troubleshooting, the issue was pinpointed to 10.15.4's new boot.efi file (located in /S/L/CoreServices) which, as many of us noticed, was displaying some new info when booting in verbose mode. Initially, replacing 10.15.4's boot.efi file with that of an earlier Catalina release or even an earlier macOS version was found to get rid of the problem without adverse affect on booting Catalina 10.15.4. However, this only worked for Hackintosh systems running Clover, not for systems running OpenCore. 10.15.3_boot.efi.zip File ownership needs to be re-adjusted to root:wheel upon replacement: sudo chown 0:0 /S*/L*/CoreServices/boot.efi Update: 15 April 2020 - - - - - - - - - - - - - - - Following further troubleshooting with vit9696, telepati and a few others, vit9696 worked out a temporary workaround for OpenCore in the form of a 5-bytes NVRAM variable wake-failure set to 00 00 00 00 00. All details and explanations are available here. For Clover users, this workaround alternative to replacing boot.efi can implemented as follows in Terminal: sudo nvram wake-failure=%00%00%00%00%00 Of course, this needs NVRAM to be working properly on the target Hack. For Hacks with no natively-supported NVRAM, it is required to install EMUVariableUEFI.efi Clover module + RC scripts on the Catalina boot volume. Once the variable is set and the system rebooted to take it into account, no more CMOS reset on rebooting from 10.15.4.

As last resort for DWA-123, you may try Chris1111's driver package for USB dongles. It's basically an app that installs a wireless management app + drivers from a collection of USB dongles/chipset drivers the author builds up over time and maintains for given OS X/macOS versions. Saves you all the hassle of searching the Web. https://github.com/chris1111/Wireless-USB-Adapter This package supports DWA-123 dongle with PCI id 2001:330b (in hex). Check that against what you'll see in your SysProfiler->USB section for your own dongle. You never know, you may get lucky!

There are at least 3 x different models of DWA-123: DWA-123 -> drivers dated 2014 for Tiger 10.4, Leo 10.5, SL 10.6, Lion 10.7 and ML 10.8 DWA-123-B1 -> latest driver dated 2013, for ? DWA-123-D1 -> drivers dated 2015 for Mv 10.9 and Yos 10.10 I'm pretty sure none of those drivers will work for any recent macOS version. Follow the advice above and install a compatible mini-PCIe card in that E7440. It'll work much better.

No! Again, you need to: fake desktop HD4600 id 0x0412 use Lilu + WEG using Clover Configurator app, apply the HDMI patches to Azul framebuffer to your Clover config