ACPI Debug Toolbox

A practical toolbox note for acpidump, iasl, acpiexec, OS logs, namespace inspection, and firmware-oriented ACPI triage.

2 min read
ACPI Advanced cover

ACPI debug becomes easier when you stop treating the table as a black box.

The basic workflow is simple:

Dump tables

Decompile AML

Inspect namespace and methods

Compare with OS logs and hardware schematic

Trace firmware generation path
Item Value Note
acpidump Dump ACPI tables Useful for collecting DSDT, SSDTs, FADT, MADT, MCFG, DBG2, SPCR, TPM2, etc.
iasl -d Decompile AML to ASL-like DSL Main tool for reading DSDT/SSDT content.
iasl -tc Compile ASL Useful for syntax checking and warning discovery.
acpiexec ACPICA method execution environment Useful for experimenting with method evaluation in controlled conditions.
/sys/firmware/acpi Linux ACPI table view Useful for checking what the running OS received.
OS logs dmesg / Event Viewer / driver logs Connect AML behavior with real OS symptoms.

Linux-style table dump workflow

sudo acpidump -b
ls *.dat
iasl -d dsdt.dat ssdt*.dat

Search common objects:

grep -R "Device (" *.dsl
grep -R "Method (_STA" *.dsl
grep -R "Method (_CRS" *.dsl
grep -R "OperationRegion" *.dsl
grep -R "PowerResource" *.dsl

What to collect for a firmware bug report

ACPI bug report package

Debug Diary: one table dump is not enough

If you only collect dsdt.dat, you may miss an SSDT that creates the broken device. If you only collect source ASL from the firmware tree, you may miss build-time generation or board-specific table selection.

The most reliable artifact is what the OS actually received.

Found this useful?

Save it or share it with someone learning firmware, BIOS/UEFI, and embedded systems.

Nội dung liên quan

Một số bài viết, ghi chú hoặc project có liên quan đến nội dung bạn vừa đọc.

Biến note thành bài viết hoàn chỉnh

Notes là nơi ghi nhanh khái niệm.