Contribute
Register

[Guide] Using Clover to "hotpatch" ACPI

Thanks very much,Sloved it.

Of course, that is the static patch method. This is the hotpatch thread.

With hotpatch, you simply add an SSDT:
Code:
DefinitionBlock ("", "SSDT", 2, "hack", "disable", 0)
{
    External(_SB.PCI0.PEG0.PEGP._OFF, MethodObj)
    Method(_SB.PCI0.PEG0.PEGP._INI) { _OFF() }
}
 
Of course, that is the static patch method. This is the hotpatch thread.

With hotpatch, you simply add an SSDT:
Code:
DefinitionBlock ("", "SSDT", 2, "hack", "disable", 0)
{
    External(_SB.PCI0.PEG0.PEGP._OFF, MethodObj)
    Method(_SB.PCI0.PEG0.PEGP._INI) { _OFF() }
}
Thanks.with your help to slove the trouble cause by _INI.I modify ssdt-disable_DUGP.dsl from you as hotpatch method.It work fine.
 
I've started to hotpatch the DSDT for my board (H77N-WiFi), using the PJALM patches as a template. I'm having difficulties with one of them. There is a device in the stock DSDT:
Code:
Device (_SB.PCI0.DOCK)
    {
        Name (_HID, "ABCDEFGH")  // _HID: Hardware ID
        Name (_CID, EisaId ("PNP0C15"))  // _CID: Compatible ID
        Name (_UID, 0x02)  // _UID: Unique ID
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            Return (Zero)
        }
    }
that is being patched like this:
Code:
    Device (_SB.PCI0.DOCK)
    {
        Name (_HID, EisaId ("PNP0C15"))  // _HID: Hardware ID
        Name (_CID, EisaId ("PNP0C15"))  // _CID: Compatible ID
        Name (_UID, 0x02)  // _UID: Unique ID
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            Return (Zero)
        }
    }
It seems that won't be simple code value patching as the patched name has bigger hex lenght than the original one. Any suggestions? Maybe if I just rename it to something like "ROCK" and inject the corrected device with SSDT in the same scope?
Attached the stock DSDT and SSDT tables and the patched DSDT.
 

Attachments

  • DSDT.dsl
    327.9 KB · Views: 207
  • DSDT_patched.dsl
    335.3 KB · Views: 174
  • SSDT-0.dsl
    6.5 KB · Views: 198
  • SSDT-1.dsl
    17.8 KB · Views: 194
  • SSDT-2.dsl
    15.1 KB · Views: 173
Last edited:
I've started to hotpatch the DSDT for my board (H77N-WiFi), using the PJALM patches as a template. I'm having difficulties with one of them. There is a device in the stock DSDT:
Code:
Device (_SB.PCI0.DOCK)
    {
        Name (_HID, "ABCDEFGH")  // _HID: Hardware ID
        Name (_CID, EisaId ("PNP0C15"))  // _CID: Compatible ID
        Name (_UID, 0x02)  // _UID: Unique ID
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            Return (Zero)
        }
    }
that is being patched like this:
Code:
    Device (_SB.PCI0.DOCK)
    {
        Name (_HID, EisaId ("PNP0C15"))  // _HID: Hardware ID
        Name (_CID, EisaId ("PNP0C15"))  // _CID: Compatible ID
        Name (_UID, 0x02)  // _UID: Unique ID
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            Return (Zero)
        }
    }
It seems that won't be simple code value patching as the patched name has bigger hex lenght than the original one. Any suggestions? Maybe if I just rename it to something like "ROCK" and inject the corrected device with SSDT in the same scope?
Attached the stock DSDT and SSDT tables and the patched DSDT.

No need to patch it. Ignore.
 
So, it's cosmetic patch in order the DSDT to be compiled without errors...
How about line 2335?
Code:
CreateDWordField (BUF0, \_SB.PCI0._Y0F._LEN, MSLN)  // _LEN: Length
is patched to
Code:
CreateQWordField (BUF0, \_SB.PCI0._Y0F._LEN, MSLN)  // _LEN: Length
Should I ignore that too?
 
Last edited:
So, it's cosmetic patch in order the DSDT to be compiled without errors...
How about line 2335?
Code:
CreateDWordField (BUF0, \_SB.PCI0._Y0F._LEN, MSLN)  // _LEN: Length
is patched to
Code:
CreateQWordField (BUF0, \_SB.PCI0._Y0F._LEN, MSLN)  // _LEN: Length
Should I ignore that too?

Yup.
 
Ok, last one: how about patching the following methods:
\UXDV
\RRIO
\_SB.PCI0.GFX0._DOD
from NotSerialized to Serialized?

Also several Names like CRS1 to CRS4 and their lenght, changed from 0x00 to 0x01 (code value patching)?
 
Last edited:
Ok, last one: how about patching the following methods:
\UXDV
\RRIO
\_SB.PCI0.GFX0._DOD
from NotSerialized to Serialized?

Also several Names like CRS1 to CRS4 and their lenght, changed from 0x00 to 0x01 (code value patching)?

All such patches are not necessary.

With hotpatch, you're concerned only with functional patches. Patches to correct warnings/errors/etc are generally not needed (and were not really needed in the first place).
 
All such patches are not necessary.

With hotpatch, you're concerned only with functional patches. Patches to correct warnings/errors/etc are generally not needed (and were not really needed in the first place).
Good to know. Thanks!
Then it seems I'm ready. All other _DSM injections from the PJALM patches are already implemented as SSDTs, also several renames in config.plist (EHCx->EH0x, SAT0->SATA, USB 3.0 is "XHC" by design, so no rename is needed).

Oh, I've missed one: the _OSI patch. Currently, the normal patch adds the following code:
Code:
If (_OSI ("Darwin"))
   {
      Store (0x2710, OSYS)
   }
to \SB.PCI0._INI, but I presume it would be better to rename those calls to XOSI and use your method from the ProBook repo, right?
 
Last edited:
Good to know. Thanks!
Then it seems I'm ready. All other _DSM injections from the PJALM patches are already implemented as SSDTs, also several renames in config.plist (EHCx->EH0x, SAT0->SATA, USB 3.0 is "XHC" by design, so no rename is needed).

Oh, I've missed one: the _OSI patch. Currently, the normal patch adds the following code:
Code:
If (_OSI ("Darwin"))
   {
      Store (0x2710, OSYS)
   }
to \SB.PCI0._INI, but I presume it would be better to rename those calls to XOSI and use your method from the ProBook repo, right?

Use _OSI->XOSI and SSDT-XOSI.aml as per post #1.
 
Back
Top