AML Deep Dive

How ASL becomes AML, how the OS evaluates ACPI methods, and why firmware bugs often appear as runtime AML behavior.

June 10, 2026 3 min read

ACPI source looks friendly when written as ASL:

Method (_STA, 0, NotSerialized)
{
    Return (0x0F)
}

But the OS does not execute ASL text. Firmware ships AML bytecode inside DSDT and SSDT tables. The OS ACPI interpreter loads that bytecode, builds a namespace, and evaluates methods when drivers or the kernel request platform information.

Firmware author writes ASL

Human-readable ACPI Source Language is written in platform code or generated from templates.

ASL is compiled to AML

`iasl` or firmware build tools compile ASL into ACPI Machine Language.

AML is embedded into ACPI tables

DSDT and SSDT binaries are installed into the ACPI table list during firmware boot.

OS loads and interprets AML

The OS evaluates methods such as `_STA`, `_CRS`, `_DSM`, `_PS0`, and `_PRW` at runtime.

Why AML matters for debugging

AML is not passive data. Some ACPI objects are static names, but many important objects are methods. They can read fields, branch on variables, access OperationRegions, and return different values depending on platform state.

That means an ACPI bug can be a runtime logic bug.

Method (_STA, 0, NotSerialized)
{
    If (LEqual (OSYS, 0x07E9)) {
        Return (0x0F)
    }
    Return (0x00)
}

The table is present. The device object is present. But the OS-visible result depends on method execution.

Real World Example: _CRS changes after a board strap

A platform may return one GPIO interrupt for board revision A and another for board revision B:

Method (_CRS, 0, Serialized)
{
    If (LEqual (BRID, One)) {
        Return (RBUF)
    }
    Return (SBUF)
}

If BRID is read from an EC field or GPIO strap incorrectly, the OS receives the wrong resource template.

Firmware Engineer Notes

When I read AML, I ask three questions:

Is this object static or evaluated at runtime?
Does it read NVRAM, EC RAM, GPIO, PCI config, or system memory?
Which OS component triggers this evaluation?

That habit prevents a common mistake: treating decompiled ACPI as a static hardware list.

Debug commands

# Linux-style workflow
sudo acpidump -b
iasl -d dsdt.dat ssdt*.dat

# Search for an object path or method
grep -R "Method (_STA" *.dsl
grep -R "OperationRegion" *.dsl

# Recompile a decompiled table to catch syntax or semantic warnings
iasl -tc dsdt.dsl

AML debug checklist

Decompile all DSDT/SSDT files together when possible.
Check compiler warnings from iasl; warnings often reveal suspicious ACPI patterns.
Trace method dependencies: local variables, names, fields, OperationRegions, and external objects.
Look for OS-specific branches such as _OSI or platform policy variables.
Compare the returned value with the symptom, not only with the source code intent.

Common Pitfall: trusting comments in ASL

Comments can say “enable device”, while AML returns Zero. The OS only sees the evaluated AML result. During debug, always verify the actual return path.

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.

Đọc blog Xem notes khác