ACPI-Systembeschreibungstabellen

Die Implementierung der ACPI-Hardwarespezifikation (Advanced Configuration and Power Interface) ist auf soC-basierten Plattformen nicht erforderlich, aber ein Großteil der ACPI-Softwarespezifikation ist (oder sein kann) erforderlich. ACPI definiert einen generischen, erweiterbaren Tabellenübergabemechanismus sowie spezifische Tabellen zur Beschreibung der Plattform für das Betriebssystem.

Tabellenstrukturen und Header, einschließlich ID- und Prüfsummenfeldern, werden in der ACPI 5.0-Spezifikation definiert. Windows verwendet diesen Mechanismus zum Übergeben von Tabellen zusätzlich zu den spezifischen Tabellen, die in diesem Artikel beschrieben werden.

Die Idee hinter diesen Tabellen besteht darin, generische Software zur Unterstützung von IP-Standardblöcken (Intellectual Property) zu ermöglichen, die auf unterschiedliche Weise in verschiedene Plattformen integriert werden können. Bei der Tabellenstrategie werden die Plattformvariablenattribute einer bestimmten Plattform in einer Tabelle bereitgestellt und von generischer Software verwendet, um sich an den spezifischen Satz von IP-Blöcken anzupassen, die in die Plattform integriert sind. Diese Software kann daher einmal geschrieben, gründlich getestet und im Laufe der Zeit optimiert werden.

Stammsystembeschreibungszeiger (RSDP)

Windows hängt von der UEFI-Firmware ab, um die Hardwareplattform zu starten. Daher verwendet Windows die EFI-Systemtabelle, um die RSDP zu ermitteln, wie in Abschnitt 5.2.5.2, "Suchen der RSDP auf UEFI-fähigen Systemen" der ACPI 5.0-Spezifikation beschrieben. Die Plattformfirmware füllt entweder die Adresse des RSDT oder des XSDT in der RSDP ein. (Wenn beide Tabellenadressen angegeben sind, bevorzugt Windows XSDT.)

Stammsystembeschreibungstabelle (RSDT)

Das RSDT (oder XSDT) enthält Zeiger auf alle anderen Systembeschreibungstabellen, die auf der Plattform bereitgestellt werden. Insbesondere enthält diese Tabelle Zeiger auf die folgenden Tabellen:

• Die fixed ACPI Hardware Table (FADT)

• Die Tabelle mit mehreren Interruptcontrollern (MADT)

• Optional die Kernsystemressourcentabelle (CSRT)

• Die Debugporttabelle 2 (DBG2)

• Die Startgrafikressourcentabelle (BGRT)

• Firmware Performance Data Table (FPDT)

• Die Basissystembeschreibungstabelle (DSDT)

• Optional zusätzliche Systembeschreibungstabellen (SSDT)

ACPI-Beschreibungstabelle behoben (FADT)

Die Fixed ACPI Hardware Table (FADT) enthält wichtige Informationen zu den verschiedenen Fixed Hardware-Features, die auf der Plattform verfügbar sind. Zur Unterstützung hardwareruzierter ACPI-Plattformen erweitert ACPI 5.0 die FADT-Tabellendefinition wie folgt:

• Das Feld Flags innerhalb des FADT (Offset 112) weist zwei neue Flags auf:

  HARDWARE_REDUCED_ACPI Bitoffset 20. Gibt an, dass ACPI-Hardware auf dieser Plattform nicht verfügbar ist. Dieses Flag muss festgelegt werden, wenn das ACPI Fixed Hardware Programming Model nicht implementiert ist.

  LOW_POWER_S0_IDLE_CAPABLE Bitoffset 21. Gibt an, dass die Plattform Zustände im Leerlauf mit geringem Energieverbrauch innerhalb des ACPI S0-Systemzustands unterstützt, die energieeffizienter sind als jeder Sx-Ruhezustand. Wenn dieses Flag festgelegt ist, versucht Windows nicht, in den Ruhezustand einzuschlafen und fortzusetzen, sondern stattdessen den Leerlaufzustand der Plattform und den verbundenen Standbymodus zu verwenden.

• Das FELD FADT Preferred_PM_Profile (Byteoffset 45) hat einen neuen Rolleneintrag, "Tablet". Diese Rolle beeinflusst die Energieverwaltungsrichtlinie für die Anzeige und Eingabe und wirkt sich auf die Anzeige von Bildschirmtastaturen aus.

• Das Feld "IA-PC Boot Architecture Flags" (Offset 109) weist das neue Flag "CMOS RTC Not Present" (Bitoffset 5) auf, um anzugeben, dass der CMOS RTC des PCs entweder nicht implementiert ist oder an den Legacyadressen nicht vorhanden ist. Wenn dieses Flag festgelegt ist, muss die Plattform das ACPI Time and Alarm Control Method-Gerät implementieren. Weitere Informationen finden Sie im Abschnitt Control Method Time and Alarm Device im Artikel ACPI defined devices .

• Neue Felder werden hinzugefügt, um den herkömmlichen PC-Standbymodus auf HARDWARE-reduzierten ACPI-Plattformen zu unterstützen. Diese Felder werden von Windows ignoriert, müssen jedoch in der Tabelle vorhanden sein, um die Konformität zu gewährleisten.

• Wenn das HARDWARE_REDUCED_ACPI-Flag festgelegt ist, werden alle Felder, die sich auf die ACPI-Hardwarespezifikation beziehen, vom Betriebssystem ignoriert.

Alle anderen FADT-Einstellungen behalten ihre Bedeutung aus der vorherigen Version ACPI 4.0 bei. Weitere Informationen finden Sie in Abschnitt 5.2.9, "Fixed ACPI Description Table (FADT)" der ACPI 5.0-Spezifikation.

Mehrere APIC-Beschreibungstabellen (MADT)

In PC-Implementierungen von ACPI werden die Multiple APIC Description Table (MADT) und PC-spezifische Interruptcontrollerdeskriptoren verwendet, um das Systemunterbrechungsmodell zu beschreiben. Für armbasierte SoC-Plattformen fügt ACPI 5.0 Deskriptoren für den Generischen Interrupt-Controller (GIC) und den GIC-Verteiler von Arm Holdings hinzu. Windows bietet Posteingangsunterstützung für den GIC- und GIC-Verteiler. Weitere Informationen zu diesen Deskriptoren finden Sie in den Abschnitten 5.2.12.14, "GIC-Struktur" und 5.2.12.15, "GIC-Verteilerstruktur" der ACPI 5.0-Spezifikation.

Die Interruptcontrollerdeskriptorstrukturen werden unmittelbar nach dem Feld Flags im MADT aufgeführt. Für Arm-Plattformen ist ein Deskriptor für jede GIC aufgeführt, gefolgt von einem für jeden GIC-Verteiler. Der dem Startprozessor entsprechende GIC muss der erste Eintrag in der Liste der Interruptcontrollerdeskriptoren sein.

Generic Timer Description Table (GTDT)

Wie beim Interruptcontroller gibt es eine Standard-Timerbeschreibungstabelle in ACPI. Für Arm-Systeme, die den GIT-Timer verwenden, kann der GTDT von ACPI verwendet werden, um die integrierte Unterstützung für git in Windows zu nutzen.

Zentrale Systemressourcentabelle (CSRT)

Kernsystemressourcen (Core System Resources, CSRs) sind freigegebene Hardwarefunktionen wie Interruptcontroller, Timer und DMA-Controller, auf die das Betriebssystem den Zugriff serialisieren muss. Wenn Industriestandards für Features wie Timer und Interruptcontroller (sowohl für x86- als auch für Arm-Architekturen) vorhanden sind, unterstützt Windows diese Features basierend auf den in ACPI beschriebenen Standardtabellen (z. B. MADT und GTDT). Bis sich die Branche jedoch mit DMA-Controllerschnittstellenstandards konvergiert, müssen einige nicht standardmäßige Geräte im Betriebssystem unterstützt werden.

Windows unterstützt das Konzept von HAL-Erweiterungen, um dieses Problem zu beheben. HAL-Erweiterungen sind soC-spezifische Module, die als DLLs implementiert werden und die Windows HAL an eine bestimmte Hardwareschnittstelle einer bestimmten Klasse von CSR anpassen, die von Windows benötigt wird. Um diese nicht standardmäßigen CSR-Module zu identifizieren und zu laden, hat Microsoft eine neue ACPI-Tabelle definiert. Diese Tabelle, die eine reservierte Signatur von "CSRT" in der ACPI-Spezifikation aufweist, muss in die RSDT aufgenommen werden, wenn nicht standardmäßige CSRs auf der Plattform verwendet werden.

Das CSRT beschreibt Ressourcengruppen von CSRs, wobei jede Ressourcengruppe Hardware eines bestimmten Typs identifiziert. Windows verwendet den für die Ressourcengruppe angegebenen Bezeichner, um die erforderliche HAL-Erweiterung für diese Gruppe zu finden und zu laden. Ressourcengruppen innerhalb des CSRT können auch einzelne Ressourcendeskriptoren enthalten, abhängig vom CSR-Typ und den Anforderungen der HAL-Erweiterung. Das Format und die Verwendung dieser Ressourcendeskriptoren werden durch den HAL-Erweiterungsschreiber definiert, der die Erweiterung viel portierbarer machen kann und dadurch verschiedene SoC-Plattformen unterstützen kann, indem einfach die im CSRT enthaltenen Ressourcendeskriptoren geändert werden.

Um die Wartung von HAL-Erweiterungen zu unterstützen und die von diesen Erweiterungen verwendeten Systemressourcen zu verwalten, muss jede im CSRT beschriebene Ressourcengruppe auch als Gerät im ACPI-Namespace der Plattform dargestellt werden. Weitere Informationen finden Sie im abschnitt "Differenzierte Systembeschreibungstabelle (DSDT)". Die im Ressourcengruppenheader verwendeten Gerätebezeichner müssen mit den bezeichnern übereinstimmen, die im Namespaceknoten des Geräts verwendet werden. Weitere Informationen finden Sie im Abschnitt Geräteidentifikation in ACPI im Artikel Geräteverwaltungsnamespaceobjekte . Da diese Ressourcengruppennamespacegeräte vorhanden sind, kann die HAL-Erweiterung vom Windows Update-Dienst gewartet werden.

Weitere Informationen finden Sie in der CsrT-Spezifikation (Core System Resources Table).

Debugport Table 2 (DBG2)

Microsoft benötigt einen Debugport auf allen Systemen. Um die in eine Plattform integrierten Debugports zu beschreiben, definiert Microsoft die Debugport-Tabelle 2 (DBG2) für ACPI. Diese Tabelle gibt einen oder mehrere unabhängige Ports für Debuggingzwecke an. Das Vorhandensein der DBG2-Tabelle gibt an, dass die Plattform mindestens einen Debugport enthält. Diese Tabelle enthält Informationen zur Identität und Konfiguration der Debugports. Die Tabelle befindet sich im Systemspeicher mit anderen ACPI-Tabellen und muss in der ACPI-RSDT-Tabelle referenziert werden.

Windows verwendet den Porttypwert in der DBG2-Tabelle, um den vom System benötigten Kerneldebugger (KD)-Transport (z. B. USB oder serial) zu identifizieren und zu laden. Der KD-Transport verwendet dann den Port-Subtype-Wert in der DBG2-Tabelle, um die vom Port verwendete Hardwareschnittstelle zu identifizieren. Andere Informationen in der DBG2-Tabelle geben die Systemadresse der Portregister an, die vom Hardwareschnittstellenmodul für den angegebenen Untertyp verwendet wird. Schließlich muss die DBG2-Tabelle einen Verweis auf den Geräteknoten im ACPI-Namespace enthalten, der dem Debugport entspricht. Dieser Verweis ermöglicht Es Windows, Konflikte zwischen der Debugverwendung und der normalen Verwendung des Geräts (falls vorhanden) zu verwalten und den Debugger auch mit Energieübergängen zu integrieren.

Weitere Informationen finden Sie in der Spezifikation von Microsoft Debug Port Table 2 (DBG2).

Differenzierte Systembeschreibungstabelle (DSDT)

In ACPI werden Peripheriegeräte und Systemhardwarefeatures auf der Plattform in der Differenzierten Systembeschreibungstabelle (Differenzierte Systembeschreibungstabelle, DSDT) beschrieben, die beim Start geladen wird, oder in sekundären Systembeschreibungstabellen (Secondary System Description Tables, SSDTs), die beim Start geladen oder zur Laufzeit dynamisch geladen werden. Bei SoCs ist die Plattformkonfiguration in der Regel statisch, sodass die DSDT möglicherweise ausreichend ist, obwohl SSDTs auch verwendet werden können, um die Modularität der Plattformbeschreibung zu verbessern.

ACPI definiert eine interpretierte Sprache (ACPI-Quellsprache oder ASL) und eine Ausführungsumgebung (ACPI virtual machine), um Systemgeräte und -features sowie deren plattformspezifische Steuerelemente auf betriebssystemunabhängige Weise zu beschreiben. ASL wird verwendet, um benannte Objekte im ACPI-Namespace zu definieren, und der Microsoft ASL-Compiler wird verwendet, um ACPI-Bytecode (AML) für die Übertragung an das Betriebssystem im DSDT zu erzeugen. Der Windows ACPI-Posteingangstreiber Acpi.sys implementiert den virtuellen ACPI-Computer und interpretiert den AML-Bytecode. Ein AML-Objekt kann einfach Beschreibungsinformationen zurückgeben. Oder ein AML-Objekt kann eine Methode sein, die Berechnungen durchführt oder E/A-Vorgänge ausführt. Eine Steuerungsmethode ist ein ausführbares AML-Objekt, das die Gerätetreiber des Betriebssystems verwendet, um E/A-Vorgänge auf der Plattformhardware auszuführen. ASL verwendet OpRegions, um die verschiedenen Adressräume zu abstrahieren, die im Betriebssystem zugänglich sind. Steuerungsmethoden führen E/A-Vorgänge als Eine Reihe von Übertragungen an und aus benannten Feldern aus, die in OpRegions deklariert sind.

Weitere Informationen zu OpRegions finden Sie in Abschnitt 5.5.2.4, "Zugriff auf Vorgangsregionen" in der ACPI 5.0-Spezifikation. Weitere Informationen zu ASL- und Steuerungsmethoden finden Sie in Abschnitt 5.5, "ACPI-Namespace" in der ACPI 5.0-Spezifikation.

Windows bietet Unterstützung für das Entwickeln und Debuggen von ASL-Code. Der ASL-Compiler enthält einen Disassembler, mit dem der Implementierer einen Namespace aus einem Debugziel laden kann. Der ASL-Compiler kann dann verwendet werden, um den Namespace für schnelle Prototyperstellung und Tests erneut auf das Ziel zu anwenden, ohne die Systemfirmware flashen zu müssen. Darüber hinaus unterstützt der Windows-Kerneldebugger in Verbindung mit einer überprüften Version (CHK) des Acpi.sys Treibers die Ablaufverfolgung und Analyse der AML-Ausführung. Weitere Informationen finden Sie unter Der AMLI-Debugger.

Windows SMM Security Mitigations Table (WSMT)

Die WSMT-Spezifikation (Windows SMM Security Mitigations Table) enthält Details zu einer ACPI-Tabelle (Advanced Configuration and Power Interface), die für die Verwendung mit Windows-Betriebssystemen erstellt wurde, die VBS-Features (Virtualisierungsbasierte Sicherheit) von Windows unterstützen.

Diese Informationen gelten für die folgenden Betriebssysteme:

Windows Server 2016

Windows 10, Version 1607

Weitere Informationen finden Sie in der Windows SMM Security Mitigations Table (WSMT)-Spezifikation (DOCX-Download).

iSCSI-Startfirmwaretabelle (iBFT)

Die iSCSI-Startfirmwaretabelle (iBF) ist ein Informationsblock, der verschiedene Parameter enthält, die für den iSCSI-Startvorgang nützlich sind. Der iBFT ist der Mechanismus, mit dem iBF-Parameterwerte an das Betriebssystem übermittelt werden. Der iBF erstellt und füllt den iBFT aus. Der iBFT ist für das Windows-Betriebssystem verfügbar, um einen konsistenten Ablauf des Startvorgangs zu ermöglichen.

Weitere Informationen finden Sie in der iSCSI-Startfirmwaretabelle (iBFT)-Spezifikation (DOCX-Download).