ACPI规范概览-1

1. Overview

背景
高级配置与电源接口（Advanced Configuration and Power Interface，ACPI）是在1990s由英特尔、微软、东芝、惠普和凤凰合作开发的。在开发ACPI之前，OS主要使用BIOS (Basic Input/Output System)接口进行电源管理、设备发现和配置。这种电源管理方法利用了操作系统的能力来调用系统BIOS进行电源管理。BIOS方案在三个关键方面存在问题。首先，操作系统应用程序的行为可能受到bios配置的电源管理设置的负面影响，导致系统在非预期场景进入休眠。其次，电源管理接口在每个系统上都是专有的，开发人员需要花大量精力了解每个系统的电源管理配置。最后，各种设备的默认设置也可能相互冲突，导致设备崩溃，行为不稳定。

ACPI就是为了解决这些问题和其他问题而开发的。

What is ACPI

ACPI可以被理解为一个与体系结构无关的电源管理和配置框架，作为OS的一个子系统。这个框架建立了一个硬件寄存器集来定义电源状态(睡眠、休眠、唤醒等)。硬件寄存器集可以兼容专用硬件和通用硬件。标准ACPI框架的主要目的是无需直接从OS本地调用固件进行电源管理和系统配置。ACPI作为操作系统和系统固件之间的接口层。

ACPI定义了两种类型的数据结构，它们通过ACPI子系统在系统固件和操作系统之间共享，数据表和定义块(data tables and definition blocks)。这些数据结构是固件和操作系统之间的主要通信机制。数据表存储原始数据，并由设备驱动程序使用。定义块由解释器可执行的字节码组成。

在初始化时，AML解释器从定义块中提取字节码作为可枚举对象。这个可枚举对象集合形成了一个ACPI namespace。OS通过AML解释器与系统硬件进行交互。

定义块字节代码是从ACPI 源语言 (ASL) 代码编译而来的。 ASL语言用来定义ACPI对象并编写控制方法。 ASL编译器将ASL 翻译成 ACPI 机器语言(AML) 字节码。 AML是AML解释器处理的语言，如下图所示。

AML 解释器执行字节码并评估定义块中的对象以允许字节码执行循环构造，条件评估，访问定义的地址空间，并执行应用程序的其他操作要求。 AML 解释器对定义的地址空间具有读/写访问权限，包括系统内存、I/O、PCI配置等等。它通过定义称为对象的入口点来访问这些地址空间。对象可以具有直接定义的值，或者可由 AML 解释器计算。

ACPI namespace是一个操作系统上设备的层次化表示。系统总线是这些 ACPI 设备的枚举根。在其他总线上可枚举的设备，如 PCI 或 USB 设备，通常不在命名空间中枚举。通常具有_HID object (hardware identification object)的设备可以由ACPI进行枚举并加载其驱动程序。具有_ADR object (physical address object)的设备通常不会被 ACPI 枚举，也不会让ACPI 加载其驱动程序。 _ADR 设备通常可以执行所有必要的功能，而无需
涉及 ACPI，但在设备驱动程序无法执行功能或驱动程序需要通信的情况下
对于系统固件，ACPI 可以评估对象以执行所需的功能。

ACPI初始化

系统上电之后，首先由系统固件完成其设置、初始化和自检。然后，在将控制权传递给引导加载程序之前，系统固件使用在固件初始化期间获得的信息来更新 ACPI 表，包括各种平台配置和电源接口数据。扩展根系统描述表 (XSDT) 是 ACPI 子系统使用的第一个表，包含系统上大多数其他 ACPI 表的地址。 XSDT 指向固定的 ACPI 描述表 (FADT)以及操作系统在初始化期间处理的其他主要表。操作系统初始化后，FADT把ACPI 子系统指向区分系统描述表 (DSDT)，它是命名空间的开始，因为它是第一个包含定义块的表。

然后，ACPI 子系统处理 DSDT 并使用 ACPI 定义块构建ACPI namespace。XSDT 还指向辅助系统描述表 (SSDT) 并将它们添加到namespace。 ACPI数据表提供有关系统硬件的操作系统原始数据。操作系统使用 ACPI 表构建namespace后，它开始遍历namespace并加载遇到的所有 _HID 设备的驱动程序。

在 ACPI 初始化图中，在将控制权交给引导加载程序之前，系统固件根据需要更新 ACPI 表。 XSDT是OS ACPI子系统使用的第一个表，并包含系统上大多数其他 ACPI 表的地址。 XSDT指向FADT，SSDT 和其他主要的 ACPI 表。 FADT 将 ACPI 子系统引导到 DSDT，，因为 DSDT 是namespace第一个包含定义块的表。然后 ACPI 子系统使用DSDT 并开始从定义块构建 ACPI namespace。 XSDT 还指向 SSDT并将它们添加到命名空间。

2. Introduction

主要目标

(1) 权衡成本/功能，使所有计算机系统能够实现主板配置和电源管理功能：

• 计算机系统包括（但不限于）台式机、移动设备、工作站和服务器机器。
• 可以自由选择从非常简单到非常激进的解决方案，同时仍保持完整的操作系统支持。

(2) 增强电源管理功能和稳健性：

• 过于复杂在平台固件中无法实现的电源管理策略，可以在OS中实现，廉价的电源管理硬件也可以支持非常复杂的电源管理政策。
• 将来自用户、应用程序和硬件的电源管理信息收集到OS中将实现更好的电源管理决策和执行。
• 操作系统中电源管理算法的统一将减少固件和操作系统之间的冲突并将提高可靠性。

(3) 促进和加速电源管理的全行业实施：

• OSPM 和 ACPI 减少了整个行业对电源管理的冗余投资，
  因为这项投资和功能将被收集到操作系统中。这将使行业参与者将他们的努力和投资集中在创新上。
• 操作系统可以独立于硬件发展，允许所有兼容 ACPI 的机器获得操作系统改进和创新的好处。

(4) 为配置主板设备创建一个强大的接口：

• 不用考虑现有接口，采用新的高级设计

Power management 基本原理

ACPI 是抽象接口，所以OS和硬件可以单独演进。而且ACP在跨操作系统和处理器 更易于进行移植。 老的电源管理方法的存在以下问题：

(1) 对电源管理的支持越少，越会阻碍应用程序供应商支持或利用它

• 将电源管理功能移到操作系统中，从而使每台机器上都可用其功能。尽管功能级别因机器而异，但用户和应用程序将在所有 OSPM 机器上看到相同的电源接口和语义。
• 这将使应用程序供应商更加愿意为其产品添加电源管理功能。

(2) 传统电源管理算法受到平台固件可用信息的限制。这限制了可以实现的功能。

• 集中用户、应用程序和硬件的电源管理信息允许实现更强大的功能。

(3) 设备功能通常需要全局一致的电源决策。

• 平台固件处理电源管理会非常复杂。因为它局限于硬件的静态配置。
• 平台固件能够保留和管理的状态信息要少得多（因为操作系统在管理它）。
• 电源管理算法在操作系统中统一实现比在OS和硬件中分开实现要好。因为可以加载额外的 ACPI 表（定义块），操作系统可以处理动态机器配置；由于平台固件的功能较少且更简单，因此更容易来实施和支持。

ACPI框架

Target Audience
本规范适用于以下用户：
• OEMs building hardware containing ACPI-compatible interfaces
• Operating system and device driver developers
• All platform system firmware developers
• CPU and chip set vendors
• Peripheral vendors