Jump to content

Dell M2800 (like E6540) - need help with dGPU disabled via DSDT for High Sierra


jonny
 Share

Recommended Posts

Hi All,

 

Have a Dell Precision M2800, similar to a E6540 but different . As I couldn't find a bootpack for it, I tried the E6540 Clover bootpack but it just hangs at the Apple bootup logo. Found it BSODs Windows when trying to load it via Clover.

 

Here's a DSDT 'acpidump -b -z' of the system'  http://www.mediafire.com/file/vc46ch8n5glqhdl/Dell-M2800_ACPI_DUMP.zip

 

Can anybody volunteer to alter the ACPI tables to load via Clover so as to disable the dGPU and enable sound? My attempts at  merging the E6540 changes in result in the W4170M dGPU getting an error43.

Link to comment
Share on other sites

  • Moderators

Boot to Clover Gui. Hit F4.

Wait a second. Remove USB, mount it on a Mac, mount the EFI partition. 

Compress and attach /EFI/Clover folder

 

Please also specify the system's specs and BIOS version.

Link to comment
Share on other sites

  • Administrators

Here are copies of those extracted ACPI tables renamed to ".aml".

M2800_APCI_tables.zip

 

As shown in DSDT:

  • iGPU HD4600 is located at usual address 0x00020000 under device PCI0.GFX0
        Device (GFX0)
        {
            Name (_ADR, 0x00020000)  // _ADR: Address
  • dGPU FirePro W4170M is located at usual address 0x00010000 under device PCI0.PEG0.PEGP  
        Device (PEG0)
        {
            Name (_ADR, 0x00010000)  // _ADR: Address
        [...]
        [...]
        [...]
            Device (PEGP)
            {
                Name (_ADR, Zero)  // _ADR: Address

`

Those GPUs are further detailed in SSDT-5 and SSDT-6 tables:

  • In SSDT-5, there is a basic initialisation method that does not do more than attributing sub-address 0 to the dPU under the PCIe graphics #0 at address 0x00010000:
   Scope (\_SB.PCI0.PEG0.PEGP)
   {
   [...]
       Method (_INI, 0, NotSerialized)  // _INI: Initialize
        {
            Store (Zero, \_SB.PCI0.PEG0.PEGP._ADR)
        }
   [...]
   }
  • in SSDT-6, there are 2 x methods (=functions) defined to turn the dGPU on and off:
   Scope (\_SB.PCI0.PEG0.PEGP)
   {
        Method (_ON, 0, Serialized)  // _ON_: Power On
        {
            SGON ()
            Notify (\_SB.PCI0.PEG0, Zero)
        }


        Method (_OFF, 0, Serialized)  // _OFF: Power Off
        {
            SGOF ()
            Notify (\_SB.PCI0.PEG0, Zero)
        }
   }

`

The 1st step towards patching your tables is to modify SSDT-5 to initialise the dGPU to off. To achieve this, we simply declare the _OFF function as external (i.e. defined elsewhere) at the top of the table before we add it to the _INI method:
    External (_SB_.PCI0.PEG0.PEGP._OFF, MethodObj)          // Declares external method _OFF
    [...]
    [...]
    [...]
    Scope (\_SB.PCI0.PEG0.PEGP)
    {
    [...]
        Method (_INI, 0, NotSerialized)  // _INI: Initialize
        {
            Store (Zero, \_SB.PCI0.PEG0.PEGP._ADR)
            _OFF ()                                        // Turns AMD dGPU off
        }
    [...]
    }

`

The 2nd step is to add a new EPOF method to that SSDT-5 table so that the dGPU is no longer reactivated on wake from sleep, as configured by default. Indeed, the vanilla DSDT shows the following code:

    External (_SB_.PCI0.PEG0.PEGP.EPON, MethodObj)    // Warning: Unknown method, guessing 0 arguments
    External (_SB_.PCI0.RP05.PEGP.EPON, MethodObj)    // Warning: Unknown method, guessing 0 arguments

and

    Method (_WAK, 1, Serialized)  // _WAK: Wake
    {
        P8XH (One, 0xAB)
        WAK (Arg0)
        ADBG ("_WAK")
        If (LOr (LEqual (Arg0, 0x03), LEqual (Arg0, 0x04)))
        {
            If (CondRefOf (\_SB.PCI0.PEG0.PEGP.EPON))
            {
                \_SB.PCI0.PEG0.PEGP.EPON ()
            }

            If (CondRefOf (\_SB.PCI0.RP05.PEGP.EPON))
            {
                \_SB.PCI0.RP05.PEGP.EPON ()
            }
        }
    [...]
    }

NB: You can confirm this through IOReg afterwards but you'll probably find that device RP05.PEGP does not exist, i.e. those lines of code related to _SB_.PCI0.RP05.PEGP.EPON are incorrect. I had the same in my E6440 DSDT and I've seen the same in E6540 DSDT too. Typical example of poorly coded DSDT... As such, these lines can be removed without any side effects.

 

The EPON method is defined in SSDT-5 as follows:

    Scope (\_SB.PCI0.PEG0.PEGP)
    {
    [...]
        Method (EPON, 0, Serialized)
        {
            Store (One, ONOF)
            Return (Zero)
        }
    [...]
    }

There is no EPOF method, so we're simply going to add one that will do the opposite of EPON, i.e. store 0 to ONOF:

    Scope (\_SB.PCI0.PEG0.PEGP)
    {
    [...]
        Method (EPON, 0, Serialized)
        {
            Store (One, ONOF)
            Return (Zero)
        }
        Method (EPOF, 0, Serialized)          // New EPOF method
        {
            Store (Zero, ONOF)                // Stores 0 to ONOF parameter
            Return (Zero)
        }
    [...]
    }

`

Once that is done, we can modify the DSDT to actually turn off the dGPU on wake. This is achieved by replacing the above EPON declarations + WAK method in the DSDT by the following code:

    External (_SB_.PCI0.PEG0.PEGP.EPOF, MethodObj)

and

    Method (_WAK, 1, Serialized)  // _WAK: Wake
    {
        P8XH (One, 0xAB)
        WAK (Arg0)
        ADBG ("_WAK")
        If (LOr (LEqual (Arg0, 0x03), LEqual (Arg0, 0x04)))
        {
            If (CondRefOf (\_SB.PCI0.PEG0.PEGP.EPOF))
            {
                \_SB.PCI0.PEG0.PEGP.EPOF ()
            }
        }
    [...]
    }

`

That should be it. Place copies of the patched tables in your Clover ACPI/patched folder and call them by inserting the following list in your Clover config's ACPI "sorted list" section:

  • SSDT.aml
  • SSDT-5.aml
  • SSDT-6.aml
Link to comment
Share on other sites

@Jake Lo, find the requested CLOVER folder. This was previously used for my E6540 though I emptied the ACPI\patched directory and of course dumped the ACPI tables on the Dell M2800:

 

http://www.mediafire.com/file/p4cndyj8ux0713i/CLOVER_Dell_M2800_A14.zip

 

System specs are:

 

15" Dell Precision M2800

A.14 BIOS

i7-4810MQ

16GB RAM, 256GB Samsung mSATA SSD

HD4600 iGPU + Fire Pro W4170M dGPU

1920x1080 LCD

 

During my failed merge of the E6540 DSDT, I noticed some differences with the E6540:

 

- some different memory addresses

- HDAU device is B0D3  (sound)

 

 

Hoping to get an expert hand here as I can't seem to disable the dGPU so that macOS HS installer boots.

 

In addition, my previous E6540 build could never get AppleHDA_ALC292.kext working, resorting to Voodoo_HDA instead. Would love to remedy that. Seems it is touchy, need to get it right else it just won't boot as has been the case so far.

 

@Hervé , thank you for your analysis. Is there some modified DSDT files you can volunteer with these changes that I can test?

Link to comment
Share on other sites

  • Moderators

Try this, replace contents into /EFI/Clover

Disabled AMD following Hervé's post above

Don't know what audio Codec it has, so that will have to be fix later once you have a running system.

If system has an Intel Wireless, that is not supported and will need to be replaced with a supported device. See FAQ for more info

M2800_A14.zip

Link to comment
Share on other sites

@Jake Lo, it works. But with a twist. I discovered that having the SSD in an optical bay caddy which boots Windows fine does not boot macOS. Moving it back to the HDD/SSD bay sees macOS boot OK as it did previously.

 

I then tried the previous E6540 bootpack and it works too.

Still having no luck with AppleHDA_ALC292.kext . Resorted to Voodoo HDA again. Here is the ioreg dump in case you can spot the anomoly.

 

http://www.mediafire.com/file/68j2fe6d5j53c9n/Dell_M2800_A14.zip

Link to comment
Share on other sites

  • Moderators

Probably need IOAHCISerialATAPI_Injector.kext to boot from the caddy.

Please stick with using the M2800 DSDT/SSDT I attached, hardware might be similar but not exact.

 

Does the M2800 also have ALC292?

Post screen of Status with DPCIManager

 

Then remove VoodooHDA and post IOReg

Any issue with sleep and wake?

Link to comment
Share on other sites

@Jake Lo,  find DPCIManager & ioreg output as requested.  dell_m2800_ioreg.ioreg

 

I'll add that if I remove AppleHDA_ALC292.kext from /S/L/E, sound works but only through the internal speakers. The problem there is there are no sound output options to use my line-out attached speakers.

 

About sleep, my E6540 had a sleep issue where it wouldn't resume if left for a few hours, but worked with  instant sleep-resume. Haven't tried a long sleep on the M2800 yet.

 

5ac83cb154b9f_ScreenShot2018-04-07at1_29_39pm.png.008857c25adc81fca6f81d0043eae1a6.png

Link to comment
Share on other sites

  • Moderators

I assume it's not auto switching over to headphone. Try having the headphone plugged in, place system to sleep and then wake it up. See if it'll switch over to headphone.

I see in IOReg, the dGPU is disabled since it's not showing there. I also noticed you have an SD card reader that can be patched to work. 

Replace DSDT with attached and reboot. SDCard reader should show in SysInfo and should work

DSDT.aml.zip

Link to comment
Share on other sites

 Share

×
×
  • Create New...