Hervé

If the module is not detected, then you have a problem at USB level; you need to make sure all your ports, including the internal ones are fully enabled; you'll then see the module listed under the USB section of System Information (SysProfiler).

Very weird. I installed Mojave on my M.2 SATA SSD after reducing the Win10 partition it came installed with. I had no issue whatsoever in installing Mojave on the recovered disk space once I booted my Mojave USB installer. My SSD partitioning arrangement now looks like this (Win10 + Mojave + Catalina): Last login: Sun Aug 4 03:03:52 on ttys000 lat-7490:~ admin$ diskutil list /dev/disk0 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *512.1 GB disk0 1: EFI BOOT 523.2 MB disk0s1 2: Microsoft Reserved 134.2 MB disk0s2 3: Microsoft Basic Data Windows 399.0 GB disk0s3 4: Apple_APFS Container disk2 81.8 GB disk0s4 5: Apple_APFS Container disk1 30.7 GB disk0s5 /dev/disk1 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +30.7 GB disk1 Physical Store disk0s5 1: APFS Volume Catalina - Data 5.8 GB disk1s1 2: APFS Volume Preboot 77.6 MB disk1s2 3: APFS Volume Recovery 520.4 MB disk1s3 4: APFS Volume VM 1.1 GB disk1s4 5: APFS Volume Catalina 10.1 GB disk1s5 /dev/disk2 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +81.8 GB disk2 Physical Store disk0s4 1: APFS Volume Mojave 47.0 GB disk2s1 2: APFS Volume Preboot 45.5 MB disk2s2 3: APFS Volume Recovery 510.3 MB disk2s3 4: APFS Volume VM 20.5 KB disk2s4 lat-7490:~ admin$

Just to be clear on the matter, it's the USB aspect of this combo port you're inquiring about, not the eSATA? right?

'doubt it but maybe you're doing it wrong. Say you install Windows on a single partition on the SSD, you can then reduce that partition from Windows and create a new partition in the freed space. You may then format that partition FAT or NTFS. You may then boot your Mojave installer USB key and, once at the main screen, open up Disk Utility to reformat that 2nd empty partition HFS+ or APFS. You should then be able to install Mojave on that freshly reformatted partition. Make sure that, from the onset, you partition your disk using a GPT/GUID scheme, not MBR.

That's not supported on those Dell laptops, not even in Windows. You can set Wake from USB in BIOS to wake laptops from an external USB keyboard/mouse but that only works when laptops run on mains.

That's wrong! Latitude E6x20 cannot be booted with BIOS set to UEFI mode, only Legacy mode. Set it back to Legacy if it's set to UEFI mode and, again, install Clover with the settings specified in JakeLo generic guide. Please follow the instructions provided in our guides, they're detailed for good reasons... If necessary, I've also listed the Clover settings I used for legacy mode in my Vostro200 Mojave guide and they should work for your E6420.

Last updated: 14 Nov 2020 Restoring support for dropped GPUs in macOS Mojave and Catalina 1) All Mojave and Catalina versions: Here are copies of the requires kexts and files required to gain graphics acceleration on 1st gen Intel HD + Sandy Bridge (SNB) HD3000 + nVidia Tesla GPUs in Mojave and Catalina up to 10.15.3. For Catalina 10.15.4 and later, use dosdude1's patcher. As described initially at MacRumors in the "Mojave on unsupported Mac" thread back in summer 2018: 1a) Intel 1st gen Intel HD and HD3000 drivers are non-existant in Mojave by default, so copy 10.13.6's kexts to /S/L/E, repair permissions and rebuild your cache. 10.13.6_1st_gen_Intel_HD_kexts.zip 10.13.6_SNB_kexts.zip 1b) Mojave natively includes drivers for nVidia Fermi and Kepler cards only. Copy the following kexts to /S/L/E, repair permissions and rebuild your cache. Tesla_kexts_for_Mojave.zip Tesla_kexts_for_Catalina.zip 2) Mojave 10.14.4/5/6 and Catalina 10.15(.0)/1/2/3: Remove the following vanilla frameworks and replace them by 10.14.3's versions. This should be done after booting in single-user mode, having previously copied those frameworks in a dedicated folder at volume/partition root. in /S/L/Frameworks: CoreDisplay + OpenGL 10.14.3_Frameworks.zip in /S/L/PrivateFrameworks: GPUSupport + SkyLight 10.14.3_PrivateFrameworks.zip 3) Catalina 10.15.4 and later The above process is no longer applicable due to significant changes in macOS. Instead, it has become mandatory to call on dosdude1's Catalina patcher to patch Catalina and get the above unsupported GPUs working again. NB: The process of reverting to older frameworks or patching Catalina needs to be repeated after/at each macOS update.

Try this revised Clover config instead of the current one you use; seems you got your knickers in a twist on the CPU power management & SMBIOS/serial numbers front... You should also get rid of FakePCIID_Intel_HD_Graphics kext since Lilu + WEG take care of your graphics. config.plist.zip I suggest you call it "config2.plist" and place it alongside your existing file, then manually call it from Clover main menu at startup to test.

Regarding audio, you failed to state that your Clover config still included old AppleHDA patches. Those should be disabled/removed if you use AppleALC since that requires full vanilla AppleHDA... For the rest, you probably need to update Clover and review the modules you chose to install.

You're using some outdated kexts: FakePCIID, Shiki, etc. Make sure you: remove old versions of Lilu + Shiki remove those old FakePCIID kexts (they're superseded by Lilu + WEG kexts) remove those graphics DVMT and/or FixUp kexts, they're not required afaik use latest Lilu + WhatEverGreen + AppleALC kexts (available off well-known Github repo)

You need to remove VoodooHDA kext + AppleHDADisabler, otherwise, no audio....

Sigh... Why don't you specify the layout in the correct and dedicated section/part of your Clover config using Clover Configurator app? And, before you report it: you won't have audio if you reboot from Windows into macOS (proceed with a cold boot) you may lose audio on some occasions (like plugging/unplugging headphones) in which case just put laptop to sleep and wake it. You'll need to have CodecCommander kext installed alongside AppleALC of course. These things been mentioned many times before so don't hesitate to use for forum Search facility before posting (it's at the top of the forum window).

Building on the info provided by @jpz4085 all those months ago, I've patched the Latitude 7490 DSDT in order to remap brightness control to Fn-F11 and Fn-F12 keys (by default, it's Fn-F6 / Fn-b). ACPI debugging confirmed that Fn-F11 and Fn-F12 controls are handled by Embedded Controller (EC) EV5 event. This was hinted by presence of call to IGPU.BRT6 method under EV5 Method in the DSDT: Method (EV5, 2, NotSerialized) { \_SB.PCI0.IGPU.BRT6 (Arg0, Arg1) } BRT6 Method showed the usual default LCD notifications: Method (BRT6, 2, NotSerialized) { If (LEqual (Arg0, One)) { Notify (LCD, 0x86) } If (And (Arg0, 0x02)) { Notify (LCD, 0x87) } } The required DSDT patch is quite simple and as follows: 1) inject Darwin in PCI0._INI Method: Scope (_SB.PCI0) { [...] [...] [...] Method (_INI, 0, Serialized) // _INI: Initialize { [...] [...] If (CondRefOf (\_OSI)) { [...] [...] [...] If (LOr (_OSI ("Darwin"), _OSI ("Windows 2009"))) // Darwin OS injection { Store (0x07D9, OSYS) } [...] [...] [...] } } 2) check for Darwin in OSID Method: Scope (_SB) { [...] [...] Method (OSID, 0, NotSerialized) { If (LEqual (ACOS, Zero)) { [...] [...] If (CondRefOf (\_OSI, Local0)) { [...] [...] [...] If (LOr (_OSI ("Darwin"), _OSI (WIN7))) // Darwin OS check { Store (0x80, ACOS) } [...] [...] [...] } Else { [...] [...] [...] } } [...] } 3) modify notifications under BRT6 Method: Method (BRT6, 2, NotSerialized) { If (LEqual (Arg0, One)) { Notify (LCD, 0x86) Notify (^^LPCB.PS2K, 0x0366) // Fn-F12 = Brightness up } If (And (Arg0, 0x02)) { Notify (LCD, 0x85) Notify (^^LPCB.PS2K, 0x0365) // Fn-F11 = Brightness down } } Patched DSDT available in the Clover pack posted above.

You need to implement the required HDMI patches to your Azul framebuffer kext. All was explained several years ago in our 4th gen/Haswell graphics patching guide. It's available in our R&D->Graphics forum subsection. You can implement the patches through Clover on-the-fly patching facility.

You can try and identify the codes associated with Dell's function keys and remap them in DSDT. There's a dedicated guide at InsanelyMac on that matter: https://www.insanelymac.com/forum/topic/330440-beginners-guide-fix-keyboard-hot-keys-functional-keys/ Good luck.

You may consult our BCM4350 guide on the matter. I think that's about it.

What version of Clover do you try to install and how & where? What options did you select? Please specify details. Jake listed the necessary steps in his generic guide available here. Did you follow it?

I've no idea about prices, that's entirely market dependant. You can install: DW1560, DW1820A or DW1830. I know of no other compatible M.2 cards.

You're mistaken: the Latitude 5580 only supports M.2 cards and that AzureWave model is mini-PCIe. Hence the models suggested by JakeLo.

Look under "Applies to"... https://www.dell.com/support/home/us/en/04/drivers/driversdetails?driverid=86M99&oscode=WT64A&productcode=latitude-15-5580-laptop

At this stage, all seems Ok on the macOS front. Must be something with your account I guess.

Ok, so your kexts are in /L/E, including IntelMausiEthernet for your LAN card. All that's left to check now is whether that got installed as 1st interface en0 or not. It's mandatory. In case it were not, remove all interfaces from your Network PrefPane and reboot. Hopefully, the interfaces will re-install automatically at reboot, starting with LAN; if they do not, simply add them manually, starting with the LAN card.

KernelPm patch is indeed necessary on those Haswell-Based Latitude Exx40 models to avoid power management-related system reset/reboot at startup. Debug files or copy of Clover folder would be most useful for further assistance.

Maybe you did not install the bootpack properly or you're not running on a vanilla installation; difficult to say at this stage...

No, of course, the serial numbers should not be identical. Coming back to your Clover setup, there is only a very small set of kexts in E/C/k/O. But your Clover config shows being set for kexts injection. Since I saw no FakeSMC or VirtualSMC kexts in your Clover folder, I must assume either of those are installed and cached from /L/E (or /S/L/E). That is perfectly Ok but, then, Clover kext injection will not work. What's important to establish here is whether you have your LAN interface running and set as 1st interface en0. Post your debug file and we'll know more on this matter.