Mojave on Dell Latitude E6410 With Working Sleep

[deeveedee]

I tried running MacOS from a disk partitioned MBR but it wouldn't perform OS updates.  I never spent time trying to figure out how to get the MacOS updates to work with MBR, since I just changed the MacOS disk to GPT and used separate disks for Windows and MacOS.  I know it's possible - I just never did it.

[deeveedee]

I finally got around to testing the display port (using display port > HDMI adapter).  Works perfectly.  Updated Post #1 to reflect this new info.

[deeveedee]

EDIT: I have a working solution for sleep later in this thread.  Keeping this post for info, but SLPT was not needed for working sleep / wake on the E6410.

 

After reading Intel's Series 5 Chipset spec (page 537) and a bit of trial and error, I think I discovered the memory-mapped location of the SLP_TYP (sleep type) register for power resources on the Latitude E6410.  The 3-bit SLP_TYP read/write register determines the sleep state to assume after SLP_EN (sleep enable) is set.  If I am correct, you can access SLP_TYP in your DSDT by modifying the OperationRegion already defined for SLPE (SLP_EN) in your DSDT as follows:

 

    OperationRegion (PMRS, SystemIO, 0x0430, One)
    Field (PMRS, ByteAcc, NoLock, Preserve)
    {
            ,   4,
        SLPE,   1,
        SLPT,   3
    }

SLPE is a 1-bit register that is enabled when set to ZERO, so I assumed that SLPT follows the same "negative logic" and that 111b in the Intel spec (the value of SLP_TYP for State S5) is actually a value of 000b in the SLP_TYP register.  I guessed the memory-mapped location of the SLP_TYP by assuming it to be bit-wise adjacent to SLP_EN as described in the Intel spec on page 537. I experimented with both locations on either side of the SLP_EN bit and believe my OperationRegion above is correct.  To confirm this, I set SLPT to 000b (ZERO) and my system shuts down normally.  Changing SLPT to other values disrupts normal shutdown.  When I get time, I will experiment with different values for SLPT to see if setting this can help the laptop assume Sleep State S3.

 

I invite others to experiment and report findings here.

 

EDIT: Here's a good article that explains the OperationRegion construct in DSDT: https://lwn.net/Articles/367630/

Edited September 6, 2019 by tonyx86

[deeveedee]

Just upgraded my Dell Latitude E6410 to Mojave 10.14.6 (from 10.14.5).  Everything works perfectly.  Upgrade process was simple:

• Backup!
• Apply 10.14.6 update from AppStore
• Before rebooting into 10.14.6, boot from DosDude-patched Mojave Installer USB and apply Legacy Graphics Patch

[hazem3ly]

I Have Latitude E6410 (i5-520m,Graphics NVS 3100M, Wi-Fi: Broadcom  BCM94352).

Successfully Installed Mojave Thanks To This Topic

(I Used The Attached dsdt and config.blist files)

But After I Installed DosDude-patch And start and login to osx, everything is fine but after one minutes or less screen start to gose black as it going to sleep and i have to move the mouse to get it back and when i reboot with nv-disable=1 the screen work normally but no graphic work ,then i tried to patch my original dsdt the nvidia works but the system become slow ,

second problem is wifi card i know it compatible with hackintosh and i get it to work but it switched off automatically and couldn't get it on again

 

Any Suggestion what to do

 

CLOVER.zip

[deeveedee]

@hazem3ly At first glance, your DSDT looks like it's missing patches.  Did you first follow duduclx's link at the beginning of Post #1 in this thread and then follow my recommendations in Post #1?  I looked for  NVidia patches and PNLF as my first two searches and didn't find either. I would recommend that you read Post #1 of this thread very carefully and then check back here with what I suspect will be a working system.

[hazem3ly]

I Forget To apply Patches in dudclx's link ,but i applied it now and then the problem of screen gone black not resolved so i tried to apply every patch individual and i found that what make the problem is in this code 

    Scope (_SB)
    {
        Device (PNLF)
        {
            Name (_ADR, Zero)  // _ADR: Address
            Name (_HID, EisaId ("APP0002"))  // _HID: Hardware ID
            Name (_CID, "backlight")  // _CID: Compatible ID
            Name (_UID, 0x0A)  // _UID: Unique ID
            Name (_STA, 0x0B)  // _STA: Status
        }
    }

and when removed it the screen works fine .

the current problems is 

   the osx not fully shutdown(i've to long press power button)

   brightness not work (the slider now not apper in preference )

   the wifi card at os start is working but after small amount of time it switched off and never turned on again until restart

 

i have attached clover file CLOVER.zip

Edited August 6, 2019 by hazem3ly

[deeveedee]

I noticed items in your config.plist that look different to me, but I didn't make a thorough comparison.  What specifically are the differences between your config.plist and the one I posted?  Also, is your BIOS A17?

 

I would recommend removing all but the 'other' folder in the CLOVER/kext folder.  Looking at just the 'other' folder, how did you decide which kexts to put in your CLOVER/kext/other folder (some that I don't recognize)?

Edited August 7, 2019 by tonyx86

[Malu]

Hello,

I need to patch my LPCB._DSM.Name, but I cannot find that method in my DSDT. I also get a lot of errors when compiling. I fixed them, but I don’t think I did it correctly, because I cannot boot using the output DSDT. 

 

I have an i7 820qm in my E6410, so it won’t boot using your files. I’ve managed to install Mojave, and it works, but without speedstep. I’ve tried the common methods for fixing this, but they don’t work well.

 

I even got my internal nec renesas usb 3.0 card working, which I didn’t think would be possible on Mojave. The kext is called mXHCD if someone is interested in trying. If you have the expressCard model it’s cheap and easy... mine is the PC-Card variant. I changed the device id in the plist, because my device id didn’t match. 

 

I’m stuck with the DSDT patching and would really like some help... maybe post an asl of it your patched file?

 

Regards

Malu

 

[Malu]

Did anyone properly setup UsbInjectAll? Currently I have many ports listed that aren’t real ports... maybe that can affect sleep?

 

Malu

[deeveedee]

@Malu The IOName patch is in the DSDT that I attached to Post #1 in this thread.  Search for it and apply the same to your DSDT.  My latest custom SSDT-UIAC (for USBInjectAll.kext) is attached to one of my posts earlier in this thread.  You'll find it as either the first post on Page 3 of this thread or about 14 posts ago.

 

I7-820QM eh?  Very cool.  Do you also run with 16GB RAM?  I read about it and decided against it when I saw that no one had speedstep working.  You could try to create an SSDT for your CPU using ssdtPRGen.  I'm not going to be much help with that, because I couldn't get it to work for custom Gen 1 CPUs.  There is an L3426 (Lynnfield, Xeon) CPU in the ssdtPRGen examples that should be a close match and a good starting point for you.  That's about all I can offer for your CPU.

 

 

Edited August 7, 2019 by tonyx86

[Malu]

@tonyx86 Thanks for your quick reply. I disassembled your DSDT to have a look... it's very different from mine, and luckily the errors I needed help with are not present. I have errors for some address ranges that I cannot really fix by changing syntax... the actual values are not accepted. I'll try to insert your values to see what happens, it will probably crash the machine though.

 

I'll try your SSDT-UIAC. I probably need to modify a bit, because having a 820QM is messing with a lot of things. For example I have a strange name for one USB controller.

 

I've tried ssdtPRGen but that doesn't work well. Clocks are lower and I think it gave me stability issues. I'll try again with your proposal. I put a startup find/replace in Clover for the AppleALC plist. This makes AppleALC load, but will only give me turbo for 4 cores. It's not that bad aside from single core performance.

I want to test your method to see if it makes a difference, it probably won't if there are no more ID matchings aside from AppleALC. Maybe there are no 4 core drivers available from Apple for this PCH ID. I don't know enough about Gen 1 speedstep and turbo... yet. For the Core2Duo the voltage and frequency was set by software. Gen 1 took the voltage setting out I know. Maybe the frequency is still set in a similar way. In that case the driver must decide how many cores to use for a certain load, and then set those values correctly.

 

Yes, I installed the 820QM just to see if it worked. They don't cost a lot nowadays... I might try the 940XM when they become a little cheaper. My machine has some custom cooling($3 laptop cooler and back cover removed from E6410), so heat is not an issue. Current from VRMs might be. There can also be Bios issues... 

I tried 16GB ram before, but windows didn't like it. Dell Bios memory check works well on it though. I don't know if it is possible to get 16GB working well on this computer?

 

What I've been spending time on is getting 4K30hz and 2K60hz working from display port. It works in windows 10, but the pixel clock patch for macOS doesn't work for this GPU. Have you any experience in patching graphics drivers? I have 2K40hz working now, so its not too bad. It's connected to a 60" 4K TV, and I use magic- trackpad2/keyboard2 for controlling it. It's perfect for some living room browsing.

 

My E6410 is already working well enough now though, but somehow I cannot stop hacking.... It will replace an old MacBook Pro late 2008 as media server. Key was getting USB 3 working for connecting my DAS. I connected USB card to WWAN slot.

 

Thanks for your help!

[deeveedee]

7 hours ago, Malu said:

I've tried ssdtPRGen but that doesn't work well. Clocks are lower and I think it gave me stability issues. I'll try again with your proposal. I put a startup find/replace in Clover for the AppleALC plist. This makes AppleALC load, but will only give me turbo for 4 cores. It's not that bad aside from single core performance.

If you can post a quick how-to on ssdtPRGen with the specific command line that you used, I have another system where I could try it and report back.

 

7 hours ago, Malu said:

Have you any experience in patching graphics drivers? I have 2K40hz working now, so its not too bad. It's connected to a 60" 4K TV, and I use magic- trackpad2/keyboard2 for controlling it. It's perfect for some living room browsing.

 

My E6410 is already working well enough now though, but somehow I cannot stop hacking.... It will replace an old MacBook Pro late 2008 as media server. Key was getting USB 3 working for connecting my DAS. I connected USB card to WWAN slot.

I don't have experience with patching graphics drivers - sorry I won't be any help there.  Sounds like you're really pushing the envelope with the E6410.  My only remaining issue at this point is sleep.  I tinker with it and continue to learn. Please continue to share your progress and any lessons you've learned.  Thanks! 

[deeveedee]

I've had good experience with USBInjectAll and Mojave, but my systems are all old, so I can't speak to systems newer than 1st Gen / Series 5.  

 

In my experience (again, older systems), Series 5 Chipset / Lynnfield, Clarkedale, Arrandale, Nehalem does much better without Generate C / Generate P states as long as the correct MacModel is selected (MacBookPro 6,2 in this case) and the correct IONameMatch is injected in LPCB._DSM ("3b09" in this case).  Adding CLOVER CPU options (like Generate C / Generate P States) limits the peak multiplier and reduces the number of P-States. I have similar experience with a Series 5 Chipset / Xeon X3450 (Using MacModel MacPro5,1 with IOName "3b09").

[Malu]

It's alive!!

Turbo is now working on my E6410 I7-820QM. I guess AppleLPC was not the only kext/driver to match pci8086,3b07.

 

I had problems getting a DSDT that wouldn't crash the machine during boot. I followed some guides I found that included a step to disassemble DSDT and additional files together, before using MaciASL.

That doesn't work for me. Only good thing to come out of that was that I could disassemble tonyx86's DSDT(it won't open in MaciASL otherwise).

 

I used tonyx86's DSDT to find correct address values for my "corrupt DSDT". Still wouldn't boot. Then I just opened system DSDT and corrected it, and machine booted! Then I added the _DSM method from tonyx86's DSDT and speedster/turbo just works.

 

I got speedster and turbo to work a bit by renaming match id pci8086,3b07 to pci8086,3b09, in AppleLPC plist.

What doesn't work is C-states. If macOS cannot set C-states correctly, the CPU can only turbo on 4 cores. Turbo is automatically handled by the CPU, but if all cores are active, it won't help much for single thread performance.

 

I used this command to check if C-states were correctly set:

sudo powermetrics --show-process-energy

Powermetrics is complaining about not getting backlight node and SMC values, but C-states are working now.

 

I'll try to finish up by fixing USB assignments and some other minor issues... then have a look at the sleep issue.

 

Hervé's proposed solution for USB sounds interesting...

 

Thanks for your support guys!

[Malu]

@Hervé That DSDT doesn't work when I have the I7-820QM installed. It works well with the 620M though. I put that method in a DSDT I pulled when I had the 820QM installed.

 

I'm currently testing the system with working power management... it seems a side effect is slow ethernet speed.

Before power management it would transfer around 70MB/s, now around 10MB/s. If I open a browser and scroll continuously, the speed goes up to 60MB/s.

 

It might not be related to the power management, I'm still investigating... I hope I can find a fix

[deeveedee]

@Malu - could you post your DSDT?  What OS are you emulating in your DSDT (Linux, Win7...)?  My E6410 seems to work best when emulating Linux.

 

Attached is my current DSDT.aml.  I haven't attached it to the first post of this thread, because it's still a work in progress.  Differences between this attached DSDT and the one in Post #1 include:

• Removed PNLF (I'm content with adjusting brightness with the keys and the DSDT does not need to be patched for this)
• Added Mutex Release (WMIX) at end of Method (WSVP) and Method (WVCU)
• Fixed Dell bug in Method (GNOT) (replaced LOr with LAnd)
• Removed duduclx "Intel Ready" patch for Intel HD Graphics (not necessary with NVidia 3100m)
• Hard-coded ACOS and OSYS variables to emulate Linux (eliminated method OSID)
• Changed IFs to ELSEIFs to eliminate unnecessary code execution in ECW and ECR1 methods
• Added EC cases for all EC registers in Method ECW
• Partially restored code execution conditional on OSYS in Device (HPET)::Method (_STA)
• Other minor changes 

 

My laptop currently runs perfectly with the exception of non-working sleep.

DSDT.zip

Edited August 9, 2019 by tonyx86
Changed ECR to ECR1 (typo)

[Malu]

@tonyx86 I haven't done anything with my DSDT yet, aside from pasting the method in Hervé's post. I'm actually running without patched DSDT now, as I didn't like how the power manager made the computer unresponsive.

 

Ethernet speed around 1MB/s if laptop is completely idle doesn't work for a server. Without patched DSDT it manages close to 100MB/s now, up from 70MB/s I had previously without patched DSDT. Probably because I rebooted the server that I copy files from,  that has been online for years. Power consumption is at 30W idle which is ok, as it's always plugged in.

 

OS emulation? I just started hacking DSDT's, so I don't even know what that is. What difference do you see between those options?

 

I experience random freezing/crashing, but logs are not updated, so I have no idea where to start looking. It mostly happens at night when the machine is idle. It also freezes in Firefox on a page with live stock charts. That very same page won't even load in Safari.

 

It seems you soon have a completely rewritten DSDT for macOS... I'll have a look at it.

I would like to get access to the PLL controller, or be able to set the frequency via DSDT. I've heard that Dell doesn't connect the PLL chip to the common SMBus, so its probably not possible.

[deeveedee]

@Malu All DSDTs that I've seen have code branches that execute differently depending on the operating system.  I'm flying blind without seeing your DSDT (you said it's different with your CPU), so search your DSDT for "Windows" and hopefully you'll see what I mean.  There are two variables in the Latitude E6410 DSDT that assume values that depend on the Operating System: OSYS and ACOS.  Method _OSI() is used to identify the currently running OS.  For example, if _OSI("Linux") returns TRUE, your system is currently running Linux.  Since the original Latitude E6410 DSDT was never coded to recognize MacOS ( which is detected by checking _OSI("Darwin") ), you may want to add the "Darwin" condition to your DSDT to see if this resolves any issues.  If you look closely at the DSDT that I attached a couple of posts ago, you'll notice that I have hard-coded OSYS and ACOS to specific values.  The hard-coded values I chose are those that would have been assigned for the condition _OSI("Linux") = TRUE (so I am telling my DSDT to pretend that Linux is running when I am running macOS).  Read Post #1 of this thread and you will see that I mention this in my "known issues" section.  I owe credit for this "OS Equivalency" to Rehabman from whom I first learned about this in one of his many posts.

 

I have not "completely rewritten DSDT for macOS."  I started making changes after I found the Dell bug in Method (GNOT) and realized that quality assurance for the Latitude DSDT must be bad if this bug remains in the DSDT at revision A17.  I noticed this same bug in other Latitude DSDTs, so someone's not paying attention.  There are always bugs in code, but the GNOT bug is so obvious, that I stopped trusting any of the Latitude DSDT code and did a thorough code review.  I was hoping that the sleep issue was simply a DSDT bug, but so far, none of my changes have fixed sleep.

 

I would suggest that you try creating two conditions for _OSI("Darwin") in your DSDT (one for OSYS and one for ACOS) such that you make them equivalent to "Linux" to see if this helps.  There are multiple ways to do this.  The brute-force way is to replace instances of _OSI("Linux") with "LOr(_OSI("Darwin"), _OSI("Linux"))" so that the "Linux" code branch executes if the OS is Linux or Darwin.  If that doesn't help, experiment with Windows 7 by replacing instances of _OSI("Windows 2009") with LOr(_OSI("Darwin"),_OSI("Windows 2009")).  Note that "LOr" is logical OR of two conditions, so it returns TRUE if either condition is TRUE.  Another way to achieve this is to create an SSDT that overrides _OSI() so that you don't have to modify the DSDT.  My hard-coded method (directly assigning values to OSYS and ACOS) is one I chose because my DSDT only needs to support macOS, so I don't care about the other conditions.

 

EDIT: If you choose to implement my hard-coded method (assigning values to ACOS and OSYS), note that you can't simply set OSYS and ACOS.  The DSDT also make calls to OSID().  You'll notice in that last DSDT that I posted that I have replaced calls to OSID() with ACOS.

 

EDIT 2: You'll notice 2 different coding styles in the Latitude DSDT that result in different ways to handle the _OSI() condition checks.  In Method (OSID), the OS strings (e.g. "Linux") are assigned to variables (e.g. "LINX") and these variables are referenced in the _OSI() condition statements.  In Method (IINI), there are no variables used for the OS strings, so the _OSI() condition statements reference the OS string.  I don't know why this inconsistency is present, but you'll need to edit Method IINI and Method OSID differently.

 

Most (if not all) DSDT patches that you find for the Latitude E6410 will ignore the ACOS and OSYS assignment (the DSDT defaults to a value if the OS is unrecognized) or they completely miss the assignment of ACOS.

Edited August 10, 2019 by tonyx86

[Malu]

@tonyx86 Thanks for the detailed explanation. I hardcoded the DSDT methods to always return Linux, and performed some testing.The mac was still hanging and ethernet power throttling was still too aggressive.

 

I have tried a lot of things for fixing the hang issue:

 

- Reinstalled Mojave on a clean disk and re-patched with dosdude1 Mojave patch (after boot macOS used 7GB ram before I reinstalled, now down to around 2GB). 

- complete ram test using memtest and bios diagnostics.

- Bare minimum kext install.

- Different network adapters.

- VirtualSMC.

- Use 130W power supply (Computer has suddenly just turned off a couple of times. Issue number 2?).

- DSDT Linux hack.

- ...

Nothing helped.

 

I decided to have a look at your Nvidia patching, as the laptop would often freeze when running more graphics intense applications. 

 

I used the DSDT from your first post as reference when adding this code. I later saw that you have made some changes since then in your recently posted DSDT.

 

Computer has been running for 6 hours now without freezing... one hour was the previous max, but average around 15 minutes.

 

 

 

[deeveedee]

@Malu "Suddenly turns off" could be thermal (which wouldn't surprise me).   You mentioned that you have modified the cooling to compensate for the higher power dissipation.  Have you installed copper shims or are you still relying on the original thermal pads for the CPU and GPU?  I'm not advising you to install the shims (I don't want to suggest anything that you're not comfortable with), but the E6410 heatpipe (with the original thermal pads) is barely sufficient to conduct the heat from the 3100m and the recommended 35W CPU (which I'm sure is by design).  I have installed .3mm copper shims on both my CPU and GPU.  For the CPU, I have no thermal pad - just the lapped copper shim with AS5 on both sides of the shim which is seated between the heatpipe and the CPU die.  For the GPU, I installed the copper shim on the GPU die (with AS5) and have a fujipoly thermal pad on the heatpipe.  The reasoning for the CPU shim is self-explanatory.  The reason for the GPU shim is that I have changed the heatpipe spacing by inserting a CPU shim, so I need to add the same shim to the GPU.  In addition, the copper shim I used is larger than the GPU die (and the same dimension as the thermal pad), so it acts as a heatspreader so the thermal pad has more surface area to work with.  My CPU and GPU temps reach a max of 20C less under load than they did without the copper shims.  That's significantly better thermal conductivity.

 

EDIT: One other observation that might help you - when I installed the copper shims, I noticed that my northbridge chip did not have a thermal pad.  There was NOTHING conducting heat away from the northbridge chip since it made no contact with the heatpipe assembly.  For the 35W 2-core CPUs, that may be ok.  For your 45W 4-core CPU, maybe that's not ok?  I don't know.  In any event, I installed a 2mm thermal pad on my northbridge chip so the heatpipe assembly conducts heat from it as well.  At a minimum, I would recommend that you add the 2mm thermal pad to your northbridge if you don't have it.

Edited August 12, 2019 by tonyx86

[Malu]

@tonyx86 It's probably not thermal(as it often happens when the computer is idle and temps are very low), but it behaves exactly like that.

 

When I first installed the 820qm, I got a thermal shutdown(logged in bios). The root cause was a thicker die of the 820qm, so the GPU overheated as it was no longer in contact with the heatpipe. I use a very thick 1mm shim on the GPU and no pad. A bit scary as the heat pipe is not very flexible, so if the gap is too big between one of the dies, the other die might get a lot of pressure.

If you are still using a pad, I don't think you need a shim on the CPU die.

 

I had a pad on the pch already. I guess someone forgot to put it there at assembly... if you are the first owner.

 

It acts like a hardware issue, so I have tried to trigger it by shaking, knocking, tapping so-dimms and heatpipe... That does nothing.

 

I've disconnected everything from the USB ports... that cheap cooler could do things to the 5V. I run it on an external source now.

 

So far everything has been working, except Firefox. When it failed, it brings down Finder... and probably everything else, as remote login is impossible.

 

I'm running Firefox on another dosdude patched computer without issues. I noticed that AGPM hasn't attached on that computer either(maybe you fixed that already), and it has some sleep issues. It's a MacBookAir3,1.

 

Can it be helpful to have a DSDT from a real MacBook Pro 6,2? I think I can get that.

[deeveedee]

@Malu I don't experience any of what you're describing, so this is unique to your laptop. I'm not the first owner, so it's possible that the first owner tinkered with the heatpipe and never replaced the northbridge thermal pad on my laptop.  I have only a copper shim on the CPU - no thermal pad on the CPU.

 

If you're confident that you have followed the recommendations in this thread for DSDT patches, kexts and config.plist, then this is an 820qm compatibility issue and not something we're going to learn from the real MBP6,2 (my opinion).  I don't experience any of what you're describing with my hackbookpro - the only remaining issue I have is sleep.  The E6410 runs Mojave perfectly except for sleep.

 

If you want to post problem reporting files for us to look at (that's the only way we can make further progress on your issues), Google "blackdragon problem reporting tool" and use the tool to generate a zipped folder that you can attach to a post in this thread.  Without your original and patched DSDT, your config.plist, your installed kexts and your ioRegExplorer dump, anyone trying to help you (including me) is blind.

[Malu]

@tonyx86 I meant that the thermal pad on the GPU is flexible enough, so you won't need shim on the CPU. 

 

I don't think I can make this laptop, with the 820qm, work well as a hackbookpro, at least not with Mojave.

I'll try it with older systems to see if it works better.

 

I meant that you might be able to find something interesting from the MBP6,2 DSDT and IOExplorer for the sleep issue. 

 

I'll have a look at the black dragon tool.

 

Thanks for your help.

[deeveedee]

@Malu When/if you decide to revisit Mojave issues specific to the i7-820qm, please start another thread that is specific to your issue and post the link for it here.  That way, we're not clobbering this thread with a topic that now appears to be unrelated.  Thanks!

 

Also, the CPU and heatpipe don't make solid contact without a shim or thermal pad.  I tried, but my CPU temps started to climb which was because there's a fine gap between the heatpipe and CPU. The gap was initially bridged by AS5, but as the AS5 settled, the thermal contact began to fail.  I'm not sure how much tolerances vary from one E6410 to another, but for my laptop, I have to use a thermal pad (low thermal conductivity) or a copper shim (high thermal conductivity) in order to ensure thermal conductivity from the CPU die to the heatpipe.

Edited August 12, 2019 by tonyx86