_STA Deep Dive
A firmware-debug focused explanation of ACPI _STA, using device disappearance and OS enumeration problems as the starting point.
Yesterday the touchpad appeared in Device Manager. Today it is gone.
No yellow bang. No driver error. The OS behaves as if the device never existed.
One of the first ACPI methods to suspect is _STA.
_STA is the method the OS evaluates to decide the status of an ACPI device. In practice, it often decides whether a device should be visible, enabled, and considered functional.
| Item | Value | Note |
|---|---|---|
| Bit 0 | Present | Device is physically present or should be considered present. |
| Bit 1 | Enabled | Device is enabled and decodable. |
| Bit 2 | Show in UI | Device should be shown in user-visible device lists. |
| Bit 3 | Functioning | Device is functioning properly. |
| Common value | 0x0F | Present + enabled + visible + functioning. |
| Common failure | 0x00 | OS may hide the device completely. |
A small ASL example
Device (TPD0)
{
Name (_HID, "PNP0C50")
Method (_STA, 0, NotSerialized)
{
If (TPEN) {
Return (0x0F)
}
Return (0x00)
}
}This looks simple, but the real debug question is not “what does _STA mean?”
The real question is: where does TPEN come from?
It may come from:
- BIOS setup variable
- EC RAM field
- GPIO strap
- board ID
- SKU policy
- manufacturing mode
- OS-specific branch
Debug Diary: setup option disables the wrong device
A common bug pattern:
BIOS Setup: Internal Touchpad = Enabled
NVRAM variable: TouchpadEnable = 1
AML reads: TPD_EN field
_STA returns: 0x00
OS result: no touchpad deviceThe issue may be a mismatch between the setup variable, the platform policy consumed by ACPI generation, and the final AML field used by _STA.
User changes BIOS option
The value is stored in NVRAM or converted into platform policy.
ACPI table generation consumes policy
DXE ACPI code generates or selects AML paths based on board/SKU/setup state.
_STA evaluates a condition
The method returns 0x0F or 0x00 depending on a variable, field, or method.
Device is enumerated or hidden
The driver may never get a chance to bind if the ACPI node is not considered present.
Debug checklist
When a device disappears
Common Pitfall
Do not assume _STA is static. If it is a method, it can return different values at different times. A device can appear on cold boot but disappear after resume if the method depends on an EC field that was not restored correctly.
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.
ACPI Debug Playbook
Symptom-driven ACPI debug guide connecting missing devices, driver binding issues, resource conflicts, EC failures, GPIO wake bugs, and power-resource problems.
What is ACPI Method?
Quick note explaining ACPI Method 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.