Errors in MaciASL

[Areeb Qaisar]

Hello every one. I just finished a successful installation of Mavericks 10.9.2 with working Graphics QE/CI (HD4600) on Lenovo G510. 

But now I need to use a custom dsdt.aml file inorder to apply the patches etc. However, when I try to Compile the default (unpatched) version using Maciasl i get Three errors. I just cannot figure out these errors, because I am not very much familiar with this DSDT Language :-(

Please help me to fix these errors. I have attached the screenshot showing the errors and the System DSDT File  :-(

 

System DSDT.zip

[pokenguyen]

Remove lines in first 2 errors.

[Areeb Qaisar]

Ammm Okay. As per your Recommendations, I removed these whole Blocks as shown below.

And the Errors were gone, but 44 New Warnings, 24 Remarks and 86 Optimizations appeared now. Is it safe to use the DSDT with Warnings ?

Moreover, can you please elaborate what does these two blocks exactly means ? and removing them does not do any harm etc ?

If (CondRefOf (\_SB.PCI0.XHC.PS0X)){
     PS0X
}


If (CondRefOf (\_SB.PCI0.XHC.PS3X))
{
     PS3X
}

[RehabMan]

Ammm Okay. As per your Recommendations, I removed these whole Blocks as shown below.

And the Errors were gone, but 44 New Warnings, 24 Remarks and 86 Optimizations appeared now. Is it safe to use the DSDT with Warnings ?

Moreover, can you please elaborate what does these two blocks exactly means ? and removing them does not do any harm etc ?

If (CondRefOf (\_SB.PCI0.XHC.PS0X)){
     PS0X
}


If (CondRefOf (\_SB.PCI0.XHC.PS3X))
{
     PS3X
}

 

Warnings will not prevent creating a binary AML.

 

The code is checking if a certain method is available (in ACPI namespace) and then calling it. You have errors with it, because you didn't disassemble your DSDT correctly. DSDT which references identifiers defined in SSDTs should be disassembled with SSDTs as context.

 

Extract all SSDT, place all SSDT and DSDT in a single directory, then disassemble using 'iasl -da *' from that directory.

[Areeb Qaisar]

Warnings will not prevent creating a binary AML.

 

The code is checking if a certain method is available (in ACPI namespace) and then calling it. You have errors with it, because you didn't disassemble your DSDT correctly. DSDT which references identifiers defined in SSDTs should be disassembled with SSDTs as context.

 

Extract all SSDT, place all SSDT and DSDT in a single directory, then disassemble using 'iasl -da *' from that directory.

 

I just got a bit confused :-(. I didn't disassembled my DSDT Correctly. ? I just tried in your Maciasl and also in DSDT Editor, and it has option to extract the DSDT. That is all I did. So by this method we dont get the correct DSDT ?

 

From this I conclude, that first I should create the SSDT using the method shown in this page:

http://rampagedev.wordpress.com/guides/make-your-own-ssdt/

 

Next I should save the created SSDT.aml in the same directory as Maciasl or DSDT Editor, and then try to extract the DSDT again ? This time the DSDT should not have errors ? Is this the right way ?

 

What does  disassemble using 'iasl -da *' from that directory. mean ?

[RehabMan]

I just got a bit confused :-(. I didn't disassembled my DSDT Correctly. ? I just tried in your Maciasl and also in DSDT Editor, and it has option to extract the DSDT. That is all I did. So by this method we dont get the correct DSDT ?

Not correct. DSDTs with complex interfaces with SSDTs must be disassembled with the SSDTs as context as I described. If you load an AML directly in MaciASL or DSDT Editor it is disassembled (with iasl) standalone.

 

From this I conclude, that first I should create the SSDT using the method shown in this page:

http://rampagedev.wordpress.com/guides/make-your-own-ssdt/

Generating an SSDT for CPU power management has nothing to do with extracting OEM SSDTs.

 

Next I should save the created SSDT.aml in the same directory as Maciasl or DSDT Editor, and then try to extract the DSDT again ? This time the DSDT should not have errors ? Is this the right way ?

 

What does  disassemble using 'iasl -da *' from that directory. mean ?

First you need to extract all SSDTs/DSDT using Linux (they are in /sys/firmware/acpi/tables and /sys/firmware/acpi/tables/dynamic. Once you have collected them, bring them into your OS X installation in a separate directory. Then use a recent build of iasl to disassemble them all with 'iasl -da *' in Terminal. That will disassemble all files as .DSL. You then load the .DSL files into MaciASL for patching.

[Areeb Qaisar]

 First you need to extract all SSDTs/DSDT using Linux (they are in /sys/firmware/acpi/tables and /sys/firmware/acpi/tables/dynamic. Once you have collected them, bring them into your OS X installation in a separate directory. Then use a recent build of iasl to disassemble them all with 'iasl -da *' in Terminal. That will disassemble all files as .DSL. You then load the .DSL files into MaciASL for patching.

 

That's Great. It worked. Now the newly created DSDT.dsl file, actually contains No errors, when I open it up with DSDT Editor.

It only contains the following types of warnings:

Use of Compiler Reserved Name (_T_0)
Use of Compiler Reserved Name (_T_1)
Not all Control Paths return a Value (PR2S)
Not all Control Paths return a Value (_PS0)
Not all Control Paths return a Value (_PS3) 
Not all Control Paths return a Value (BIFX) 
Not all Control Paths return a Value (MHPF) 
Unknown reserved name (_VPG)
Unknown reserved name (_CFG)
Caller Method may not always return a Value.
Result is not used, operator has no effect.

So is it safe to apply the patches, along with these warning ? or should I look into removing these warning ?

 

Moreover, There are other DSL Files of SSDT as well such as SSDT1.dsl, SSDT2.dsl etc etc. We do not need them for patching right ?

 

---------------------------------------------------------------

---------------------------------------------------------------

 

Just in case, here is the methodology that I used.

 

There were a total of 7 SSDT and 1 DSDT.

SSDT1, SSDT2, SSDT3, SSDT4 were in /sys/firmware/acpi/tables/

SSDT5, SSDT6, SSDT7 were in /sys/firmware/acpi/tables/dynamic/

 

I extracted all these files, along with the DSDT.aml and placed them in a directory, using

sudo cat /sys/firmware/acpi/tables/SSDT1 > SSDT1.aml
sudo cat /sys/firmware/acpi/tables/SSDT2 > SSDT2.aml
sudo cat /sys/firmware/acpi/tables/SSDT3 > SSDT3.aml
sudo cat /sys/firmware/acpi/tables/SSDT4 > SSDT4.aml
sudo cat /sys/firmware/acpi/tables/dynamic/SSDT5 > SSDT5.aml
sudo cat /sys/firmware/acpi/tables/dynamic/SSDT6 > SSDT6.aml
sudo cat /sys/firmware/acpi/tables/dynamic/SSDT7 > SSDT7.aml
sudo cat /sys/firmware/acpi/tables/DSDT > DSDT.aml

I came across your Your Repository of iasl here, compiled it after installing XCode, and then used 

iasl -da /Folderpath/*

It created 8 more files, with the dsl extension. I just used DSDT.dsl and openned it in DSDT Editor. I hope this is the only file that is required, and we dont have much to do with the files SSDT1.dsl, SSDT2.dsl and so on ?

[RehabMan]

That's Great. It worked. Now the newly created DSDT.dsl file, actually contains No errors, when I open it up with DSDT Editor.

It only contains the following types of warnings:

Use of Compiler Reserved Name (_T_0)
Use of Compiler Reserved Name (_T_1)
Not all Control Paths return a Value (PR2S)
Not all Control Paths return a Value (_PS0)
Not all Control Paths return a Value (_PS3) 
Not all Control Paths return a Value (BIFX) 
Not all Control Paths return a Value (MHPF) 
Unknown reserved name (_VPG)
Unknown reserved name (_CFG)
Caller Method may not always return a Value.
Result is not used, operator has no effect.

So is it safe to apply the patches, along with these warning ? or should I look into removing these warning ?

 

Moreover, There are other DSL Files of SSDT as well such as SSDT1.dsl, SSDT2.dsl etc etc. We do not need them for patching right ?

 

---------------------------------------------------------------

---------------------------------------------------------------

 

Just in case, here is the methodology that I used.

 

There were a total of 7 SSDT and 1 DSDT.

SSDT1, SSDT2, SSDT3, SSDT4 were in /sys/firmware/acpi/tables/

SSDT5, SSDT6, SSDT7 were in /sys/firmware/acpi/tables/dynamic/

 

I extracted all these files, along with the DSDT.aml and placed them in a directory, using

sudo cat /sys/firmware/acpi/tables/SSDT1 > SSDT1.aml
sudo cat /sys/firmware/acpi/tables/SSDT2 > SSDT2.aml
sudo cat /sys/firmware/acpi/tables/SSDT3 > SSDT3.aml
sudo cat /sys/firmware/acpi/tables/SSDT4 > SSDT4.aml
sudo cat /sys/firmware/acpi/tables/dynamic/SSDT5 > SSDT5.aml
sudo cat /sys/firmware/acpi/tables/dynamic/SSDT6 > SSDT6.aml
sudo cat /sys/firmware/acpi/tables/dynamic/SSDT7 > SSDT7.aml
sudo cat /sys/firmware/acpi/tables/DSDT > DSDT.aml

I came across your Your Repository of iasl here, compiled it after installing XCode, and then used 

iasl -da /Folderpath/*

It created 8 more files, with the dsl extension. I just used DSDT.dsl and openned it in DSDT Editor. I hope this is the only file that is required, and we dont have much to do with the files SSDT1.dsl, SSDT2.dsl and so on ?

Warnings are fine as they do not prevent generation of an AML binary.  Keep in mind the DSDT as a whole is working/tested (with Windows) so unless you have evidence to suggest otherwise, you should assume the code works.  Obviously there are cases where the code doesn't work for OS X, which is why we need patches, but those problems are rarely pointed out by warnings from the iasl compiler.

 

As for the SSDTs, there are cases where the SSDTs are needed and sometimes even patched.  It all depends on the content of the various files.  Consider the entire set of DSDT/SSDTs as one ACPI set that is intended to be used together.

 

With recent Haswell systems it is common for the definition of the Intel graphics device (typically named GFX0) to be in an SSDT, and to implement brightness patches for ACPIBacklight.kext it is necessary to patch both the SSDT that contains the definition for GFX0 as well as the DSDT.

[Streamie]

Warnings are fine as they do not prevent generation of an AML binary.  Keep in mind the DSDT as a whole is working/tested (with Windows) so unless you have evidence to suggest otherwise, you should assume the code works.  Obviously there are cases where the code doesn't work for OS X, which is why we need patches, but those problems are rarely pointed out by warnings from the iasl compiler.

 

As for the SSDTs, there are cases where the SSDTs are needed and sometimes even patched.  It all depends on the content of the various files.  Consider the entire set of DSDT/SSDTs as one ACPI set that is intended to be used together.

 

With recent Haswell systems it is common for the definition of the Intel graphics device (typically named GFX0) to be in an SSDT, and to implement brightness patches for ACPIBacklight.kext it is necessary to patch both the SSDT that contains the definition for GFX0 as well as the DSDT.

 

Thank you VERY much for taking the time to explain this. I didn't realize the SSDT files were required for for decompilation.

 

I basically followed the same procedure Areeb did but I used Aida64, and there were only 3 SSDT tables listed.

 

I also used iasl built from the head of master on GitHub and this generated a dsl, but I still ended up with errors trying to compile this.

 

In diffing the output of iasl vs. what I got from Maciasl, I noticed that there was a nice comment at the top explaining some assumptions that might cause errors. I'm wondering if I need something else. I experimented with some of the other acpi tables but none of them would even decompile without error (presumably as expected).

 

Anyway, if you can offer me any guidance I would be very grateful. I have a working DSDT.dsl, which I patched last summer but I'm very curious to know if I can actually get this decompilation to produce something without errors.

 

    /*
     * iASL Warning: There were 6 external control methods found during
     * disassembly, but only 0 was resolved (6 unresolved). Additional
     * ACPI tables may be required to properly disassemble the code. This
     * resulting disassembler output file may not compile because the
     * disassembler did not know how many arguments to assign to the
     * unresolved methods.
     *
     * If necessary, the -fe option can be used to specify a file containing
     * control method external declarations with the associated method
     * argument counts. Each line of the file must be of the form:
     *     External (<method pathname>, MethodObj, <argument count>)
     * Invocation:
     *     iasl -fe refs.txt -d dsdt.aml
     *
     * The following methods were unresolved and many not compile properly
     * because the disassembler had to guess at the number of arguments
     * required for each:
     */
    External (_SB_.PCI0.IEIT.EITV, MethodObj)    // Warning: Unresolved method, guessing 0 arguments
    External (ECST, MethodObj)    // Warning: Unresolved method, guessing 1 arguments
    External (HDOS, MethodObj)    // Warning: Unresolved method, guessing 0 arguments
    External (HNOT, MethodObj)    // Warning: Unresolved method, guessing 1 arguments
    External (IDAB, MethodObj)    // Warning: Unresolved method, guessing 0 arguments
    External (TNOT, MethodObj)    // Warning: Unresolved method, guessing 0 arguments

Thanks in advance for any advice.

 

System: ASUS P8Z68-V Pro / ATI 5700 Dual 

[RehabMan]

Thank you VERY much for taking the time to explain this. I didn't realize the SSDT files were required for for decompilation.

 

I basically followed the same procedure Areeb did but I used Aida64, and there were only 3 SSDT tables listed.

 

I also used iasl built from the head of master on GitHub and this generated a dsl, but I still ended up with errors trying to compile this.

 

In diffing the output of iasl vs. what I got from Maciasl, I noticed that there was a nice comment at the top explaining some assumptions that might cause errors. I'm wondering if I need something else. I experimented with some of the other acpi tables but none of them would even decompile without error (presumably as expected).

 

Anyway, if you can offer me any guidance I would be very grateful. I have a working DSDT.dsl, which I patched last summer but I'm very curious to know if I can actually get this decompilation to produce something without errors.

 

 

    /*
     * iASL Warning: There were 6 external control methods found during
     * disassembly, but only 0 was resolved (6 unresolved). Additional
     * ACPI tables may be required to properly disassemble the code. This
     * resulting disassembler output file may not compile because the
     * disassembler did not know how many arguments to assign to the
     * unresolved methods.
     *
     * If necessary, the -fe option can be used to specify a file containing
     * control method external declarations with the associated method
     * argument counts. Each line of the file must be of the form:
     *     External (<method pathname>, MethodObj, <argument count>)
     * Invocation:
     *     iasl -fe refs.txt -d dsdt.aml
     *
     * The following methods were unresolved and many not compile properly
     * because the disassembler had to guess at the number of arguments
     * required for each:
     */
    External (_SB_.PCI0.IEIT.EITV, MethodObj)    // Warning: Unresolved method, guessing 0 arguments
    External (ECST, MethodObj)    // Warning: Unresolved method, guessing 1 arguments
    External (HDOS, MethodObj)    // Warning: Unresolved method, guessing 0 arguments
    External (HNOT, MethodObj)    // Warning: Unresolved method, guessing 1 arguments
    External (IDAB, MethodObj)    // Warning: Unresolved method, guessing 0 arguments
    External (TNOT, MethodObj)    // Warning: Unresolved method, guessing 0 arguments

Thanks in advance for any advice.

 

 

System: ASUS P8Z68-V Pro / ATI 5700 Dual

 

Disassemble all files at once with:

iasl -da SSDT*.aml DSDT*.aml

It will result in *less* errors...

[Streamie]

Disassemble all files at once with:

iasl -da SSDT*.aml DSDT*.aml

It will result in *less* errors...

 

 

I tried that command line, but the generated .dsl files are basically identical to the ones I got previously when invoking the command as:

iasl -da directory_with_just_aml_files/*

Would there be any difference in the SSDT files extracted running Linux vs. Aida64 on Windows7x64?

I was assuming they would be the same.

 

I'm also curious to know if you would recommend any particular resource for learning more about the iasl compiler and disassembler? I was going to look at what is available at https://acpica.org/documentation .

 

Thanks again for giving me a hand.

[RehabMan]

I tried that command line, but the generated .dsl files are basically identical to the ones I got previously when invoking the command as:

iasl -da directory_with_just_aml_files/*

Would there be any difference in the SSDT files extracted running Linux vs. Aida64 on Windows7x64?

I was assuming they would be the same.

 

I'm also curious to know if you would recommend any particular resource for learning more about the iasl compiler and disassembler? I was going to look at what is available at https://acpica.org/documentation .

 

Thanks again for giving me a hand.

 

Without seeing the actual files, no ideas. I'm not sure why you're concerned about comments in the code from the iasl disassembler...

[Areeb Qaisar]

I tried that command line, but the generated .dsl files are basically identical to the ones I got previously when invoking the command as:

iasl -da directory_with_just_aml_files/*

Would there be any difference in the SSDT files extracted running Linux vs. Aida64 on Windows7x64?

I was assuming they would be the same.

 

I'm also curious to know if you would recommend any particular resource for learning more about the iasl compiler and disassembler? I was going to look at what is available at https://acpica.org/documentation .

 

Thanks again for giving me a hand.

 

Use any Ubuntu Live CD. I got it perfectly working using this. I haven't tried it using Aida64, But use Ubuntu and follow the Rehabman's method, it will work flawlessly :-)

By the Way, Rehabman, thank you so much for the help.

I was just wondering that we tend to play with the DSDT and use it to run OS X, 

Isn't harmful for the BIOS ? I mean, can a faulty setting in a Customized DSDT that we use in the form of DSDT.aml to load Mac, can ever corrupt a BIOS or cause it to malfunction ? ?

[RehabMan]

Use any Ubuntu Live CD. I got it perfectly working using this. I haven't tried it using Aida64, But use Ubuntu and follow the Rehabman's method, it will work flawlessly :-)

 

By the Way, Rehabman, thank you so much for the help.

I was just wondering that we tend to play with the DSDT and use it to run OS X, 

Isn't harmful for the BIOS ? I mean, can a faulty setting in a Customized DSDT that we use in the form of DSDT.aml to load Mac, can ever corrupt a BIOS or cause it to malfunction ? ?

BIOS can only be changed by reflashing. What we do on the OS X side is only files loaded from disk.

[startergo]

Hello I have disassembled my DSDT and SSDT, but errors in external method were unresolved:

 

External (_GPE.VHOV, MethodObj)    // Warning: Unknown method, guessing 2 arguments

    External (_PR_.CFGD, FieldUnitObj)

    External (_PR_.CPPC, FieldUnitObj)

    External (_PR_.CPU0._PPC, IntObj)

    External (_PR_.CPU0._PSS, PkgObj)

    External (_SB_.IFFS.FFRU, UnknownObj)    // Warning: Unknown object

    External (_SB_.ISCT, UnknownObj)    // Warning: Unknown object

    External (_SB_.ISCT.ASCT, UnknownObj)    // Warning: Unknown object

    External (_SB_.ISCT.SAOS, MethodObj)    // Warning: Unknown method, guessing 1 arguments

    External (_SB_.ISCT.WKRS, UnknownObj)    // Warning: Unknown object

    External (_SB_.PCI0.B0D3.ABWA, MethodObj)    // 1 Arguments

    External (_SB_.PCI0.B0D3.AINI, MethodObj)    // 0 Arguments

    External (_SB_.PCI0.B0D3.ARST, MethodObj)    // 0 Arguments

    External (_SB_.PCI0.B0D3.ASTR, MethodObj)    // 0 Arguments

    External (_SB_.PCI0.B0D3.CXDC, MethodObj)    // 0 Arguments

    External (_SB_.PCI0.B0D3.DCCC, MethodObj)    // 1 Arguments

    External (_SB_.PCI0.CTCD, MethodObj)    // Warning: Unknown method, guessing 0 arguments

    External (_SB_.PCI0.CTCN, MethodObj)    // Warning: Unknown method, guessing 0 arguments

    External (_SB_.PCI0.GFX0.DGCE, MethodObj)    // Warning: Unknown method, guessing 0 arguments

    External (_SB_.PCI0.PAUD.PUAM, MethodObj)    // Warning: Unknown method, guessing 0 arguments

    External (_SB_.PCI0.RP05.DGFX.DD01, UnknownObj)    // Warning: Unknown object

    External (_SB_.PCI0.RP05.DGFX.SBRV, UnknownObj)    // Warning: Unknown object

    External (_SB_.PCI0.RP05.DGFX.SVID, UnknownObj)    // Warning: Unknown object

    External (_SB_.PCI0.XHC_.DUAM, MethodObj)    // Warning: Unknown method, guessing 0 arguments

    External (_SB_.PCI0.XHC_.PS0X, MethodObj)    // Warning: Unknown method, guessing 0 arguments

    External (_SB_.PCI0.XHC_.PS3X, MethodObj)    // Warning: Unknown method, guessing 0 arguments

    External (_SB_.PCI0.XHC_.RHUB.PS0X, MethodObj)    // Warning: Unknown method, guessing 0 arguments

    External (_SB_.PCI0.XHC_.RHUB.PS2X, MethodObj)    // Warning: Unknown method, guessing 0 arguments

    External (_SB_.PCI0.XHC_.RHUB.PS3X, MethodObj)    // Warning: Unknown method, guessing 0 arguments

    External (GSMI, FieldUnitObj)

    External (HVCO, FieldUnitObj)

    External (IDMS, FieldUnitObj)

    External (IGDS, FieldUnitObj)

    External (LTRA, FieldUnitObj)

    External (OBFA, FieldUnitObj)

    External (PDC0, IntObj)

    External (PDC1, IntObj)

    External (PDC2, IntObj)

    External (PDC3, IntObj)

    External (PDC4, IntObj)

    External (PDC5, IntObj)

    External (PDC6, IntObj)

    External (PDC7, IntObj)

    External (SMSL, FieldUnitObj)

    External (SNSL, FieldUnitObj)

    External (WMAB, MethodObj)    // Warning: Unknown method, guessing 1 arguments

 

tables.zip