disassembly issues.

[jcfrosty]

iasl -da *.dat DOES NOT WORK.

iasl -e ssdt1.dat ssdt4.dat ssdt8.dat ssdt14.dat -d dsdt.dat
iasl -e ssdt1.dat ssdt4.dat ssdt8.dat ssdt14.dat -d ssdt1.dat
iasl -e ssdt1.dat ssdt4.dat ssdt8.dat ssdt14.dat -d ssdt2.dat
iasl -e ssdt1.dat ssdt4.dat ssdt8.dat ssdt14.dat -d ssdt3.dat
iasl -e ssdt1.dat ssdt4.dat ssdt8.dat ssdt14.dat -d ssdt4.dat
iasl -e ssdt1.dat ssdt4.dat ssdt8.dat ssdt14.dat -d ssdt5.dat
iasl -e ssdt1.dat ssdt4.dat ssdt8.dat ssdt14.dat -d ssdt6.dat
iasl -e ssdt1.dat ssdt4.dat ssdt8.dat ssdt14.dat -d ssdt7.dat
iasl -e ssdt1.dat ssdt10.dat ssdt14.dat -d ssdt8.dat
iasl -e ssdt1.dat ssdt14.dat -d ssdt9.dat
iasl -e ssdt1.dat ssdt14.dat -d ssdt10.dat
iasl -e ssdt1.dat ssdt14.dat -d ssdt11.dat
iasl -e ssdt1.dat ssdt14.dat -d ssdt12.dat
iasl -e ssdt1.dat ssdt8.dat ssdt14.dat -d ssdt13.dat

iasl -e ssdt1.dat ssdt5.dat ssdt6.dat -d ssdt14.dat (broken, no matter what combination I use after -e)
iASL Warning: There were 9 external control methods found during
disassembly, but only 5 were resolved (4 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. Note: SSDTs can be dynamically loaded at
runtime and may or may not be available via the host OS.

RWEverything shows:
Store(_SB.ALIB(Zero, M207), M207)

iasl dsl file shows:
= _SB.ALIB /* External reference */
M207
M207
iasl version, obviously isn't going to work due to missing/misplaced information.

I'll attach my .dat files so you can figure out why disassembly is broken.
These are from an ACER Nitro5 Ryzen 5 model (AN515-42-R5GT)
RWEverything disassembly
RWEverything.tar.gz

iasl disassembly
iasl-DSL.tar.gz

Original ACPIDUMP
bios_sck.tar.gz

[SchmErik]

iasl disassembly
iasl-DSL.tar.gz

I'm getting a crash while disassembling ssdt13.dat. Which version did you use to generate this iasl disassembly?

Original ACPIDUMP
bios_sck.tar.gz

[jcfrosty]

20181003

[SchmErik]

could you get me the result of the acpidump utility rather than the result from acpixtract? I'm having trouble disassembling.

[jcfrosty]

I think you misunderstand, these files are a result of the "acpidump -b" command. not acpixtract.

[jcfrosty]

SSDT13 decompiled for me OK.

jcfrosty@Silent-Knight ~/Downloads/bios_sck $ iasl -e ssdt1.dat ssdt8.dat ssdt14.dat -d ssdt13.dat

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20171215
Copyright (c) 2000 - 2017 Intel Corporation

Input file ssdt13.dat, Length 0x86 (134) bytes
ACPI: SSDT 0x0000000000000000 000086 (v01 ACRSYS ACRPRDCT 00000001 1025 00040000)
External object resolution file ssdt14.dat
Input file ssdt14.dat, Length 0x1A41 (6721) bytes
ACPI: SSDT 0x0000000000000000 001A41 (v01 ACRSYS ACRPRDCT 00000001 1025 00040000)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
External object resolution file ssdt8.dat
Input file ssdt8.dat, Length 0xE96 (3734) bytes
ACPI: SSDT 0x0000000000000000 000E96 (v01 ACRSYS ACRPRDCT 00000001 1025 00040000)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
External object resolution file ssdt1.dat
Input file ssdt1.dat, Length 0x5367 (21351) bytes
ACPI: SSDT 0x0000000000000000 005367 (v02 ACRSYS ACRPRDCT 00000002 1025 00040000)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed

Found 6 external control methods, reparsing with new information
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed
Disassembly completed
ASL Output: ssdt13.dsl - 1572 bytes

[acpibob]

= _SB.ALIB /* External reference */
M207
M207

At first glance, this looks like the issue where the disassembler gets confused because it does no know how many arguments are defined for the method. It is a serious limitation of the AML.

Some symbols may not get loaded into the namespace because of conditional loading code within the DSDT/SSDTs.

That's the meaning of this message:

This
resulting disassembler output file may not compile because the
disassembler did not know how many arguments to assign to the
unresolved methods.

the -fe option is intended to assist with the disassembly of these methods.

Look at the header of the .DSL file(s) for more information.

[jcfrosty]

acpibob: so why does RWEverything understand the number of arguments that are defined, but iasl does not?

Also, I can decompile each file one by one, but decompiling the group causes a segfault. is -e not an appropriate method? Also, no matter what file I reference, SSDT14 is going to have issues due to missing scopes that I can't locate even with RWEverything. I'm a n00b to this stuff, so I open to learning. what would a -fe file look like in my case? I'm willing to give it a try, but I'm not sure this is going to resolve the confusion with the arguments. I'm curious what to do in that case as well.

[SchmErik]

acpibob: so why does RWEverything understand the number of arguments that are defined, but iasl does not?

It's likely that RWEverything is correct in guessing the amount of arguments. Either that or RWEverything might be querying windows OS to determine the amount of arguments that a control method requires

[SchmErik]

acpibob: so why does RWEverything understand the number of arguments that are defined, but iasl does not?

It would be great if you could you ask the RWEverything owners on how they did this? It would be nice to do this but they might be using some sort of windows API..

[acpibob]

Here is the complete (and unfortunate) store concerning disassembly of external control methods:

4.2.1 Multiple Table Disassembly
There is a known difficulty in disassembling control method invocations for methods that are external to the table being disassembled. This is because there is often insufficient information within the AML to properly disassemble these method invocations.
Therefore, whenever possible, all DSDTs and SSDTs for a given machine should be disassembled together using the –da or –e option. If all SSDTs are included this way, the necessary information will be available to fully and correctly disassemble the target table.
For example, to disassemble the DSDT on a machine with multiple SSDTs:

$ iasl -essdt1.dat,ssdt2.dat,ssdt3.dat -d dsdt.dat

Intel ACPI Component Architecture
AML Disassembler version 20100528 [May 28 2010]
Copyright (c) 2000 - 2010 Intel Corporation
Supports ACPI Specification Revision 5.0

Loading Acpi table from file DSDT.dat
Acpi table [DSDT] successfully installed and loaded
Loading Acpi table from file ssdt1.dat
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Loading Acpi table from file ssdt2.dat
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Loading Acpi table from file ssdt3.dat
Acpi table [SSDT] successfully installed and loaded
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Pass 1 parse of [DSDT]
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
..................................................................................
Parsing completed
Disassembly completed, written to "DSDT.dsl"
4.2.2 External Declarations
During disassembly, any ACPI names that cannot be found or resolved within the table under disassembly are added to a list of externals that are emitted at the start of the table definition block, as shown below:

DefinitionBlock ("DSDT.aml", "DSDT", 1, "INTEL ", "EXAMPLE", 0x06040000)
{
External (Z003)
External (_SB_.PCI0.LNKH)
If the object type that is associated with the name can be resolved during the disassembly, this type is emitted with the external statement also:

External (PETE, IntObj) 
External (HDOS, MethodObj)    // 0 Arguments
External (ECST, MethodObj)    // 1 Arguments
External (PSEN, FieldUnitObj)
External (C7EN, FieldUnitObj)
External (\_PR_.CPU1, DeviceObj)
External (\_PR_.CPU0, DeviceObj)

4.2.2.1 The External AML Opcode
In ACPI 6.1, a new AML opcode (0x15) was defined to allow the compiler to insert external declarations within the AML code itself. This allows the disassembler to easily and deterministically construct the original External() statements in the source ASL code.
4.2.2.2 Generation of ASL External() Statements
There are two ways that external declarations can be emitted by the disassembler: external opcodes within the AML and ACPI names that cannot be found within the table. External opcodes encode names that should be declared as external named objects. This facilitates disassembly of external control method objects because the external opcode contains the object’s type as well as the number of parameters for external control methods. These externals are emitted at the start of the table definition block shown below:
However, not all AML contain external opcodes. During disassembly, any ACPI names that cannot be found or resolved within the table under disassembly are added to a list of externals that are emitted at the start of the table definition block, as shown above.

[acpibob]

I think we have beaten this one to death, so I'm closing it.

Externals are a major problem for disassembly.