ACPI system description tables
Advanced Configuration and Power Interface Specification (ACPI) defines a generic, extensible table-passing mechanism, plus specific tables for describing the platform to the operating system. Table structures and headers, including ID and checksum fields, are defined in the ACPI specification. Tables enable to code generic software to support standard intellectual property (IP) blocks that can be integrated into various platforms in diverse ways.
Root System Description Table (RSDT)
The platform firmware fills in the address of either the RSDT or XSDT in the Root System Description Pointer (RSDP). Windows will use the EFI system table to locate the RSDP. The RSDT (or XSDT) includes pointers to any other system description tables provided on the platform. Few of the tables are
- The Fixed ACPI Hardware Table (FADT)
- The multiple interrupt controller table (MADT)
- Optionally, the Core System Resource Table (CSRT)
- The Debug Port Table 2 (DBG2)
- The Boot Graphics Resource Table (BGRT)
- The Firmware Performance Data Table (FPDT)
- The base system description table (DSDT)
- Optionally, additional system description tables (SSDT)
Fixed ACPI Description Table (FADT)
The Fixed ACPI Hardware Table (FADT) contains important information about the various Fixed Hardware features available on the platform.
Generic Timer Description Table (GTDT)
It is a standard timer description table in ACPI. For ARM systems that utilize the GIT timer, ACPI’s GTDT can be used to leverage the built-in support for the GIT in Windows.
Core System Resources Table (CSRT)
Core System Resources (CSRs) are shared hardware functions such as interrupt controllers, timers and DMA controllers to which the operating system must serialize access. Windows builds in support for these features based on the standard tables described in ACPI (for example, MADT and GTDT).
The CSRT describes resource groups of CSRs, where each resource group identifies hardware of a particular type. Windows uses the identifier provided for the resource group to find and load the required HAL extension for this group. Resource groups within the CSRT might also contain individual resource descriptors, depending on the CSR type and the needs of the HAL extension.
Debug Port Table 2 (DBG2)
Microsoft requires a debug port on all systems. To describe the debug port(s) built into a platform, Microsoft defines the Debug Port Table 2 (DBG2) for ACPI. This table specifies one or more independent port(s) for debugging purposes. The presence of the DBG2 table indicates that the platform includes at least one debug port. This table includes information about the identity and configuration of the debug port(s).
Differentiated System Description Table (DSDT)
In ACPI, peripheral devices and system hardware features on the platform are described in the Differentiated System Description Table (DSDT), which is loaded at boot, or in Secondary System Description Tables (SSDTs), which are loaded at boot or loaded dynamically at run time. For SoCs, the platform configuration is typically static, so the DSDT might be sufficient, although SSDTs can also be used to improve the modularity of the platform description.
Device identification in Windows
ACPI defines several types of namespace objects that can be used to manage devices. For example, device identification objects contain identification information for devices that connect to buses, such as I2C. Windows Plug and Play finds and loads device drivers based on a device identifier provided by the enumerator of the device. Enumerators are bus drivers that know how to extract identification information from the device. Some buses (such as PCI, SD, and USB) have hardware-defined mechanisms to do this extraction. For buses that do not (such as the processor bus or a simple peripheral bus), ACPI defines identification objects in the namespace.
Device identification in ACPI
Hardware ID (_HID)
The minimum requirement for identifying a device in ACPI is the Hardware ID (_HID) object. _HID returns a string with the format of “ABC[D]xxxx”, where “ABC[D]” is a 3- or 4-character string that identifies the manufacturer of the device (the “Vendor ID”), and xxxx is a hexadecimal number that identifies the specific device manufactured by that vendor (the “Device ID”). Vendor IDs must be unique across the industry. Microsoft allocates these strings to ensure that they are unique.
Compatible ID (_CID)
Microsoft has reserved the vendor ID “PNP” for devices that are compatible with inbox drivers shipped with Windows. Windows defines a number of device IDs for use with this vendor ID that can be used to load the Windows-provided driver for a device. A separate object, the Compatible ID (_CID) object, is used to return these identifiers. Windows always prefers Hardware IDs (returned by _HID) over Compatible IDs (returned by _CID) in INF matching and driver selection. This preference allows the Windows-provided driver to be treated as a default driver if a vendor-provided device-specific driver is not available. The Compatible IDs in the following table are newly created for use with SoC platforms.
Subsystem ID (_SUB), Hardware Revision (_HRV), and Class (_CLS)
ACPI 5.0 defines the _SUB, _HRV, and _CLS objects that can be used along with the _HID to create identifiers that more uniquely identify a specific version, integration, or hardware revision of a device, or to indicate membership in a PCI-defined device class. These objects are generally optional, but might be required by certain device classes in Windows.
Device-Specific Method (_DSM)
This method provides for individual, device-specific data and control functions that can be called by a device driver without conflicting with other such device-specific methods. The _DSM for a particular device or device class defines a UUID (GUID) that is guaranteed not to clash with other UUIDs. For each UUID, there is a set of defined functions that the _DSM method can implement to provide data or to perform control functions for the driver.
Device configuration objects
For each device identified in the namespace, the system resources (memory addresses, interrupts, and so on) consumed by the device must also be reported by the Current Resource Settings (_CRS) object. Reporting of multiple possible resource configurations (_PRS) and controls for changing a device’s resource configuration (_SRS) are supported but optional.
Device status changes
ACPI-enumerated devices can be disabled or removed for a variety of reasons. The Status (_STA) object is provided to enable such status changes to be communicated to the operating system. Additionally, ACPI provides a notification mechanism that ASL can use to notify drivers of events in the platform, such as a device being removed as part of a dock.
Device dependencies
Typically, there are hardware dependencies between devices on a particular platform. Windows requires that all such dependencies be described so that it can ensure that all devices function correctly as things change dynamically in the system (device power is removed, drivers are stopped and started, and so on). In ACPI, dependencies between devices are described in the following ways:
- Namespace hierarchy. Any device that is a child device (listed as a device within the namespace of another device) is dependent on the parent device. For example, a USB HSIC device is dependent on the port (parent) and controller (grandparent) it is connected to. Similarly, a GPU device listed within the namespace of a system memory-management unit (MMU) device is dependent on the MMU device.
- Resource connections. Devices connected to GPIO or SPB controllers are dependent on those controllers. This type of dependency is described by the inclusion of Connection Resources in the device’s _CRS.
- OpRegion dependencies. For ASL control methods that use OpRegions to perform I/O, dependencies are not implicitly known by the operating system because they are only determined during control method evaluation. This issue is particularly applicable to GeneralPurposeIO and GenericSerialBus OpRegions in which Plug and Play drivers provide access to the region. To mitigate this issue, ACPI defines the OpRegion Dependency (_DEP) object. _DEP should be used in any device namespace in which an OpRegion (HW resource) is referenced by a control method, and neither 1 nor 2 above already applies for the referenced OpRegion’s connection resource.