DE102022130856A1

DE102022130856A1 - Eingabe-ausgabe-vorrichtung mit debug-steuerung

Info

Publication number: DE102022130856A1
Application number: DE102022130856.1A
Authority: DE
Inventors: Aruni P. Nelson; Abdul R. Ismail; Ashok Mishra; Enrico David Carrieri; Ilya Wagner
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2021-12-23
Filing date: 2022-11-22
Publication date: 2023-06-29
Also published as: US20220113353A1; CN116340077A

Abstract

Bei einer Ausführungsform kann eine Eingabe-Ausgabe(E/A)-Vorrichtung eine E/A-Steuerung und eine Debug-Steuerung beinhalten. Die E/A-Steuerung kann E/A-Datenpakete verarbeiten. Die Debug-Steuerung kann zu Folgendem dienen: Empfangen eines ersten Debug-Pakets von einem Hostsystem über eine In-Band-Verbindung, Verarbeiten des ersten Debug-Pakets, um einen durch das Hostsystem erzeugten Befehl zu extrahieren, und Ausführen des extrahierten Befehls zum Debuggen der E/A-Vorrichtung. Weitere Ausführungsformen sind beschrieben und beansprucht.

Description

Hintergrund
In vielen Computersystemen können Peripherievorrichtungen unter Verwendung von Kommunikationslinks mit den Rechensystemen verbunden sein. Die Kommunikationslinks können ein Busprotokoll implementieren, wie etwa eines der Universal-Serial-Bus(USB)-Familie von Busprotokollen.
Figurenliste

1A-1B sind Blockdiagramme beispielhafter Systeme gemäß einer oder mehreren Ausführungsformen.
2 ist ein Flussdiagramm eines beispielhaften Verfahrens gemäß einer oder mehreren Ausführungsformen.
3A-3C sind Blockdiagramme beispielhafter Vorrichtungen gemäß einer oder mehreren Ausführungsformen.
4A-4B sind Blockdiagramme beispielhafter Systeme gemäß einer oder mehreren Ausführungsformen.
5 ist ein Flussdiagramm eines beispielhaften Verfahrens gemäß einer oder mehreren Ausführungsformen.
6 ist ein Flussdiagramm eines beispielhaften Verfahrens gemäß einer oder mehreren Ausführungsformen.
7 ist ein Blockdiagramm eines beispielhaften Systems gemäß einer oder mehrerer Ausführungsformen.
8 ist eine Veranschaulichung eines beispielhaften Speichermediums gemäß einer oder mehreren Ausführungsformen.

Ausführliche Beschreibung
Bei manchen Computersystemen kann eine Hostvorrichtung über Kommunikationslinks mit einer oder mehreren Peripherievorrichtungen gekoppelt sein. Zum Beispiel kann ein System einen Host-Computer beinhalten, der über einen Universal-Serial-Bus(USB)-Link mit mehreren Eingabe-Ausgabe(E/A)-Vorrichtungen verbunden ist. Jede E/A-Vorrichtung kann eine Steuerung zum Verarbeiten von E/A-Datenpaketen beinhalten, die über die den Link empfangen oder gesendet werden. Zum Beispiel kann eine E/A-Steuerung ein vereinfachter Prozessor sein, der Firmware ausführt, die für die Funktion der E/A-Vorrichtung spezifisch ist. Der Hauptdatenlink, der E/A-Datenpakete zwischen der Hostvorrichtung und der E/A-Vorrichtung überträgt, kann als ein „In-Band“-Link bezeichnet werden. Ferner kann ein Datenlink, der distinkt und/oder getrennt von dem In-Band-Hauptlink ist, als ein „Out-of-Band“-Link bezeichnet werden.
In einigen Beispielen kann die Entwicklung und/oder Modifikation derartiger Computersysteme Durchführen eines „Debugging“ oder Identifizieren eines Problems in Hardware oder Software des Systems umfassen. Das Debuggen des Hostsystems kann Ausführen von Debug-Software auf dem Hostsystem beinhalten, die Laufzeitsteuerfähigkeit für Quellebenendebug bereitstellen kann (z. B. zum Pausieren der Ausführung eines Programms an einem spezifischen Unterbrechungspunkt). Das Debuggen eines Systems, das eine verbundene E/A-Vorrichtung beinhaltet, kann jedoch zusätzliche Komplexität und Kosten beinhalten. Zum Beispiel kann die Debug-Software, die auf dem Hostsystem ausgeführt wird, In-Band-Zugriff auf die E/A-Vorrichtung aufweisen, weist jedoch möglicherweise keine Laufzeitsteuerfähigkeit für Firmware, die auf der E/A-Vorrichtung ausgeführt wird, auf. Ferner können hardwarebasierte Debug-Tools zur Laufzeitsteuerfähigkeit verwendet werden, können aber physisches Verbinden (z. B. Verlöten) mit Verbinderpins der E/A-Steuerung oder Verbinden mit zusätzlichen physischen Ports, die zur Debug-Verwendung dediziert sind, erfordern. Daher stellen solche hardwarebasierten Debug-Tools möglicherweise nur ein Out-of-Band-Debugging bereit, was erhebliche Kosten und/oder Komplexität beinhalten kann.
Bei verschiedenen hierin beschriebenen Ausführungsformen kann eine E/A-Vorrichtung eine Debug-Steuerung oder Funktion beinhalten, um In-Band-Debugging der E/A-Vorrichtung bereitzustellen. Zum Beispiel kann die Debug-Steuerung Debug-Pakete einschließlich Debug-Befehlen von einem Hostsystem über eine In-Band-Verbindung empfangen. Wie hierin verwendet, bezieht sich der Begriff „Debug-Paket“ auf ein Paket, das zur Verwendung in dem Debug-Prozess dediziert ist. Die Debug-Steuerung kann den Befehl aus dem empfangenen Paket extrahieren und kann dann den Befehl ausführen, um Debug-Aktionen in der E/A-Vorrichtung durchzuführen. Solche Debug-Aktionen können zum Beispiel Debuggen verschiedener Komponenten oder Fähigkeiten der E/A-Vorrichtung, Durchführen einer Laufzeitsteuerung für Quellebenendebug, Zugreifen auf Onboard-Debug-Trace-Fähigkeiten, Zugreifen auf Telemetriedaten und so weiter beinhalten. Die Debug-Steuerung kann die Ergebnisse des ausgeführten Befehls erhalten, die Ergebnisse in einem anderen Debug-Paket verkapseln und das Debug-Paket über die In-Band-Verbindung zu dem Hostsystem übertragen. Bei Empfang des Debug-Pakets kann das Hostsystem die Ergebnisse aus dem Debug-Paket extrahieren und kann die Ergebnisse in dem Debugging-Prozess verwenden. Auf diese Weise können einige Ausführungsformen In-Band-Debugging von E/A-Vorrichtungen bereitstellen, das Laufzeitsteuerungsfähigkeiten aufweist. Dementsprechend können eine oder mehrere Ausführungsformen erweiterte Debug-Aktionen durchführen, ohne separate Out-of-Band-Verbindungen oder Vorrichtungsmodifikationen zu erfordern, und können daher die mit dem Debuggen von E/A-Vorrichtungen assoziierten Kosten und Komplexität reduzieren.
FIG. 1A-1B-Beispielhafte Systeme
Nun unter Bezugnahme auf 1A ist ein Blockdiagramm eines ersten beispielhaften Systems 100 gemäß einer oder mehreren Ausführungsformen gezeigt. Das System 100 kann ein Hostsystem 110 beinhalten, das über einen Link 140 mit einer Eingabe-Ausgabe(E/A)-Vorrichtung 150 verbunden ist. Das Hostsystem 110 kann eine Rechenvorrichtung (z. B. ein Server, ein Desktop-Computer, ein Laptop, ein Handheld-Computer usw.) sein. Die E/A-Vorrichtung 150 kann eine Peripherievorrichtung sein, die mit dem Hostsystem 110 verbunden ist. Wie hier verwendet, bezieht sich eine „E/A-Vorrichtung“ auf eine beliebige Vorrichtung, die einer verbundenen Rechenvorrichtung (z. B. dem Hostsystem 110) eine Eingabe und/oder Ausgabe bereitstellt. Zum Beispiel kann sich eine E/A-Vorrichtung auf einen USB-Hub, eine USB-Vorrichtung und so weiter beziehen.
Wie in 1A gezeigt, kann das Hostsystem 110 einen Speicher 120, eine Speicherung 125, einen Prozessor 130 und einen Port 146 beinhalten. Bei manchen Ausführungsformen kann der Speicher 120 mit einem oder mehreren beliebigen Typen von Computerspeicher (z. B. dynamischen Direktzugriffsspeicher (DRAM), statischen Direktzugriffsspeicher (SRAM), nichtflüchtigen Speicher (NVM), einer Kombination von DRAM und NVM usw.) implementiert sein. Die Speicherung 125 kann unter Verwendung einer oder mehrerer persistenter (z. B. nichtflüchtiger) Speicherungsvorrichtungen implementiert sein, wie etwa einer oder mehrerer plattenbasierter Speicherungsvorrichtungen (z. B. einer oder mehrerer Festplatten (HDDs)), einer oder mehrerer Solid-State-Vorrichtungen (SSDs) (z. B. Flash-Speicherungsvorrichtungen), optischer Platten und so weiter. Der Prozessor 130 kann eine Hardwareverarbeitungsvorrichtung (z. B. eine Zentralverarbeitungseinheit (CPU), ein System-on-Chip (SoC) und so weiter) sein und kann eine beliebige Anzahl von Verarbeitungsschaltungen oder „Kernen“ beinhalten. Der Port 146 kann ein E/A-Kommunikationsport (z. B. ein USB-Port) zum Übertragen von Dateneinheiten (z. B. Paketen) über einen Link sein.
In einigen Ausführungsformen kann der Prozessor 130 verschiedene Software ausführen, darunter E/A-Steuerungssoftware 132, Debug-Schnittstelle 134 und Debug-Software 136. Die E/A-Steuerungssoftware 132 kann E/A-Datenpakete 142 an die E/A-Steuerung 162 der E/A-Vorrichtung 150 senden und kann auch E/A-Datenpakete 142 von der E/A-Steuerung 162 (z. B. über den Link 140 und die Ports 146) empfangen. In einigen Ausführungsformen kann die E/A-Steuerung 162 eine Hardwareverarbeitungsvorrichtung sein, die Firmware- oder Softwareanweisungen ausführt, um E/A-Datenpakete 142 zu senden und zu empfangen und die E/A-Vorrichtung 150 und ihre Vorrichtungsfähigkeiten 166 zu steuern. Die Vorrichtungsfähigkeiten 166 können verschiedene Hardware- und Softwareelemente mit unterschiedlichen Funktionalitäten der E/A-Vorrichtung 150 (z. B. Routing, Multiplexen, Filtern, Protokollumwandlung, Komprimierung usw.) beinhalten. Die E/A-Datenpakete 142 können gemäß einem Busprotokoll des Links 140 formatiert werden.
In einigen Ausführungsformen kann die Debug-Software 136 ausgeführt werden, um ein Debugging des Hostsystems 110 und der E/A-Vorrichtung 150 durchzuführen. Zum Beispiel kann die Debug-Software 136 Elemente, wie etwa Daten, Anweisungen, Register, Puffer und so weiter, analysieren. Ferner kann die Debug-Software 136 eine oder mehrere Debug-Aktionen bestimmen, die für den Debug-Prozess benötigt werden (z. B. Pausieren der Ausführung, Lesen von Variablenwerten usw.), und kann Befehle ausgeben, um zu bewirken, dass die Debug-Aktionen in dem Hostsystem 110 und/oder der E/A-Vorrichtung 150 durchgeführt werden.
In einigen Ausführungsformen kann die Debug-Schnittstelle 134 einen Befehl von der Debug-Software 136 in einem Debug-Paket 144 verkapseln. Die Debug-Schnittstelle 134 kann dann das Debug-Paket 144 (einschließlich des Befehls) über den Link 140 an die E/A-Vorrichtung 150 übertragen. Ferner kann die Debug-Schnittstelle 134 Debug-Pakete 144 empfangen, die Debug-Ergebnisse von der E/A-Vorrichtung 150 beinhalten (z. B. Ergebnisse des Ausführens von Befehlen von der Debug-Software 136) und kann die Debug-Ergebnisse aus den empfangenen Debug-Paketen 144 extrahieren. In einigen Ausführungsformen kann das Hostsystem 110 durch Verwenden der Debug-Schnittstelle 134, um ein ausgehendes Debug-Paket 144 zu erzeugen und eingehende Debug-Pakete 144 zu verarbeiten, ein In-Band-Debugging der E/A-Vorrichtung 150 durchführen (d. h. ohne eine Out-of-Band-Verbindung zu erfordern). In einigen Ausführungsformen können die Debug-Pakete 144 einen Pakettyp aufweisen, der zur Verwendung in dem Debug-Prozess dediziert ist. Ferner können die Debug-Pakete 144 in manchen Ausführungsformen gemäß einem Busprotokoll des Links 140 formatiert werden.
Bei einer oder mehreren Ausführungsformen kann die Debug-Steuerung 180 der E/A-Vorrichtung 150 eine Hardwaresteuervorrichtung (z. B. eine Schaltung, ein Mikrocontroller, eine programmierbare integrierte Schaltung, ein programmierbares Gate-Array, ein Prozessor und so weiter) sein, die für das Debugging der E/A-Vorrichtung 150 dediziert ist. Zum Beispiel kann die Debug-Steuerung 180 das erste Debug-Paket 144 empfangen, das durch die Debug-Schnittstelle 134 gesendet wird, kann den verkapselten Befehl (d. h. durch die Debug-Software 136 erzeugt) extrahieren und kann dann den Befehl ausführen (z. B. zum Pausieren der Ausführung, zum Lesen von Variablenwerten usw.). In einem anderen Beispiel kann die Debug-Steuerung 180 die Ergebnisse des Ausführens des Befehls (z. B. Daten, die den Zustand der E/A-Vorrichtung 150 angeben) bestimmen oder erhalten, die Ergebnisse in einem zweiten Debug-Paket 144 verkapseln und dann das zweite Debug-Paket 144 über den Link 140 und die Ports 146 an das Hostsystem 110 übertragen. Ferner kann die Debug-Schnittstelle 134 das zweite Debug-Paket 144 empfangen, die verkapselten Ergebnisse extrahieren und dann die Ergebnisse an die Debug-Software 136 liefern. Die Debug-Software 136 kann die Ergebnisse verwenden, um die E/A-Vorrichtung 150 zu debuggen und/oder um das kombinierte System einschließlich des Hostsystems 110 und der E/A-Vorrichtung 150 zu debuggen.
In einigen Ausführungsformen kann die E/A-Vorrichtung 150 eine E/A-Leistungsdomäne 160 und eine Debug-Leistungsdomäne 170 beinhalten. Die E/A-Leistungsdomäne 160 kann der E/A-Steuerung 162 und den Vorrichtungsfähigkeiten 166 elektrische Leistung bereitstellen. Ferner kann die Debug-Leistungsdomäne 170 der Debug-Steuerung 180 elektrische Leistung bereitstellen und kann unabhängig von der E/A-Leistungsdomäne 160 arbeiten. Zum Beispiel kann die Debug-Leistungsdomäne 170 eingeschaltet bleiben, während die E/A-Leistungsdomäne 160 nicht eingeschaltet ist. Auf diese Weise kann die Debug-Steuerung 180 mit dem Durchführen des Debuggings fortfahren, während die E/A-Steuerung 162 zurückgesetzt wird, indem sie heruntergefahren und dann hochgefahren wird. Ferner kann die E/A-Leistungsdomäne 160 eingeschaltet bleiben, während die Debug-Leistungsdomäne 170 nicht eingeschaltet ist.
In einer oder mehreren Ausführungsformen kann die E/A-Vorrichtung 150 in einen spezialisierten Betriebsmodus eintreten, in dem ein Debugging der E/A-Vorrichtung 150 durchgeführt werden darf (als „Debug-Modus“ bezeichnet). Zum Beispiel kann die Debug-Steuerung 180 nur Debug-Befehle ausführen und/oder Debug-Aktionen durchführen, wenn die E/A-Vorrichtung 150 in den Debug-Modus eingetreten ist. In einigen Ausführungsformen können die Debug-Aktionen, die von der Debug-Steuerung 180 durchgeführt werden, Zugreifen auf alle Entitäten, die in der E/A-Vorrichtung 150 einem Debugging unterzogen werden können (z. B. Vorrichtungsfähigkeiten 166), Bereitstellen einer Laufzeitsteuerfähigkeit für Quellebenendebug, Zugreifen auf beliebige verfügbare Onboard-Debug-Trace-Fähigkeiten und Zugreifen auf Telemetriedaten (z. B. Ausfallrate, Verschleißanalyse usw.), die lokal in der E/A-Vorrichtung 150 gespeichert sind, beinhalten.
Bei manchen Ausführungsformen kann der Debug-Modus als Reaktion auf eine Anforderung von dem Hostsystem 110 (z. B. über den Link 140) implementiert werden. Bei Empfang einer Anforderung zum Eintreten in den Debug-Modus kann die Debug-Steuerung 180 bestimmen, ob die Anforderung gültig und/oder autorisiert ist. Falls ja, kann die Debug-Steuerung 180 den Debug-Modus entsperren (d. h. bewirken, dass die E/A-Vorrichtung 150 in dem Debug-Modus arbeitet). Die Debug-Modus-Anforderung kann zum Beispiel ein sicheres Token sein, das durch die Debug-Steuerung 180 empfangen und validiert wird. Das sichere Token kann den Typ des Debugs (Quellebene, Trace, Telemetrie usw.) und den Grad des Debug-Zugriffs (vollständiges Entsperren, Teilentsperren usw.) spezifizieren. In anderen Beispielen kann die Debug-Modus-Anforderung ferner unter Verwendung eines digitalen Zertifikats, einer Challenge/Response-Technik oder einer beliebigen geeigneten Form von kryptographischer Authentifizierung implementiert werden. Bei manchen Ausführungsformen kann die Debug-Schnittstelle 134 die Debug-Modus-Anforderung in einem ersten Debug-Paket 144 verkapseln. Ferner kann die Debug-Steuerung 180 die Debug-Modus-Anforderung aus dem ersten Debug-Paket 144 extrahieren.
Bei einer oder mehreren Ausführungsformen kann die Debug-Steuerung 180 beim Eintreten in den Debug-Modus eine Bestätigung über den Link 140 zu dem Hostsystem 110 senden. Die Bestätigung kann das Eintreten der E/A-Vorrichtung 150 in den Debug-Modus angeben. Ferner kann die Debug-Software 136 des Hostsystems 110 beim Empfangen der Bestätigung Debug-Befehle erzeugen, die zu der E/A-Vorrichtung 150 gesendet werden sollen. Bei manchen Ausführungsformen kann die Debug-Steuerung 180 die Bestätigung in einem zweiten Debug-Paket 144 verkapseln. Ferner kann die Debug-Schnittstelle 134 die Bestätigung aus dem zweiten Debug-Paket 144 extrahieren.
Nun unter Bezugnahme auf 1B ist ein Blockdiagramm eines zweiten beispielhaften Systems 105 gemäß anderen Ausführungsformen gezeigt. Es sei angemerkt, dass das Hostsystem 110 in dem in 1B gezeigten Beispiel die gleichen Komponenten und Funktionalitäten beinhaltet wie jene, die oben unter Bezugnahme auf das in 1 gezeigte Beispiel beschrieben sind. Die E/A-Vorrichtung 150 beinhaltet jedoch eine Debug-Funktion 185, bei der es sich um Anweisungen (z. B. Firmware oder Software) handeln kann, die durch die E/A-Steuerung 162 ausgeführt werden. Die Debug-Funktion 185 kann einen Teil der oder die gesamte Funktionalität der Debug-Steuerung 180 (oben unter Bezugnahme auf 1A beschrieben) bereitstellen. Zum Beispiel kann die Debug-Funktion 185 ein Debug-Paket 144 empfangen, das durch die Debug-Schnittstelle 134 gesendet wird, einen verkapselten Befehl extrahieren und den Befehl ausführen. In einem anderen Beispiel kann die Debug-Funktion 185 die Ergebnisse des Ausführens des Befehls erhalten, die Ergebnisse in einem Debug-Paket 144 verkapseln und das Debug-Paket 144 zu dem Hostsystem 110 übertragen.
FIG. 2 - Beispielhaftes Verfahren
Nun unter Bezugnahme auf 2 ist ein Flussdiagramm eines Verfahrens 200 gemäß einer oder mehreren Ausführungsformen gezeigt. Bei verschiedenen Ausführungsformen kann das Verfahren 200 durch Verarbeitungslogik (z. B. Prozessor 130, Eingabe-Ausgabe(E/A)-Steuerung 162, Debug-Steuerung 180 und/oder Debug-Funktion 185, die in 1A bis 1B gezeigt sind) durchgeführt werden, die Hardware (z. B. Verarbeitungsvorrichtung, Schaltungsanordnung, dedizierte Logik, programmierbare Logik, Mikrocode usw.), Software und/oder Firmware (z. B. auf einer Verarbeitungsvorrichtung ausgeführte Anweisungen) oder eine Kombination davon beinhalten kann. In Firmware- oder Softwareausführungsformen kann das Verfahren 200 durch computerausgeführte Anweisungen implementiert werden, die in einem nichtflüchtigen maschinenlesbaren Medium, wie etwa einer optischen, Halbleiter- oder magnetischen Speichervorrichtung, gespeichert sind. Das maschinenlesbare Medium kann Daten speichern, die bei Verwendung durch mindestens eine Maschine bewirken, dass die mindestens eine Maschine mindestens eine integrierte Schaltung zum Durchführen eines Verfahrens herstellt.
Block 210 kann beinhalten, dass ein Hostsystem eine Anforderung für einen Debug-Modus an eine E/A-Vorrichtung überträgt. Block 220 kann beinhalten, dass die E/A-Vorrichtung die Anforderung validiert. Block 230 kann beinhalten, dass die E/A-Vorrichtung in den Debug-Modus eintritt und eine Bestätigung an das Hostsystem sendet. Beispielsweise unter Bezugnahme auf 1A kann das Hostsystem 110 eine Debug-Modus-Anforderung über den Link 140 an die E/A-Vorrichtung 150 übertragen. Die Debug-Steuerung 180 kann bestimmen, dass die Debug-Modus-Anforderung autorisiert ist (z. B. unter Verwendung kryptographischer Authentifizierung der Anforderung), und kann als Reaktion den Debug-Modus der E/A-Vorrichtung 150 entsperren. Ferner kann die Debug-Steuerung 180 eine Bestätigung des Entsperrens des Debug-Modus an das Hostsystem 110 übertragen. In einigen Ausführungsformen kann die Debug-Modus-Anforderung in einem ersten Debug-Paket 144 verkapselt sein. Ferner kann in manchen Ausführungsformen die Bestätigung in einem zweiten Debug-Paket 144 verkapselt sein.
Block 240 kann beinhalten, dass das Host-System bei Empfang der Bestätigung einen Befehls zum Debuggen der E/A-Vorrichtung erzeugt. Block 250 kann beinhalten, dass das Hostsystem den Befehl in einem Debug-Paket verkapselt und das Debug-Paket an die E/A-Vorrichtung sendet. Beispielsweise unter Bezugnahme auf 1A kann die Debug-Software 136 des Hostsystems 110 die Bestätigung von der E/A-Vorrichtung 150 über den Link 140 empfangen und kann einen Befehl zum Debuggen der E/A-Vorrichtung 150 erzeugen. Die Debug-Schnittstelle 134 kann den Befehl in einem Debug-Paket 144 verkapseln und kann das Debug-Paket 144 über den Link 140 an die E/A-Vorrichtung 150 übertragen.
Block 260 kann beinhalten, dass die E/A-Vorrichtung den Befehl aus dem durch das Hostsystem gesendeten Debug-Paket extrahiert. Block 270 kann beinhalten, dass die E/A-Vorrichtung den extrahierten Befehl ausführt, um eine Debug-Aktion in der E/A-Vorrichtung durchzuführen. Beispielsweise unter Bezugnahme auf 1A kann die Debug-Steuerung 180 das Debug-Paket 144 von dem Hostsystem 110 empfangen und den Befehl aus dem empfangenen Debug-Paket 144 extrahieren. Die Debug-Steuerung 180 kann den extrahierten Befehl ausführen, um eine Debug-Aktion in der E/A-Vorrichtung 150 durchzuführen.
Block 280 kann beinhalten, dass die E/A-Vorrichtung Ergebnisse der Debug-Aktion (d. h. vom Ausführen des Befehls) in einem Debug-Paket verkapselt und das Debug-Paket an das Hostsystem überträgt. Block 290 kann beinhalten, dass das Hostsystem die Ergebnisse aus dem von der E/A-Vorrichtung gesendeten Debug-Paket extrahiert. Beispielsweise unter Bezugnahme auf 1A kann die Debug-Steuerung 180 Daten bestimmen oder erhalten, die die Ergebnisse des Ausführens des Debug-Befehls angeben, die Ergebnisse in dem Debug-Paket 144 verkapseln und das Debug-Paket 144 über den Link 140 an das Hostsystem 110 übertragen. Ferner kann die Debug-Schnittstelle 134 das Debug-Paket 144 empfangen und die Debug-Ergebnisse aus dem Debug-Paket 144 extrahieren. In einigen Ausführungsformen kann die Debug-Software 136 die Ergebnisse verwenden, um die E/A-Vorrichtung 150 zu debuggen und/oder das kombinierte System einschließlich des Hostsystems 110 und der E/A-Vorrichtung 150 zu debuggen. Nach Block 290 ist das Verfahren 200 abgeschlossen.
FIG. 3A-3C - Beispielhafte Vorrichtungen
Nun unter Bezugnahme auf 3A-3C sind Blockdiagramme beispielhafter Vorrichtungen gezeigt, nämlich eines Universal-Serial-Bus-4(USB4)-Hosts 302, eines USB4-Host und einer USB4-Vorrichtung 306. Bei manchen Ausführungsformen können manche oder alle der beispielhaften Vorrichtungen 302, 304, 306 allgemein beispielhaften Implementierungen der Eingabe-Ausgabe(E/A)-Vorrichtung 150 (gezeigt in 1A) entsprechen.
In einigen Ausführungsformen kann der USB4-Host 302 einen Host-Router 310, eine interne Hoststeuerung und eine DisplayPort-Quelle 312 beinhalten. Die DisplayPort-Quelle 312 kann ein Grafikprozessor sein und kann einen DisplayPort-Sender (DPTX) beinhalten. Der USB4-Host 302 kann optional auch eine PCIe-Steuerung 314 enthalten. Die PCIe-Steuerung 314 kann einen PCIe-Root-Komplex oder PCIe-Switch-Komplex zum Steuern von PCIe-basiertem Routing zu einer oder mehreren Peripherievorrichtungen beinhalten (oder damit verbunden sein). Die PCIe-Steuerung 314 kann über einen oder mehrere PCIe-Adapter (z. B. PCIe-Downstream-Facing-Adapter 328, 330) mit dem USB4-Host-Router 310 verbunden sein.
In einigen Ausführungsformen kann der USB4-Hub 304 einen PCIe-Switch 344 über einen PCIe-Upstream-Facing-Adapter 354 und PCIe-Downstream-Facing-Adapter 356 und 358 beinhalten (oder damit verbunden sein). Die USB4-Vorrichtung 306 kann eine PCIe-Funktion 380 beinhalten, die die Downstream-verbundene PCIe-Komponente oder Endpunktvorrichtung ist, die mit der PCIe-Steuerung 314 kommunizieren kann (z. B. über ein USB4-Fabric). Der USB4-Vorrichtungsrouter 378 kann einen PCIe-Upstream-Facing-Adapter 390 beinhalten, um die PCIe-Funktion 380 mit Upstream-verbundenen Komponenten (z. B. USB4-Hub 304, PCIe-Switch 344 und PCIe-Steuerung 314) zu koppeln.
Bei manchen Ausführungsformen kann der USB4-Host 302 einen USB-Host-Router 310 beinhalten. Der USB4-Hub 304 kann einen USB-Hub-Router 342 beinhalten. Die USB4-Vorrichtung 306 kann einen USB-Vorrichtungsrouter 378 beinhalten. Ein Router ist ein Baustein der USB4-Architektur. Ein Router bildet getunnelten Protokollverkehr auf USB4-Pakete ab und routet Pakete durch ein USB4-Fabric. Ein Router verteilt und synchronisiert auch Zeit durch das USB4-Fabric über seine Zeitverwaltungseinheit (TMU: Time Management Unit), wie etwa TMLJ 340, 370 und 396. Ein Router wird durch einen Verbindungsmanager (z. B. einen Host-Schnittstellenadapter) 324 entdeckt und konfiguriert, der sich innerhalb des USB4-Hosts 302 befindet. Der Router beinhaltet einen flachen konfigurierbaren Punkt-zu-Punkt-Switch, der notwendig ist, um die internen Pfade zwischen Adaptern zu erzeugen. Ein Router existiert typischerweise innerhalb jeder Instanz eines USB4-Hosts 302, eines USB4-Hubs 304 oder einer USB4-Vorrichtung 306. Es gibt zwei Arten von Routern: Host-Router und Vorrichtungsrouter.
In einigen Ausführungsformen kann der USB4-Host 302 eine DisplayPort(DP)-Quelle 312, wie etwa eine Grafikverarbeitungseinheit (GPU) oder eine andere Quelle von Grafik, Video, Bildern usw., beinhalten (oder damit verbunden sein). Der USB4-Host-Router 310 kann einen DP IN-Adapter 326 beinhalten, der eine Schnittstelle zu der DP-Quelle 312 ermöglichen kann. In Ausführungsformen kann die DP-Quelle eine USB4-Peripherievorrichtung sein oder kann über eine DisplayPort-basierte Zwischenverbindung (z. B. über eine DisplayPort-Protokoll-Zwischenverbindung) mit dem USB4-Host-Router 310 verbunden sein.
Bei manchen Ausführungsformen kann der USB4-Hub 304 einen DPOUT-Adapter 352 zum Ausgeben von DP-Signalisierung an eine DP-Senke, wie etwa eine Anzeige oder einen Monitor, beinhalten. Der USB4-Hub 304 kann auch DP-Signalisierung über einen USB4-Tunnel zu der USB4-Vorrichtung 306 übertragen. Die USB4-Vorrichtung 306 kann einen DP_OUT-Adapter 392 zum Ausgeben von DP-Signalen an eine DP-Senke 382 beinhalten, die eine Anzeige oder ein Monitor sein kann.
Bei einigen Ausführungsformen kann der interne Enhanced-SuperSpeed-Host 316 einen oder mehrere Downstream-USB3-Ports offenlegen, die mit einem USB-Endpunkt oder Downstream-USB3-Protokolladapter verbunden sein können. Der Upstream-Port des internen Enhanced-SuperSpeed-Hubs ist über eine Schnittstelle mit einem Upstream-USB3-Protokolladapter verbunden, der Pakete an den Upstream-Facing-Port des USB4-Hubs 304 weiterleitet. Bei manchen Ausführungsformen kann jeder Router bis zu 64 Adapter enthalten. Adapter können eine Schnittstelle zwischen einem Router und einer externen Entität bereitstellen. Die Adapter können drei Typen umfassen: Protokolladapter, Spuradapter und Steueradapter. Ein Protokolladapter wird zum Übersetzen zwischen einem unterstützten nativen Protokoll und einem USB4-Tunnel verwendet. Es kann vier Typen von Protokolladaptern geben: USB3-Adapter 336, 338, 364, 366, 368 und 394, DisplayPort(DP)-Adapter 326, 352 und 392, PCIe-Adapter 328, 330, 354, 356, 358 und 390 und Host-Schnittstellenadapter 324. In einigen Ausführungsformen kann ein Router einen internen Steueradapter unterstützen, der ausschließlich zum Übertragen und Empfangen von Steuerpaketen zu und von der Transportschicht verwendet wird. Im Gegensatz zu den Nicht-Steueradaptern ist der Steueradapter nicht direkt mit einem Link verbunden und weist somit keine mit ihm assoziierte physikalische Schicht auf.
Bei einigen Ausführungsformen kann ein USB4-Port eine Entität sein, die die USB4-Funktionsschnittstelle bereitstellt, die sich an jedem Ende eines USB4-Links befindet. Sie kann Sende- und Empfangsspuren des USB4-Datenbusses zusammen mit einem Zweidraht-Seitenband(SB)-Kanal (SBTX/SBRX) beinhalten. Die USB4-Ports können entweder als einspuriger Link oder als doppelspuriger Link arbeiten. Wenn sie als ein einspuriger Link arbeiten, ist die Spur 1 des USB4-Ports deaktiviert. Wenn sie als ein doppelspuriger Link arbeiten, werden die Spuren 0 und 1 logisch miteinander gebunden, um einen einzigen Datenkanal bereitzustellen. Beispielhafte USB4-Ports sind als Elemente 332, 334, 360, 362 und 388 gezeigt. Die USB4-Ports können einen USB-Typ-C-Verbinder oder einen Thunderbolt(z. B. TBT3)-Typ-Verbinder usw. unterbringen. Zusätzlich zu der USB4-spezifischen Hub-Funktionalität wird USB-3.2- und USB-2.0-Hub-Funktionalität unterstützt, sodass Downstream-Facing-Ports eines USB4-Hubs Rückwärtskompatibilität mit USB-3.2- und USB-2.0-Vorrichtungen unterstützen können. Die USB-2.0-Funktionalität kann über den USB-2.0-Host 318 bereitgestellt werden, der mit einem USB-2.0-Hub 346 und einer USB-2.0-Funktion 384 verbunden ist.
Bei manchen Ausführungsformen können der USB4-Host 302, der USB4-Hub 304 und die USB4-Vorrichtung 306 jeweils einen oder mehrere USB-Typ-C-Verbinderports 320, 322, 372, 374, 376 und 398 beinhalten. Die USB-Typ-C-Verbinderports können USB-Typ-C-Verbinder für verbundene USB-konforme Komponenten und zum Transferieren von Informationen und Leistung zwischen Komponenten empfangen.
In einigen Ausführungsformen können der USB4-Host 302, der USB4-Hub 304 und die USB4-Vorrichtung 306 jeweils eine Debug-Steuervorrichtung 301 und eine assoziierte Leistungsdomäne 303 beinhalten. Die Debug-Steuerung 301 kann allgemein einer beispielhaften Implementierung der Debug-Steuerung 180 entsprechen (oben unter Bezugnahme auf 1A beschrieben). Zum Beispiel kann die Debug-Steuerung 301 ein Debug-Paket empfangen, das durch ein Hostsystem (z. B. das Hostsystem 110, das in 1A gezeigt ist) gesendet wird, einen verkapselten Befehl extrahieren und den Befehl ausführen. Die Debug-Steuerung 301 kann auch die Ergebnisse des Ausführens des Befehls erhalten, die Ergebnisse in einem Debug-Paket verkapseln und das Debug-Paket an ein Hostsystem übertragen. Wie in 3A-3B gezeigt, kann die Debug-Steuerung 301 mit verschiedenen Komponenten verbunden sein und kann ein Debugging der verschiedenen Komponenten (z. B. PCIe-Steuerung 314, Enhanced-SuperSpeed-Host 316, USB-2.0-Host 318, PCIe-Switch 344, PCIe-Funktion 380 und so weiter) durchführen.
Bei manchen Ausführungsformen kann die Leistungsdomäne 303 der assoziierten Debug-Steuerung 301 elektrische Leistung bereitstellen und kann unabhängig von der E/A-Vorrichtung 302, 304, 306 arbeiten. Die Leistungsdomäne 303 kann es zum Beispiel der Debug-Steuerung 301 ermöglichen, eingeschaltet zu bleiben und das Debuggen fortzusetzen, während die assoziierte E/A-Vorrichtung heruntergefahren wird (z. B. während eines Neustarts).
FIG. 4A-4B - Beispielhafte Systeme
Nun unter Bezugnahme auf 4A-4B sind Blockdiagramme beispielhafter Systeme 400, 405 gemäß manchen Ausführungsformen gezeigt. Insbesondere können die Systeme 400, 405 mehrere Vorrichtungen 410, 420, 430, 440 beinhalten, die in einer Reihen oder Verkettungsanordnung verbunden sind. Bei manchen Ausführungsformen kann das Hostsystem 410 allgemein einer beispielhaften Implementierung des Hostsystems 110 (gezeigt in 1A) entsprechen. Ferner können manche oder alle der Vorrichtungen 420, 430, 440 allgemein Beispielimplementierungen der Eingabe-Ausgabe(E/A)-Vorrichtung 150 (gezeigt in 1A) entsprechen.
Nun unter Bezugnahme auf 4A ist ein erstes beispielhaftes System 400 gezeigt, das ein Hostsystem 410, einen Host-Router 440, einen E/A-Hub 420 und eine E/A-Vorrichtung 430 beinhaltet. Wie gezeigt, kann das Hostsystem 410 E/A-Steuerungssoftware 132, Debug-Schnittstelle 134 und Debug-Software 136 (oben unter Bezugnahme auf 1A beschrieben) beinhalten. Ferner können der Host-Router 440, der E/A-Hub 420 und die E/A-Vorrichtung 430 jeweils eine E/A-Steuerung 162, eine Debug-Steuerung 180 und eine Debug-Leistungsdomäne 170 (oben unter Bezugnahme auf 1A beschrieben) beinhalten.
Wie gezeigt, können die Vorrichtungen 410, 420, 430, 440 bei manchen Ausführungsformen durch einen In-Band-Link verbunden sein. Ferner kann die In-Band-Verbindung verwendet werden, um E/A-Datenpakete 142 durch die verschiedenen E/A-Steuerungen 162 zu senden, weiterzuleiten oder zu empfangen. Der In-Band-Link kann auch verwendet werden, um Debug-Pakete 144 durch die verschiedenen Debug-Steuerungen 180 zu senden, weiterzuleiten oder zu empfangen. Zum Beispiel kann das Hostsystem 410 ein erstes Debug-Paket 144 übertragen, um die E/A-Vorrichtung 430 zu debuggen. In einigen Ausführungsformen kann das erste Debug-Paket 144 an die E/A-Vorrichtung 430 adressiert sein. Dementsprechend kann das erste Debug-Paket 144 durch den Host-Router 440 und den E/A-Hub 420 an die E/A-Vorrichtung 430 weitergeleitet werden. In einem anderen Beispiel kann das Hostsystem 410 ein zweites Debug-Paket 144 übertragen, um den Host-Router 440 zu debuggen, und daher kann das zweite Debug-Paket 144 an den Host-Router 440 adressiert sein. In noch einem anderen Beispiel kann das Hostsystem 410 ein drittes Debug-Paket 144 übertragen, um den gesamten Link-Pfad einschließlich jeder der Vorrichtungen 420, 430, 440 zu debuggen. In noch einem anderen Beispiel kann das Hostsystem 410 andere Debug-Pakete 144 empfangen, die Ergebnisse von Debug-Aktionen beinhalten, die an einer beliebigen der Vorrichtung 420, 430, 440 durchgeführt werden.
Nun unter Bezugnahme auf 4B ist ein zweites beispielhaftes System 405 gemäß anderen Ausführungsformen gezeigt. Es sei angemerkt, dass in dem in 4B gezeigten Beispiel das Hostsystem 411 die E/A-Steuerungssoftware 132, die Debug-Schnittstelle 134 und die Debug-Software 136 beinhaltet. Ferner können der E/A-Hub 420 und die E/A-Vorrichtung 430 jeweils eine E/A-Steuerung 162, eine Debug-Steuerung 180 und eine Debug-Leistungsdomäne 170 beinhalten. Es sei angemerkt, dass das System 405 den Host-Router 440 (oben unter Bezugnahme auf 4A beschrieben) nicht beinhaltet. Stattdessen kann in dem in 4B gezeigten System 405 das Hostsystem 411 einen integrierten Host-Router 450 beinhalten. Wie gezeigt, kann der integrierte Host-Router 450 eine E/A-Steuerung 162, eine Debug-Steuerung 180 und eine Debug-Leistungsdomäne 170 beinhalten. Bei manchen Ausführungsformen kann das Hostsystem 411 eine System-on-Chip(SoC)-Vorrichtung sein. Ferner kann die Debug-Software 136 ein Debugging des integrierten Host-Routers 450 durchführen, der in demselben Hostsystem 411 enthalten ist.
FIG. 5 - Beispielhaftes Verfahren
Nun unter Bezugnahme auf 5 ist ein Flussdiagramm eines Verfahrens 500 gemäß einer oder mehreren Ausführungsformen gezeigt. Bei verschiedenen Ausführungsformen kann das Verfahren 500 durch Verarbeitungslogik (z. B. Debug-Steuerung 180 und/oder Debug-Funktion 185, die in 1A bis 1B gezeigt sind) durchgeführt werden, die Hardware (z. B. Verarbeitungsvorrichtung, Schaltungsanordnung, dedizierte Logik, programmierbare Logik, Mikrocode usw.), Software und/oder Firmware (z. B. auf einer Verarbeitungsvorrichtung ausgeführte Anweisungen) oder eine Kombination davon beinhalten kann. In Firmware- oder Softwareausführungsformen kann das Verfahren 500 durch computerausgeführte Anweisungen implementiert werden, die in einem nichtflüchtigen maschinenlesbaren Medium, wie etwa einer optischen, Halbleiter- oder magnetischen Speichervorrichtung, gespeichert sind. Das maschinenlesbare Medium kann Daten speichern, die bei Verwendung durch mindestens eine Maschine bewirken, dass die mindestens eine Maschine mindestens eine integrierte Schaltung zum Durchführen eines Verfahrens herstellt.
Block 510 kann das Empfangen, durch eine Eingabe-Ausgabe(E/A)-Vorrichtung, eines Debug-Pakets von einem Hostsystem über eine In-Band-Verbindung beinhalten, wobei die E/A-Vorrichtung eine E/A-Steuerung und eine Debug-Steuerung umfasst. Block 520 kann das Verarbeiten, durch die Debug-Steuerung, des Debug-Pakets beinhalten, um einen durch das Hostsystem erzeugten Befehl zu extrahieren, beinhalten. Block 530 kann das Ausführen, durch die Debug-Steuerung, des extrahierten Befehls zum Debuggen der E/A-Vorrichtung beinhalten. Nach Block 530 ist das Verfahren 500 abgeschlossen. Beispielsweise unter Bezugnahme auf 1A kann die Debug-Steuerung 180 ein Debug-Paket 144 von dem Hostsystem 110 empfangen und einen Befehl aus dem empfangenen Debug-Paket 144 extrahieren. Die Debug-Steuerung 180 kann den extrahierten Befehl ausführen, um eine Debug-Aktion in der E/A-Vorrichtung 150 durchzuführen. In einigen Ausführungsformen kann die Debug-Software 136 des Hostsystems 110 den Befehl erzeugen, und die Debug-Schnittstelle 134 kann den Befehl in dem Debug-Paket 144 verkapseln.
FIG. 6 - Beispielhaftes Verfahren
Nun unter Bezugnahme auf 6 ist ein Flussdiagramm eines Verfahrens 600 gemäß einer oder mehreren Ausführungsformen gezeigt. Bei verschiedenen Ausführungsformen kann das Verfahren 600 durch Verarbeitungslogik (z. B. Prozessor 130, Debug-Schnittstelle 134 und/oder Debug-Software 136, die in 1A gezeigt sind) durchgeführt werden, die Hardware (z. B. Verarbeitungsvorrichtung, Schaltungsanordnung, dedizierte Logik, programmierbare Logik, Mikrocode usw.), Software und/oder Firmware (z. B. auf einer Verarbeitungsvorrichtung ausgeführte Anweisungen) oder eine Kombination davon beinhalten kann. In Firmware- oder Softwareausführungsformen kann das Verfahren 600 durch computerausgeführte Anweisungen implementiert werden, die in einem nichtflüchtigen maschinenlesbaren Medium, wie etwa einer optischen, Halbleiter- oder magnetischen Speichervorrichtung, gespeichert sind. Das maschinenlesbare Medium kann Daten speichern, die bei Verwendung durch mindestens eine Maschine bewirken, dass die mindestens eine Maschine mindestens eine integrierte Schaltung zum Durchführen eines Verfahrens herstellt.
Block 610 kann das Erzeugen, durch ein Hostsystem, eines Befehls zum Debuggen einer Eingabe-Ausgabe(E/A)-Vorrichtung, die mit dem Hostsystem gekoppelt ist, beinhalten. Block 620 kann das Verkapseln, durch das Hostsystem, des Befehls in einem ersten Debug-Paket beinhalten. Block 630 kann das Übertragen, durch das Hostsystem, des ersten Debug-Pakets über eine In-Band-Verbindung an die E/A-Vorrichtung beinhalten. Beispielsweise unter Bezugnahme auf 1A kann die Debug-Software 136 des Hostsystems 110 einen Befehl zum Debuggen der E/A-Vorrichtung 150 erzeugen. Die Debug-Schnittstelle 134 kann den Befehl in einem Debug-Paket 144 verkapseln und kann das Debug-Paket 144 über den Link 140 an die E/A-Vorrichtung 150 übertragen.
Block 640 kann das Empfangen, durch das Hostsystem, eines zweiten Debug-Pakets von der E/A-Vorrichtung über die In-Band-Verbindung beinhalten. Block 650 kann das Extrahieren, durch das Hostsystem, eines Debug-Ergebnisses aus dem zweiten Debug-Paket beinhalten, wobei das Debug-Ergebnis durch die E/A-Vorrichtung bei Ausführung des Befehls erzeugt wird. Nach Block 650 ist das Verfahren 600 abgeschlossen. Beispielsweise unter Bezugnahme auf 1A kann die Debug-Steuerung 180 das Debug-Paket 144 von dem Hostsystem 110 empfangen und den Befehl aus dem empfangenen Debug-Paket 144 extrahieren. Die Debug-Steuerung 180 kann den extrahierten Befehl ausführen, um eine Debug-Aktion in der E/A-Vorrichtung 150 durchzuführen.
FIG. 7 - Beispielhaftes System
In 7 ist nunmehr ein Blockdiagramm eines Systems gemäß einer anderen Ausführungsform, wie etwa einer Edge-Plattform, gezeigt. Wie in 7 gezeigt ist, beinhaltet das Multiprozessorsystem 700 einen ersten Prozessor 770 und einen zweiten Prozessor 780, die über eine Zwischenverbindung 750 gekoppelt sind, die bei einer Ausführungsform eine optische Zwischenverbindung sein kann, die mit einer optischen Schaltungsanordnung (die in Prozessoren 770 enthalten oder mit diesen gekoppelt sein kann) kommuniziert. Wie in 7 gezeigt, kann jeder der Prozessoren 770 und 780 ein Prozessor mit vielen Kernen sein, einschließlich repräsentativer erster und zweiter Prozessorkerne (d. h. Prozessorkerne 774a und 774b und Prozessorkerne 784a und 784b).
Bei der Ausführungsform von 7 beinhalten die Prozessoren 770 und 780 ferner Punkt-zu-Punkt-Zwischenverbindungen 777 und 787, die über die Zwischenverbindungen 742 und 744 (die CXL-Busse sein können) mit den Schaltern 759 und 760 gekoppelt sind. Im Gegenzug sind die Switches 759, 760 mit gepoolten Speichern 755 und 765 gekoppelt.
Immer noch unter Bezugnahme auf 7 beinhaltet der erste Prozessor 770 einen Speichersteuerung-Hub (MCH) 772 und Punkt-zu-Punkt(P-P)-Schnittstellen 776 und 778. Gleichermaßen beinhaltet der zweite Prozessor 780 einen MCH 782 und P-P-Schnittstellen 786 und 788. Wie in 7 gezeigt, koppeln MCHs 772 und 782 die Prozessoren mit jeweiligen Speichern, nämlich einem Speicher 732 und einem Speicher 734, die Teile des Systemspeichers (z. B. DRAM) sein können, die lokal mit den jeweiligen Prozessoren verbunden sind. Der erste Prozessor 770 und der zweite Prozessor 780 können über die P-P-Zwischenverbindungen 776 und 786 jeweils mit einem Chipsatz 790 gekoppelt sein. Wie in 7 gezeigt, beinhaltet der Chipsatz 790 die P-P-Schnittstellen 794 und 798.
Des Weiteren beinhaltet der Chipsatz 790 eine Schnittstelle 792 zum Koppeln des Chipsatzes 790 mit einer Hochleistungsgrafikmaschine 738 über eine P-P-Zwischenverbindung 739. Wie in 7 gezeigt ist, können verschiedene Eingabe/Ausgabe(E/A)-Vorrichtungen 714 mit dem ersten Bus 716 gekoppelt sein, zusammen mit einer Busbrücke 718, die den ersten Bus 716 mit einem zweiten Bus 720 koppelt. Verschiedene Vorrichtungen können bei einer Ausführungsform mit dem zweiten Bus 720 gekoppelt sein, einschließlich zum Beispiel einer Tastatur/Maus 722, Kommunikationsvorrichtungen 726 und einer Datenspeicherungseinheit 728, wie etwa einem Plattenlaufwerk oder einer anderen Massenspeicherungsvorrichtung, die Code 730 beinhalten kann. Ferner kann mit dem zweiten Bus 720 eine Audio-E/A 724 gekoppelt sein.
FIG. 8 - Beispielhaftes Speichermedium
Gemäß 8 ist ein Speicherungsmedium 800 gezeigt, auf dem ausführbare Anweisungen 810 gespeichert sind. In einigen Ausführungsformen kann das Speicherungsmedium 800 ein nichtflüchtiges maschinenlesbares Medium sein, wie etwa ein optisches Medium, ein Halbleiter, eine magnetische Speicherungsvorrichtung und so weiter. Die ausführbaren Anweisungen 810 können durch eine Verarbeitungsvorrichtung ausführbar sein. Ferner können die ausführbaren Anweisungen 810 von mindestens einer Maschine verwendet werden, um mindestens eine integrierte Schaltung herzustellen, um eine/s oder mehrere der in 1-6 dargestellten Verfahren und/oder Operationen durchzuführen.
Die folgenden Abschnitte und/oder Beispiele betreffen weitere Ausführungsformen:
In Beispiel 1 beinhaltet eine Eingabe-Ausgabe(E/A)-Vorrichtung zum Debuggen eine E/A-Steuerung, die mit einer Debug-Steuerung gekoppelt ist. Die E/A-Steuerung dient zum Verarbeiten von E/A-Datenpaketen. Die Debug-Steuerung dient zum: Empfangen eines ersten Debug-Pakets von einem Hostsystem über eine In-Band-Verbindung; Verarbeiten des ersten Debug-Pakets, um einen durch das Hostsystem erzeugten Befehl zu extrahieren; und Ausführen des extrahierten Befehls zum Debuggen der E/A-Vorrichtung.
In Beispiel 2 kann der Gegenstand von Beispiel 1 optional beinhalten, dass die Debug-Steuerung zu Folgendem dient: Erhalten eines Debug-Ergebnisses aus einer Ausführung des extrahierten Befehls; Verkapseln des Debug-Ergebnisses in ein zweites Debug-Paket; und Übertragen des zweiten Debug-Pakets an das Hostsystem.
In Beispiel 3 kann der Gegenstand der Beispiele 1-2 optional beinhalten, dass die Debug-Steuerung vor einem Empfang des ersten Debug-Pakets zu Folgendem dient: Empfangen einer Debug-Anforderung von dem Hostsystem; Bestimmen, ob die Debug-Anforderung autorisiert ist; und als Reaktion auf eine Bestimmung, dass die Debug-Anforderung autorisiert ist, Entsperren eines Debug-Modus der E/A-Vorrichtung und Übertragen einer Bestätigung der Debug-Anforderung an das Hostsystem.
In Beispiel 4 kann der Gegenstand der Beispiele 1-3 optional beinhalten, dass die Debug-Anforderung ein sicheres Token umfasst, um einen Debug-Typ und einen Debug-Grad anzugeben, und dass das Hostsystem das erste Debug-Paket als Reaktion auf einen Empfang der Bestätigung von der E/A-Vorrichtung erzeugt.
In Beispiel 5 kann der Gegenstand der Beispiele 1-4 optional Folgendes beinhalten: eine erste Leistungsdomäne, um der E/A-Steuerung elektrische Leistung bereitzustellen; und eine zweite Leistungsdomäne, um der Debug-Steuerung elektrische Leistung bereitzustellen, wobei die zweite Leistungsdomäne eingeschaltet bleibt, wenn die erste Leistungsdomäne nicht eingeschaltet ist.
In Beispiel 6 kann der Gegenstand der Beispiele 1-5 optional beinhalten, dass die E/A-Vorrichtung eine aus einem Universal-Serial-Bus(USB)-Host, einem USB-Hub und einer USB-Vorrichtung ausgewählte ist.
In Beispiel 7 kann der Gegenstand der Beispiele 1-6 optional beinhalten, dass die Debug-Steuerung den extrahierten Befehl ausführt, um eine Ausführung der E/A-Steuerung zu pausieren.
In Beispiel 8 kann der Gegenstand der Beispiele 1-7 optional einen In-Band-Port zum Übertragen mehrerer E/A-Datenpakete und mehrerer Debug-Pakete beinhalten.
In Beispiel 9 kann der Gegenstand der Beispiele 1-8 optional mindestens eine zusätzliche Komponente beinhalten, wobei die Debug-Steuerung den extrahierten Befehl ausführt, um die mindestens eine zusätzliche Komponente zu debuggen.
In Beispiel 10 kann ein Verfahren zum Debuggen Folgendes beinhalten: Empfangen, durch eine Eingabe-Ausgabe(E/A)-Vorrichtung, eines ersten Debug-Pakets von einem Hostsystem über eine In-Band-Verbindung, wobei die E/A-Vorrichtung eine E/A-Steuerung und eine Debug-Steuerung umfasst; Verarbeiten, durch die Debug-Steuerung, des ersten Debug-Pakets, um einen durch das Hostsystem erzeugten Befehl zu extrahieren; und Ausführen, durch die Debug-Steuerung, des extrahierten Befehls, um die E/A-Vorrichtung zu debuggen.
In Beispiel 11 kann der Gegenstand von Beispiel 10 optional Folgendes beinhalten: Erhalten, durch die Debug-Steuerung, eines Debug-Ergebnisses aus einer Ausführung des extrahierten Befehls; Verkapseln, durch die Debug-Steuerung, der Debug-Ergebnisse in einem zweiten Debug-Paket; und Übertragen, durch die Debug-Steuerung, des zweiten Debug-Pakets an das Hostsystem.
In Beispiel 12 kann der Gegenstand der Beispiele 10-11 vor einem Empfang des ersten Debug-Pakets optional Folgendes beinhalten: Empfangen, durch die Debug-Steuerung, einer Debug-Anforderung von dem Hostsystem; Bestimmen, durch die Debug-Steuerung, ob die Debug-Anforderung autorisiert ist; und als Reaktion auf eine Bestimmung, dass die Debug-Anforderung autorisiert ist: Entsperren, durch die Debug-Steuerung, eines Debug-Modus der E/A-Vorrichtung; und Übertragen, durch die Debug-Steuerung, einer Bestätigung der Debug-Anforderung an das Hostsystem.
In Beispiel 13 kann der Gegenstand der Beispiele 10-12 optional Folgendes beinhalten: Empfangen, durch das Hostsystem von der Debug-Steuerung, der Bestätigung der Debug-Anforderung; Erzeugen, durch das Hostsystem, des Befehls als Reaktion auf einen Empfang der Bestätigung; und Verkapseln, durch das Hostsystem, des Befehls des ersten Debug-Pakets als Reaktion auf einen Empfang der Bestätigung.
In Beispiel 14 kann der Gegenstand der Beispiele 10-13 optional Folgendes beinhalten: Verarbeiten, durch die E/A-Steuerung der E/A-Vorrichtung, mehrerer E/A-Datenpakete; Verarbeiten, durch die Debug-Steuerung der E/A-Vorrichtung, mehrerer Debug-Pakete; und Übertragen der mehreren E/A-Datenpakete und der mehreren Debug-Paketen unter Verwendung eines In-Band-Ports der E/A-Vorrichtung.
In Beispiel 15 kann der Gegenstand der Beispiele 10-14 optional beinhalten, dass das Ausführen des extrahierten Befehls durch die Debug-Steuerung Pausieren einer Ausführung der E/A-Steuerung umfasst.
In Beispiel 16 kann eine Datenverarbeitungsvorrichtung einen oder mehrere Prozessoren und einen Speicher mit mehreren darin gespeicherten Anweisungen beinhalten, die bei Ausführung durch den einen oder die mehreren Prozessoren bewirken, dass die Datenverarbeitungsvorrichtung das Verfahren nach einem der Beispiele 10 bis 15 durchführt.
In Beispiel 17 kann ein maschinenlesbares Medium darauf gespeicherte Daten aufweisen, die bei Verwendung durch mindestens eine Maschine bewirken, dass die mindestens eine Maschine mindestens eine integrierte Schaltung zum Durchführen eines Verfahrens nach einem der Beispiele 10 bis 15 herstellt.
In Beispiel 18 kann eine elektronische Vorrichtung Mittel zum Durchführen des Verfahrens nach einem der Beispiele 10 bis 15 beinhalten.
In Beispiel 19 kann ein System zum Debuggen ein Hostsystem und eine Eingabe-Ausgabe(E/A)-Vorrichtung beinhalten. Die E/A-Vorrichtung kann Folgendes beinhalten: eine E/A-Steuerung zum Verarbeiten von E/A-Datenpaketen und eine Debug-Steuerung, die mit der E/A-Steuerung gekoppelt ist. Die Debug-Steuerung kann dienen zum Empfangen eines ersten Debug-Pakets von einem Hostsystem über eine In-Band-Verbindung, Verarbeiten des ersten Debug-Pakets, um einen durch das Hostsystem erzeugten Befehl zu extrahieren, und Ausführen des extrahierten Befehls zum Debuggen der E/A-Vorrichtung.
In Beispiel 20 kann der Gegenstand von Beispiel 19 optional beinhalten, dass die Debug-Steuerung zu Folgendem dient: Erhalten eines Debug-Ergebnisses aus einer Ausführung des extrahierten Befehls; Verkapseln des Debug-Ergebnisses in ein zweites Debug-Paket; und Übertragen des zweiten Debug-Pakets an das Hostsystem.
In Beispiel 21 kann der Gegenstand der Beispiele 19-20 optional beinhalten, dass die Debug-Steuerung vor einem Empfang des ersten Debug-Pakets zu Folgendem dient: Empfangen einer Debug-Anforderung von dem Hostsystem; Bestimmen, ob die Debug-Anforderung autorisiert ist; und als Reaktion auf eine Bestimmung, dass die Debug-Anforderung autorisiert ist; Entsperren eines Debug-Modus der E/A-Vorrichtung; und Übertragen einer Bestätigung der Debug-Anforderung an das Hostsystem.
In Beispiel 22 kann der Gegenstand der Beispiele 19-21 optional beinhalten, dass die Debug-Anforderung ein sicheres Token umfasst, um einen Debug-Typ und einen Debug-Grad anzugeben, und dass das Hostsystem das erste Debug-Paket als Reaktion auf einen Empfang der Bestätigung von der E/A-Vorrichtung erzeugt.
In Beispiel 23 kann der Gegenstand der Beispiele 19-22 optional beinhalten, dass die E/A-Vorrichtung eine erste Leistungsdomäne, um der E/A-Steuerung elektrische Leistung bereitzustellen; und eine zweite Leistungsdomäne, um der Debug-Steuerung elektrische Leistung bereitzustellen, beinhaltet, wobei die zweite Leistungsdomäne eingeschaltet bleibt, wenn die erste Leistungsdomäne nicht eingeschaltet ist.
In Beispiel 24 kann eine Einrichtung zum Debuggen Folgendes beinhalten: Mittel zum Empfangen, durch eine Eingabe-Ausgabe(E/A)-Vorrichtung, eines ersten Debug-Pakets von einem Hostsystem über eine In-Band-Verbindung, wobei die E/A-Vorrichtung eine E/A-Steuerung und eine Debug-Steuerung umfasst; Mittel zum Verarbeiten des ersten Debug-Pakets, um einen durch das Hostsystem erzeugten Befehl zu extrahieren; und Mittel zum Ausführen des extrahierten Befehls, um die E/A-Vorrichtung zu debuggen.
In Beispiel 25 kann der Gegenstand von Beispiel 24 optional Folgendes: Mittel zum Erhalten eines Debug-Ergebnisses aus einer Ausführung des extrahierten Befehls; Mittel zum Verkapseln der Debug-Ergebnisse in ein zweites Debug-Paket; und Mittel zum Übertragen des zweiten Debug-Pakets von der Debug-Steuerung an das Hostsystem.
In Beispiel 26 kann der Gegenstand der Beispiele 24-25 optional Folgendes beinhalten: Mittel zum Empfangen einer Debug-Anforderung von dem Hostsystem; Mittel zum Bestimmen, ob die Debug-Anforderung autorisiert ist; und Mittel zum, als Reaktion auf eine Bestimmung, dass die Debug-Anforderung autorisiert ist: Entsperren eines Debug-Modus der E/A-Vorrichtung; und Übertragen einer Bestätigung der Debug-Anforderung an das Hostsystem.
In Beispiel 27 kann der Gegenstand der Beispiele 24-26 optional Folgendes beinhalten: Mittel zum Empfangen der Bestätigung der Debug-Anforderung; Mittel zum Erzeugen des Befehls als Reaktion auf einen Empfang der Bestätigung; und Mittel zum Verkapseln des Befehls des ersten Debug-Pakets als Reaktion auf einen Empfang der Bestätigung.
In Beispiel 28 kann der Gegenstand der Beispiele 24-27 optional Folgendes beinhalten: Mittel zum Verarbeiten mehrerer E/A-Datenpakete; Mittel zum Verarbeiten mehrerer Debug-Pakete; und Mittel zum Übertragen der mehreren E/A-Datenpakete und der mehreren Debug-Pakete unter Verwendung eines In-Band-Ports der E/A-Vorrichtung.
In Beispiel 29 kann der Gegenstand der Beispiele 24-28 optional beinhalten, dass das Mittel zum Ausführen des extrahierten Befehls durch die Debug-Steuerung Mittel zum Pausieren einer Ausführung der E/A-Steuerung umfasst.
In einigen hierin beschriebenen Ausführungsformen kann eine E/A-Vorrichtung eine Debug-Steuerung zum Empfangen von Debug-Paketen einschließlich Debug-Befehlen von einem Hostsystem über eine In-Band-Verbindung beinhalten. Die Debug-Steuerung kann den Befehl aus dem empfangenen Paket extrahieren und kann dann den Befehl ausführen, um Debug-Aktionen in der E/A-Vorrichtung durchzuführen. Die Debug-Steuerung kann die Ergebnisse des ausgeführten Befehls erhalten, die Ergebnisse in einem anderen Debug-Paket verkapseln und das Debug-Paket über die In-Band-Verbindung zu dem Hostsystem übertragen. Bei Empfang des Debug-Pakets kann das Hostsystem die Ergebnisse aus dem Debug-Paket extrahieren und kann die Ergebnisse in dem Debugging-Prozess verwenden. Auf diese Weise können einige Ausführungsformen In-Band-Debugging von E/A-Vorrichtungen bereitstellen, das Laufzeitsteuerungsfähigkeiten aufweist. Dementsprechend können eine oder mehrere Ausführungsformen erweiterte Debug-Aktionen durchführen, ohne separate Out-of-Band-Verbindungen oder Vorrichtungsmodifikationen zu erfordern, und können daher die mit dem Debuggen von E/A-Vorrichtungen assoziierten Kosten und Komplexität reduzieren.
Es sei angemerkt, dass 1-8 zwar verschiedene beispielhafte Implementierungen zeigen, aber auch andere Varianten möglich sind. Zum Beispiel dienen die in 1-8 gezeigten Beispiele nur der Veranschaulichung und sind nicht dazu gedacht, irgendwelche Ausführungsformen einzuschränken. Insbesondere können, obgleich Ausführungsformen der Klarheit halber in vereinfachter Form gezeigt sein können, Ausführungsformen eine beliebige Anzahl und/oder Anordnung von Komponenten beinhalten. Es ist beispielsweise denkbar, dass einige Ausführungsformen eine beliebige Anzahl von Komponenten zusätzlich zu den gezeigten beinhalten und dass bei bestimmten Implementierungen eine unterschiedliche Anordnung der gezeigten Komponenten auftreten kann. Darüber hinaus wird in Betracht gezogen, dass die Besonderheiten der in 1-8 an jeder Stelle in einer oder mehreren Ausführungsformen verwendet werden können.
Es versteht sich, dass verschiedene Kombinationen der obigen Beispiele möglich sind. Ausführungsformen können in vielen unterschiedlichen Typen von Systemen verwendet werden. In einer Ausführungsform kann zum Beispiel eine Kommunikationsvorrichtung angeordnet sein, um die verschiedenen hierin beschriebenen Verfahren und Techniken durchzuführen. Natürlich ist der Schutzumfang der vorliegenden Erfindung nicht auf eine Kommunikationsvorrichtung beschränkt und stattdessen können andere Ausführungsformen andere Arten von Einrichtungen zum Verarbeiten von Anweisungen oder ein oder mehrere maschinenlesbare Medien einschließlich Anweisungen, die als Reaktion darauf, dass sie auf einer Rechenvorrichtung ausgeführt werden, bewirken, dass die Vorrichtung eines bzw. eine oder mehrere der hier beschriebenen Verfahren und Techniken ausführt, betreffen.
In dieser Patentschrift bedeuten Bezugnahmen auf „eine Ausführungsform“, dass ein spezielles Merkmal, eine spezielle Struktur oder eine spezielle Charakteristik, das bzw. die in Verbindung mit der Ausführungsform beschrieben wird, in mindestens einer innerhalb der vorliegenden Erfindung eingeschlossenen Implementierung enthalten ist. Daher bezieht sich die Formulierung „eine Ausführungsform“ oder „in einer Ausführungsform“ nicht notwendigerweise auf dieselbe Ausführungsform. Ferner können die bestimmten Merkmale, Strukturen oder Charakteristika in anderen geeigneten Formen als in der bestimmten Ausführungsform dargestellt eingerichtet sein, und alle solchen Formen können in die Ansprüche der vorliegenden Anmeldung eingeschlossen sein.
Während die vorliegende Erfindung im Hinblick auf eine beschränkte Anzahl von Ausführungsformen beschrieben wurde, sind für Fachleute zahlreiche Modifikationen und Variationen davon ersichtlich. Die beigefügten Ansprüche sollen alle diese Abwandlungen und Variationen, die dem wahren Geist und Schutzumfang dieser vorliegenden Erfindung entsprechen, abdecken.

Claims

Eingabe-Ausgabe(E/A)-Vorrichtung, die Folgendes umfasst: eine E/A-Steuerung zum Verarbeiten von E/A-Datenpaketen; und eine Debug-Steuerung, die mit der E/A-Steuerung gekoppelt ist, wobei die Debug-Steuerung zu Folgendem dient: Empfangen eines ersten Debug-Pakets von einem Hostsystem über eine In-Band-Verbindung; Verarbeiten des ersten Debug-Pakets, um einen durch das Hostsystem erzeugten Befehl zu extrahieren; und Ausführen des extrahierten Befehls zum Debuggen der E/A-Vorrichtung.
E/A-Vorrichtung nach Anspruch 1, wobei die Debug-Steuerung zu Folgendem dient: Erhalten eines Debug-Ergebnisses aus einer Ausführung des extrahierten Befehls; Verkapseln des Debug-Ergebnisses in einem zweiten Debug-Paket; und Übertragen des zweiten Debug-Pakets an das Hostsystem.
E/A-Vorrichtung nach Anspruch 1, wobei die Debug-Steuerung vor einem Empfang des ersten Debug-Pakets zu Folgendem dient: Empfangen einer Debug-Anforderung von dem Hostsystem; Bestimmen, ob die Debug-Anforderung autorisiert ist; und als Reaktion auf eine Bestimmung, dass die Debug-Anforderung autorisiert ist: Entsperren eines Debug-Modus der E/A-Vorrichtung; und Übertragen einer Bestätigung der Debug-Anforderung an das Hostsystem.
E/A-Vorrichtung nach Anspruch 3, wobei die Debug-Anforderung ein sicheres Token umfasst, um einen Debug-Typ und einen Debug-Grad anzugeben, und wobei das Hostsystem das erste Debug-Paket als Reaktion auf einen Empfang der Bestätigung von der E/A-Vorrichtung erzeugt.
E/A-Vorrichtung nach Anspruch 1, die ferner Folgendes umfasst: eine erste Leistungsdomäne, um der E/A-Steuerung elektrische Leistung bereitzustellen; und eine zweite Leistungsdomäne, um der Debug-Steuerung elektrische Leistung bereitzustellen, wobei die zweite Leistungsdomäne eingeschaltet bleibt, wenn die erste Leistungsdomäne ausgeschaltet ist.
E/A-Vorrichtung nach Anspruch 1, wobei die E/A-Vorrichtung eine aus einem Universal-Serial-Bus(USB)-Host, einem USB-Hub und einer USB-Vorrichtung ausgewählte ist.
E/A-Vorrichtung nach Anspruch 1, wobei die Debug-Steuerung den extrahierten Befehl ausführt, um eine Ausführung der E/A-Steuerung zu pausieren.
E/A-Vorrichtung nach Anspruch 1, die ferner einen In-Band-Port zum Übertragen mehrerer E/A-Datenpakete und mehrerer Debug-Pakete umfasst.
E/A-Vorrichtung nach Anspruch 1, die ferner mindestens eine zusätzliche Komponente umfasst, wobei die Debug-Steuerung den extrahierten Befehl ausführt, um die mindestens eine zusätzliche Komponente zu debuggen.
Verfahren, das Folgendes umfasst: Empfangen, durch eine Eingabe-Ausgabe(E/A)-Vorrichtung, eines ersten Debug-Pakets von einem Hostsystem über eine In-Band-Verbindung, wobei die E/A-Vorrichtung eine E/A-Steuerung und eine Debug-Steuerung umfasst. Verarbeiten, durch die Debug-Steuerung, des ersten Debug-Pakets, um einen durch das Hostsystem erzeugten Befehl zu extrahieren; und Ausführen, durch die Debug-Steuerung, des extrahierten Befehls, um die E/A-Vorrichtung zu debuggen.
Verfahren nach Anspruch 10, das Folgendes umfasst: Erhalten, durch die Debug-Steuerung, eines Debug-Ergebnisses aus einer Ausführung des extrahierten Befehls; Verkapseln, durch die Debug-Steuerung, der Debug-Ergebnisse in einem zweiten Debug-Paket; und Übertragen, durch die Debug-Steuerung, des zweiten Debug-Pakets an das Hostsystem.
Verfahren nach Anspruch 10, das vor einem Empfang des ersten Debug-Pakets Folgendes umfasst: Empfangen, durch die Debug-Steuerung, einer Debug-Anforderung von dem Hostsystem; Bestimmen durch die Debug-Steuerung, ob die Debug-Anforderung autorisiert ist; und als Reaktion auf eine Bestimmung, dass die Debug-Anforderung autorisiert ist: Entsperren, durch die Debug-Steuerung, eines Debug-Modus der E/A-Vorrichtung; und Übertragen, durch die Debug-Steuerung, einer Bestätigung der Debug-Anforderung an das Hostsystem.
Verfahren nach Anspruch 12, das Folgendes umfasst: Empfangen, durch das Hostsystem von der Debug-Steuerung, der Bestätigung der Debug-Anforderung; Erzeugen, durch das Hostsystem, des Befehls als Reaktion auf einen Empfang der Bestätigung; und Verkapseln, durch das Hostsystem, des Befehls des ersten Debug-Pakets als Reaktion auf einen Empfang der Bestätigung.
Verfahren nach Anspruch 10, das Folgendes umfasst: Verarbeiten, durch die E/A-Steuerung der E/A-Vorrichtung, mehrerer E/A-Datenpakete ; Verarbeiten, durch die Debug-Steuerung der E/A-Vorrichtung, mehrerer Debug-Pakete; und Übertragen der mehreren E/A-Datenpakete und der mehreren Debug-Pakete unter Verwendung eines In-Band-Ports der E/A-Vorrichtung.
Verfahren nach Anspruch 10, wobei das Ausführen des extrahierten Befehls durch die Debug-Steuerung Pausieren einer Ausführung der E/A-Steuerung umfasst.
Datenverarbeitungsvorrichtung, die Folgendes umfasst: einen oder mehrere Prozessoren und einen Speicher, in dem mehrere Anweisungen gespeichert sind, die bei Ausführung durch den einen oder die mehreren Prozessoren bewirken, dass die Datenverarbeitungsvorrichtung das Verfahren nach einem der Ansprüche 10 bis 15 ausführt.
Maschinenlesbares Medium, auf dem Daten gespeichert sind, die bei Verwendung durch mindestens eine Maschine bewirken, dass die mindestens eine Maschine mindestens eine integrierte Schaltung zum Durchführen eines Verfahrens nach einem der Ansprüche 10 bis 15 herstellt.
Elektronische Vorrichtung, die Mittel zur Durchführung des Verfahrens nach einem der Ansprüche 10 bis 15 umfasst.
System, das Folgendes umfasst: ein Hostsystem; und eine Eingabe-Ausgabe(E/A)-Vorrichtung, die Folgendes umfasst: eine E/A-Steuerung zum Verarbeiten von E/A-Datenpaketen; und eine Debug-Steuerung, die mit der E/A-Steuerung gekoppelt ist, wobei die Debug-Steuerung ein erstes Debug-Paket von einem Hostsystem über eine In-Band-Verbindung empfängt, das erste Debug-Paket verarbeitet, um einen durch das Hostsystem erzeugten Befehl zu extrahieren, und den extrahierten Befehl ausführt, um die E/A-Vorrichtung zu debuggen.
System nach Anspruch 19, wobei die Debug-Steuerung zu Folgendem dient: Erhalten eines Debug-Ergebnisses aus einer Ausführung des extrahierten Befehls; Verkapseln des Debug-Ergebnisses in einem zweiten Debug-Paket; und Übertragen des zweiten Debug-Pakets an das Hostsystem.
System nach Anspruch 19, wobei die Debug-Steuerung vor einem Empfang des ersten Debug-Pakets zu Folgendem dient: Empfangen einer Debug-Anforderung von dem Hostsystem; Bestimmen, ob die Debug-Anforderung autorisiert ist; und als Reaktion auf eine Bestimmung, dass die Debug-Anforderung autorisiert ist: Entsperren eines Debug-Modus der E/A-Vorrichtung; und Übertragen einer Bestätigung der Debug-Anforderung an das Hostsystem.
System nach Anspruch 21, wobei die Debug-Anforderung ein sicheres Token umfasst, um einen Debug-Typ und einen Debug-Grad anzugeben, und wobei das Hostsystem das erste Debug-Paket als Reaktion auf einen Empfang der Bestätigung von der E/A-Vorrichtung erzeugt.
System nach Anspruch 19, wobei die E/A-Einrichtung ferner Folgendes umfasst: eine erste Leistungsdomäne, um der E/A-Steuerung elektrische Leistung bereitzustellen; und eine zweite Leistungsdomäne, um der Debug-Steuerung elektrische Leistung bereitzustellen, wobei die zweite Leistungsdomäne eingeschaltet bleibt, wenn die erste Leistungsdomäne ausgeschaltet ist.