Issue in dissassembly acpi files

[Quandril]

Hello all,

While disassembling my freshly extracted (clover F4) acpi files,
I ran into this message when decompiling (aisle -da -dl DSDT.aml SSDT*.aml)
i’ve no idea why, I never had this befor ( didnt do this model yet, not high Sierra either)

ACPI Warning: NsLookup: Type mismatch on TGPC (Integer), searching for (Buffer) (20161210/nsaccess-732)

Any ideas?, some help would be greatly appreciated.

I Attached the fresh extracted acpi files minus the non-dsdt non ssdt's .

 

[RehabMan]

Hello all,

While disassembling my freshly extracted (clover F4) acpi files,
I ran into this message when decompiling (aisle -da -dl DSDT.aml SSDT*.aml)
i’ve no idea why, I never had this befor ( didnt do this model yet, not high Sierra either)

ACPI Warning: NsLookup: Type mismatch on TGPC (Integer), searching for (Buffer) (20161210/nsaccess-732)

Any ideas?, some help would be greatly appreciated.

I Attached the fresh extracted acpi files minus the non-dsdt non ssdt's .

Must be bad version of iasl.
See guide:
https://www.tonymacx86.com/threads/guide-patching-laptop-dsdt-ssdts.152573/

 

[Quandril]

Ok sorry i didnt notice that iasl62 was there somehow.

So now i got an almost clean dissasembly except for the 6th ssdt and none of the patches in syntax folder in your repo has the fix. would you mind take a look at it so i know what to do?

these are only extracted and dissasembled, nothing more

 

[RehabMan]

Ok sorry i didnt notice that iasl62 was there somehow.

So now i got an almost clean dissasembly except for the 6th ssdt and none of the patches in syntax folder in your repo has the fix. would you mind take a look at it so i know what to do?

these are only extracted and dissasembled, nothing more

No need to patch SSDT-6, so why are you attempting to recompile it?

Hint: For single GPU laptop, no need to patch any SSDTs, as all renames can be done with config.plist/ACPI/DSDT/Patches.

Note: The errors in SSDT-6 are in a _DSM method. Even if you were to patch this SSDT (as I mention, no need to), you would normally be applying "Remove _DSM methods", which removes the error too.

 

[Quandril]

ah didnt know that, thanks for clarifying, one more question, since i'll have to _dsm patch the dsdt, how does it work for the ssdt's closer is handling? do i need a hotpatch for the _dsm? _dsm to ?

 

[RehabMan]

ah didnt know that, thanks for clarifying, one more question, since i'll have to _dsm patch the dsdt, how does it work for the ssdt's closer is handling? do i need a hotpatch for the _dsm? _dsm to ?

No idea what you're asking.

 

[Quandril]

No idea what you're asking.

normally when you use _dsm patch you have to apply it to all the ssdt's also right?
but since i wont be using them do i still have to patch it?

 

[RehabMan]

normally when you use _dsm patch you have to apply it to all the ssdt's also right?
but since i wont be using them do i still have to patch it?

It depends on whether any of the SSDTs have a conflicting _DSM at an ACPI path where you're trying to add a _DSM.

 

[Quandril]

It depends on whether any of the SSDTs have a conflicting _DSM at an ACPI path where you're trying to add a _DSM.

How can i tell?
and if that is the case do i solve it by hotpatching it in clover?

 

[RehabMan]

How can i tell?

Well, you'll know when the _DSM methods you're adding don't work.
And that if you attempt to disassemble your patchmatic -extract output, iasl will find duplicate _DSM methods.
Or you could check all your SSDTs for _DSM methods to see which path they are at to understand whether the paths you plan to add _DSM methods conflict.

and if that is the case do i solve it by hotpatching it in clover?

There are a variety of ways to solve it, and the best way depends on exactly how you're approaching ACPI patching.