Catalina on Dell Latitude E6410 (Nvidia Graphics) With Working Sleep

[vbmota]

I have one BRM9460CS2 board and can confirm that it works nicely with a properly adaptation with a original MacBook antenna plug. The antennas plugs are different to connect to Dell Latitude. Apple use a "mini" connector that wont fits on the E6XXX series and another laptops (case that I believe is the same used in the BRM94360HMB board ordered by @unilock, unfortunatley). Besides, this model of card, from the images I researched, has 3 connectors for the antennas and the laptop has only two. I don't know how much work it will take to figure out how to make it work fully. Good luck.

[deeveedee]

57 minutes ago, vbmota said:

 

I have one BRM9460CS2 board and can confirm that it works nicely with a properly adaptation with a original MacBook antenna plug. The antennas plugs are different to connect to Dell Latitude. Apple use a "mini" connector that wont fits on the E6XXX series and another laptops (case that I believe is the same used in the BRM94360HMB board ordered by @unilock, unfortunatley). Besides, this model of card, from the images I researched, has 3 connectors for the antennas and the laptop has only two. I don't know how much work it will take to figure out how to make it work fully. Good luck.

Attached is a picture of the BCM94352HMB in my Latitude E6410.  My laptop has 3 mini-coax cables, but I only used two of them as shown.  The original Intel card had 3 coax connectors.

[unilock]

@tonyx86 @vbmota

 

My BCM94360HMB (AW-CB160H) arrived today. Indeed, it has three MHF4 antennae rather than two U.FL antennae, the latter of which being what the E6410 is equipped for. I now have some adapter cables on the way; they're shipping from China, so they'll probably get here within my lifetime.

In the meantime, Wi-Fi seems to work well enough without antennae, as my router is located directly beside my desk. Bluetooth, too, works short range, though it should be noted that I had to tape over the Bluetooth disable pins (5 and 51) in order to get it to power on under any OS. I also had to disable Bluetooth in BIOS (to turn off the built-in module). I can now turn Bluetooth on/off from the menubar, though!

Unfortunately, I'm running into the issue where it takes a few minutes after boot for the Wi-Fi hardware to turn on. I have the latest Lilu + BrcmPatchRAM3 + BrcmBluetoothData + BrcmBluetoothInjector installed, so I'm not sure what the issue is.

 

I've been messing with my accursed modular bay HDD caddy, as well. I tried putting my boot drive in it, from which macOS started just fine, but it still ended up at the expected white screen after a while. When it's not crashing the system, whatever HDD I have plugged into the bay is properly recognized by model under System Information.app. I have no idea what the problem could be here.

 

On an unrelated note, I tried turning on my WWAN card in BIOS to see if macOS would recognize it. Surprisingly, it does; however, it shows up in System Information.app only as a USB device, not a WWAN device. Oh well. Maybe it would work better if I had a SIM card installed in my laptop.

[deeveedee]

@unilock If you'd like opinions on your issues, please attach your Black.Dragon problem reporting files to your post.

 

EDIT: have your researched the expected signal attenuation caused by the adapter cables?

Edited January 28, 2020 by tonyx86

[deeveedee]

EDIT 2: If you are unable to turn-on Bluetooth, see Known Issues in Post #1.

 

EDIT: I have isolated this bluetooth issue to occur only if I turn-off bluetooth before shutting down.  If I leave bluetooth on (or at least make sure bluetooth is on before shutting down), bluetooth is reliably available after each boot and I am able to turn bluetooth off and back on within a session.  I hadn't seen this before, because I was leaving bluetooth on.  I will continue to monitor to see if I can isolate more specifics about this behavior on my Latitude E6410 with BCM94352HMB.

 

There is something wrong with bluetooth after I switched from Brcm kexts version 2.5.0 to 2.5.1.  I had guessed that it was a firmware update issue, but I don't think that is the problem (at least I don't think it's the only problem).  I also am not certain that this started with 2.5.1, since I didn't test bluetooth very rigorously for version 2.5.0.  I am not always able to turn-on bluetooth after a  cold boot and don't know the problem. Will look at this more when I have time and welcome testing help from others.  My system is currently running with version 2.5.1 Brcm kexts in /L/E.

 

Bluetooth in Mojave on my Latitude E6410 is solid, so this problem is specific to Catalina.  I have no problems with Wi-Fi.

Edited February 4, 2020 by tonyx86

[unilock]

@tonyx86 Attaching logs would help, wouldn't it? My bad.

I've generated three archives using gen_debug.zip:

debug_no-bay.zip = generated without modular bay HDD caddy inserted

debug_bay-data.zip = generated with modular bay HDD caddy inserted, containing a secondary HDD for data

debug_bay-boot.zip = generated with modular bay HDD caddy inserted, containing the boot SSD

(the sum of the archives exceeds InsanelyMac's upload size limit)

 

The adapter cables are only 5cm long, so I can't imagine they'll contribute much to signal attenuation. If they do, then the signal will still likely remain "good enough" for my purposes. Hell, I can get a tolerable signal as it is.

Edited January 29, 2020 by unilock

[deeveedee]

Upgrade to 10.15.3 is painless.  I followed my instructions in Post #1 to update Catalina from 10.15.2 to 10.15.3.  So far, I haven't found the need to re-apply the Legacy Video patch.

 

Keep using VoodooHDA.kext with 10.15.3.  Use of AppleALC causes delayed Wi-Fi connection.

 

Bluetooth and Wi-Fi appear to work perfectly following sleep / wake with no delay in availability of bluetooth and Wi-Fi after wake.  In fact, bluetooth and wi-fi are available immediately after wake in 10.15.3.  Credit to @RehabMan's USBInjectAll.kext and his custom SSDT instructions for leading to the perfect USB behavior on this Dell Latitude E6410.

Edited February 3, 2020 by tonyx86
Removed incorrect reference to delayed Wi-Fi connection

[deeveedee]

Deleting my original post after figuring out that the 'delayed Wi-Fi problem' is caused by AppleALC.  Use VoodooHDA 2.9.2 v14 pkg installer and not Apple ALC.

Edited February 3, 2020 by tonyx86
Changed post to indicate use of VoodooHDA

[unilock]

I can confirm that the same Wi-Fi issue occurs with the BCM94360HMB (AW-CB160H), although this is true for 10.15.2 as well.

As far as I know, these are the only two chipsets that are "natively" supported by macOS Catalina. Note that I've yet to update to 10.15.3, although I doubt much will change, considering @tonyx86 is facing the same issue on that version.

[deeveedee]

Deleting my original response now that I understand the problem.  Use VoodooHDA 2.9.2 v14 installer package and NOT AppleALC.

[deeveedee]

I have determined that the delayed Wi-Fi problem is related to sound.  This sounds as crazy to me as it sounds to you (no pun intended  ).  Use VoodooHDA 2.9.2 v14 pkg installer (select classic install method) and NOT AppleALC.  I have installed VoodooHDA version 2.9.2 v14 and it is working well for me.  I discovered this sound-related issue when I switched back to Catalina 10.15.2 and still had the delayed Wi-Fi problem.

 

I have added a note to post #1 in this thread indicating that AppleALC should be avoided.

 

Details:

When I reverted to 10.15.2 after having the "delayed Wi-Fi" problem in 10.15.3, I had the same problem.  I did a clean install of 10.15.2 and had not yet installed sound.  I tried AppleALC and while sound worked, Wi-Fi acquisition was still delayed.  I removed AppleALC and installed VoodooHDA and the Wi-Fi problem is resolved.  

 

While trying to figure out the Wi-Fi problem, I noticed that Wi-Fi would connect immediately after there was an AppleHDA event that I observed in IORegistryExplorer.  I suspect that the Wi-Fi problem is "fixed" when VoodooHDA installs AppleHDADisabler.

Edited February 3, 2020 by tonyx86

[deeveedee]

EDIT: I have updated post #1 to the new baseline for 10.15.3.

 

EDIT 2: See Known Issues in Post #1 for Bluetooth work-around

 

I can confirm that Wi-Fi, Bluetooth, sleep ... all works perfectly after upgrading to 10.15.3.  Continue to use VoodooHDA 2.9.2 v14 and don't use AppleALC.

 

My current baseline includes the following (I'll update post #1 after further testing):

• Catalina 10.15.3
• CLOVER v2.5k r5103
• DosDude Catalina Patcher: v1.3.0
• Lilu.kext 1.4.1
• BrcmFirmwareRepo.kext 2.5.1
• BrcmBluetoothInjector.kext 2.5.1
• BrcmPatchRAM3.kext 2.5.1

• IntelMausiEthernet.kext 2.5.0

• VoodooHDA.kext 2.9.2 v14 (NOT AppleALC)

Edited February 4, 2020 by tonyx86

[deeveedee]

Catalina's read-only file permissions may interfere with your installation of black.dragon74's gen_debug.  If you're having problems installing gen_debug, try the attached gen_debug by copying it to your Desktop.  After you copy to your Desktop, open terminal and change file attributes by executing 'chmod a+x ~/Desktop/gen_debug'

 

Run it from terminal by cd'ing to your Desktop and executing ./gen_debug

 

I'm not a script guru, so forgive me if these instructions or my methods are remedial.

 

 

gen_debug.zip

Edited February 3, 2020 by tonyx86

[james487]

I successfully installed everything works except the wifi I must change the wifi card because I have an intel, thank you for your patience and your kindness I begin and I try to understand, it's not easy, I need to update the system to 10.5.3 now

[deeveedee]

Congratulations!!! Great job!  Your patience and persistence has paid off.   Well done!

[deeveedee]

I was playing with @headkaze's hackintool (awesome tool by the way) and noticed that hibernatemode was 3 when it should be 0.  I added an installation step in Post #1 for setting hibernatemode.

Edited February 8, 2020 by tonyx86

[deeveedee]

There is a new version of AirportBrcmFixup.kext (version 2.0.6).  I have installed this to see if it made any difference, but I don't notice any changes.  At the time of this writing, this new version of AirportBrcmFixup.kext is not yet part of the baseline in Post #1 of this thread.

[deeveedee]

EDIT: A newer version of the attached .zip is now included in Post #1 of this thread.  Leaving this post for historical purposes.

 

The attached E6410-Catalina-3v2.zip represents the current baseline of my Latitude E6410.  Changes from the baseline in Post #1 are listed below. With these changes, I am noticing that booting between High Sierra 10.13.6, Mojave 10.14.6 and Catalina 10.15.3 is more "seamless."  Occasionally, I would see a "white screen" when shutting down one OS and booting another.  This "white screen" always recovered itself and wasn't a big deal, but it made me suspect that something wasn't quite right.  I'm not seeing this with the attached files.  If you want to test and you're running the baseline in Post #1, you don't need to replace everything - just the changed files referenced below.

 

• New CLOVER config.plist: Removed all CLOVER USB fixes (leaving EHCx > EH0x renaming) - be sure to replace XX-MASKED-XX with your own values.
• New DSDT.aml: Restored _S3D and _S1D definitions in Device (EHC1) and Device (EHC2) to their original values (I was experimenting with these when working on the sleep solution)
• New SSDT-UIAC.aml: Changed EH01:HP14 USB port from External to Internal (there isn't an external 4th USB port on the Latitude E6410)
• New version of AirportBrcmFixup.kext (2.0.6)

 

Note that the drivers folder in the attached EFI is from CLOVER r5103.

 

 

E6410-Catalina-3v2.zip

Edited February 14, 2020 by tonyx86

[deeveedee]

EDIT: I should mention that I still prefer the original HWMonitor and will be staying with the original HWMonitor in my baseline.  I am posting this only for those who might be curious about HWMonitor alternatives.

 

I've been interested in possible replacements for HWMonitor, specifically in the packages posted at https://sourceforge.net/projects/hwsensors3.hwsensors.p/files/

 

If you want to try this alternate HWMonitor, follow the steps below.  The required files and a screenshot of the sensor display are attached.

 

This installation of a new HWMonitor assumes that you have installed the E6410 Catalina baseline as per Post #1 in this thread.

1. Remove the following kexts from /Library/Extensions
   • ACPIBatteryManager.kext
   • FakeSMC_ACPISensors.kext
   • FakeSMC_CPUSensors.kext
   • FakeSMC_GPUSensors.kext
   • FakeSMC_LPCSensors.kext
   • FakeSMC.kext
2. Remove FakeSMC.kext from EFI/Clover/kexts/Other
3. Copy all kexts in the attached LE folder to /Library/Extensions
   • Note that AppleHWSensor.kext from Mojave 10.14.6 is included.  I'm still experimenting with this, so you may or may not want to install this.
4. Copy FakeSMC.kext from the attached LE folder to /EFI/Clover/kexts/Other
5. Remove HWMonitor from Applications
6. Copy HWMonitorSMC from the attached Applications folder to Applications
7. Ensure PROPER kext installation
   • cd /Library/Extensions
   • sudo chown -R root:wheel *.kext
   • sudo chmod -R 755 *.kext
   • sudo kextcache -i /
   • After you execute 'sudo kextcache -i /' you should observe that ALL kexts are allowed.  If not, your kext directory attributes are probably incorrect.  Repeat kext installation and try again.
8. Restart your HackBookPro
9. Run HWMonitorSMC

 

 

NewHWMonitor.zip

Edited February 7, 2020 by tonyx86

[deeveedee]

The new baseline that I attached a couple of posts ago is working extremely well for me.  I have added the following as a known issue in Post #1:

 

I continue to refine the DSDT and CLOVER config.plist to optimize my Latitude E6410 for multi-booting between various macOS versions (High Sierra, Mojave and Catalina at the time of this writing). If you upgrade your Latitude E6410 EFI using my attached EFI (my tested baseline will always be attached to Post #1), you may find that your Latitude E6410 is stuck in a boot-loop that ends in a white screen and reboots.  Clear your system by doing the following: turn off your laptop, remove A/C power, remove the main battery, press and hold the power button for 30 seconds, restore A/C power and battery, boot normally.  I have only found this to be necessary (very rarely) after making an EFI change, but you may find it helpful if making kext changes in /Library/Extensions as well.

[deeveedee]

EDIT: This updated DSDT is now included in the new E6410-Catalina-3v3.zip attached to Post #1 in this thread.  A new config.plist is also included in the E6410-Catalina-3v3.zip attached to Post #1.  This new config.plist removes the CLOVER USB fixes which are no longer necessary.

 

A new DSDT for the Latitude E6410 is attached.  Replace your DSDT in EFI/CLOVER/ACPI/patched with the DSDT attached to this post.  Details below.

 

I found an incorrectly applied patch in my Latitude E6410 DSDT.  This DSDT has been incorrect since I first applied patches for Mojave in this thread and explains why I originally thought I needed to enable USBFix in CLOVER config.plist (which I ended up not having to do).  I had incorrectly applied the _DSM patch for Device (EHC1).  This _DSM patch was nested inside of Device EHC1.RHUB1 instead of up one level in Device EHC1.

 

This error doesn't appear to have affected USB behavior, but I haven't finished testing. Please replace your Latitude E6410 DSDT (in EFI/CLOVER/ACPI/patched) with this new one.  I was hoping that this error explained the Bluetooth behavior in Catalina, but I haven't found that any behavior changes after applying this fix.

 

I will eventually update the EFI attached to Post #1 in this thread and to the Mojave Thread.

 

 

DSDT.zip

Edited February 10, 2020 by tonyx86

[deeveedee]

Attached is the GeekBench5 score for my HackBookPro6,2 (i7-620m).  The GeekBench4 score is attached to Post #1 in this thread.  Performance of this Latitude E6410 with Catalina is virtually identical to performance with Mojave.

 

 

[deeveedee]

Thanks to @holyfield for his detailed explanation of darkwake in this thread, I now realize that my use of "darkwake=8" (a carry-over from my Mojave thread) is incorrect.  The correct value should be "darkwake=0" for reasons explained in this thread.  I am running with Clover boot arg "darkwake=0" and will include this the next time I update the baseline attached to Post #1.

[deeveedee]

EDIT: A new lid sleep solution is now attached to Post #1.  This new solution eliminates the need for the ACPIPoller.kext and the Method (LIDP) addition to the DSDT.

 

-------------------------------------------------------------------------------

 

@unilock and others that might be interested, I was working on something else related to the display and quickly implemented what I believe are the necessary elements for sleep on lid close (as implemented by Rehabman).  I did try it and it "works" (only tried once), so I'm not sure I did this correctly (didn't spend much time on it).  If you're interested, take my work below/attached and test it yourself.  I don't know if this breaks something else (again, didn't test extensively).  Please report your findings in this thread if you do test this. The basic elements (attached) are as follows:

 

• Add Method (PNLF) to DSDT (not sure this was necessary - I was playing with something else)
• Add pwm-info to GFX0._DSM to DSDT (not sure this was necessary - I was playing with something else)
• Add Device (LIDP) to DSDT (required for Rehabman's ACPIPoller.kext)
• Install ACPIPoller.kext (I installed in /L/E)

 

EDIT: Remove the following kext (appears to be unnecessary)

• FakeSMC_LPCSensors.kext

 

To try this, you just need to replace your DSDT in /EFI/Clover/ACPI/patched with the attached DSDT and properly install the ACPIPoller.kext (I installed in /L/E) and reboot.  You'll noticed that the Display Brightness Slider appears in System Preferences > Display.  The slider doesn't work (this would be another project if you're interested).  

 

References:

• Rehabman's ACPIPoller.kext: https://github.com/RehabMan/OS-X-ACPI-Poller
• Rehabman's Device (LIDP): https://github.com/RehabMan/Laptop-DSDT-Patch/blob/master/misc/misc_LidPoll.txt
• Implementation of Lid Polling on Dell Latitude E6430: https://osxlatitude.com/forums/topic/9248-working-sleep-on-intel-hd-and-nvidia-nvs-on-dell-latitude-e6430-optimus-enabled-or-disabled/

If I remember correctly, you may find a Brightness Slider solution in the E6430 thread.  I would recommend reading this thread, since it's what I used to derive the sleep solution for the Latitude E6410.  FrostyTheSnowMan did a great job with the E6430.

 

 

DSDT.zip

ACPIPoller.kext.zip

Edited February 17, 2020 by tonyx86
No longer needed ACPIPoller.kext and Method (LIDP)

[unilock]

@tonyx86

I attempted to apply RehabMan's LidPoll patch some time ago, but couldn't get it working on its own (I did have ACPIPoller.kext installed, of course). Perhaps something else you did with the DSDT since then had some effect after all -- or, more likely, I did something wrong.

I'll try out the patch and report my findings after using it for a bit. I've still yet to update from the first published version of your EFI, as well as upgrade to Catalina 10.15.3. Here's hoping my accursed bay drive will start working properly after getting everything up-to-date.

As for AppleALC causing the Wi-Fi delay -- well, I'm not sure what to say about that. Very bizarre.

 

EDIT:

After uninstalling AppleALC and replacing it with VoodooHDA (installed via the "classic method"), Wi-Fi still takes some time to be recognized after boot. Attached is the output from black.dragon74's tool, notably taken after Wi-Fi was recognized.

Also, I still can't seem to get sleep on lid close working. Perhaps this is because I installed IntelBacklight.kext in an attempt to get the brightness slider in System Preferences working (the slider currently does not appear at all).

Maybe updating to 10.15.3 will fix my issues.

debug_voodoohda.zip

Edited February 16, 2020 by unilock