Contribute
Register

[Guide] Patching LAPTOP DSDT/SSDTs

my DSDT comes back with the common error with ECRW _CRS method.

After applying the fix mentioned in post#1 I get the following syntax errors:

TBFF: 19973, 6126, syntax error, unexpected PARSEOP_OPERATIONREGION
DMSI: 20297, 6126, syntax error, unexpected PARSEOP_INTEGER, expecting PARSEOP_CLOSE_PAREN
RSMI: 20353, 6126, syntax error, unexpected PARSEOP_OPERATIONREGION
GNIS: 20435, 6126, syntax error, unexpected PARSEOP_INTEGER, expecting PARSEOP_CLOSE_PAREN
TINI: 20607, 6126, syntax error, unexpected PARSEOP_NAMESEG
​
Any chance someone could perhaps point me in the right direction to fix these?

Files in question are located on the zip attached under "DSDT/SSDT patching" folder in "Resulting DSLs"
The ones currently under the default Clover location are actually not from this system, but they kinda work.. I just want to make my own since I'm having a few problems with USB-C etc.

Aside from the DSDT in that folder only the "SSDT-13-sensrhub" gives issues when trying to compile.

103, 6126, syntax error, unexpected '}'
124, 6126, syntax error, unexpected PARSEOP_IF
124, 6126, syntax error, unexpected PARSEOP_CLOSE_PAREN
129, 6126, syntax error, unexpected '}'
162, 6126, syntax error, unexpected $end and premature End-Of-File

Code: 
                                }

                                If (LEqual (\_SB.GGOV (0x02010016), One))
                                {
                                    Sleep (0x96)
                                    If (LEqual (\_SB.GGOV (0x02010014), One)) {}
                                    Else
                                    {
                                        Notify (\_SB.PCI0.I2C0.DFUD, One)
                                    }
                                }

                                Return (Zero)
                            }
                            ElseIf (LEqual (_T_0, 0x02))
                            {
                                Store (DerefOf (Index (Arg3, Zero)), DFUE)
                                Store (DerefOf (Index (Arg3, One)), DFUD)
                                Store (\_SB.GGOV (0x02010014), OLDV)
                                \_SB.GGOV (0x02010014)
                                DFUE
                                If (LGreater (DFUD, Zero))
                                {
                                    Sleep (DFUD)
                                    \_SB.GGOV (0x02010014)
                                    OLDV
                                }

                                Return (Zero)
                            }
                            ElseIf (LEqual (_T_0, 0x03))
                            {
                                Store (\_SB.GGOV (0x02010014), DFUV)
                                Store (\_SB.GGOV (0x02010016), PGCV)
                                Return (Package (0x02)
                                {
                                    PGCV,
                                    DFUV
                                })
                            }

                            Break
                        }

                        Return (Zero)
                    }

                    Return (Zero)
                }

                Return (Buffer (One)
                {
                     0x00                                         
                })
            }
        }
    }
}
Cheers!
 

Attachments

  • Problem reporting.zip
    3 MB · Views: 60
Last edited:
tgmac said:
my DSDT comes back with the common error with ECRW _CRS method.

After applying the fix mentioned in post#1 I get the following syntax errors:

TBFF: 19973, 6126, syntax error, unexpected PARSEOP_OPERATIONREGION
DMSI: 20297, 6126, syntax error, unexpected PARSEOP_INTEGER, expecting PARSEOP_CLOSE_PAREN
RSMI: 20353, 6126, syntax error, unexpected PARSEOP_OPERATIONREGION
GNIS: 20435, 6126, syntax error, unexpected PARSEOP_INTEGER, expecting PARSEOP_CLOSE_PAREN
TINI: 20607, 6126, syntax error, unexpected PARSEOP_NAMESEG
​
Any chance someone could perhaps point me in the right direction to fix these?

Files in question are located on the zip attached under "DSDT/SSDT patching" folder in "Resulting DSLs"
The ones currently under the default Clover location are actually not from this system, but they kinda work.. I just want to make my own since I'm having a few problems with USB-C etc.

Aside from the DSDT in that folder only the "SSDT-13-sensrhub" gives issues when trying to compile.

103, 6126, syntax error, unexpected '}'
124, 6126, syntax error, unexpected PARSEOP_IF
124, 6126, syntax error, unexpected PARSEOP_CLOSE_PAREN
129, 6126, syntax error, unexpected '}'
162, 6126, syntax error, unexpected $end and premature End-Of-File

Code: 
                                }

                                If (LEqual (\_SB.GGOV (0x02010016), One))
                                {
                                    Sleep (0x96)
                                    If (LEqual (\_SB.GGOV (0x02010014), One)) {}
                                    Else
                                    {
                                        Notify (\_SB.PCI0.I2C0.DFUD, One)
                                    }
                                }

                                Return (Zero)
                            }
                            ElseIf (LEqual (_T_0, 0x02))
                            {
                                Store (DerefOf (Index (Arg3, Zero)), DFUE)
                                Store (DerefOf (Index (Arg3, One)), DFUD)
                                Store (\_SB.GGOV (0x02010014), OLDV)
                                \_SB.GGOV (0x02010014)
                                DFUE
                                If (LGreater (DFUD, Zero))
                                {
                                    Sleep (DFUD)
                                    \_SB.GGOV (0x02010014)
                                    OLDV
                                }

                                Return (Zero)
                            }
                            ElseIf (LEqual (_T_0, 0x03))
                            {
                                Store (\_SB.GGOV (0x02010014), DFUV)
                                Store (\_SB.GGOV (0x02010016), PGCV)
                                Return (Package (0x02)
                                {
                                    PGCV,
                                    DFUV
                                })
                            }

                            Break
                        }

                        Return (Zero)
                    }

                    Return (Zero)
                }

                Return (Buffer (One)
                {
                     0x00                                        
                })
            }
        }
    }
}
Cheers!
Click to expand...

The initial errors in your DSDT.dsl are specifically covered in post #1.
Disassemble with: iasl -da -dl DSDT.aml SSDT*.aml
Then fix this code as per post #1:
Code: 
                If (LEqual (PM6H, One))
                {
                    CreateBitField (BUF0, \_SB.PCI0._Y0C._RW, ECRW)  // _RW_: Read-Write Status
                    Store (Zero, ECRW (If (PM0H)
                            {
                                CreateDWordField (BUF0, \_SB.PCI0._Y0D._LEN, F0LN)  // _LEN: Length
                                Store (Zero, F0LN)
                            }))
                }

After you do that, you're left with only this problem:
20350, 6152, Illegal recursive call to method that creates named objects
The code is in the XTBT method, and it is calling itself:
Code: 
                    XTBT (TBSE, CPGN)

The compiler is telling you this is illegal, but what to do about it... you can force the compiler to compile the code and have the code execute the same by changing that code:
Code: 
                    XTB2 (TBSE, CPGN)

Then adding an XTB2 method just before the XTBT method:
Code: 
Method(XTB2, 2) { XTBT(Arg0, Arg1) }

This change avoids the error regarding an illegal recursive call by making it difficult for the compiler to detect.
You then run the risk of what the runtime does with it since it is going to be run by the Intel ACPI runtime instead of the macOS/OS X runtime.
(Windows uses a different ACPI runtime than other platforms... other platforms such as Linux and macOS/OS X use Intel's ACPI runtime, where Microsoft uses its own).
It is possible that specific code path is never taken for the macOS/OS X/Linux case... or there is a bug in the ACPI on those platforms.
 
RehabMan said:
The initial errors in your DSDT.dsl are specifically covered in post #1.
Disassemble with: iasl -da -dl DSDT.aml SSDT*.aml
Then fix this code as per post #1:
Click to expand...

Code: 
ACPI Error: Invalid type (Region) for target of Scope operator [PRT0] (Cannot override) (20161117/dswload-351)
ACPI Exception: AE_AML_OPERAND_TYPE, During name lookup/catalog (20161117/psobject-310)
Could not parse external ACPI tables, AE_AML_OPERAND_TYPE

So disassembling with -da results in the error above.
so as per this post I did it without -da and it disassembles successfully, but that's how I got the initial errors in the first place. vicious cycle...

As for the rest, awesome! thanks so much I will give it all a go as soon as I get past the pesky first one.
 
tgmac said:
Code: 
ACPI Error: Invalid type (Region) for target of Scope operator [PRT0] (Cannot override) (20161117/dswload-351)
ACPI Exception: AE_AML_OPERAND_TYPE, During name lookup/catalog (20161117/psobject-310)
Could not parse external ACPI tables, AE_AML_OPERAND_TYPE

So disassembling with -da results in the error above.
Click to expand...

You should check that you're using the correct iasl.

And should probably even try the latest iasl built from my github sources.
(I have a slightly newer version on my own machine, but it is unlikely the last few commits from Intel that I have here (as of yet not pushed to my github) are signficant).
 
RehabMan said:
You should check that you're using the correct iasl.

And should probably even try the latest iasl built from my github sources.
(I have a slightly newer version on my own machine, but it is unlikely the last few commits from Intel that I have here (as of yet not pushed to my github) are signficant).
Click to expand...

That worked like a charm! Thanks, Rehabman!

Any chance someone could point me in the right direction for the SSDT-13-sensrhub.aml
PARSE errors I'm getting while trying to compile? This is the only one left giving issues.

Problem reporting files are available from post #2510 (nothing has changed)

Thanks!
 
Within OS X, is there any advantage to patching DSDT to disable touchscreens? I'm wondering if higher power usage on touchscreen laptops could be due to an unsupported touchscreen. I've looked through my DSDT, and found a device called TPL0 under my I2C connection which I suspect is the touchscreen. Here is the relevant DSDT code for the device:

Code: 
Scope (_SB.PCI0.I2C0)
    {
        Device (TPL0)
        {
            Name (HID2, Zero)
            Name (SBFB, ResourceTemplate ()
            {
                I2cSerialBusV2 (0x004C, ControllerInitiated, 0x00061A80,
                    AddressingMode7Bit, "\\_SB.PCI0.I2C0",
                    0x00, ResourceConsumer, _Y24, Exclusive,
                    )
            })
            Name (SBFG, ResourceTemplate ()
            {
                GpioInt (Level, ActiveLow, Exclusive, PullDefault, 0x0000,
                    "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x0000
                    }
            })
            Name (SBFI, ResourceTemplate ()
            {
                Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, _Y25)
                {
                    0x00000000,
                }
            })
            CreateWordField (SBFB, \_SB.PCI0.I2C0.TPL0._Y24._ADR, BADR)  // _ADR: Address
            CreateDWordField (SBFB, \_SB.PCI0.I2C0.TPL0._Y24._SPE, SPED)  // _SPE: Speed
            CreateDWordField (SBFI, \_SB.PCI0.I2C0.TPL0._Y25._INT, INT2)  // _INT: Interrupts
            CreateWordField (SBFG, 0x17, INT1)
            Method (_INI, 0, NotSerialized)  // _INI: Initialize
            {
                If (LLess (OSYS, 0x07DC))
                {
                    SRXO (GPLI, One)
                }

                Store (GNUM (GPLI), INT1)
                Store (INUM (GPLI), INT2)
                If (LEqual (SDM1, Zero))
                {
                    SHPO (GPLI, One)
                }

                Store ("ELAN0732", _HID)
                Store (One, HID2)
                Store (0x10, BADR)
                Store (0x00061A80, SPED)
                Return (Zero)
            }

            Name (_HID, "XXXX0000")  // _HID: Hardware ID
            Name (_CID, "PNP0C50")  // _CID: Compatible ID
            Name (_S0W, 0x04)  // _S0W: S0 Device Wake State
            Method (_DSM, 4, Serialized)  // _DSM: Device-Specific Method
            {
                If (LEqual (Arg0, HIDG))
                {
                    Return (HIDD (Arg0, Arg1, Arg2, Arg3, HID2))
                }

                If (LEqual (Arg0, TP7G))
                {
                    Return (TP7D (Arg0, Arg1, Arg2, Arg3, SBFB, SBFG))
                }

                Return (Buffer (One)
                {
                     0x00                                         
                })
            }

            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                Return (0x0F)
            }

            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                If (LLess (OSYS, 0x07DC))
                {
                    Return (SBFI)
                }

                If (LEqual (SDM1, Zero))
                {
                    Return (ConcatenateResTemplate (SBFB, SBFG))
                }

                Return (ConcatenateResTemplate (SBFB, SBFI))
            }
        }
    }

Screen Shot 2017-10-20 at 12.07.20 PM.png


I have looked in IOReg and the device says its current power state is 0x0. Does this mean the touchscreen is already effectively disabled?
 
ddegrasse said:
I have looked in IOReg and the device says its current power state is 0x0. Does this mean the touchscreen is already effectively disabled?
Click to expand...

No.
Disabling it would require some sort of kext to put it into a sleep state.
There is ongoing work on kexts for I2C devices, so that may help in the future.
 
RehabMan said:
No.
Disabling it would require some sort of kext to put it into a sleep state.
There is ongoing work on kexts for I2C devices, so that may help in the future.
Click to expand...

Interesting, and modifying _INI in the DSDT couldn't prevent the device from loading? also no indication of an _OFF method in my DSDT or SSDTs, is that a GPU specific method?
 
You must log in or register to reply here.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top