Jump to content

tonyx86

Just Joined
  • Content Count

    95
  • Joined

  • Last visited

Everything posted by tonyx86

  1. tonyx86

    Mojave on Dell Latitude E6410

    I was inspired by @duduclx post for installing El Capitan on a Dell Latitude E6410, so I decided to install Mojave 10.14.5. Everything works perfectly except for sleep. I'm starting this thread hoping to help others install Mojave on their E6410s and to diagnose and resolve the sleep issue. This thread is not currently intended to be an installation guide and is better suited to the intermediate/advanced hackintosher. Eventually, it may evolve into a guide. I started with this thread and ended up with the system captured in the attached files. The keys were to change the LPCB._DSM.Name to "3b09" and remove all CLOVER configs not necessary for Mojave, plus some other items mentioned below. My system is as follows: Dell Latitude E6410 (I7-620m, Nvidia 3100M, 8GB DDR3, 512GB SSD, 1440x900 display, BIOS: A17) MacOS: Mojave 10.14.6 (APFS) (Patched with DosDude Mojave Patcher 1.3.3) MacModel: MacBookPro 6,2 (LPCB._DSM.Name "pci8086,3b09") Kexts: Lilu 1.3.6, VoodooHDA 2.9.2, AirportBrcmFixup 2.0.0, IntelMausiEthernet 2.4.1d1, ACPIBatteryManager 1.90.1, BrcmPatchRam2.kext, BrcmFirmwareRepo.kext, VoodooPS2Controller (the "Refined ALPS Touchpad" version - release 5, not the original version), USBInjectAll (with custom SSDT-UIAC) Wi-Fi: Broadcom BCM 94352HMB (with AirportBrcmFixup.kext) CLOVER (Legacy): R4961 Configuration items that may be different from what you have seen in other E6410 configurations LPCB._DSM patched with device-id "3b09" AND "name", "pci8086,3b09" for native Nehalem power management with MacBookPro 6,2 ECDV renamed to EC so that AppleBusPowerController loads AGP.VID._DSM patched with device-id "0a29" so that AppleGraphicsPowerManagement loads  No CLOVER Generate P or Generate C States (with the correct LPCB._DSM and MacBookPro 6,2, these CLOVER options are unnecessary for this architecture and only limit max multiplier and reduce number of P states) DSDT patched to include HDAU device (device-id 0x0be3) What is NOT working: Sleep (display goes blank, but power light stays on. System cannot wake and must be forced off with power button) Display brightness can be controlled with keyboard keys, but cannot be controlled with slider in Display settings. The slider appears in Display settings (because of the backlight DSDT injection in AGP.VID._DSM), but the slider doesn't work (yet). Haven't spent time to figure this out, but would love help. Graphics Power Management - AGPM loads (because 10de,0a29 device is injected), but there's no evidence that 3100m frequency and voltage is changing. What is NOT tested: SD Card Slot Smartcard Reader eSata (I have this disabled in my BIOS) Firewire Port (it does appear in the Network settings, just haven't tried it) Microphone Jack PC Card Slot (I have this disabled in my BIOS) Camera (I have this disabled in my BIOS) What IS working: Everything else not mentioned above. Speedstep/CPUPowerManagement is perfect, system temps are low, CPU multiplier operates as expected, battery life is long Shutdown is fast Display/graphics acceleration is perfect (thanks to DosDude's Mojave patcher) Brightness (adjusted with brightness keys on keyboard) works perfectly Battery Manager works (battery status is displayed in menu bar) simply by installing ACPIBatterManager.kext. Wi-Fi (after changing to Broadcom BCM94352HMB and installing AirportBrcmFixup.kext) Audio (volume adjustable, volume indicator appears in menu bar). Switched to VoodooHDA from AppleALC after AppleALC caused slow boot due to "IOHDACodecFunction timeout." Ethernet port (with IntelMausiEthernet.kext) Broadcom BCM20702A0 Bluetooth (with BrcmPatchRam2.kext and BrcmFirmwareRepo.kext) Optical Drive External VGA (with corrected NVCAP. Need NVCAP 04000000 00000100 0E000000 00000007 00000000 (credit: here) for working external VGA display. Headphone jack Display Port (tested using DP > HDMI adapter) Known issues and their solutions AAPL,clock-id and device_type do not appear in IORegistry for EHC1. Solution is to use CLOVER on-the-fly patching/fixing/renaming for EHC1 and EHC2. This has been completed and tested, but does not fix the sleep behavior. This fix is not reflected in the attached files. ALPS trackpad performance is not good with the "standard" VoodooPS2Controller.kext that I initially used. Switching to the "Refined ALPS TouchPad driver" is a big improvement. I've implemented and tested this on my system. The ALPS version of VoodooPS2Controller.kext mixes up a few keys. Need to switch the Command and Option keys (System Preferences > Keyboard > Modifier Keys) and change keyboard type to ISO European. The updated VoodooPS2Controller.kext is not reflected in the attached files. This proposed configuration uses an injected device-id (10de,0a29) for NVidia 3100m to get AGPM to load. While I haven't observed any performance differences, a better approach may be to inject AGPM properties for device 10de,0a6c (the actual device-id for the 3100m). This AGPM method is discussed later in this thread. I have briefly tested this "FakeSMC.kext method" for injecting AGPM attributes without any noticeable changes in laptop/graphics behavior and have not updated attached files to reflect this change. IOHWControl is not loaded under AGPM (Should be AGP > VID > NVDA,Display-A@0 > NVDATesla > AGPM > gpu-control > IOHWControl as viewed in IORegistryExplorer). It is loaded on a real MacBookPro6,2 running Mojave and is loaded on this Dell Latitude E6410 running High Sierra. If I "Inject NVidia" via CLOVER, IOHWControl loads properly. I have made this change and am testing it on my system, but have not updated the attached configuration files. The Dell Latitude DSDT (BIOS A17) has a bug in Method (GNOT). In the method, the expression If (LOr (LGreater (OSYS, 0x07D0), LLess (OSYS, 0x07D6))) always evaluates to TRUE, so the patched DSDT has no dependency on the value of OSYS. I suspect that LOr should be replaced with LAnd, so that this expression is TRUE for variants of Windows 2001 and False for any other OS. While this may have no affect on MacOS, it makes one wonder how such an obvious bug made it through Dell QA and is still present in BIOS A17. Also makes one wonder whether the sleep problem (which no one has solved) was fixed in Windows to address another DSDT bug. The DSDT patch that duduclx refers to as "Intel GMA Ready" in his El Capitan Guide is not applied correctly to the DSDT attached to this post. Somehow, the contents of patched _DSM are located in the PCI0.VID device instead of in Method (_DSM) within the PCI0.VID device. MaciASL didn't complain about this, so it went unnoticed, but it doesn't appear to have had any affect. I have completely removed this "Intel GMA Ready" patch from my DSDT since it is not necessary for Dell Latitude E6410's with NVidia 3100m, but have not updated the attached DSDT. The assigned value of ACOS in the DSDT is conditional on the operating system. There is no condition for "Darwin." The solution is to add a condition for "Darwin" (making it equivalent to one of the defined operating systems (e.g. Linux, Win7, etc), analogous to the assignment of OSYS. I made this change in my DSDT (not yet reflected in the attached files), but have not observed any behavioral differences (sleep or otherwise). EDIT: Another way to handle this might be to override _OSI with XOSI (defined in a custom SSDT). Still learning about XOSI and haven't yet drawn a conclusion. I'm currently experimenting with ACOS and OSYS equivalent to Win7 and Linux (manually patched in my DSDT which has not yet been updated as a new attachment to this post). The portType of the Internal Bluetooth device is portType=0 which, according to Rehabman's comments in SSDT-UIAC-All.dsl, is an external USB 2 port. I believe that this should be an internal USB port (portType=2). My custom SSDT-UIAC.dsl is wrong. I just learned through trial and error that the HUB1 and HUB2 definitions in Rehabman's SSDT-UIAC-ALL.dsl apply to the ports on the EHCx USB hubs. The solution is to include the HUB1 definition in SSDT-UIAC.dsl and change portType to 2 for HP15. I have not attached an updated SSDT-UIAC.aml to this first post, but my current EFI includes an updated SSDT-UIAC.aml with ports HP15, 16 17 and 18 set to internal (portType = 2). This change doesn't appear to affect/fix sleep, but it may prevent instant wake if we get sleep working. Brief Installation Guide (for the experienced Hackintosher): Follow duduclx's guide for BIOS config Create your MacOS installer USB (Use DosDude's Mojave Patcher for Mojave) (start with High Sierra and not Mojave if you're new to hackintosh). Install CLOVER (Legacy) on installer USB using attached EFI as your guide for patched ACPI, kexts and config.plist Install MacOS to your SSD. When you run DosDude's Mojave Patcher, DO NOT install LegacyUSBInjector.kext - you're going to use Rehabman's USBInjectAll.kext. Also, do not install the DosDude SIP kext (you're using CLOVER to manage SIP). Install the following kexts in /Library/Extensions: ACPIBatteryManager.kext, AirportBrcmFixup.kext, BrcmFirmwareRepo.kext, BrcmPatchRAM2.kext, FakeSMC.kext, FakeSMC_ACPISensors.kext, FakeSMC_CPUSensors.kext, FakeSMC_GPUSensors.kext, FakeSMC_LPCSensors.kext, IntelMausiEthernet.kext, Lilu.kext, USBInjectAll.kext, VoodooPS2Controller.kext (the "Refined ALPS Touchpad driver," not the original) Switch Command and Option keys to compensate for Refined ALPS driver issue (System Preferences > Keyboard > Modifier Keys). Also change keyboard type to ISO European to fix the [ ` ~ ] key (to the left of the "1" (one) key. Install VoodooHDA Install HWMonitor application Tips for Improved Performance (on this and other older systems) System Preferences > Spotlight > Search Results: Uncheck all options System Preferences > Spotlight > Privacy: Add all Volumes System Preferences > Accessibility > Display: Check "Reduce motion" System Preferences > Accessibility > Display: Check "Reduce transparency" Other tips If your fan is always running and temps are good, try pressing Fn + z CLOVER.zip
  2. tonyx86

    Mojave on Dell Latitude E6410

    There are new versions of the following kexts that I have not yet tested. Has anyone tested these to confirm that they work with the Latitude E6410? AirportBrcmFixup (v2.0.3 as of this post: https://github.com/acidanthera/AirportBrcmFixup/releases) Lilu.kext (v1.3.8 as of this post: https://github.com/acidanthera/Lilu/releases)
  3. tonyx86

    Mojave on Dell Latitude E6410

    @vbmota After a quick scan of your debug files, here's what I see: Your CLOVER/kexts folder has kexts in CLOVER/kexts and CLOVER/kexts/Other. You only want kexts in CLOVER/kexts/Other Too many kexts in CLOVER/kext/other. Just follow the example I attached to post #1 and install other kexts in /Library/Extensions as I have indicated in my instructions in Post #1. This is my preference (others have differing opinions). It appears that you may have selected the SIP Manager option in DosDude's Mojave patcher. Properly remove SIP Manager.kext from /Library/Extensions It appears that you have have NullCPUPowerManagement.kext installed. Why? It appears that you have both USBInjectAll.kext (Rehabman) and LegacyUSBInjector.kext (DosDude) installed Why do you have CLOVER boot option 'nvda_drv=1'? I'm going to stop there. Please re-read Post #1 and follow it exactly for your Mojave installation. You cannot start with a previous installation of Mojave that was not working and then start with the instructions in this thread. This thread assumes that you are starting your Mojave installation from scratch. Good luck!
  4. tonyx86

    Mojave on Dell Latitude E6410

    @vbmota It may take me a while to post an updated config.plist. Did you have any specific questions about something that's not working for you? Did you get sleep working?
  5. tonyx86

    Mojave on Dell Latitude E6410

    @Malu I've tinkered with CLOVER just enough to be dangerous, but still prefer manually patching my DSDT. Currently, my E6410 config.plist renames EHCx to EH0x, Fixes USB, Injects NVidia, enables TRIM, adds the -no_compat_check boot flag and configures SMBIOS. All other patches are manually applied to my DSDT using Rehabman's version 1.31 of MacIsl. I wouldn't be the right person to start with the original DSDT and fix everything with a CLOVER config.plist, but I'd love to see it if anyone has it. Also, now that your system is stable, could you post your Geekbench results? I'm curious to see the performance difference between the I7-820QM and the I7-620M. My I7-620m Geekbench score is attached to the first post in this thread.
  6. tonyx86

    Mojave on Dell Latitude E6410

    @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.
  7. tonyx86

    Mojave on Dell Latitude E6410

    @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.
  8. tonyx86

    Mojave on Dell Latitude E6410

    @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.
  9. tonyx86

    Mojave on Dell Latitude E6410

    @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 ECR 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
  10. tonyx86

    Mojave on Dell Latitude E6410

    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").
  11. tonyx86

    Mojave on Dell Latitude E6410

    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. 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!
  12. tonyx86

    Mojave on Dell Latitude E6410

    @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.
  13. tonyx86

    Mojave on Dell Latitude E6410

    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 on which kexts to put in your CLOVER/kext/other folder (some that I don't recognize)?
  14. @rongu I don't work on the ThinkPad T61 very often (only updated to Mojave to see if it worked and it works well for a 2008 laptop). If I remember to get the DSDT the next time I'm on that system, I'll post here. In all honesty, the DSDT does not add any value to this thread. Everything that I required to implement onejay09's brightness fix for the Thinkpad T61 is in my previous post. I hope that helps. I think the biggest revelation for me was that the GFX0._DSM doesn't require much if you use CLOVER's "Inject NVidia" option. It significantly simplifies this brightness fix on the Thinkpad T61 and maybe other laptops as well (likely with different values for pwm-info and NVCAP). .
  15. tonyx86

    Mojave on Dell Latitude E6410

    @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.
  16. tonyx86

    Mojave on Dell Latitude E6410

    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
  17. tonyx86

    Mojave on Dell Latitude 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/
  18. tonyx86

    Older Hackintosh CMOS reset error on Sierra

    I'm having what appears to be the same problem with my Biostar TH55HD / X3450 system running Mojave 10.14.5 (CLOVER R4961 Legacy). I just read on another forum that configuring S3 suspend state in BIOS with P55 / H55 chipsets results in BIOS corruption on sleep (even with CLOVER RTC fix) and that the solution is to change suspend state to S1 in BIOS. This is the first I heard of this. In order to make this change and try this fix, I will have to extract new DSDT. Has anyone tried changing suspend state to S1? I'll report back with my findings when I have time to test. EDIT: I changed S3 to S1 in BIOS. On sleep, displays go black and fans stay running (which I think is expected S1 behavior). System wakes normally with mouse or keyboard activity. While I wouldn't consider this a "fix," this is the configuration that I'll run with until theres a working solution for S3 suspend state. NOTE: Changing state S3 to S1 in BiOS did not result in any DSDT changes. I thought that I had seen two OperatingRegion changes in my DSDT when I had experimented with suspend state before. This might have been when I set suspend state to "Auto S1/S3" (instead of to either S1 or S3). Not sure, but no DSDT changes were required for this 'fix."
  19. As I previously reported, after upgrading my Thinkpad T61 to Mojave 10.14.5 (using DosDude's Mojave patcher), @onejay09's brightness fix (patching DSDT with PNLF and GFX0._DSM and running onejay09's script) still works (Display slider still controls brightness). I recently noticed that when running Mojave, IOHWControl was not loading under AGPM as viewed in IORegistryExplorer (see attached screenshot showing IOHWControl in IORegistryExplorer). IOHWControl was loading in High Sierra 10.13.6, but not in Mojave 10.14.5. I'm not sure what I was missing in my DSDT patches, but the "fix" for this is to use CLOVER's "Inject NVidia" option (I wasn't using the CLOVER option before, since I injected all NVidia attributes via DSDT GFX0._DSM). Now, IOHWControl loads in both High Sierra and Mojave. With the use of CLOVER's "Inject NVidia" option, my DSDT patches now include only the PNLF patch and the following elements in my GFX0._DSM: define "@0,pwm-info": this is required for proper brightness control. Brightness control "worked" without this in my DSDT, but brightness adjustment wasn't "smooth" across the entire adjustment range. With this defined, brightness adjustment is smooth across the entire adjustment range. define "NVCAP": this is required for the internal and external display to work properly. Without "NVCAP" defined, the internal LCD display works when an external monitor is NOT plugged into the Thinkpad VGA port; however, if "NVCAP" is not defined, neither the internal LCD nor the external display work when an external display is connected to the VGA port. With these adjustments (enabling CLOVER's "Inject NVidia" option and including only "@0,pwm-info" and "NVCAP" in my DSDT's GFX0._DSM), my Thinkpad T61's display brightness slider works perfectly in High Sierra 10.13.6 and Mojave 10.14.5 (with DosDude's Mojave patcher). My new GFX0._DSM includes only following: If (LEqual (Arg2, Zero)){Return (Buffer (){0x03})} Return (Package () { "@0,pwm-info", Buffer () { /* 0000 */ 0x01, 0x14, 0x00, 0x64, 0xA8, 0x61, 0x00, 0x00, /* 0008 */ 0x1C, 0x02, 0x00, 0x00, 0x64, 0x00, 0x00, 0x00, /* 0010 */ 0x00, 0x04, 0x00, 0x00 }, "NVCAP", Buffer () { /* 0000 */ 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, /* 0008 */ 0x1E, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0A, /* 0010 */ 0x00, 0x00, 0x00, 0x00 } }
  20. tonyx86

    Mojave on Dell Latitude E6410

    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.
  21. tonyx86

    Mojave on Dell Latitude E6410

    @vbmota I am not sure how to dual-boot Windows and MacOS on the same disk while preserving MacOS ability to perform updates. I have a replacement drive caddy that lets me install a second SSD in the DVD slot. I press F12 at boot to select the drive that I want to boot from. This allows me to have Windows on one drive and CLOVER/MacOS on the other. Note that my MacOS partition is formatted APFS and I dual-boot Mojave 10.14.5 and High Sierra 10.13.6 from the same SSD (each MacOS in its own APFS container). When you ran OSX and Windows on the same SSD, were you booting legacy or UEFI? Was your SSD partitioned MBR or GPT?
  22. tonyx86

    Mojave on Dell Latitude E6410

    @Dr. Monkey I have been experimenting with different OS identification equivalents to "Darwin" and believe that my laptop runs coolest (indicating lower power consumption) when I emulate "Linux" for _OSI("Darwin"). Do you know enough about editing your DSDT, so that your laptop is emulating "Linux" when running macOS? I haven't worked on an XOSI SSDT to override _OSI (still learning about it), so you would need to manually edit your DSDT to patch Methods IINI() and OSID(). I'm curious to know if you see a temp difference. I compared Linux and Win7.
  23. tonyx86

    Mojave on Dell Latitude E6410

    After reviewing IORegistryExplorer, I noticed that the portType of the Internal USB Port 5 on hub EHC1 is wrong. It is portType = 0 which is an external USB port instead of portType = 2 which is an internal USB port. I never knew that the HUB1 and HUB2 definitions in Rehabman's SSDT-UIAC-All.dsl applied to the USB ports on the EHCx hubs. By including the definition of HUB1 in my custom SSDT-UIAC.dsl and setting the portType of HP15 to 2, I was able to change the Bluetooth USB port type from external to internal. This does not appear to have had any affect on sleep, but may be important to prevent instant wake when sleep is finally working. This change is not yet reflected in the files that are attached to Post #1 in this thread. I have attached my new custom SSDT-UIAC.dsl to this post. EDIT: I uploaded a newer SSDT-UIAC.dsl that includes the UsbConnector values for each EHC1 USB port. SSDT-UIAC.zip
  24. tonyx86

    Mojave on Dell Latitude E6410

    @vbmota Welcome to the discussion! You mentioned Sierra - did you also try High Sierra? If your graphics worked fine in High Sierra, my first guess would be that you didn't apply Dosdude's legacy graphics patch (or you did and it didn't install correctly for some reason). Also, are you running HWMonitor and if so, can you see your GPU temps? EDIT: Also, did you follow my performance improvement tips listed in the first post of this thread? If you're confident in the legacy graphics patch, GPU temps are reasonable and you followed my performance improvement tips in the first post of this thread, are you able to post the following items for review (in a single zip file)? If you don't know how to produce these items, Google 'GENERATE PROPER PROBLEM REPORTING FILES BlackDragon' to use Black Dragon's problem reporting tool and post the zip file in this forum. The files you should post are: DSDT (I'd prefer your DSDT.dsl, but DSDT.aml is ok) IORegistryExplorer dump CLOVER config.plist list of kexts in your CLOVER/kexts/Other folder output of 'sudo kextcache -i /' CLOVER preboot.log (generated by pressing F2 in CLOVER bootloader screen. File located in EFI/CLOVER/misc)
  25. tonyx86

    Mojave on Dell Latitude E6410

    EDIT: I'm still learning about ACPI and DSDT patching and just learned about overriding _OSI with an XOSI SSDT (credit Rehabman). My comments/observations below do not reflect this new knowledge of XOSI as evidenced by my rather naive statement about Methods IINI and OSID. I don't know enough about the use of XOSI to apply it to the Dell Latitude E6410, but I suspect that a custom XOSI SSDT is the best way to "patch" _OSI in the E6410 DSDT. Will provide more detail as I learn about this and I welcome any comments, especially from others who have used the XOSI / _OSI override on their Latitude E6410 or similar laptops. After further review of the Dell Latitude E6410 DSDT (BIOS A17), I'm noticing a programming style that is inconsistent ( see OS Identification differences in Method (IINI) and Method (OSID) ) and flawed (note coding error in Method (GNOT) ), so I'm suspicious of the code's quality. Call me paranoid. I would appreciate other opinions on these suspicious items in the DSDT that may actually be nothing to worry about - just checking: Not a problem, but Method (ECR1) and Method (ECW1) each include a series of IF conditions, such that the methods always evaluate every IF condition, even if the first evaluates to TRUE. It would have been very easy to return immediately upon a TRUE IF condition. ACOS is used in Method (ECIN) without first initializing ACOS. Note the way ACOS is used in Method (STOS) Mutex (WMIX) is acquired in Method (WSVP) and Method (WVCU) and is never released at the end of the methods. All other methods that acquire a mutex release the mutex before exiting. Method (ECW1) does not support writing to every EC register (note that ECR1 supports reading from every EC register). I have addressed each of these in my DSDT and am currently running with these updates as I continue to look for reasons why the E6410 does not sleep. So far, I haven't noticed any difference in behavior.
×