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.
At first glance, ACPI could be one giant table. Put every device, method, and resource in the DSDT and ship the firmware.
Real platforms rarely stay that simple.
CPU topology may depend on SKU. Thunderbolt may be enabled only on some boards. A touchpad may be I2C on one model and USB on another. An OEM may need to patch a device method without rewriting the entire platform namespace.
That is why DSDT and SSDT are usually used together.
Base platform namespace
Usually contains the main board tree such as \_SB, PCI root, EC, thermal, and core platform methods.
Additional namespace fragments
Adds CPU, devices, power resources, hotplug, graphics, storage, or OEM-specific feature blocks.
Namespace merge
The OS ACPI interpreter loads all AML tables and builds a single namespace tree.
Driver binding and method evaluation
Drivers do not care which table created the object. They consume the final merged namespace.
The practical difference
| Item | Value | Note |
|---|---|---|
| DSDT | Main AML table | Referenced from FADT. Usually the platform backbone. |
| SSDT | Supplemental AML table | Loaded from XSDT/RSDT as an additional description block. |
| Namespace effect | Merged | Objects from DSDT and SSDTs become one ACPI namespace. |
| Typical use | Base vs modular | DSDT for common board description; SSDT for SKU/device/policy-specific additions. |
| Debug risk | Override and ordering confusion | The bug may live in an SSDT even when the visible namespace path looks like a DSDT object. |
Real World Example: CPU SSDT
On many systems, CPU-related objects are produced as SSDTs. The base DSDT may describe the platform skeleton, while CPU SSDTs describe processor objects, power states, performance capabilities, or topology.
That lets firmware generate CPU information according to the installed processor and enabled features.
XSDT
├── FACP/FADT → DSDT
├── SSDT-CPU
├── SSDT-PState
├── SSDT-I2C
└── SSDT-OEMFeatureIf a CPU power management bug appears, reading only the DSDT may miss the real source.
Debug Diary: the object exists, but not where you expected
A common mistake is to decompile dsdt.dat, search for a device, and conclude that firmware does not describe it.
But the device may be in an SSDT:
acpidump -b
iasl -d dsdt.dat ssdt*.dat
grep -R "Device (TPD0)" *.dslIf the object appears in ssdt4.dsl, then your debug target is the module that produced that SSDT, not necessarily the main DSDT generation path.
Common Pitfall: assuming SSDT means optional only
SSDT often means modular, not unimportant. A required device can live in an SSDT. A critical power method can live in an SSDT. A wrong SSDT can break boot, sleep, PCIe hotplug, or driver binding.
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.
What is AML?
Quick note explaining AML for BIOS/UEFI and embedded firmware readers.
acpidump Workflow
How to collect ACPI tables from a running system and use them as firmware handoff evidence.
Biến note thành bài viết hoàn chỉnh
Notes là nơi ghi nhanh khái niệm.