acpidump Workflow
How to collect ACPI tables from a running system and use them as firmware handoff evidence.
The firmware source says the device exists.
The OS says it does not.
The useful question is not who is right. The useful question is:
What ACPI tables did the OS actually receive?That is where acpidump becomes important.
Typical workflow
sudo acpidump -b
ls *.dat
ias -d DSDT.dat SSDT*.datSome environments use different ACPICA package commands, but the flow is the same:
Collect binary tables
Use acpidump to capture DSDT, SSDT, FADT, MADT, MCFG, and OEM tables from the running machine.
Convert AML to ASL
Use iasl to read methods, devices, resources, operation regions, and conditions.
Find device path
Look for _HID, _CID, _STA, _CRS, _DSM, OperationRegion, and power methods.
Good vs bad system
Compare ACPI namespace and resource output across BIOS versions or SKUs.
Return to firmware source
Use ASL paths, OEM table IDs, and method names to find the responsible platform code.
Real world example: touchpad missing
grep -R "PNP0C50\|ELAN\|SYNA\|TPD" *.dslThen inspect:
Device path
_HID / _CID
_STA
_CRS
_DSM
GPIO interrupt
I2C serial bus resourceIf the device is missing from ACPI output, the firmware generation path is suspect. If the device exists but _STA returns unavailable, the OS may correctly hide it.
Related notes
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.
ACPI Architecture Overview
How firmware describes platform hardware to the operating system through ACPI tables, AML, namespace objects, and device methods.
DSDT vs SSDT for Firmware Engineers
A practical explanation of why platforms use both DSDT and SSDT, how they are loaded, and how to debug table layering issues.
ACPI Table Types: key points
Quick note explaining ACPI Table Types for BIOS/UEFI and embedded firmware readers.
Biến note thành bài viết hoàn chỉnh
Notes là nơi ghi nhanh khái niệm.