Partager via


Microsoft Debug Port Table 2 (DBG2)

Cette spécification définit le format du tableau de ports de débogage 2 (DBG2), utilisé dans le microprogramme de plateforme pour décrire les ports de débogage disponibles sur le système. Ces informations s’appliquent aux systèmes d’exploitation suivants : Windows 8 et versions ultérieures.

Les références et les ressources présentées ici sont répertoriées à la fin de ce document.

Avis de brevet : Microsoft met certains droits de brevet à la disposition des implémentations de cette spécification sous deux options :

  1. Microsoft Community Promise, disponible à l’adresse https://www.microsoft.com/openspecifications/en/us/programs/community-promise/default.aspx
  2. Le Contrat de spécification final Open Web Foundation version 1.0 (« OWF 1.0 ») à compter du 1er octobre 2012, disponible à l’adresse http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0.

Document History

Date Change
29 novembre 2011 First publication.
22 mai 2012 Mises à jour du tableau 3 par plateforme prise en charge finale pour Windows 8.
10 août 2015 Mise à jour de l’avis de brevet.
6 octobre 2015 Ajout de nouveaux sous-types de débogage série (Arm SBSA UART, Arm DCC)
10 décembre 2015 Ajout d’un nouveau sous-type de débogage série (BCM2835)
31 mai 2017 Ajout d’un sous-type de débogage série (i.MX6, Generic Address Structure 16550-compatible)
11 juin 2020 Ajout d’un sous-type de débogage série (SDM845v2)
1 septembre 2020 Modifications apportées à la syntaxe Markdown et à la mise en forme du document converti.
21 septembre 2020 Ajout d’un sous-type de débogage série (IALPSS)
17 février 2021 Documenter tous les sous-types de débogage série connus
10 avril 2023 Ajout d’un nouveau sous-type de débogage série (RISC-V) et ajout d’informations de clarification sur les sous-types compatibles 16550

Introduction

Microsoft nécessite un port de débogage sur tous les systèmes. Pour décrire le ou les ports de débogage disponibles sur une plateforme, Microsoft définit une table spécifique au système d’exploitation (DBG2). Ce tableau spécifie un ou plusieurs ports indépendants à des fins de débogage. La présence d’une table de ports de débogage indique que le système inclut un port de débogage. La table contient des informations sur la configuration du port de débogage. La table se trouve dans la mémoire système avec d’autres tables ACPI (Advanced Configuration and Power Interface), et doit être référencée dans la table de description du système racine ACPI (RSDT).

La table DBG2 remplace la table de ports DEbug ACPI (DBGP) sur les plateformes dont les implémentations de port de débogage ne peuvent pas être décrites à l’aide de DBGP.

Port de débogage Tableau 2 (DBG2)

Table 1. Format Debug Port Table 2

Le tableau 1 définit les champs dans DBG2.

Field Byte length Byte offset Description
Header
Signature 4 0 'DBG2'. Signature pour le tableau de ports de débogage 2.
Length 4 4 Longueur, en octets, de l’ensemble du tableau de ports de débogage 2.
Revision 1 8 Pour cette version de la spécification, cette valeur est 0.
Checksum 1 9 La table entière doit être égale à zéro.
OEM ID 6 10 ID du fabricant d’équipement d’origine (OEM).
OEM Table ID 8 16 Pour le tableau de port de débogage 2, l’ID de table est l’ID de modèle du fabricant.
OEM Revision 4 24 Révision OEM du tableau de port de débogage 2 pour l’ID de table OEM fourni.
Creator ID 4 28 ID du fournisseur de l’utilitaire qui a créé la table.
Creator Revision 4 32 Révision de l’utilitaire qui a créé la table.
OffsetDbgDeviceInfo 4 36 Offset, en octets, du début de cette table à la première entrée de structure Debug Device Information.
NumberDbgDeviceInfo 4 40 Indique le nombre d’entrées de structure Debug Device Information.
Structure des informations sur l’appareil de débogage[NumberDbgDeviceInfo] Variable OffsetDbgDeviceInfo Liste des structures Debug Device Information pour cette plateforme. Le format de structure est défini dans la section Debug Device Information, plus loin dans ce document.

Déboguer la structure d’informations sur l’appareil

Table 2. Format de structure Debug Device Information

Field Byte length Byte offset Description
Revision 1 0 Révision de la structure Debug Device Information. Pour cette version de la spécification, il doit s’agir de 0.
Length 2 1 Longueur, en octets, de cette structure, y compris NamespaceString et OEMData.
NumberofGenericAddressRegisters 1 3 Nombre de registres d’adresses génériques en cours d’utilisation.
NamespaceStringLength 2 4 Longueur, en octets, de NamespaceString, y compris les caractères NUL.
NamespaceStringOffset 2 6 Offset, en octets, du début de cette structure au champ NamespaceString[]. Cette valeur doit être valide, car cette chaîne doit être présente.
OemDataLength 2 8 Longueur, en octets, du bloc de données OEM.
OemDataOffset 2 10 Offset, en octets, vers le champ OemData[] à partir du début de cette structure. Cette valeur est 0 si aucune donnée OEM n’est présente.
Port Type 2 12 Type de port de débogage pour cet appareil de débogage. Chacune de ces valeurs a une valeur de sous-type correspondante, comme indiqué dans le tableau 3.
Port Subtype 2 14 Sous-type de port de débogage pour cet appareil de débogage. Voir le tableau 3.
Reserved 2 16 Réservée, doit être 0.
BaseAddressRegisterOffset 2 18 Offset, en octets, du début de cette structure au champ BaseaddressRegister[].
AddressSizeOffset 2 20 Offset, en octets, du début de cette structure au champ AddressSize[].
BaseAddressRegister[] (NumberofGenericAddressRegisters) * 12 BaseAddressRegisterOffset Tableau d’adresses génériques.
AddressSize[] (NumberofGenericAddressRegisters) * 4 AddressSizeOffset Tableau de tailles d’adresses correspondant à chaque adresse générique ci-dessus.
NamespaceString[] NamespaceStringLength NamespaceStringOffset Chaîne ASCII terminée par un nul pour identifier de manière unique cet appareil. Cette chaîne se compose d’une référence complète à l’objet qui représente cet appareil dans l’espace de noms ACPI. Si aucun appareil d’espace de noms n’existe, NamespaceString[] ne doit contenir qu’un seul « . » Caractère (période ASCII).
OemData[] OemDataLength OemDataOffset Données facultatives spécifiques à l’OEM de longueur variable.

Table 3. Déboguer les types de ports et les sous-types

Port Type Subtype Description
Reserved 0x0000 – 0x7FFF et 0xFFFF All Réservé (ne pas utiliser)
Serial 0x8000 0x0000 Fully 16550-compatible
0x0001 Sous-ensemble 16550 compatible avec DBGP Revision 1
0x0002 MAX311xE SPI UART
0x0003 Arm PL011 UART
0x0004 MSM8x60 (par exemple, 8960)
0x0005 NVIDIA 16550
0x0006 TI OMAP
0x0007 Réservé (ne pas utiliser)
0x0008 APM88xxxx
0x0009 MSM8974
0x000A SAM5250
0x000B Intel USIF
0x000C i.MX 6
0x000D (déconseillé) Arm SBSA (2.x uniquement) UART générique prenant en charge uniquement les accès 32 bits
0x000E Arm SBSA Generic UART
0x000F Arm DCC
0x0010 BCM2835
0x0011 SDM845 avec fréquence d’horloge de 1,8432 MHz
0x0012 Compatible 16550 avec les paramètres définis dans la structure d’adresses générique
0x0013 SDM845 avec fréquence d’horloge de 7,372 MHz
0x0014 Intel LPSS
0x0015 RISC-V console SBI (n’importe quel mécanisme SBI pris en charge)
0x0016 – 0xFFFF Réservé (pour une utilisation ultérieure)
1394 0x8001 0x0000 interface de contrôleur hôte standard IEEE1394
0x0001 – 0xFFFF Réservé (pour une utilisation ultérieure)
USB 0x8002 0x0000 Contrôleur compatible XHCI avec interface de débogage
0x0001 Contrôleur compatible EHCI avec interface de débogage
0x0002 – 0x0006 Réservé (ne pas utiliser)
0x0007 – 0xFFFF Réservé (pour une utilisation ultérieure)
Net 0x8003 NNNN NNNN doit être un ID fournisseur affecté par PCI valide
0x8004 All Réservé (ne pas utiliser)
Reserved 0x8005 – 0xFFFE All Réservé (pour une utilisation ultérieure)

Remarque sur les champs de la structure d’adresses générique

  • La structure d’adresse générique dans BaseAddressRegister[0] est utilisée pour spécifier la largeur du bit d’enregistrement et la taille d’accès utilisée par certains sous-types série.

  • L’ID d’espace d’adressage et les champs Inscrire le décalage de bits doivent être 0.

  • Le champ Largeur du bit d’enregistrement contient le pas de registre et doit être une puissance de 2 qui est au moins aussi grande que la taille d’accès. Sur les plateformes 32 bits, cette valeur ne peut pas dépasser 32. Sur les plateformes 64 bits, cette valeur ne peut pas dépasser 64.

  • Le champ Taille d’accès est utilisé pour déterminer si les accès byte, WORD, DWORD ou QWORD doivent être utilisés. Les accès QWORD sont valides uniquement sur les architectures 64 bits.

Remarque sur les UART basés sur 16550

Il existe trois sous-types d’interface qui peuvent être utilisés pour les UART basés sur 16550. Les différences entre elles sont subtiles mais importantes.

  • Le sous-type d’interface 0x0 fait référence à un port série qui utilise des E/S de port « hérités », comme indiqué sur les plateformes x86. Ce type doit être évité sur les plateformes qui utilisent des E/S mappées en mémoire, telles que ARM ou RISC-V.

  • Le sous-type d’interface 0x1 prend en charge les UART mappés en mémoire, mais uniquement ceux qui sont décribables dans la table ACPI DBGP. Les implémentations du système d’exploitation peuvent les traiter comme équivalentes à un port de débogage fourni par DBGP et respecter uniquement le champ Adresse de base de la structure d’adresses générique.

  • Le sous-type d’interface 0x12 est le choix le plus flexible et est recommandé lors de l’exécution de systèmes d’exploitation compatibles sur de nouvelles plateformes. Ce sous-type prend en charge tous les ports série qui peuvent être décrits par les sous-types 0x0 et les 0x1, ainsi que les nouveaux ports, tels que ceux nécessitant des tailles d’accès et des largeurs de bits non traditionnelles dans la structure d’adresses générique.

Resources

ACPI Specification