1

I want to extract and decompile my laptops ACPI tables. I am running Ubuntu mate 20.04.

There are many ways to do this it seems. I follow this guide.

Get all tables: sudo acpidump > acpi.log
Extract DSDT and SSDT: acpixtract acpi.log

This gives me...

Intel ACPI Component Architecture
ACPI Binary Table Extraction Utility version 20190509
Copyright (c) 2000 - 2019 Intel Corporation

  DSDT -   36705 bytes written (0x00008F61) - dsdt.dat
  SSDT -    7917 bytes written (0x00001EED) - ssdt1.dat
  SSDT -    2144 bytes written (0x00000860) - ssdt2.dat
  SSDT -    2706 bytes written (0x00000A92) - ssdt3.dat
  SSDT -    1790 bytes written (0x000006FE) - ssdt4.dat
  SSDT -     281 bytes written (0x00000119) - ssdt5.dat
  SSDT -    2107 bytes written (0x0000083B) - ssdt6.dat
  SSDT -     771 bytes written (0x00000303) - ssdt7.dat

Disassemble tables: iasl -e *.dat -d dsdt.dat

This is the output...

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

File appears to be binary: found 12206 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file dsdt.dat, Length 0x8F61 (36705) bytes
ACPI: DSDT 0x0000000000000000 008F61 (v01 DELL   CL09     00000000 ASL  00040000)
External object resolution file        ssdt7.dat
Input file ssdt7.dat, Length 0x303 (771) bytes
ACPI: SSDT 0x0000000000000000 000303 (v01 PmRef  ApIst    00003000 INTL 20121220)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
External object resolution file        ssdt6.dat
Input file ssdt6.dat, Length 0x83B (2107) bytes
ACPI: SSDT 0x0000000000000000 00083B (v01 PmRef  Cpu0Cst  00003001 INTL 20121220)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
External object resolution file        ssdt5.dat
Input file ssdt5.dat, Length 0x119 (281) bytes
ACPI: SSDT 0x0000000000000000 000119 (v01 PmRef  ApCst    00003000 INTL 20121220)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
External object resolution file        ssdt4.dat
Input file ssdt4.dat, Length 0x6FE (1790) bytes
ACPI: SSDT 0x0000000000000000 0006FE (v01 COMPAL CRV ORB  00001000 ACPI 00040000)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
External object resolution file        ssdt3.dat
Input file ssdt3.dat, Length 0xA92 (2706) bytes
ACPI: SSDT 0x0000000000000000 000A92 (v01 COMPAL CRV ORB  00003000 ACPI 00040000)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
External object resolution file        ssdt2.dat
Input file ssdt2.dat, Length 0x860 (2144) bytes
ACPI: SSDT 0x0000000000000000 000860 (v01 COMPAL CRV ORB  00003000 ACPI 00040000)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
External object resolution file        ssdt1.dat
Input file ssdt1.dat, Length 0x1EED (7917) bytes
ACPI: SSDT 0x0000000000000000 001EED (v01 COMPAL CRV ORB  00001000 ACPI 00040000)
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

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

Parsing completed
Disassembly completed
ASL Output:    dsdt.dsl - 330062 bytes

 iASL Warning: There were 7 external control methods found during
 disassembly, but only 2 were resolved (5 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.

 In addition, 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

Is it possible for me to decompile/disassemble my ACPI tables and not have those unresolved external control methods?

I thought that by using this command: iasl -e *.dat -d dsdt.dat all possible external control commands would be resolved because I include all my laptops SSDTs in the iasl command?

Cheers

1 Answer 1

0

I think the unresolved dependencies I get after running this command: iasl -e *.dat -d dsdt.dat i.e: on decompiling the DSDT file are not errors as such and not necessarily even a problem.

They are most likely due to methods being called from my dsdt.dat file that are NOT defined in any of SSDTs from the list (*.dat) I supplied with the iasl command to decompile the DSDT file.

You may not have all your systems original SSDTs (ACPI tables) because some may only be loaded when they are needed and so may not have been in-use when you ran the command to extract the DSDT and all the SSDTs in the first place.

I tried re-compiling the DSDT.dsl file using this command: iasl DSDT.dsl and it DID compile without errors. I got just 3 warnings and a few other informational messages.

The ACPICA Documentation is a very useful source of information on ACPI tables and how to decompile them using the iasl command.

What I don't know is if there is any way to see the definition of those "unresolved external control methods". If anyone knows how to locate the (?unloaded) SSDTs that contain those methods please feel free to contribute.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .