Jump to content
Hervé

Dell Latitude E6440 with i5-4300M, HD4600 and 1600x900 LCD - Mavericks/Yosemite/El Capitan/Sierra

Recommended Posts

Did some additional tuning to the DSDT. Credits to RehabMan and his repository:

  • Closing the lid now puts the laptop to sleep.
  • Brightness bar added to Display PrefPane (Fn-Up/Fn_Down controls are moved to Fn-F3/Fn-Insert)

Updated Mavericks pack loaded to post #1 (pack #6) and updated Yosemite pack loaded to post #15 (pack #2).

 

Also added the new 10.9.5 Security Update Haswell-patched kernel.

Share this post


Link to post
Share on other sites

Had a hunch about obtaining the laptop to sleep through Fn-F1 and started experimenting... Got it to work by bypassing/removing the generated SSDT altogether. Using or not using Chameleon options "DropDSDT" or "Generate P States/C States" or "CST using SystemIO" then becomes irrelevant and without any effect. Laptop still gets CPU power management, just not the single intermediary multiplier x17: 8, 26, 27, 28, 29, 30, 31, 32/33 multipliers all remain.

 

I need to look into the SSDT to try and find a permanent fix.

Share this post


Link to post
Share on other sites

Sometimes, weird things happen. All of a sudden, DVD Player stopped working and returned the well known initialisation error:
DVD_error.jpg
 
I installed the IOAHCISerialATAPI_injector kext and the DVD came back to life, though slightly differently and somehow improved this time. When looking at the Supported Features in the Help menu, HD is no longer reported Unsupported like it used to be (see post #15):
DVD_SupportedFeatures.jpg
 
This applies to both Mavericks and Yosemite. I had been playing with DSDT/SSDT recently so the trouble may originates from that. 'need to see if I can suss out a way to get rid of that horrible little kext though.
 
IOAHCISerialATAPI_Injector.kext.zip

 

I'll add it to the next Yosemite boot pack.

Share this post


Link to post
Share on other sites

I've identified the SSDT-related problem and it appears the culprit that messes up behaviour of Fn-F1 (causing the key combination to shutdown the laptop rather than put it to sleep) is the following _DSM method at the very end of the \_PR.CPU0 scope:

       Method (_DSM, 4, NotSerialized)
      {
          Store ("Method CPU0._DSM Called", Debug)
          If (LEqual (Arg2, Zero))
          {
              Return (Buffer (One)
              {
                   0x03    // This appears to be the value causing trouble
              })
          }
          Return (Package (0x02)
          {
              "plugin-type", 
              One
          })
      }
I'd lie by pretending to know what this particular value equates to, but am investigating...

Share this post


Link to post
Share on other sites

I decided to try and return various alternative values from the _DSM method of the generated SSDT. By trial and error, I regained x17 CPU multiplier and retained Sleep through Fn-F1 when returning a value of 7. I'm therefore sticking to the following code:

       Method (_DSM, 4, NotSerialized)
      {
          Store ("Method CPU0._DSM Called", Debug)
          If (LEqual (Arg2, Zero))
          {
              Return (Buffer (One)
              {
                   0x07 // This values retains x17 CPU multiplier + Sleep via Fn-F1
              })
          }
          Return (Package (0x02)
          {
              "plugin-type", 
              One
          })
      }

CPU_P-States.jpg

 

I've also noticed that the Chameleon option DropSSDT=Yes is not necessary to obtain native CPU SpeedStep and/or Turbo boost. I've therefore changed my boot plist to that effect.

ssdt.aml.zip org.chameleon.Boot.plist.zip

 

:excl: In order to guarantee good behaviour of Fn-F1, make sure hibernate mode is set to 0 and that there is no 'sleepimage' file in /var/vm directory. If present, it must be deleted. A safety alternative consists of pointing the hibernate file to /dev/null.

 

NB: The above applies to both Mavericks and Yosemite.  :)

 

Updated Mavericks pack loaded to post #1 (pack #7) and updated Yosemite pack loaded to post #15 (pack #3).

Share this post


Link to post
Share on other sites

Thanks to JakeLo who passed on the details for testing, the Yosemite Azul frame buffer kext can now be binary patched to support HDMI output: the patch consists of replacing Hex code 01050900 00040000 87000000 by Hex code 01051200 00080000 87000000 in binary file  AppleIntelFramebufferAzul through perl script or via a binary editor such as 0xED.
 
HDMI output is then fully supported with hot plug/unplug. The only thing weird is the reported TV screen size (73.5" for an actual 40" screen!)
 
E6440_10.10.2_LCD+HDMI.jpg
E6440_HDMI_to_HD-TV.jpg
 
10.10.2_HDMI-bin-patched_AppleIntelFramebufferAzul.kext.zip
 
I have also verified that HDMI output can be sole video output when booting up the laptop with lid closed; it worked perfectly but system then hung when I opened up the lid... Best to avoid such mode in those conditions.
 

Updated Yosemite pack loaded to post #15 (pack #4).

Share this post


Link to post
Share on other sites

Following on another valuable advice from JakeLo and since we could get the SD card reader to work natively by patching the AppleSDXC kext, the following DSDT patch (under device RP08@1C,7, that's where it's found in IOReg) avoids all subsequent kext patches, especially as that was required after each OS X update:

               Device (SDXC)
               {
                    Name (_ADR, Zero)
                    Method (_DSM, 4, NotSerialized)
                    {
                        Store (Package (0x08)
                        {
                            "AAPL,slot-name", 
                            "Built-in", 
                            "device_type", 
                            Buffer (0x11)
                            {
                                "Media controller"
                            }, 
                            "model", 
                            Buffer (0x18)
                            {
                                "O2 Micro SD card reader"
                            }, 
                            "compatible", 
                            Buffer (0x0D)
                            {
                                "pci14e4,16bc"
                            }
                        }, Local0)
                        DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                        Return (Local0)
                    }
                    ...

The Info.plist file of the vanilla AppleSDXC kext containing a specific reference to Broadcom BCM57765/57785 SDXC/MMC card reader (PCI device 14e4:16bc), a simple statement "compatible" referring to that device enables the 02 Micro SD card reader once and for all, the rest of the patch being cosmetic info for the SysProfiler!

E6440_O2_CardReader.jpg E6440_O2_CardReader#2.jpg

 

This applies to both Mavericks and Yosemite so kext packs updated accordingly (Mavericks pack #8 in post #1 and Yosemite pack #5 in post #9).

Share this post


Link to post
Share on other sites

When using Rehabman's most recent or latest ACPIBatteryManager kext (v1.60.x for instance), battery icon keeps flapping between battery level and no battery, this being accompanied by a very annoying flapping of screen brightness.

 

I've looked into the DSDT to try and fix this and noticed 2 x different battery devices: BAT0 and BAT1.

        Device (BAT0)
        {
            Name (_HID, EisaId ("PNP0C0A"))
            Name (_UID, One)
            Name (_PCL, Package (0x01)
            {
                _SB
            })
            Method (_STA, 0, NotSerialized)
            {
                Store (ECG5 (), Local0)
                And (Local0, 0x02, Local0)
                If (Local0)
                {
                    Return (0x1F)
                }


                Return (0x0F)
            }


            Method (_BIF, 0, NotSerialized)
            {
                Name (BIF0, Package (0x0D) {})
                ECG9 (One, BIF0)
                Return (BIF0)
            }


            Method (_BST, 0, NotSerialized)
            {
                Name (BST0, Package (0x04) {})
                ECG6 (One, BST0)
                Return (BST0)
            }
        }


        Device (BAT1)
        {
            Name (_HID, EisaId ("PNP0C0A"))
            Name (_UID, 0x02)
            Name (_PCL, Package (0x01)
            {
                _SB
            })
            Method (_STA, 0, NotSerialized)
            {
                Store (EEAC (0x05, Zero), Local0)
                If (LLess (Local0, 0x02))
                {
                    Return (Zero)
                }


                Store (ECG5 (), Local0)
                And (Local0, 0x08, Local0)
                If (Local0)
                {
                    Return (0x1F)
                }


                Return (0x0F)
            }

`

After some research on the issue and reading several real MacBook's DSDT code, I experimented a little on this and obtained what I believe to be a good and suitable solution by:

  1. removing the DSDT section related to Device (BAT1)
  2. replacing all remaining DSDT references to BAT1 by BAT0
  3. renumbering Device (BAT0) _UID identifier from 1 to 0

 

Since applying those changes, battery icon and screen brightness have stopped flapping.  :)

 

I invite all E6440 owners to try out this patched DSDT and report accordingly.

New_E6440_DSDT_Battery_Fix.zip

  • Like 1

Share this post


Link to post
Share on other sites

The left side USB port is not functional OOB under El Capitan. It's the well-known USB ports problem... I have therefore revised the patched DSDT for El Capitan, with USB2.0 devices renamed from EHCx to EH0x in order to use the attached USB2.0 injector kext.

 

The original DSDT code shows 2 x USB2.0 controllers:

  1. EHC1 @1D: 8 x ports, numbered PR11 to PR18 under hub PR01
  2. EHC2 @1A: 6 x ports, numbered PR11 to PR16 under hub PR01

and the physical USB ports appear arranged in the following manner (as visible in IOReg when a device is plugged in the ports):

  • EHC1 controller, port #1 (PR11) @1D11: rear port
  • EHC1 controller, port #2 (PR12) @1D12: right-rear port
  • EHC1 controller, port #3 (PR13) @1D13: right-front port
  • EHC2 controller, port #2 (PR12) @1A12: left port

Some hardware accessories such as integrated webcam or BT module (part of combo mini-PCIe cards) are also visible @1A15, @1D15 or @1D18.

E6440_native_USB_tree_Mav10.9.jpg

 

In order to regain full USB functionality, the attached USB2.0 injector (based on Info plist of vanilla AppleUSBEHCIPCI PlugIn of /S/L/E/IOUSBHostFamily kext) reflects the above arrangements with the following settings:

  1. 1 x hub PR01 attached to MacBookPro11,1-EH01 USB controller
  2. 1 x hub PR01 attached to MacBookPro11,1-EH02 USB controller

USB2.0_injector_config.jpg E6440_EC10.11_IOReg_USB2.0_tree.jpg

 

All 4 x external ports are then fully functional as USB2.0 under EC 10.11.

 

[E6440_DSDT_ElCap10.11_EHCx-patched.zip] [E6440_ElCap10.11_USB2.0_Injector.kext.zip]

 

Edit: See below for a further USB ports update

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

×
×
  • Create New...