ACPI Advanced Seed

ACPI Architecture Overview

How firmware describes platform hardware to the operating system through ACPI tables, AML, namespace objects, and device methods.

4 min read
ACPI Advanced cover

A board can boot perfectly in firmware setup, but once Windows or Linux starts, the same board may suddenly lose a touchpad, fail to enter sleep, report a wrong battery state, or show an unknown device in Device Manager.

That gap exists because firmware and the OS do not look at the machine in the same way.

Firmware initializes hardware. The OS needs a description of that hardware after firmware hands off control. ACPI is one of the main contracts used for that handoff.

01 Firmware

Platform code builds ACPI tables

DXE modules collect board policy, silicon data, GPIO routing, power state information, and OEM-specific methods.

02 Tables

RSDP points to XSDT

The OS finds the root ACPI pointer, then walks the table list: FADT, MADT, MCFG, DSDT, SSDT, and other tables.

03 AML

DSDT / SSDT contain executable description

ASL source is compiled into AML. The OS interpreter evaluates methods such as _STA, _CRS, _DSM, _PS0, and _PRW.

04 Namespace

OS builds an ACPI namespace

Objects under paths such as \_SB.PCI0.I2C1.TPD0 become OS-visible platform devices.

05 Driver

OS drivers bind to described devices

Drivers use _HID/_CID, resources from _CRS, power methods, GPIO descriptors, and vendor methods to operate the device.

ACPI handoff path from firmware to OS

Why ACPI exists

A PC platform is not only PCI devices. It also has board-specific things:

  • power button and lid switch
  • battery and thermal zones
  • embedded controller RAM fields
  • GPIO interrupts
  • I2C touchpad reset lines
  • camera privacy switch
  • sleep/wake wiring
  • vendor-specific feature toggles

PCI enumeration can discover PCI devices, but it cannot fully describe these platform relationships. ACPI fills that gap.

The minimum mental model

Item Value Note
RSDP Root System Description Pointer Entry point used by the OS to find ACPI tables.
XSDT Extended System Description Table Table directory containing pointers to other ACPI tables.
FADT Fixed ACPI Description Table Contains fixed power management information and a pointer to DSDT.
DSDT Differentiated System Description Table Main AML namespace for the platform.
SSDT Secondary System Description Table Additional AML namespace fragments for CPU, devices, features, or dynamic policy.
AML ACPI Machine Language Bytecode executed by the OS ACPI interpreter.
Namespace Tree of ACPI objects The OS view of firmware-described devices and methods.

Real world example: an I2C touchpad that disappears

Imagine a laptop board where the touchpad is connected through I2C. Firmware setup can still run. The EC is alive. The OS boots. But the touchpad is missing.

A firmware engineer should not start from the driver alone. The ACPI path is usually more useful:

RSDP
└── XSDT
    ├── FADT → DSDT
    └── SSDT-Touchpad
        └── \\_SB.PCI0.I2C1.TPD0
            ├── _HID = "PNP0C50" or vendor HID
            ├── _STA = 0x0F
            ├── _CRS = I2CSerialBus + GpioInt + GpioIo
            └── _DSM = vendor feature package

If _STA returns 0x00, the OS may hide the device. If _CRS has a wrong GPIO interrupt, the driver may bind but never receive events. If _DSM returns an unexpected package, Windows may enable a feature that Linux ignores, or the opposite.

Debug Diary: when ACPI lies

A common ACPI bug is not that the table is completely missing. The table is present, but one small object lies.

For example:

Device (TPD0)
{
    Name (_HID, "PNP0C50")
    Method (_STA, 0, NotSerialized)
    {
        If (TPEN) {
            Return (0x0F)
        }
        Return (0x00)
    }
}

If TPEN is initialized from the wrong NVRAM variable or EC field, the OS sees a different machine from the one firmware intended to expose.

ACPI first-pass debug checklist

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.

Ghi chúACPI Advanced

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.

Ghi chúACPI / Hardware Terms

How are DSDT vs SSDT different?

Quick note explaining DSDT vs SSDT for BIOS/UEFI and embedded firmware readers.

Ghi chúACPI / Hardware Terms

What is AML?

Quick note explaining AML 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.

Đọc blog Xem notes khác