[Guide] Using Clover to "hotpatch" ACPI

RehabMan · Mar 9, 2017

danif said:
I didn't want to waste too much of your time thats why I didn't do a full problem report, sorry.
Here you have and again thank you very much.

No need to patch "errors". By definition, there are no errors in an AML file. No need to try to "fix" errors you may see as a result of imperfect disassembly.

Your patch for SCK1._STA is renaming both the _STA in SCK1 and SCK0... (and SCK2, and SCK3).
I don't think that is your intention.

It is quite obvious when you look at DSDT.aml from patchmatic -extract...

danif · Mar 9, 2017

RehabMan said:
Your patch for SCK1._STA is renaming both the _STA in SCK1 and SCK0... (and SCK2, and SCK3).
I don't think that is your intention.

That is what i tryed to fix with SSDT-1.aml But all

Code:

Processor (CPxx, ....)

are still present in ioreg. And that makes me think that _STA=Zero in Device (SCKx) is not affecting processor declaration as it were device declaration.

In a fixed dsdt edit I was doing like this:

Code:

# CPU unused

into device label SCK1 parent_label \_SB remove_entry;
into device label SCK2 parent_label \_SB remove_entry;
into device label SCK3 parent_label \_SB remove_entry;

into processor label CP10 parent_label SCK0 remove_entry;
into processor label CP11 parent_label SCK0 remove_entry;
into processor label CP12 parent_label SCK0 remove_entry;
into processor label CP13 parent_label SCK0 remove_entry;
into processor label CP14 parent_label SCK0 remove_entry;
into processor label CP15 parent_label SCK0 remove_entry;
into processor label CP16 parent_label SCK0 remove_entry;
into processor label CP17 parent_label SCK0 remove_entry;
into processor label CP18 parent_label SCK0 remove_entry;
into processor label CP19 parent_label SCK0 remove_entry;
into processor label CP1A parent_label SCK0 remove_entry;
into processor label CP1B parent_label SCK0 remove_entry;
into processor label CP1C parent_label SCK0 remove_entry;
into processor label CP1D parent_label SCK0 remove_entry;
into processor label CP1E parent_label SCK0 remove_entry;
into processor label CP1F parent_label SCK0 remove_entry;
into processor label CP20 parent_label SCK0 remove_entry;
into processor label CP21 parent_label SCK0 remove_entry;
into processor label CP22 parent_label SCK0 remove_entry;
into processor label CP23 parent_label SCK0 remove_entry;
into processor label CP24 parent_label SCK0 remove_entry;
into processor label CP25 parent_label SCK0 remove_entry;
into processor label CP26 parent_label SCK0 remove_entry;
into processor label CP27 parent_label SCK0 remove_entry;
into processor label CP28 parent_label SCK0 remove_entry;
into processor label CP29 parent_label SCK0 remove_entry;
into processor label CP2A parent_label SCK0 remove_entry;
into processor label CP2B parent_label SCK0 remove_entry;
into processor label CP2C parent_label SCK0 remove_entry;
into processor label CP2D parent_label SCK0 remove_entry;
into processor label CP2E parent_label SCK0 remove_entry;
into processor label CP2F parent_label SCK0 remove_entry;

Could there be another aproach to do this in a hot-patch scenario?

RehabMan · Mar 9, 2017

danif said:

That is what i tryed to fix with SSDT-1.aml But all

Code:

Processor (CPxx, ....)

are still present in ioreg. And that makes me think that _STA=Zero in Device (SCKx) is not affecting processor declaration as it were device declaration.

In a fixed dsdt edit I was doing like this:

Code:

# CPU unused

into device label SCK1 parent_label \_SB remove_entry;
into device label SCK2 parent_label \_SB remove_entry;
into device label SCK3 parent_label \_SB remove_entry;

into processor label CP10 parent_label SCK0 remove_entry;
into processor label CP11 parent_label SCK0 remove_entry;
into processor label CP12 parent_label SCK0 remove_entry;
into processor label CP13 parent_label SCK0 remove_entry;
into processor label CP14 parent_label SCK0 remove_entry;
into processor label CP15 parent_label SCK0 remove_entry;
into processor label CP16 parent_label SCK0 remove_entry;
into processor label CP17 parent_label SCK0 remove_entry;
into processor label CP18 parent_label SCK0 remove_entry;
into processor label CP19 parent_label SCK0 remove_entry;
into processor label CP1A parent_label SCK0 remove_entry;
into processor label CP1B parent_label SCK0 remove_entry;
into processor label CP1C parent_label SCK0 remove_entry;
into processor label CP1D parent_label SCK0 remove_entry;
into processor label CP1E parent_label SCK0 remove_entry;
into processor label CP1F parent_label SCK0 remove_entry;
into processor label CP20 parent_label SCK0 remove_entry;
into processor label CP21 parent_label SCK0 remove_entry;
into processor label CP22 parent_label SCK0 remove_entry;
into processor label CP23 parent_label SCK0 remove_entry;
into processor label CP24 parent_label SCK0 remove_entry;
into processor label CP25 parent_label SCK0 remove_entry;
into processor label CP26 parent_label SCK0 remove_entry;
into processor label CP27 parent_label SCK0 remove_entry;
into processor label CP28 parent_label SCK0 remove_entry;
into processor label CP29 parent_label SCK0 remove_entry;
into processor label CP2A parent_label SCK0 remove_entry;
into processor label CP2B parent_label SCK0 remove_entry;
into processor label CP2C parent_label SCK0 remove_entry;
into processor label CP2D parent_label SCK0 remove_entry;
into processor label CP2E parent_label SCK0 remove_entry;
into processor label CP2F parent_label SCK0 remove_entry;

Could there be another aproach to do this in a hot-patch scenario?

I'm not clear on what you're trying to do. Processor definitions have nothing to do with SCKx device definitions.

danif · Mar 9, 2017

RehabMan said:
I'm not clear on what you're trying to do. Processor definitions have nothing to do with SCKx device definitions.

It´s my english, sorry.

Code:

   Device (SCK1)
            {
                ....
                Processor (CP00, 0xFF, 0x00000410, 0x06) {...}
                Processor (CP01, 0xFF, 0x00000410, 0x06) {...}
                .....
                }

In my DSDT this processors declaration are inside SCKx and I try to remove them so that my IOReg is not like this

Captura de pantalla 2017-03-09 a las 15.25.19.png

RehabMan · Mar 9, 2017

danif said:
It´s my english, sorry.

Code:

Device (SCK1) { .... Processor (CP00, 0xFF, 0x00000410, 0x06) {...} Processor (CP01, 0xFF, 0x00000410, 0x06) {...} ..... }

In my DSDT this processors declaration are inside SCKx and I try to remove them so that my IOReg is not like this
View attachment 240838

Each Processor _STA would need to be overridden to eliminate them from IOService).
You cannot disable sub-objects by disabling the object at parent scope.

mo7a1995 · Mar 29, 2017

Great Guide , however it needed more examples.
Rehabman I want to convert this DSDT patch https://github.com/RehabMan/Laptop-DSDT-Patch/blob/master/battery/battery_Lenovo-G50-70.txt
To a hot patch , is it already done in another Repo ? If not can you help me do it

RehabMan · Mar 29, 2017

mo7a1995 said:
Great Guide , however it needed more examples.
Rehabman I want to convert this DSDT patch https://github.com/RehabMan/Laptop-DSDT-Patch/blob/master/battery/battery_Lenovo-G50-70.txt
To a hot patch , is it already done in another Repo ? If not can you help me do it

I think there is a already a hotpatch guide for the G50-70.
https://www.tonymacx86.com/threads/guide-lenovo-g50-70-g40-70-using-clover-uefi-10-11.200712/

jl4c · Apr 1, 2017

RehabMan,
Is safe to disable devices like WMID this way:

Code:

Scope (_SB._SB.WMID)
    {
        Method (_STA, 0, NotSerialized) // _STA: Status
        {
            Return (Zero)
        }
    }

Obviously, there is not _STA for WMID in original DSDT.
If is safe, is necessary to remove all calls to this device?
Example:

Code:

Method (_Q0A, 0, NotSerialized)  // _Qxx: EC Query
            {
                D80H (0x0A)
                Store (ADIN, PWRS)
                Notify (AC, 0x80)
                Notify (BAT0, 0x80)
                Notify (BAT0, 0x81)
                Store (0x03, ^^^^WMID.WEID)
                Store (Zero, ^^^^WMID.WMED)
                Notify (WMID, 0x80)
                PNOT ()
            }

Thanks.

RehabMan · Apr 1, 2017

jl4c said:

RehabMan,
Is safe to disable devices like WMID this way:

Code:

Scope (_SB._SB.WMID)
    {
        Method (_STA, 0, NotSerialized) // _STA: Status
        {
            Return (Zero)
        }
    }

Obviously, there is not _STA for WMID in original DSDT.
If is safe, is necessary to remove all calls to this device?
Example:

Code:

Method (_Q0A, 0, NotSerialized)  // _Qxx: EC Query
            {
                D80H (0x0A)
                Store (ADIN, PWRS)
                Notify (AC, 0x80)
                Notify (BAT0, 0x80)
                Notify (BAT0, 0x81)
                Store (0x03, ^^^^WMID.WEID)
                Store (Zero, ^^^^WMID.WMED)
                Notify (WMID, 0x80)
                PNOT ()
            }

Thanks.

There is no need to disable the WMID device, nor necessary to disable the calls into it.

gujiangjiang · Apr 30, 2017

Hello Rehabman.

I'm now works well with hotpatch on my HP Pavilion g4 1018tu.
And now I have a problem in _PRW.

Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
{
0x0D,
0x03
})

Mine have no _PRW method in EHC1 and EHC2 but only Name(_PRW).

So how to change the 0x03 to 0 in my Name(_PRW) rather than Method(_PRW).

Search

[Guide] Using Clover to "hotpatch" ACPI

RehabMan

Moderator

danif

RehabMan

Moderator

danif

RehabMan

Moderator

mo7a1995

RehabMan

Moderator

jl4c

RehabMan

Moderator

gujiangjiang

Forum

Guides

Downloads