Stripped DSDT for Gigabyte Z87M-D3H

Yesterday I blogged about the USB stutter and random hangs that I was trying to resolve, and one of the things that I did was to strip the DSDT. Not that it was that much smaller, and thus I asked my father for a bit of help. After just 30 minutes… it suddenly went down from 52365 bytes to only 5922 bytes. I tell you. That is a lot less than what I had.

Too bad that the thirty minutes dried up so quick, and that dad had to leave to catch his flight back home. Luckily, he gave me some tips and today I had another stab at it. The computer that we used, which is actually a GA-Z87MX-D3H but the DSDT is for a GA-Z87M-D3H, still boots from the USB 2.0 memory stick, which is painfully slow by the way, but now it does it with just 3292 bytes. This instead of the 5922 bytes I started with.

The new static DSDT appears to be working. Sleep/wake works properly. Reboot and shutdown too. Audio works, and the Ethernet port and WiFi/Bluetooth module are still fine. Power management is also ok with a generated SSDT. USB 2.0 and USB 3.0 is also functional, be it with the same annoying mouse stutter at startup. The good news is that I received the source code, be it the USB only bits and pieces, and thus the hunt for the error will start tomorrow…

Anyway. You can find my (example of a) stripped down DSDT in my Github repository but please be aware that it may not work, most likely not, on other hardware. With a different BIOS version, or with a different IGPU memory setting, and more/less memory than the two 4GB memory modules that I have installed on this motherboard.

Also. Do not change your _CRS object data. Not without knowing what you are doing!

Have fun!!!

Edit: To me American Megatrends, Inc. is a serious company, with dozens of BIOS developers, and they write BIOS code for all kinds of motherboard… but they do this without having a single target motherboard. All testing is done by the vendor itself. Not by AMI. So much for fake facts from you know who…

6 thoughts on “Stripped DSDT for Gigabyte Z87M-D3H

  1. Hi, Pike! Nice, clean and apprehensible work!
    I have few questions.

    1. How did you figured out all _Yxx’s in some _CRS ResourceTemplates?

    2. Does your MB has enabled or disabled EC? You’ve returned Zero in EC’s _STA.
    And what kind of methods does EC contains with ECON Register? Are they kext- specific?

    3. _PIC method contains GPIC data. But it is always contain 1, and no reason to have that method at all. ACPI_Platform_Plugin doesn’t contain specific code for LNKx interrupts for _PIC=0. Don’t you think so?

    4. Have you tried to replace _PRW to _GPE in subdevices? Like Name (_PRW, Package (0x02) { 0x09, 0x04 }) —> Name (_GPE, 0x09) to correspond _L09 method in \_GPE Scope; and maybe to add Name _S4D with correct data, like Name (_S4D, 0x03) ?

    5. Have you tried to clean _PRT packages in devices? I have incomplete information and I’m trying to understand hardware specific or universal methods does it use. For example, PCI0 device contains of huge _PRT data table, listing all subdevices’ interrupt wiring. And mostly all of subdevices contains counter _PRTs with 4 packages. But if see harder and add IOREG’s and LSPCI’s data for completing, I understand that way:
    For example, Device (RP01) has _ADR = 0x001C0000, so PCI0._PRT has 4 PKGs for it.

                        Package (0x04) { 0x001CFFFF, Zero, Zero, 0x10 }, 
                        Package (0x04) { 0x001CFFFF,  One, Zero, 0x11 }, 
                        Package (0x04) { 0x001CFFFF, 0x02, Zero, 0x12 }, 
                        Package (0x04) { 0x001CFFFF, 0x03, Zero, 0x13 },

    In IOREG it is hardwired to ” 10 00 00 00 07 00 00 InterruptSpecifier
    and PCI0.RP01._PRT has also 4 PKGs, but w/o full addresses:

                        Return (Package (0x04)
                            Package (0x04) { 0xFFFF, Zero, Zero, 0x10 }, 
                            Package (0x04) { 0xFFFF,  One, Zero, 0x11 },
                            Package (0x04) { 0xFFFF, 0x02, Zero, 0x12 },
                            Package (0x04) { 0xFFFF, 0x03, Zero, 0x13 }

    How do you think, is it possible to use only 1 package? And name it

    Name (_PRT, Package (One) { Package (0x04) { 0xFFFF, Zero, Zero, 0x10 } })

    just because it has 10 interrupt permanently?
    For other RP0x that way.

    6. Why did you leaving IRQNoFlags () {8} in RTC and IRQNoFlags () {0} in TIMR, but added to HPET no interrupts at all?
    I think it is possible to delete IPIC, LDRC, TIMR, RMSC completely. And maybe MATH and DMAC too. How do you think? And if EC is disabled, to delete it too from code. Don’t know about Device (PDRC) and Device (MEM2) are they needed at all? I know, that they have HW specific addresses in _CRS data, but I’ve deleted in my code such devices at all and have no trouble.

    7. Have you specific custom SSDTs with Devices’ control methods? For example, for SATA or EHC1-2 UHC1-6-7-8?

    Please, if it possible, answer my questions!
    Cheers! Steve.

    • Wow. That is quite an extensive list of questions. I hope I didn’t skipped anything so here goes…

      1.) The data for device LDRC and PDRC can be found in IORegistryExplorer, but the data for PCI0 requires some more work. For this I added the following _DSM mouthed to MCHC:

      Method (_DSM, 4, NotSerialized)
          If (LEqual (Arg2, Zero))
              Return (Buffer (One) { 0x03 })
          Return (Package (0x1C)

      Note: The names can be different on other motherboards so use what you need for your BIOS.

      2.) What do you think when I use Zero? And yeah. Device (EC) could have been stripped down some more, but we simply ran out of time for it.

      3.) Method _PIC is optional, but Apple still calls it, so Method _PIC is there to suppress the ACPI error: “ACPI: setPICMode error: AE_NOT_FOUND

      The configurable PCI interrupt model is not used. Apple uses the hardwired PCI specific interrupt inputs on the interrupt controller and as such there is no need for Device (LNKx) and accompanied objects and methods.

      Edit: Errors added.

      4.) No. Not used. You lose the LowestSleepState. See ACPI specification.

      5.) _PRT is required for all PCI root bridges so I leave it there as is.

      Changing the IRQs is doomed to fail, for many people, simply because they don’t know how it works. I did limit certain packages, and it works, but again. You must know what you are doing.

      6.) Actually. I do have two IRQNoFlags (0/8) in Device HPET but I somehow lost them during the transition to the Github repository (I do have more code examples that I didn’t share). Thanks for the tip.

      Device MEM2 is for the IGPU and can be removed if it is disabled in the BIOS. Device PEG0 can either be removed or renamed to P0P2 for discrete GPU cards. I want the data to be Apple like, as much as possible, and I have no intention to delete other devices.

      7.) No. Only one SSDT for power management.

      • Hi, Pike! Thanks for detailed answering.

        I asked Slice about _PIC method and he answered, that PIC model has stopped using from OSX 10.4.8. Thats’s why no need to ask OS for used IRQ model. It is always APIC for now. No need to have a _PIC method, yep.

        Also I tried to stripe down _PRT methods located under RPxx (PCIe root ports)
        You have that way stripped down (maybe methods _STA, _PRW you’ve removed; and why (?) ):

                    Device (RP02)
                        Name (_ADR, 0x001C0001)  // _ADR: Address
                        Method (_PRT, 0, NotSerialized)  // _PRT: PCI Routing Table (AR05)
                            Return (Package (0x04)
                                Package (0x04) { 0xFFFF, Zero, Zero, 0x11 }, 
                                Package (0x04) { 0xFFFF,  One, Zero, 0x12 },
                                Package (0x04) { 0xFFFF, 0x02, Zero, 0x13 }, 
                                Package (0x04) { 0xFFFF, 0x03, Zero, 0x10 }

        But I think it is too big and can be stripped down little more (example is from my code):

        Name(_PRT, Package(4) {
         Package(4) {0xFFFF, 0x00, 0x00, 0x11}, 
         Package(4) {0xFFFF, 0x01, 0x00, 0x12}, 
         Package(4) {0xFFFF, 0x02, 0x00, 0x13}, 
         Package(4) {0xFFFF, 0x03, 0x00, 0x10}
        Or even more, just dropping 3 unnecessary packages. I've done this way, and had no trouble. Example of my PR01 device:
        [code]Device (RP01) { Name (_ADR, 0x001C0000) Name (_PRT, Package(1) { Package(4) {0xFFFF, 0x00, 0x00, 0x10} }) }

        But if you have more than 1 device under RPxx, you have to add more packages with correct IRQs. For example, under my RP02 device are sitting 2 sub- devices. It is JMicron's JMB363 AHCI+IDE combo- controller. Main AHCI piece locating in _ADR=0, second IDE piece in _ADR=1. ADR0 has Pin A IRQ 17; ADR1 has Pin B IRQ18 (according to LSPCI and IOReg).
        This is my RP02 device:

        Device (RP02) { Name (_ADR, 0x001C0001)
        Name (_PRT, Package(2)
          { Package(4) {0xFFFF, 0x00, 0x00, 0x11},
            Package(4) {0xFFFF, 0x01, 0x00, 0x12} }) }

        I think you may try that striping down way too.

        Also I tried to combine all UHCx's _PRWs to one corporate namespace. All UHCx had the same _PRW:

        Name(_PRW, Package(2) {0x03, 0x03}) }

        and were located under 1 _L03 method in _GPE:

        Method (_L03) { Notify(\_SB.PCI0.UHC1, 0x02) Notify(\_SB.PCI0.UHC2, 0x02) Notify(\_SB.PCI0.UHC3, 0x02)
        Notify(\_SB.PCI0.UHC4, 0x02) Notify(\_SB.PCI0.UHC5, 0x02) Notify(\_SB.PCI0.UHC6, 0x02) }

        but after this I lost waking from sleep with KB, mouse and trackpad connected to different ports. Only PWRB worked. So, had to invert to original _Lxx:

        Method (_L03) { Notify(\_SB.PCI0.UHC1, 0x02) }
        Method (_L04) { Notify(\_SB.PCI0.UHC2, 0x02) }
        Method (_L0C) { Notify(\_SB.PCI0.UHC3, 0x02) }
        Method (_L0E) { Notify(\_SB.PCI0.UHC4, 0x02) }
        Method (_L05) { Notify(\_SB.PCI0.UHC5, 0x02) }
        Method (_L20) { Notify(\_SB.PCI0.UHC6, 0x02) }

        and all seems working fine again.

        Now I'm trying to figure out, how to disable all UHCIs and to enable EHCI's RHUB. Have you a tip?
        *** I know that it is BIOS related setting. Maybe R/WO register, that BIOS sets automatically, and I have no setting in the BIOS's GUI to take my choice.

        Cheers. Steve.

      • 1.) About Method (_PIC).

        Please re-read what I said last time. Nothing has changed since. Apple is still calling Method (_PIC) and this is exactly why I do my own research. Not that I don’t trust other people, but I like to be right and spot on. That and because my father said that we still need it. By the way. I now also added the exact error message to my previous reply. Just so that people know why it is still there.

        2.) About Method (_PRT).

        You don’t need _STA because the ports are hardware controlled. Hiding it from ACPI makes no sense.

        I have not stripped all _PRT objects in the released DSDT, but I did convert it from a Method to Name object in a couple of places. Like I said. I have not released all my work. Too busy with other stuff.

        I personally strip ACPI tables to make the AML file smaller so that it loads and executes quicker. I do not change Zero and One to 0/1 because that way people never learn what to use (think optimisation).

        Like I said in my previous reply. The _PRT object is not something everyone can change. Good for you that you can, but again. People need to know what they are doing, and since I don’t want to become a help desk.. I chose not to make that public in any of my ACPI tables.

        3.) About the other changes.

        My blog article is for people with a Gigabyte GA-Z87M-D3H motherboard. Other people may read and learn from it, but I don’t have the time to solve other peoples problems. Sorry. You should understand this. I have too much on my plate already.

  2. Yeah I know the feeling myself.
    My current computer also has 100% modded uefi firmware.
    I also don’t care to pull the bios apart to make it better but I do say this:
    Vendors – make better firmware, especially the ACPI components.

  3. Pingback: GA-Z87M-D3H USB keyboard/mouse wake problem | Pike's Universum

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s