Hervé

PM981 are Samsung NVME (PCIe) SSDs (you could have Googled for this); yours is a Micron SATA SSD (it's written on it), therefore not an NVME model. Exact model is Micron 1300 MTFDDAV512TDL 512GB (it's also written on it). Anyway, given that it's a SATA disk, no issue on the SSD front.

Jake only provided 1 x SSDT for the brightness keys. You'll find it with a quick and simple search. Name contains "BRT6" from memory. Just look it up.

Re: brightness keys, you may consult my 7490 guide where you'll find details of a DSDT patch that enables the keys. Failing that, JakeLo has posted an alternative in the form of a specific SSDT.

A supplemental update was issued to address and fix the problem.

It's entirely up to you. There's a chance you won't see much difference in terms of CPU power management and performance between patched kernel and unlocked CFG register/variable. But I guess, only experimentation can tell...

You're extracting those raw vfiles out of a complete dev package. Download the complete package from parent level and you may compile the .asl files with the provided makefile. These .asl files are plain source code. You may rename the extension to .dsl to open them in MaciASL app. MaciASL uses .dsl extension for source code and .aml extension for compiled code. Here, the .asl files are meant to be compiled with the command line (Intel) iasl tool through the makefile. If you open up the makefile with a text editor, you'll see how it operates. As for errors, well they can depend on the ACPI version the code is based on and the ACPI version the compiler will be using. Check your MaciASL settings here. After a few years with good old DSDTEditor, I switched to rehabman's version of MaciASL several years ago and have been using that same version without problems ever since. Of course, I had to get into ACPI coding to be able to fix DSDT/SSDT when compiler returns errors... https://github.com/RehabMan/Intel-iasl https://github.com/RehabMan/OS-X-MaciASL-patchmatic

It's been reported that Mojave's Security Update 2020-005 causes performance issues due to unexpected memory usage. After installation of the update, a very significant quantity of RAM is used as reported in Activity Monitor app where App Memory/Wired Memory/Compressed are at much higher level than before the update. It's a very impacting situation for systems with 4GB or RAM which will suffer severe performance degradation. Think twice before installing!

My 7490 is USB-c/DP only, no optional TB. You may check the SSDT used on that laptop in the pack I posted in the associated guide.

8086:a12f is the USB3.0 controller built-in the Intel 100 Series/C230 chipset. 8086:15b5 is the USB3.1 controller offered by the DSL6340 Thunderbolt 3 Bridge. I know that USB-c ports of an Intel chipset controller are detected and listed (it's the case of my Latitude 7490) so, given that your DSK6430 bridge is properly detected in Hackintool, I'd have expected the app to list the associated ports too. Maybe you actually have to select it/click it at the top of the window.

The parent device is 8086:1576, i.e. DSL6340 Thunderbolt 3 Bridge [Alpine Ridge 2C 2015]. The XHC5 device you see underneath is the associated DSL6340 USB3.1 controller. Seeing an "XHCx" device is what you want.

RP05 is the PCIe root port (hence RP). RP05.PXSX and/or RP05.UPSB are the actual TB/USB-c PCIe devices.

Which guide are you following? Please specify the Clover version you're using and post a copy of the Clover EFI folder you use. High Sierra installs in several steps and reboots. At each intermediary reboot, you should see an offer to boot "install macOS from <target partition>". If you don't see that, press F3 and select it. Once installation has completed, this temp partition will disappear and you'll be left with only your finalised High Sierra partition to boot. I'm leaving the Preboot/Recover/VM partitions aside here of course, ignore them.

You need to finalise your USB ports definition with Hackintool app. USB-c ports are not necessarily TB too; that's an option you select at order time with Dell. If the port supports TB, it'll show in BIOS. If it's not mentioned then it's a plain USB-c port, normally with DP support. Check the logo printed next to the port.

Config is incorrect: it's missing the SMBIOS info.

Seems like you need to adjust your USB controller power settings. Did you apply DSDT patches to that effect or use a specific SSDT? None in the EFI folder you originally posted... Also: you inject HibernationFixup kext; I don't believe you need that and should therefore get rid of this. your ACPI/patched folder shows a CPU-specific SSDT when your CPU power management is set through PluginType. I don't see the need for that SSDT. make sure you disable hibernation as per detailed in our FAQ section.

Yes, this may happen from time to time. Could be a bug in AppleALC, I'm not too sure. Solution is to put the laptop to sleep and wake it after a couple of seconds or reboot. Check that you use latest versions of Lilu, AppleALC and CodecCommander and update if required. You may use Clover Configurator app to that effect.

Adjust tracking speed through the Trackpad PrefPane.

The 2 x partitions are perfectly normal, you just have some serious catch-up to do on macOS Catalina. You may start with this for instance... From memory, HoRNDIS was last updated in 2018 and last stated to run on Mojave. Did you check if it was compatible with Catalina? At a minimum, set your file system to RW before you try to install the app again. It may not install due to Catalina's default filesystem mode. Edit: confirmed! https://github.com/jwise/HoRNDIS/issues/102 Please conduct minimum research before popping questions that already have answers. Remember to consult our FAQ section too.

Just follow the existing guide(s). In the future, get to know your hardware as 1st pre-requisite and pay all due attention to the detailed steps provided in the guides you follow.

NVME kext? What NVME kext? SMCHelper is for installations that use FakeSMC, it's clearly shown when you select the driver at Clover installation. You're using VirtualSMC. It's long been stated that using SMCHelper driver with VirtualSMC kext causes issues and it's clearly stated in Jake's guide that you said you followed... So, a little attention maybe?

Did you check that your NVME SSD is not one of those incompatible ones? Please specify model. NB: -x boot arg not required to boot a macOS USB installer; a proper/adequate config suffices -f is not a valid boot arg (Clover has not supported booting without cache for years)

DW1820 is not supported. If it's a DW1820A card, which is a totally different model, see our BCM4350 article and guide here. You may consult our Wireless Cards inventories too. Green dot next to kexts is what is called a tag. You can Google about it, it's an old OS X feature to label/sort/filter files. It can be applied to any file and can be of any other available colour. Absolutely nothing to do with a kext being "active" or not, no.

Following BIOS update to v1.16.0, I revisited the patched DSDT since it was (finally) also causing a reset to me. I dumped all tables from BIOS and came to realise I had applied the brightness keys patch to a Clover pre-patched DSDT! I therefore re-applied the patch to the raw DSDT. My 7490 now boots Catalina without reset and brightness keys are fully operational. I've also updated the patch code above to return those Clover pre-patched lines to full vanilla code (XOSI returned to _OSI and XSID returned to OSID). Patched_DSDT_Lat7490_BIOS-1.16.0.aml.zip I invite Latitude 7490 users to test this revised patched DSDT and feedback to me by PM so that I can update the bootpacks accordingly. In case of issues (system reset), select BIOS.aml DSDT table in Options->ACPI patching->Dsdt name at Clover main boot menu to load the raw DSDT at macOS startup.

Updated for v1.16.0.

Refer to the E6540 Big Sur thread posted in this very section.