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

[deeveedee]

Attached is a new DSDT for the Latitude E6410.  Details are below.  This DSDT is not yet included in the baseline in Post #1.

 

I don't know much about Clover hot patching, so I was reading to learn and I just learned that I have been incorrectly applying Rehabman's "Instant Wake" DSDT patch.  Rehabman explains that in order to prevent instant wake, any Method (_PRW) that returns Package() { 0x0D, 0xXX } should be changed to return Package() { 0x0D, 0x00 }.  What is a bit harder to find (at least it was for me) is Rehabman's explanation of the proper handling of Method (_PRW) that returns GPRW(0x0D, 0xXX).  In this case, I had incorrectly changed GPRW(0x0D, 0xXX) to GPRW(0x0D, 0x00).  The correct application of Rehabman's instant wake fix is to change GPRW(0x0D, 0xXX) to Package() {0x0D, 0x00} so that GPRW is not called and _PRW simply returns the Package.  You'll find this explanation if you Google "Rehabman Using Clover hot patch ACPI". Rehabman actually changes Method (GPRW), which achieves the same as my correction below.

 

The result of this correction is that my originally patched Method(_PRW):

 

 

                Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
                {
                    Return ( GPRW (0x0D, 0x00) )
                }

 

 

should be changed to

 

                Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
                {
                    Return ( Package() { 0x0D, 0x00 } )
                }
 

 

I have made this change in the attached DSDT.  This DSDT also includes other minor fixes to resolve DSDT compile warnings (fixes that I found in Slice's E6430 DSDT (thank you, @Slice)).

 

By the way - with this instant wake patch, you will not be able to wake your laptop with USB.  This patch completely disables wake by USB (even if it is enabled in BIOS).

 

 

DSDT.zip

Edited February 28, 2020 by tonyx86

[unilock]

@tonyx86

The way I'm using the aux drive is almost identical:

• It's formatted as MBR
• Windows 7 is installed on it
• Windows 7 was installed without any other drives in the laptop (it wouldn't install correctly otherwise)
• The Windows 7 partition takes up the entirety of the drive
• I enabled "legacy" scanning in Clover so I could boot Windows 7 from there

Pardon if the following seems a bit rushed:

I realized the other day that perhaps there truly is a difference between aux drives, as mine was originally purchased for a Thinkpad W500 (which no longer functions for unrelated reasons). I've read online that there could be technical differences between aux drives advertised for different brands concerning how they interface with the laptop. Maybe that's the issue? If it is, fully disassembling your drive might provide some insight, as we could search for any differences in wiring or whatnot that I might be able to solve with a soldering iron.

See here

[deeveedee]

CORRECTION: I thought the circled resistor in the attached pic was missing from my circuit board, but upon closer inspection, I can't be certain.  I would recommend purchasing a new caddy specifically for the E6410.  Sorry I can't be of more help with this.

 

@unilock That sounds logical. I don't want to disassemble my aux bay caddy any more than I have, so I'd suggest purchasing one specifically for the E6410.  I think I found mine for $8 on Ebay.  I splurged and purchased one with the release latch, since reviews I read suggested that other "universal" caddies did not fit well.  My caddy fits perfectly and has the same release mechanism as the original DVD.

Edited February 28, 2020 by tonyx86
Added picture with suspected extra pull-up resistor

[unilock]

@tonyx86

I think I can spy the same resistor on your board from the image you supplied -- it looks like it has something to do with the activity indicator LED.

I'm going to end up spending money on *something* here, anyway, since I accidentally broke the aforementioned release latch off of my aux bay drive. Unfortunately, that was the same one that was on my stock DVD drive...

Thanks for all the help trying to get this working, though. At least we figured out what the white switch on the side of the modular bay drive does, after all this.

[deeveedee]

For those who would like to figure out why AppleALC.kext "interferes" with Wi-Fi, causing a delay in the Wi-Fi connection, I might have a clue.  I'm content with VoodooHDA and won't be pursuing an alternative to VoodooHDA, but others may find this of interest.  When using AppleALC.kext for sound instead of VoodooHDA.kext, I have noticed that Wi-Fi won't connect until there is an AppleHDA "event" in Device (HDAU) (observed using IORegistryExplorer).  If you open IORegistryExplorer and watch Device (HDAU) when AppleALC is installed, you'll noticed a change in the status of HDAU, immediately followed by the Wi-Fi connection.  Wi-Fi won't connect until this HDAU status change occurs.

 

I have also noticed that, with AppleALC installed, the layout-id of Device (HDAU) always changes to 0x07, regardless of the injected value in the DSDT.  From what I have read, HDAU should have the same layout-id as HDEF.  With AppleALC installed, I had tried to inject layout-id 0x0b (to match that of HDEF) by including layout-id in HDAU._DSM, but the layout-id doesn't seem to matter when using AppleALC. The layout-id of HDAU is always changed to 0x07 when AppleALC is installed.

Edited March 1, 2020 by tonyx86

[deeveedee]

Looks like the upgrade to Catalina 10.15.4 on unsupported systems has a few challenges.  If you're curious, refer to this discussion at MacRumors.

[deeveedee]

EDIT: I did a little more research on USB Power and found that Rehabman discussed this issue for Sierra and later ( Google "Rehabman USB power property injection for Sierra (and later)" ). He suggests that the IORegistry keys for USB Power should be injected via the custom SSDT-UIAC for USBInjectAll.kext.  Since we're using USBInjectAll.kext for this HackBookPro6,2, I have modified SSDT-UIAC (attached) to include Rehabman's suggestion (still using the MacBookPro6,2 power values from High Sierra 10.13.6 IOUSBHostFamily.kext).  You can choose your method of injecting these values (the attached SSDT-USBX or the replace SSDT-UIAC in EFI/CLOVER/ACPI/patched with the attached SSDT-UIAC).  Note that if you employ the revised SSDT-UIAC, the USB power keys are properly injected (search for AppleBusPowerController in IORegistryExplorer), but the USBMap utility mentioned below will still report that you haven't created Device (USBX).  I don't think that USBMap's reported status matters as long as the values are injected, but I can't be sure, since I still haven't determined whether these USB Power keys make any difference in operational behavior.

 

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

 

As I continue to try to figure out the Bluetooth Issue mentioned in Known Issues in Post #1, I found this tool that reports USB status:   USBMap.  When I ran the tool and selected option 'U' to Validate USB Power Settings, the tool reported that MacBookPro6,2 is not defined in IOUSBHostFamily.kext/Contents/Info.plist.  The tool proposes installation of a custom SSDT-USBX.aml that injects power values from the MacBookPro12,2 definition.  

 

Instead of using the USBMap tool's proposed power settings, I went back to High Sierra 10.13.6 (MacBookPro6,2 wasn't defined in Mojave's  IOUSBHostFamily.kex either) to find the USB power settings, created the attached custom SSDT-USBX.aml and installed this custom SSDT in EFI/CLOVER/ACPI/patched.  After rebooting Catalina, I don't notice any difference in behavior, other than that the USBMap Tool now says that USB Power is configured correctly.

 

I'm not sure what this custom SSDT is supposed to resolve/address, but I just want to report that it does NOT appear to fix the Bluetooth issue (in Known Issues in Post #1) and Catalina sleep still takes 32 seconds while High Sierra and Mojave sleep in 5 seconds.

 

 

SSDT-USBX.zip

SSDT-UIAC.zip

Edited March 5, 2020 by tonyx86
Added updated SSDT-UIAC

[deeveedee]

A new E6410-Catalina-3v6.zip archive is attached to Post #1 of this thread with the changes listed below.  My Latitude E6410 (Nvidia Graphics) is running perfectly with this configuration.  You may need to execute Step #9 in Post #1 before applying these changes.  Note that I am no longer pursuing a solution for the Display brightness slider, so these changes have no attempts to fix the Display brightness slider (use the Dell brightness keys).  Also, I'm continuing to use CLOVER r5103 since I didn't see any required changes in r5104.  Also, I am using the same EFI for triple-booting High Sierra 10.13.6, Mojave 10.14.6 and Catalina 10.15.3 (with kexts unique to each macOS in /Library/Extensions) and all three OSes run great.

 

Changes in E6410-Catalina-3v6.zip attached to Post #1

• Addition of SSDT-USBX.aml (install in EFI/CLOVER/ACPI/patched) - injects MacBookPro6,2 USB wake/sleep power properties which have been removed from IOUSBHostFamily.kext after High Sierra 10.13.6
• DSDT changes
  • Resolve a few ACPI compile warnings (fixes borrowed from Slice's E6430 DSDT)
  • Rename EHCx to EH0x in DSDT (the only instance of these renames is in the DSDT, so no need for Clover to do this)
  • Other minor revisions 
• Disabled EHCx -> EH0x renames in CLOVER config.plist (no longer necessary after performing renames in DSDT)
• Upgraded Lili.kext from 1.4.1 to 1.4.2

Edited March 26, 2020 by tonyx86
Removed note about EH01:HP14 since it is a real external USB2 port

[deeveedee]

EDIT: I prefer a revision to this kext injection strategy here.  Leaving this post for historical purposes.

 

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

 

Setting Clover's "Inject Kexts" to YES (not DETECT) and placing the Brcm kexts in E/C/k/O may be a solution to the Bluetooth issue reported in Known Issues in Post #1 of this thread.  See more here.

 

EDIT: I am now running with the following configuration for triple-booting High Sierra 10.13.6, Mojave 10.14.6 and Catalina 10.15.3.  I will continue to test and am not yet recommending this as a baseline, but it looks promising.

 

Clover: Inject Kexts -> YES (not Detect)

 

The following kexts in E/C/k/O (not in /L/E)

• Lilu.kext v1.4.2
• BrcmFirmwareData.kext v2.5.1
• BrcmPatchRAM3.kext v2.5.1
• BrcmBluetoothInjector.kext v2.5.1
• AirportBrcmFixup.kext v2.0.6
• FakeSMC.kext v6.26
• IntelMausiEthernet.kext v2.5.0
• USBInjectAll.kext v0.7.1
• VoodooPS2Controller.kext (Bronxteck) v6.0.0
• ACPIBatteryManager.kext v1.90.1
• FakeSMC_CPUSensor.kext v6.26
• FakeSMC_GPUSensor.kext v6.26

 

The following kexts in /L/E for High Sierra and Mojave (not Catalina)

• VoodooSDHC.kext 1.1.2

 

EDIT2: It appears that in Mojave (not Catalina), AppleHDADisabler.kext and VoodooHDA.kext need to be installed in /System/Library/Extensions.  In Mojave, I tried moving these kexts to /Library/Extensions and my laptop took forever to boot.  I do not observe this in Catalina 10.15.3 (where I can move AppleHDADisabler.kext and VoodooHDA.kext to /Library/Extensions without any issues).

 

EDIT3: It appears that FakeSMC_CPUSensors.kext and FakeSMC_GPUSensors.kext dependencies are such that they don't load unless they are co-located with FakeSMC.kext.  I haven't needed to set Clover's "Inject Kexts" to "Yes" before (I have always used "Detect"), so I'm not sure if there are problems with including kexts in both E/C/k/O and /L/E when set to "Yes."  It may be necessary to place the FakeSMC Sensor kexts in E/C/k/O as well if running HWMonitor.

 

EDIT4: I have moved all kexts to E/C/k/O as indicated above.  This kext configuration (combined with Clover "Inject Kexts" set to "YES" and not "DETECT") apprears to be working for High Sierra 10.13.6, Mojave 10.14.6 and Catalina 10.15.3.  I have VoodooHDA.kext and AppleHDADisabler.kext installed in /System/Library/Extensions where the VoodooHDA installer package placed them.

Edited March 23, 2020 by tonyx86
corrected typos

[deeveedee]

EDIT: I prefer a revision to this kext injection strategy here.  Leaving this post for historical purposes.

 

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

 

I'm now convinced that the correct way to install the Brcm kexts for Catalina requires placing them in E/C/k/O with CLOVER "Inject Kexts" = YES.  On this Latitude E6410, the BrcmRepo kext does not inject reliably from /L/E.   Placing Brcm kexts in /L/E was reliable in High Sierra and Mojave.

 

I will be updating the baseline with this new (for me) kext installation strategy.  You can all tell me you told me so

 

EDIT: My candidate updates are attached.  Note that the LE folder is no longer included, as no 3rd party kexts are installed in /L/E for Catalina.

 

EDIT2: I haven't timed it, but it seems the boot times are slower.  I think that's to be expected now that Clover is injecting all 3rd-party kexts.

 

E6410-Catalina-3v7.zip

Edited March 23, 2020 by tonyx86
Added E6410-Catalina-3v7.zip attachment

[ferfwe]

hi. need link how to create a bootable flash drive . and where to download the catalina . I have latitude e6410 but can't find , how  zip to make a download from the format

[deeveedee]

Sounds like you're new to hackintosh.  You have a lot to learn - just be patient with yourself.  You will need to know quite a bit in order to maintain your hackintosh, so the learning is essential.  Follow the installation instructions in Post #1 of this thread.  At each step, use Google to search when there are instructions that you don't understand.  There is plenty of available documentation that explains each step in more detail.  Good luck!

[ferfwe]

should I change the wi-fi module?

BCM943225HM
BCM943225HMB
BCM94322HM8L
BCM943224HMS
BCM94352HMB will be alright?

[deeveedee]

I personally have only tested the Broadcom BCM 94352HMB as noted in Post #1 of this thread.  Others who have posted in this thread have other cards working with the use of antenna adapter cables.  My instructions in Post #1 have been designed and tested to work with BCM 94352HMB.

[ferfwe]

doesn't see my disk. what could it be? something with kekx

samsung 840 evo 

[deeveedee]

@ferfwe If you are installing Mojave, please post your questions in this thread.

[ferfwe]

please excuse me . I'm happy. established with the help of your keks mak sierra. it remains to understand it and put wifi tp link tl-wn725n

[deeveedee]

EDIT: I have attached my current EFI / LE folders to this post (consistent with the explanation below).  I have not yet attached this to Post #1, as I'm not ready to make it my baseline.  The attached configuration is working very well in High Sierra, Mojave and Catalina.

 

Note that I'm still running Clover r5103.

 

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

 

I have not yet updated the baseline in Post #1 of this thread, because I still prefer to have kexts in /L/E for all the reasons that @Hervé states here, so I have been trying to find a way to get Bluetooth firmware update to work reliably in Catalina with kexts in /L/E. After experimenting with Clover's "ForceKextsToLoad" and giving up on that approach, here's the closest that I have come to having all kexts in /L/E:

• CLOVER r5103 (Legacy): Inject Kexts = YES (not DETECT)
• Kexts in E/C/k/O
  • BrcmFirmwareData.kext v2.5.1
  • BrcmPatchRAM3.kext v2.5.1
• Kexts in /L/E
  • Lilu.kext v1.4.2
  • BrcmBluetoothInjector.kext v2.5.1
  • AirportBrcmFixup.kext v2.0.6
  • FakeSMC.kext v6.26
  • IntelMausiEthernet.kext v2.5.0
  • USBInjectAll.kext v0.7.1
  • VoodooPS2Controller.kext (Bronxteck) v6.0.0
  • ACPIBatteryManager.kext v1.90.1
  • FakeSMC_CPUSensor.kext v6.26
  • FakeSMC_GPUSensor.kext v6.26

It appears to me that there is something about BrcmPatchRAM3.kext and BrcmFirmwareRepo.kext installed in /L/E that does not agree with Catalina.  I'm not sure if the problem has something to do with Clover Legacy mode or is something specific to this laptop.

 

EDIT: This configuration appears to be working reliably for High Sierra 10.13.6, Mojave 10.14.6 and Catalina 10.15.3.  I will continue to test.

 

 

E6410-Catalina-3v8.zip

Edited March 23, 2020 by tonyx86
Attached new E6410-Catalina-3v8.zip

[deeveedee]

Catalina 10.15.4 has been released.  The new DosDude Catalina Patcher is available here.  I am too busy with other things to try it now, but the installation / upgrade process should be as stated in Post #1 of this thread, replacing Catalina Patcher v1.3.0 with the new DosDude Patcher.

 

EDIT: It appears that a CLOVER update is required for Catalina 10.15.4.  Be sure to get the latest CLOVER bootloader (r5107 as of this writing).

 

Be sure to backup first!

Edited March 27, 2020 by tonyx86
Added note about latest CLOVER version

[vbmota]

Theres a way to enable Airplay mirroring on Latitude hack 6,2?

[deeveedee]

I'm not on my Apple TV Wi-Fi network to test it, but when I open mirroring from the Menu Bar, it shows "AirPlay: Looking for TV".  What are you seeing?

 

 

[vbmota]

None...

and in yours are with a second monitor attached?

[deeveedee]

EDIT2: @vbmota According to this post in MacRumors, AirPlay no longer works with patched Legacy NVidia Video after Mojave.  I have confirmed that AirPlay still works perfectly on my HackPro5,1 running Catalina 10.15.3 with Sapphire Pulse RX580.

 

EDIT: @vbmota I was able to use Airplay to Apple TV in High Sierra 10.13.6 and Mojave 10.14.6, so maybe the Airplay problem in Catalina has something to do with a DosDude Catalina patch that I missed.  Not sure.  I deleted my previous statement about needing HD Graphics after finding that Airplay does work with this Latitude E6410 (Nvidia Graphics) running High Sierra 10.13.6 and Mojave 10.14.6.

 

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

 

I'm not currently using a second monitor (although both the VGA and Display Port do work).  Successful Display mirroring to Apple TV does depend on your Wi-Fi card and requires your Apple TV to be on the same Wi-Fi network with Apple TV enabled.  If I remember correctly, you're not using the same Wi-Fi card that I'm using.  If you're not using Broadcom BCM 94352HMB, see if you can google Airplay with your card.

Edited March 28, 2020 by tonyx86
Added note indicating that AirPlay no longer works after Mojave

[deeveedee]

I just discovered that I've been wrong about EH01:HP14 USB port.  I never knew that the ESATA port on the left side of the E6410 is actually a dual ESATA/USB2 port, so EH01:HP14 should be an external USB2 port in SSDT-UIAC.aml.  Attached is the corrected SSDT-UIAC.aml file.  Replace the SSDT-UIAC.aml file in EFI/CLOVER/ACPI/patched with the attached file.  I'll make the correction in the baseline attached to Post #1 when I make the next baseline update (probably for Catalina 10.15.4).

 

Sorry about the mixup and going back and forth on this.  Good to know I'm still learning.

SSDT-UIAC.zip

[deeveedee]

I just participated in a Zoom meeting and found that my internal mic is not working. I had to connect an external mic to the right mic jack (which worked fine).  Does anyone have the internal mic working on their HackBookPro6,2 and if so, how did you get it working?

 

EDIT: If I install AppleALC.kext (removing VoodooHDA.kext and AppleHDADisabler.kext), the internal mic works.  I guess the internal mic needs some kind of additional VoodHDA.kext configuration.  

Edited March 27, 2020 by tonyx86