Partager via

Tables de description système ACPI

  • Article

L’implémentation de la spécification matérielle ACPI (Advanced Configuration and Power Interface) n’est pas requise sur les plateformes basées sur SoC, mais une grande partie de la spécification logicielle ACPI est (ou peut l’être). ACPI définit un mécanisme générique et extensible de passage de table, ainsi que des tables spécifiques pour décrire la plateforme au système d’exploitation.

Les structures et en-têtes de table, y compris les champs ID et somme de contrôle, sont définis dans la spécification ACPI 5.0. Windows utilise ce mécanisme de passage de table, en plus des tables spécifiques décrites dans cet article.

L’idée derrière ces tableaux est de permettre aux logiciels génériques de prendre en charge les blocs de propriété intellectuelle standard qui peuvent être intégrés à diverses plateformes de diverses manières. Avec la stratégie de table, les attributs de variable de plateforme d’une plateforme particulière sont fournis dans une table et utilisés par les logiciels génériques pour s’adapter à l’ensemble spécifique de blocs IP intégrés à la plateforme. Ce logiciel peut donc être écrit une seule fois, minutieusement testé, puis optimisé dans le temps.

Pointeur de description du système racine (RSDP)

Windows dépend du microprogramme UEFI pour démarrer la plateforme matérielle. Par conséquent, Windows utilisera la table système EFI pour localiser le RSDP, comme décrit dans la section 5.2.5.2, « Recherche du RSDP sur les systèmes compatibles UEFI », de la spécification ACPI 5.0. Le microprogramme de plateforme remplit l’adresse du RSDT ou du XSDT dans le RSDP. (Si les deux adresses de table sont fournies, Windows préfère le XSDT.)

Table de description du système racine (RSDT)

Le RSDT (ou XSDT) inclut des pointeurs vers d’autres tables de description système fournies sur la plateforme. Plus précisément, cette table contient des pointeurs vers les tables suivantes :

  • La table matérielle ACPI fixe (FADT)

  • La table de contrôleurs d’interruption multiples (MADT)

  • Si vous le souhaitez, la table de ressources système de base (CSRT)

  • Debug Port Table 2 (DBG2)

  • La table de ressources graphiques de démarrage (BGRT)

  • Table de données de performances du microprogramme (FPDT)

  • Table de description du système de base (DSDT)

  • Éventuellement, d’autres tables de description système (SSDT)

Table de description ACPI fixe (FADT)

La table de matériel ACPI fixe (FADT) contient des informations importantes sur les différentes fonctionnalités matérielles fixes disponibles sur la plateforme. Pour prendre en charge les plateformes ACPI à réduction matérielle, ACPI 5.0 étend la définition de table FADT comme suit :

  • Le champ Indicateurs dans le FADT (décalage 112) comporte deux nouveaux indicateurs :

    HARDWARE_REDUCED_ACPI Décalage de bits 20. Indique que le matériel ACPI n’est pas disponible sur cette plateforme. Cet indicateur doit être défini si le modèle de programmation matérielle fixe ACPI n’est pas implémenté.

    LOW_POWER_S0_IDLE_CAPABLE Décalage de bits 21. Indique que la plateforme prend en charge les états d’inactivité à faible consommation d’énergie dans l’état d’alimentation du système ACPI S0 qui sont plus économes en énergie que n’importe quel état de veille Sx. Si cet indicateur est défini, Windows n’essaie pas de mettre en veille et de reprendre, mais utilise plutôt les états inactifs de la plateforme et la veille connectée.

  • Le champ Preferred_PM_Profile FADT (décalage d’octet 45) a une nouvelle entrée de rôle, « Tablette ». Ce rôle influence la stratégie de gestion de l’alimentation pour l’affichage et l’entrée, et affecte l’affichage des claviers visuels.

  • Le champ « Indicateurs d’architecture de démarrage IA-PC » (décalage 109) a un nouvel indicateur « CMOS RTC non présent » (décalage de bits 5) pour indiquer que le RTC CMOS du PC n’est pas implémenté ou n’existe pas aux adresses héritées. Si cet indicateur est défini, la plateforme doit implémenter le dispositif de méthode de contrôle de l’heure et de l’alarme ACPI. Pour plus d’informations, consultez la section Temps de la méthode de contrôle et dispositif d’alarme dans l’article Appareils définis par ACPI .

  • De nouveaux champs sont ajoutés pour prendre en charge la mise en veille/reprise du PC traditionnel sur les plateformes ACPI à réduction matérielle. Ces champs sont ignorés par Windows, mais doivent être présents dans le tableau à des fins de conformité.

  • Si l’indicateur HARDWARE_REDUCED_ACPI est défini, tous les champs relatifs à la spécification matérielle ACPI sont ignorés par le système d’exploitation.

Tous les autres paramètres FADT conservent leur signification de la version précédente, ACPI 4.0. Pour plus d’informations, consultez la section 5.2.9, « Table de description ACPI fixe (FADT) », de la spécification ACPI 5.0.

Multiple APIC Description Table (MADT)

Dans les implémentations PC d’ACPI, les descripteurs MADT (Multiple APIC Description Table) et les descripteurs de contrôleur d’interruption spécifiques au PC sont utilisés pour décrire le modèle d’interruption système. Pour les plateformes SoC basées sur Arm, ACPI 5.0 ajoute des descripteurs pour le contrôleur d’interruption générique (GIC) et le distributeur GIC d’Arm Holdings. Windows inclut la prise en charge de la boîte de réception pour le serveur GIC et le serveur de distribution GIC. Pour plus d’informations sur ces descripteurs, consultez les sections 5.2.12.14, « GIC Structure » et 5.2.12.15, « GIC Distributor Structure », de la spécification ACPI 5.0.

Les structures de descripteur du contrôleur d’interruption sont répertoriées immédiatement après le champ Indicateurs dans le MADT. Pour les plateformes Arm, un descripteur est répertorié pour chaque GIC, suivi d’un pour chaque serveur de distribution GIC. Le GIC correspondant au processeur de démarrage doit être la première entrée de la liste des descripteurs de contrôleur d’interruption.

Table de description du minuteur générique (GTDT)

Comme avec le contrôleur d’interruption, il existe une table de description du minuteur standard dans ACPI. Pour les systèmes Arm qui utilisent le minuteur GIT, le GTDT d’ACPI peut être utilisé pour tirer parti de la prise en charge intégrée de GIT dans Windows.

Table des ressources système de base (CSRT)

Les ressources système de base (CSR) sont des fonctions matérielles partagées telles que les contrôleurs d’interruption, les minuteurs et les contrôleurs DMA auxquels le système d’exploitation doit sérialiser l’accès. Lorsqu’il existe des normes du secteur pour des fonctionnalités telles que les minuteurs et les contrôleurs d’interruption (sur les architectures x86 et Arm), Windows prend en charge ces fonctionnalités en fonction des tables standard décrites dans ACPI (par exemple, MADT et GTDT). Toutefois, jusqu’à ce que le secteur converge vers les normes d’interface du contrôleur DMA, il est nécessaire de prendre en charge certains appareils non standard dans le système d’exploitation.

Windows prend en charge le concept d’extensions HAL pour résoudre ce problème. Les extensions HAL sont des modules spécifiques au SoC, implémentés en tant que DLL, qui adaptent le HAL Windows à une interface matérielle spécifique d’une classe spécifique de CSR requise par Windows. Pour identifier et charger ces modules CSR non standard, Microsoft a défini une nouvelle table ACPI. Cette table, qui a une signature réservée « CSRT » dans la spécification ACPI, doit être incluse dans le RSDT si des csr non standard sont utilisées sur la plateforme.

Le CSRT décrit les groupes de ressources de csr, où chaque groupe de ressources identifie le matériel d’un type particulier. Windows utilise l’identificateur fourni pour le groupe de ressources pour rechercher et charger l’extension HAL requise pour ce groupe. Les groupes de ressources au sein du CSRT peuvent également contenir des descripteurs de ressources individuels, en fonction du type csr et des besoins de l’extension HAL. Le format et l’utilisation de ces descripteurs de ressources sont définis par l’enregistreur d’extension HAL, qui peut rendre l’extension beaucoup plus portable et ainsi prendre en charge différentes plateformes SoC simplement en modifiant les descripteurs de ressources contenus dans le CSRT.

Pour prendre en charge la maintenance des extensions HAL et gérer les ressources système utilisées par ces extensions, chaque groupe de ressources décrit dans le CSRT doit également être représenté en tant qu’appareil dans l’espace de noms ACPI de la plateforme. Pour plus d’informations, consultez la section « DSDT (Differentiated System Description Table) » suivante. Les identificateurs d’appareil utilisés dans l’en-tête du groupe de ressources doivent correspondre aux identificateurs utilisés dans le nœud d’espace de noms de l’appareil. Pour plus d’informations, consultez la section Identification de l’appareil dans ACPI dans l’article Objets d’espace de noms de gestion des appareils . L’existence de ces appareils d’espace de noms de groupe de ressources permet à l’extension HAL d’être service par le service Windows Update.

Pour plus d’informations, consultez la spécification CSRT (Core System Resources Table).

Debug Port Table 2 (DBG2)

Microsoft nécessite un port de débogage sur tous les systèmes. Pour décrire le ou les ports de débogage intégrés à une plateforme, Microsoft définit la table de port de débogage 2 (DBG2) pour ACPI. Ce tableau spécifie un ou plusieurs ports indépendants à des fins de débogage. La présence de la table DBG2 indique que la plateforme comprend au moins un port de débogage. Ce tableau contient des informations sur l’identité et la configuration des ports de débogage. La table se trouve dans la mémoire système avec d’autres tables ACPI et doit être référencée dans la table ACPI RSDT.

Windows utilise la valeur Type de port dans la table DBG2 pour identifier et charger le transport du débogueur de noyau (KD) (par exemple, USB ou série) requis par le système. Le transport KD utilise ensuite la valeur de sous-type de port dans la table DBG2 pour identifier l’interface matérielle utilisée par le port. D’autres informations dans la table DBG2 spécifient l’adresse système des registres de port, qui est utilisée par le module d’interface matérielle pour le sous-type spécifié. Enfin, la table DBG2 doit inclure une référence au nœud d’appareil dans l’espace de noms ACPI qui correspond au port de débogage. Cette référence permet à Windows de gérer les conflits entre l’utilisation du débogage et l’utilisation normale de l’appareil, le cas échéant, ainsi que d’intégrer le débogueur aux transitions d’alimentation.

Pour plus d’informations, consultez la spécification Microsoft Debug Port Table 2 (DBG2).

Table de description du système différencié (DSDT)

Dans ACPI, les périphériques et les fonctionnalités matérielles système sur la plateforme sont décrits dans la table de description du système différencié (DSDT), qui est chargée au démarrage, ou dans les tables de description du système secondaire (SSDT), qui sont chargées au démarrage ou chargées dynamiquement au moment de l’exécution. Pour les soC, la configuration de la plateforme est généralement statique, de sorte que le DSDT peut être suffisant, bien que les SSDT puissent également être utilisés pour améliorer la modularité de la description de la plateforme.

ACPI définit un langage interprété (langage source ACPI ou ASL) et un environnement d’exécution (machine virtuelle ACPI) pour décrire les appareils et fonctionnalités système, ainsi que leurs contrôles spécifiques à la plateforme, de manière indépendante du système d’exploitation. ASL est utilisé pour définir des objets nommés dans l’espace de noms ACPI, et le compilateur Microsoft ASL est utilisé pour produire du code d’octet AML (ACPI Machine Language) pour la transmission au système d’exploitation dans le DSDT. Le pilote WINDOWS ACPI de boîte de réception, Acpi.sys, implémente la machine virtuelle ACPI et interprète le code d’octet AML. Un objet AML peut simplement retourner des informations de description. Ou bien, un objet AML peut être une méthode qui effectue des calculs ou effectue des opérations d’E/S. Une méthode de contrôle est un objet AML exécutable qui utilise les pilotes de périphérique du système d’exploitation pour effectuer des opérations d’E/S sur le matériel de la plateforme. ASL utilise OpRegions pour extraire les différents espaces d’adressage accessibles dans le système d’exploitation. Les méthodes de contrôle effectuent des opérations d’E/S sous la forme d’une série de transferts vers et depuis des champs nommés déclarés dans OpRegions.

Pour plus d’informations sur OpRegions, consultez la section 5.5.2.4, « Accès aux régions d’opération », dans la spécification ACPI 5.0. Pour plus d’informations sur l’ASL et les méthodes de contrôle, consultez la section 5.5, « Espace de noms ACPI », dans la spécification ACPI 5.0.

Windows prend en charge le développement et le débogage de code ASL. Le compilateur ASL inclut un désassembleur pour permettre à l’implémenteur de charger un espace de noms à partir d’une cible de débogage. Le compilateur ASL peut ensuite être utilisé pour réappliquer l’espace de noms à la cible à des fins de prototypage et de test rapides, sans avoir à flasher le microprogramme système. En outre, le débogueur de noyau Windows, conjointement avec une version vérifiée (CHK) du pilote Acpi.sys, prend en charge le suivi et l’analyse de l’exécution AML. Pour plus d’informations, consultez Le débogueur AMLI.

Table d’atténuations de la sécurité Windows SMM (WSMT)

La spécification WSMT (Windows SMM Security Mitigations Table) contient les détails d’une table ACPI (Advanced Configuration and Power Interface) créée pour une utilisation avec les systèmes d’exploitation Windows qui prennent en charge les fonctionnalités de sécurité basée sur la virtualisation (VBS) De Windows.

Ces informations s’appliquent aux systèmes d’exploitation suivants :

Windows Server 2016

Windows 10, version 1607

Pour plus d’informations, consultez la spécification WSMT (Windows SMM Security Mitigations Table) (téléchargement DOCX).

Table de microprogramme de démarrage iSCSI (iBFT)

IBFT (iSCSI Boot Firmware Table) est un bloc d’informations qui contient différents paramètres utiles au processus de démarrage iSCSI. IBFT est le mécanisme par lequel les valeurs de paramètre iBF sont transmises au système d’exploitation. L’iBF génère et remplit l’iBFT. IBFT est disponible pour le système d’exploitation Windows pour permettre un flux cohérent du processus de démarrage.

Pour plus d’informations, consultez la spécification iSCSI Boot Firmware Table (iBFT) (téléchargement DOCX).