ACPI-Systembeschreibungstabellen

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

Tabellenstrukturen und Kopfzeilen, einschließlich ID- und Prüfsummenfeldern, werden in der ACPI 5.0-Spezifikation definiert. Windows verwendet diesen Mechanismus für die Tabellenübergabe zusätzlich zu den spezifischen Tabellen, die in diesem Artikel beschrieben werden.

Die Idee hinter diesen Tabellen besteht darin, generische Software zu ermöglichen, Standard-Ip-Blöcke (Geistiges Eigentum) zu unterstützen, die auf vielfältige Weise in verschiedene Plattformen integriert werden können. Mit der Tabellenstrategie werden die plattformvariablen Attribute 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 dann im Laufe der Zeit optimiert werden.

Root System Description Pointer (RSDP)

Windows hängt von der UEFI-Firmware ab, um die Hardwareplattform zu starten. Daher verwendet Windows die EFI-Systemtabelle, um die RSDP zu finden, wie in Abschnitt 5.2.5.2 beschrieben, "Suchen der RSDP für UEFI-fähige Systeme", der ACPI 5.0-Spezifikation. Die Plattformfirmware trägt die Adresse entweder des RSDT oder des XSDT in die RSDP ein. (Wenn beide Tabellenadressen bereitgestellt werden, bevorzugt Windows XSDT.)

Stammsystembeschreibungstabelle (RSDT)

Der 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-Hardwaretabelle (FADT)

• Die Tabelle mit mehreren Interruptcontrollern (MADT)

• Optional: Die Kernsystemressourcentabelle (CSRT)

• Die Debugporttabelle 2 (DBG2)

• Die Startgrafikressourcentabelle (BGRT)

• Die Firmware Performance Data Table (FPDT)

• Die Basissystembeschreibungstabelle (DSDT)

• Optional können zusätzliche Systembeschreibungstabellen (SSDT) eingefügt werden.

Feststehende ACPI-Beschreibungstabelle (FADT)

Die Fixed ACPI Hardware Table (FADT) enthält wichtige Informationen zu den verschiedenen Fixed Hardware-Features, die auf der Plattform verfügbar sind. Um Hardware-eingeschränkte ACPI-Plattformen zu unterstützen, 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 Bit-Offset 21. Gibt an, dass die Plattform im ACPI S0-System-leistungszustand Ruhezustände unterstützt, die energieeffizienter sind als jeder Sx-Schlafmodus. Wenn diese Kennzeichnung festgelegt ist, versucht Windows nicht, in den Ruhezustand zu wechseln und fortzusetzen, sondern verwendet stattdessen den Zustand der Plattform im Leerlauf und den verbundenen Standbymodus.

• Das Feld "FADT Preferred_PM_Profile" (Byte-Offset 45) hat einen neuen Rolleneintrag "Tablet". Diese Rolle wirkt sich auf die Energieverwaltungsrichtlinie für die Anzeige und Eingabe aus und wirkt sich auf die Anzeige von Bildschirmtastaturen aus.

• Das Feld "IA-PC Boot Architecture Flags" (Offset 109) weist ein neues Flag "CMOS RTC Not Present" (Bit-Offset 5) auf, um anzugeben, dass das CMOS RTC des PCs entweder nicht implementiert ist oder an den Legacy-Adressen nicht vorhanden ist. Wenn diese Kennzeichnung festgelegt ist, muss die Plattform das ACPI-Gerät für Zeit- und Alarmsteuerung implementieren. Weitere Informationen finden Sie im Abschnitt „Control Method Time and Alarm device“ im Artikel „ACPI defined devices“.

• Neue Felder werden hinzugefügt, um die traditionellen PC-Schlaf-/Aufwachmodi auf hardware-reduzierten ACPI-Plattformen zu unterstützen. Diese Felder werden von Windows ignoriert, müssen jedoch in der Tabelle für die Compliance vorhanden sein.

• Wenn das flag HARDWARE_REDUCED_ACPI festgelegt ist, werden alle Felder, die mit der ACPI-Hardwarespezifikation zusammenhängen, vom Betriebssystem ignoriert.

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

Mehrfache APIC-Beschreibungstabelle (MADT)

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

Die Strukturen der Interrupt-Controller-Deskriptoren werden unmittelbar nach dem Flags-Feld im MADT aufgelistet. Für Arm-Plattformen wird ein Deskriptor für jeden GIC aufgeführt, gefolgt von einem für jeden GIC-Distributor. Der GIC, der dem Startprozessor entspricht, muss der erste Eintrag in der Liste der Interruptcontrollerdeskriptoren sein.

Generische Zeitgeberbeschreibungstabelle (GTDT)

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

Core-Systemressourcentabelle (CSRT)

Kernsystemressourcen (CSRs) sind gemeinsam genutzte Hardwarefunktionen wie Interruptcontroller, Zeitgeber und DMA-Controller, auf die das Betriebssystem den Zugriff serialisieren muss. Wenn Branchenstandards für Features wie Timer und Interruptcontroller (sowohl auf x86- als auch Arm-Architekturen) vorhanden sind, unterstützt Windows diese Features basierend auf den standardtabellen, die in ACPI beschrieben sind (z. B. MADT und GTDT). Bis die Branche jedoch auf 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, die 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 das RSDT aufgenommen werden, wenn nicht standardmäßige CSRs auf der Plattform verwendet werden.

Das CSRT beschreibt Ressourcengruppen von CSRs, in denen jede Ressourcengruppe Hardware eines bestimmten Typs identifiziert. Windows verwendet den für die Ressourcengruppe bereitgestellten Bezeichner, um die erforderliche HAL-Erweiterung für diese Gruppe zu suchen 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 wird vom HAL-Erweiterungs-Writer definiert, der die Erweiterung wesentlich portierbarer machen kann und dadurch verschiedene SoC-Plattformen einfach durch Ändern der ressourcendeskriptoren im CSRT unterstützt.

Um die Wartung von HAL-Erweiterungen zu unterstützen und die von diesen Erweiterungen verwendeten Systemressourcen zu verwalten, muss jede ressourcengruppe, die im CSRT beschrieben wird, auch als Gerät im ACPI-Namespace der Plattform dargestellt werden. Weitere Informationen finden Sie im folgenden 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 ". Die Existenz dieser Geräte im Ressourcengruppen-Namensraum ermöglicht es, die HAL-Erweiterung durch den Windows Update-Dienst warten zu lassen.

Weitere Informationen finden Sie in der Spezifikation "Core System Resources Table (CSRT)".

Debug Port Tabelle 2 (DBG2)

Microsoft erfordert einen Debugport auf allen Systemen. Um die in eine Plattform integrierten Debugports zu beschreiben, definiert Microsoft die Debugporttabelle 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 kerneldebugger (KD)-Transport (z. B. USB oder serial) zu identifizieren und zu laden, den das System benötigt. Der KD-Transport verwendet dann den Port-Untertypwert in der DBG2-Tabelle, um die vom Port verwendete Hardwareschnittstelle zu identifizieren. Weitere 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. Diese Referenz ermöglicht Windows das Verwalten von Konflikten zwischen der Verwendung des Debuggings und der normalen Verwendung des Geräts, sofern vorhanden, sowie die Integration des Debuggers mit Stromübergängen.

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

Differenzierte Systembeschreibungstabelle (DSDT)

In ACPI werden Peripheriegeräte und Systemhardware-Features auf der Plattform in der Differenzierten Systembeschreibungstabelle (Differentiated System Description Table, DSDT) beschrieben, die beim Start geladen wird, oder in sekundären Systembeschreibungstabellen (Secondary System Description Tables, SSDTs), die entweder beim Start oder dynamisch zur Laufzeit geladen werden. Für SoCs ist die Plattformkonfiguration in der Regel statisch, sodass der DSDT möglicherweise ausreicht, 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) zur Beschreibung von Systemgeräten und Features sowie deren plattformspezifischen Steuerelemente auf osunabhängige Weise. ASL wird verwendet, um benannte Objekte im ACPI-Namespace zu definieren, und der Microsoft ASL-Compiler wird verwendet, um AML-Bytecode (ACPI Machine Language) für die Übertragung an das Betriebssystem im DSDT zu erzeugen. Der Windows ACPI-Treiber des Posteingangs, Acpi.sys, implementiert den virtuellen ACPI-Computer und interpretiert den AML-Bytecode. Ein AML-Objekt gibt möglicherweise einfach Beschreibungsinformationen zurück. Oder ein AML-Objekt kann eine Methode sein, die Berechnungen durchführt oder E/A-Vorgänge ausführt. Eine Steuerelementmethode ist ein ausführbares AML-Objekt, das die Gerätetreiber des Betriebssystems zum Ausführen von E/A-Vorgängen auf der Plattformhardware verwendet. ASL verwendet OpRegions, um die verschiedenen Adressräume abzustrahieren, die im Betriebssystem zugänglich sind. Steuerungsmethoden führen E/A-Vorgänge als Eine Reihe von Übertragungen an und von benannten Feldern aus, die in OpRegions deklariert sind.

Weitere Informationen zu OpRegions finden Sie unter Abschnitt 5.5.2.4, "Zugriff auf Betriebsregionen", in der ACPI 5.0-Spezifikation. Weitere Informationen zu ASL- und Steuermethoden 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 Debuggingziel laden kann. Der ASL-Compiler kann dann verwendet werden, um den Namespace erneut auf das Ziel für schnelle Prototypen und Tests anzuwenden, ohne die Systemfirmware flashen zu müssen. Darüber hinaus unterstützt der Windows-Kerneldebugger in Verbindung mit einer überprüften (CHK)-Version des Acpi.sys Treibers die Ablaufverfolgung und Analyse der AML-Ausführung. Weitere Informationen finden Sie im AMLI-Debugger.

Windows SMM-Sicherheitsabschwächungstabelle (WSMT)

Die Windows SMM Security Mitigations Table (WSMT)-Spezifikation enthält Details einer Advanced Configuration and Power Interface (ACPI)-Tabelle, die für die Verwendung mit Windows-Betriebssystemen erstellt wurde, die Windows-Virtualisierungsbasierte Sicherheitsfeatures (VBS) 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 Boot Firmware Tabelle (iBFT)

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

Weitere Informationen finden Sie in der iSCSI Boot Firmware Table (iBFT)-Spezifikation (DOCX-Download).