Microsoft Debug Port Table 2 (DBG2)
Diese Spezifikation definiert das Format des Debugport Table 2 (DBG2), der in der Plattformfirmware verwendet wird, um die auf dem System verfügbaren Debugports zu beschreiben. Diese Informationen gelten für die folgenden Betriebssysteme: Windows 8 und neuer.
Verweise und Ressourcen, die hier erläutert werden, sind am Ende dieses Artikels aufgeführt.
Patenthinweis: Microsoft stellt bestimmte Patentrechte für die Implementierung dieser Spezifikation unter zwei Optionen zur Verfügung:
- Microsofts Community Promise, verfügbar unter
https://www.microsoft.com/openspecifications/en/us/programs/community-promise/default.aspx
- Die Open Web Foundation Final Specification Agreement Version 1.0 ("OWF 1.0") ab dem 1. Oktober 2012, verfügbar unter
http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0
.
Dokumentverlauf
Date | Change |
---|---|
29. November 2011 | Erste Veröffentlichung. |
22. Mai 2012 | Updates in Tabelle 3 für die endgültigen unterstützten Plattformen für Windows 8. |
10. August 2015 | Aktualisierter Patenthinweis. |
6. Oktober 2015 | Neue Untertypen für serielles Debuggen hinzugefügt (Arm SBSA UART, Arm DCC) |
10. Dezember 2015 | Neuer Untertyp für serielles Debuggen hinzugefügt (BCM2835) |
31. Mai 2017 | Neuer Untertyp für serielles Debuggen hinzugefügt (i.MX6, generische Adressstruktur 16550-kompatibel) |
11. Juni 2020 | Neuer Untertyp für serielles Debuggen hinzugefügt (SDM845v2) |
1. September 2020 | Konvertiertes Dokument in Markdownsyntax und Formatierungsänderungen. |
21. September 2020 | Neuer Untertyp für serielles Debuggen (IALPSS) hinzugefügt |
17. Februar 2021 | Dokumentieren aller bekannten seriellen Debuguntertypen |
10. April 2023 | Neuer Untertyp für serielles Debuggen (RISC-V) hinzugefügt und klarstellende Informationen zu 16550-kompatiblen Untertypen hinzugefügt |
Einführung
Microsoft benötigt einen Debugport auf allen Systemen. Um die auf einer Plattform verfügbaren Debugports zu beschreiben, definiert Microsoft eine betriebssystemspezifische Tabelle (DBG2). Diese Tabelle gibt einen oder mehrere unabhängige Ports für Debuggingzwecke an. Das Vorhandensein einer Debugporttabelle gibt an, dass das System einen Debugport enthält. Die Tabelle enthält Informationen zur Konfiguration des Debugports. Die Tabelle befindet sich im Systemspeicher mit anderen ACPI-Tabellen (Advanced Configuration and Power Interface) und muss in der ACPI-Stammsystembeschreibungstabelle (RSDT) referenziert werden.
Die DBG2-Tabelle ersetzt die ACPI-Debugporttabelle (DBGP) auf Plattformen, deren Debugportimplementierungen nicht mithilfe von DBGP beschrieben werden können.
Debugport Table 2 (DBG2)
Tabelle 1. DebugportTabelle 2-Format
Tabelle 1 definiert die Felder in DBG2.
Feld | Bytelänge | Byteoffset | BESCHREIBUNG |
---|---|---|---|
Header | |||
Signatur | 4 | 0 | "DBG2". Signatur für Debugport Tabelle 2. |
Länge | 4 | 4 | Länge des gesamten Debugports In Tabelle 2 in Bytes. |
Revision | 1 | 8 | Für diese Version der Spezifikation ist dieser Wert 0. |
Checksum | 1 | 9 | Die gesamte Tabelle muss auf Null summieren. |
OEM ID | 6 | 10 | OEM-ID (Original Equipment Manufacturer). |
OEM-Tabellen-ID | 8 | 16 | Für Debugport Tabelle 2 ist die Tabellen-ID die Herstellermodell-ID. |
OEM Revision | 4 | 24 | OEM-Revision von Debugport Table 2 für die angegebene OEM-Tabellen-ID. |
Ersteller-ID | 4 | 28 | Anbieter-ID des Dienstprogramms, das die Tabelle erstellt hat. |
Ersteller-Revision | 4 | 32 | Revision des Dienstprogramms, das die Tabelle erstellt hat. |
OffsetDbgDeviceInfo | 4 | 36 | Offset in Byte vom Anfang dieser Tabelle bis zum ersten Eintrag zur Debuggeräteinformationsstruktur. |
NumberDbgDeviceInfo | 4 | 40 | Gibt die Anzahl der Debuggeräteinformationsstruktureinträge an. |
Debuggen der Geräteinformationsstruktur[NumberDbgDeviceInfo] | Variable | OffsetDbgDeviceInfo | Eine Liste der Debuggeräteinformationsstrukturen für diese Plattform. Das Strukturformat wird im Abschnitt Debug Device Information structure weiter unten in diesem Dokument definiert. |
Debuggen der Geräteinformationsstruktur
Tabelle 2: Debuggen des Strukturformats für Geräteinformationen
Feld | Bytelänge | Byteoffset | BESCHREIBUNG |
---|---|---|---|
Revision | 1 | 0 | Überarbeitung der Debuggeräteinformationsstruktur. Für diese Version der Spezifikation muss dies 0 sein. |
Länge | 2 | 1 | Länge dieser Struktur in Bytes, einschließlich NamespaceString und OEMData. |
NumberofGenericAddressRegisters | 1 | 3 | Anzahl der verwendeten generischen Adressregister. |
NamespaceStringLength | 2 | 4 | Länge von NamespaceString in Byte, einschließlich NUL-Zeichen. |
NamespaceStringOffset | 2 | 6 | Offset in Bytes vom Anfang dieser Struktur bis zum Feld NamespaceString[]. Dieser Wert muss gültig sein, da diese Zeichenfolge vorhanden sein muss. |
OemDataLength | 2 | 8 | Länge des OEM-Datenblocks in Byte. |
OemDataOffset | 2 | 10 | Offset in Byte auf das Feld OemData[] vom Anfang dieser Struktur. Dieser Wert ist 0, wenn keine OEM-Daten vorhanden sind. |
Porttyp | 2 | 12 | Debugporttyp für dieses Debuggerät. Jeder dieser Werte verfügt über einen entsprechenden Untertypwert, wie in Tabelle 3 dargestellt. |
Portuntertyp | 2 | 14 | Debugport-Untertyp für dieses Debuggerät. Siehe Tabelle 3. |
Reserviert | 2 | 16 | Reserviert, muss 0 sein. |
BaseAddressRegisterOffset | 2 | 18 | Offset in Bytes vom Anfang dieser Struktur bis zum Feld BaseaddressRegister[]. |
AddressSizeOffset | 2 | 20 | Offset in Bytes vom Anfang dieser Struktur bis zum Feld AddressSize[]. |
BaseAddressRegister[] | (NumberofGenericAddressRegisters) * 12 | BaseAddressRegisterOffset | Array von generischen Adressen. |
AddressSize[] | (NumberofGenericAddressRegisters) * 4 | AddressSizeOffset | Array von Adressgrößen, die jeder generischen Adresse entsprechen. |
NamespaceString[] | NamespaceStringLength | NamespaceStringOffset | NUL-beendete ASCII-Zeichenfolge, um dieses Gerät eindeutig zu identifizieren. Diese Zeichenfolge besteht aus einem vollqualifizierten Verweis auf das Objekt, das dieses Gerät im ACPI-Namespace darstellt. Wenn kein Namespacegerät vorhanden ist, darf NamespaceString[] nur ein einzelnes "." enthalten. (ASCII-Zeitraum) Zeichen. |
OemData[] | OemDataLength | OemDataOffset | Optionale OEM-spezifische Daten mit variabler Länge. |
Tabelle 3: Debuggen von Porttypen und Untertypen
Port | type | Subtype | Beschreibung |
---|---|---|---|
Reserviert | 0x0000 – 0x7FFF und 0xFFFF | All | Reserviert (nicht verwenden) |
Seriell | 0x8000 | 0x0000 | Vollständig 16550-kompatibel |
0x0001 | 16550-Teilmenge kompatibel mit DBGP Revision 1 | ||
0x0002 | MAX311xE SPI UART | ||
0x0003 | Arm PL011 UART | ||
0x0004 | MSM8x60 (z. B. 8960) | ||
0x0005 | Nvidia 16550 | ||
0x0006 | TI OMAP | ||
0x0007 | Reserviert (Nicht verwenden) | ||
0x0008 | APM88xxxx | ||
0x0009 | MSM8974 | ||
0x000A | SAM5250 | ||
0x000B | Intel USIF | ||
0x000C | i.MX 6 | ||
0x000D | (veraltet) Arm SBSA (nur 2.x) Generisches UART, das nur 32-Bit-Zugriffe unterstützt | ||
0x000E | Arm SBSA Generic UART | ||
0x000F | Arm DCC | ||
0x0010 | BCM2835 | ||
0x0011 | SDM845 mit Taktfrequenz von 1,8432 MHz | ||
0x0012 | 16550-kompatibel mit Parametern, die in generischer Adressstruktur definiert sind | ||
0x0013 | SDM845 mit Taktfrequenz von 7,372 MHz | ||
0x0014 | Intel LPSS | ||
0x0015 | RISC-V SBI-Konsole (jeder unterstützte SBI-Mechanismus) | ||
0x0016 – 0xFFFF | Reserviert (für zukünftige Verwendung) | ||
1394 | 0x8001 | 0x0000 | IEEE1394 Standard-Hostcontrollerschnittstelle |
0x0001 – 0xFFFF | Reserviert (für zukünftige Verwendung) | ||
USB | 0x8002 | 0x0000 | XHCI-kompatibler Controller mit Debugschnittstelle |
0x0001 | EHCI-kompatibler Controller mit Debugschnittstelle | ||
0x0002 – 0x0006 | Reserviert (Nicht verwenden) | ||
0x0007 – 0xFFFF | Reserviert (für zukünftige Verwendung) | ||
Net | 0x8003 | NNNN | NNNN muss eine gültige PCI-zugewiesene Anbieter-ID sein. |
0x8004 | All | Reserviert (Nicht verwenden) | |
Reserviert | 0x8005 – 0xFFFE | All | Reserviert (für zukünftige Verwendung) |
Hinweis zu den Feldern der generischen Adressstruktur
Die generische Adressstruktur in BaseAddressRegister[0] wird verwendet, um die Registerbitbreite und Zugriffsgröße anzugeben, die von einigen seriellen Untertypen verwendet wird.
Die Felder Adressraum-ID und Bitoffset registrieren müssen 0 sein.
Das Feld Register Bit Width enthält den Registerschritt und muss eine Leistung von 2 aufweisen, die mindestens so groß wie die Zugriffsgröße ist. Auf 32-Bit-Plattformen darf dieser Wert 32 nicht überschreiten. Auf 64-Bit-Plattformen darf dieser Wert 64 nicht überschreiten.
Das Feld Zugriffsgröße wird verwendet, um zu bestimmen, ob Byte-, WORD-, DWORD- oder QWORD-Zugriffe verwendet werden sollen. QWORD-Zugriffe sind nur für 64-Bit-Architekturen gültig.
Hinweis zu 16550-basierten UARTs
Es gibt drei Schnittstellenuntertypen, die für 16550-basierte UARTs verwendet werden können. Die Unterschiede zwischen ihnen sind subtil, aber wichtig.
Schnittstellenuntertyp 0x0 bezieht sich auf einen seriellen Port, der "Legacy"-Port-E/A verwendet, wie auf x86-basierten Plattformen zu sehen. Dieser Typ sollte auf Plattformen vermieden werden, die speicherbezogene E/A verwenden, z. B. ARM oder RISC-V.
Schnittstellenuntertyp 0x1 unterstützt speicherzuordnungsbasierte UARTs, aber nur solche, die in der DBGP ACPI-Tabelle beschreibbar sind. Betriebssystemimplementierungen können dies als gleichwertig mit einem von DBGP bereitgestellten Debugport behandeln und nur das Feld Basisadresse der generischen Adressstruktur berücksichtigen.
Der Schnittstellenuntertyp 0x12 ist die flexibelste Wahl und wird empfohlen, wenn kompatible Betriebssysteme auf neuen Plattformen ausgeführt werden. Dieser Untertyp unterstützt alle seriellen Ports, die durch die Untertypen 0x0 und 0x1 beschrieben werden können, sowie neue Ports, z. B. solche, die nicht herkömmliche Zugriffsgrößen und Bitbreiten in der generischen Adressstruktur erfordern.