DE102020115453A1 - Automatisches Umschalten und Einsetzen von Software- oder Firmware-basierten USB-Verbindungsmanagern - Google Patents

Automatisches Umschalten und Einsetzen von Software- oder Firmware-basierten USB-Verbindungsmanagern Download PDF

Info

Publication number
DE102020115453A1
DE102020115453A1 DE102020115453.4A DE102020115453A DE102020115453A1 DE 102020115453 A1 DE102020115453 A1 DE 102020115453A1 DE 102020115453 A DE102020115453 A DE 102020115453A DE 102020115453 A1 DE102020115453 A1 DE 102020115453A1
Authority
DE
Germany
Prior art keywords
usb4
host
firmware
control unit
host platform
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102020115453.4A
Other languages
English (en)
Inventor
Prashant Sethi
Robert Gough
Reuven Rozic
Uri Soloveychik
Vinay Raghav
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE102020115453A1 publication Critical patent/DE102020115453A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4403—Processor initialisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206—Monitoring of events, devices or parameters that trigger a change in power modality
    • G06F1/3215—Monitoring of peripheral devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/382—Information transfer, e.g. on bus using universal interface adapter
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/0042—Universal serial bus [USB]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Systems (AREA)

Abstract

Automatisches Umschalten und Einsetzen von Software- (SW-) oder Firmware-(FW-) basierten USB4-Verbindungmanagem (CMs) und zugeordnete Verfahren, Einrichtungen, Software und Firmware. Ein Handshake ist zwischen dem BIOS und einem Betriebssystem (OS) definiert, um unterstützte CM-Fähigkeit zu finden und dynamisch von einem FW-CM zu einem SW-CM und umgekehrt umzuschalten, falls eine Nichtübereinstimmung vorhanden ist. Zusätzlich ist ein Mechanismus definiert, um basierend auf dem Klassencode, 2-Teile- oder 4-Teile-ID den korrekten FW- oder SW-CM-Treiber einzusetzen. Die Unterstützung für fortgesetzten USB4-Betrieb während eines OS-Upgrade oder Downgrade ist bereitgestellt, während sichergestellt ist, dass basierend auf der bekanntgegebenen Plattform- und OS-Fähigkeit die bestmögliche CM-Lösung verwendet wird. USB4-Steuereinheiten unterstützen eine Durchlassbetriebsart, unter der die Host-Steuereinheit-FW Steuerpakete, die zwischen einem SW-CM und einem USB4-Fabric gesendet werden, umlenkt, und eine FW-CM-Betriebsart, unter der Steuerpakete zwischen der Host-Steuereinheit-FW und dem USB4-Fabric kommuniziert werden, um USB4-Peripheriegeräte und/oder USB4-Hubs in dem USB4-Fabric zu konfigurieren.

Description

  • HINTERGRUNDINFORMATIONEN
  • Der universelle serielle Bus (USB) ist ein Industriestandard, der Spezifikationen für Kabel, Schnittstellen und Protokolle zur Verbindung, Kommunikation und Stromversorgung zwischen USB-Hosts (z. B. Computern, mobilen Geräten), Peripheriegeräten und anderen Vorrichtungen wie z. B. USB-Hubs festlegt. Der USB-Standard ist durch drei Generationen von USB-Spezifikation definiert: USB 1.x, USB 2.0 und USB 3.x. Eine vierte als USB4 bezeichnete Generation ist durch die USB 3.0-Promoter-Gruppe in der Entwicklung gewesen, und ihre Veröffentlichung ist in Q3 von 2019 (erste Version USB 4.0; der derzeitige Arbeitsentwurf ist die Draft-Version 0.95) geplant. Die USB4-Architektur basiert teilweise auf der Thunderbolt® 3-Protokollspezifikation, die kürzlich durch Intel® Corporation als Open Source zugänglich gemacht wurde. USB4 unterstützt einen Durchsatz von 40 Gbit/s und ist mit USB 3.2, USB 2.0 und Thunderbolt® 3 kompatibel. Die Architektur definiert ein Schema zum dynamischen gemeinsamen Verwenden einer einzigen Hochgeschwindigkeitsstrecke mit mehreren Endgerätetypen, das der Übertragung von Daten nach Typ und Anwendung am besten gerecht wird.
  • Derzeit ist ein Firmware- (FW-) basierter Thunderbolt®-Verbindungsmanager (CM) bereitgestellt (mit Intel®-basierten Plattformen), um bei Einrichten und Aufzählung von Thunderbolt®-Peripheriegeräten zu unterstützen (unter anderen Funktionen). Mit USB 4.0 wird erwartet, dass dritte Silizium-Anbieter ebenfalls ihre eigenen Host-Steuereinheiten ausliefern. Um die Interoperabilität unter diesem verschiedenen Host- und Vorrichtungs-Silizium zu ermöglichen, ist ein Hardware-unabhängiger Software-(SW-) basierter Verbindungsmanager, der in dem Betriebssystem (OS) nativ unterstützt wird, vorgeschlagen worden und ist in der Entwicklung. Es ist außerdem vorstellbar, dass ein mit USB 4.0 konformer FW-basierter Verbindungsmanager ebenfalls verfügbar sein wird. Diese Lösung wird auch für alte OS-Versionen erforderlich sein, die keine native SW-Verbindungsmanagerlösung aufweisen.
  • SW- und FW-CM schließen sich gegenseitig aus. Falls das System eingerichtet ist, einen FW-CM zu verwenden, dann sollten sowohl die BIOS-Prä-Boot-(wie z. B. UEFI („Universal Extensible Firmware Interface“)) als auch die Betriebssystem- (OS) Umgebung in der gleichen Betriebsart arbeiten, und umgekehrt. Abhängig von der Betriebssystemversion, der Plattform-FW-Fähigkeit und OEM-(Originalgerätehersteller) Anforderungen kann eine Lösung, die das Umschalten zwischen FW- und SW-basierten Verbindungsmanagern ermöglichen wird, benötigt werden oder wäre anderweitig von Vorteil. Dieses Umschalten kann während eines OS-Upgrade, eines OS-Downgrade oder Dual-Boot-Szenarios eingesetzt werden. Ein solches Umschalten sollte darauf zielen, die Verbindungsmanagerbetriebsart im BIOS und dem OS ähnlich zu halten.
  • Figurenliste
  • Die vorstehenden Aspekte und viele der zugehörigen Vorteile dieser Erfindung werden einfacher anerkannt, wenn sie durch Bezugnahme auf die folgende ausführliche Beschreibung in Verbindung mit den begleitenden Zeichnungen besser verstanden werden, wobei sich gleiche Bezugszeichen durchgehend durch die verschiedenen Ansichten auf gleiche Teile beziehen, sofern nicht anders spezifiziert.
    • 1 ist ein schematisches Diagramm eines USB4-Hosts, der einen Firmware-basierten Verbindungsmanager (FW-CM) enthält, der mit einem USB4-Peripheriegerät gekoppelt ist, in Übereinstimmung mit einer Ausführungsform;
    • 2a ist ein Blockdiagramm, das USB4-Kommunikation durch eine funktionale Schicht, die einen SW-basierten CM (SW-CM) enthält, in Übereinstimmung mit der USB 4.0-Spezifikation abbildet;
    • 2b ist ein Blockdiagramm, das USB4-Kommunikation durch die Funktionsschicht, die einen FW-CM einsetzt, in Übereinstimmung mit einer Ausführungsform abbildet;
    • 3a ist ein schematisches Diagramm einer ersten beispielhaften Host-Plattformarchitektur, unter der eine USB4-Steuereinheit in einer diskreten Komponente implementiert ist, gemäß einer Ausführungsform;
    • 3b ist ein schematisches Diagramm einer zweiten beispielhaften Host-Plattformarchitektur, unter der eine USB4-Steuereinheit in einem eingebetteten USB4-Steuereinheit-Block auf einem SoC implementiert ist, gemäß einer Ausführungsform;
    • 3c ist ein schematisches Diagramm, das weitere Einzelheiten der diskreten USB4-Steuereinheit von 3a gemäß einer Ausführungsform darstellt;
    • 4 ist ein Ablaufplan, der Operationen und Logik zum Implementieren von automatischem Umschalten zwischen Software- (SW-) und Firmware- (FW-) Verbindungsmanagern (CMs) gemäß einer Ausführungsform darstellt;
    • 5 ist ein Zustands/Ablaufplan-Diagramm, das Durchgangs- und FW-CM-Zustände darstellt;
    • 6 ist ein Diagramm, das Nachrichtenströme zwischen einem Software-CM-Treiber, USB4-Steuereinheits-Firmware und einem USB4-Fabric beim Betrieb in einer Durchgangsbetriebsart gemäß einer Ausführungsform darstellt;
    • 7 ist ein Diagramm, das Nachrichtenströme zwischen der USB4-Steuereinheits-Firmware und einem USB4-Fabric beim Betrieb in einer FW-CM-Betriebsart gemäß einer Ausführungsform darstellt;
    • 8 ist ein Ablaufplan/Zustandsdiagramm, das einer ersten Startkonfiguration entspricht, unter der eine Plattform einen SW-CM-Treiber eines Drittanbieters hosten wird, unter Verwendung einer 2-Teile-ID auf einem Windows-Update gemäß einer Ausführungsform;
    • 9 ist ein Ablaufplan/Zustandsdiagramm, das einer zweiten Startkonfiguration entspricht, unter der ein OS einen nativen SW-CM-Treiber des OS basierend auf einem Klassencode laden wird, gemäß einer Ausführungsform;
    • 10 ist ein Ablaufplan/Zustandsdiagramm, das einer dritten Startkonfiguration entspricht, unter der ein OEM einen nativen SW-CM-Treiber des OS basierend auf einem Klassencode auf entweder einen nativen SW-CM-Treiber des OS, einen SW-CM-Treiber eines Drittanbieters oder einen FW-CM-Treiber basierend auf einer 4-Teile-ID überschreiben wird, gemäß einer Ausführungsform;
    • 11 ist ein schematisches Diagramm, das die verschiedenen Ausführungsphasen darstellt, die in Übereinstimmung mit dem „Universal Extensible Firmware Interface“- (UEFI-) Framework ausgeführt werden; und
    • 12 ist ein schematisches Blockdiagramm, das verschiedene Komponenten einer UEFI-Systemtabelle darstellt, die verwendet wird, um einem Betriebssystem zu ermöglichen, während OS-Laufzeitoperationen auf UEFI-Komponenten zuzugreifen.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Ausführungsformen für automatisches Umschalten und Einsetzen von Software- (SW-) oder Firmware- (FW-) basierten USB4-Verbindungmanagern (CMs) und zugehörige Verfahren, Einrichtungen, Software und Firmware sind hier beschrieben. In der folgenden Beschreibung sind zahlreiche spezifische Einzelheiten dargelegt, um ein gründliches Verständnis der Ausführungsformen der Erfindung bereitzustellen. Ein Fachmann wird jedoch erkennen, dass die Erfindung ohne eine oder mehrerer der spezifischen Einzelheiten oder mit anderen Verfahren, Komponenten, Materialien usw. praktiziert werden kann. In anderen Fällen sind bekannte Strukturen, Materialien oder Operationen nicht gezeigt oder im Einzelnen beschrieben, um das Verdecken von Aspekten der Erfindung zu vermeiden.
  • Durchgehend durch diese Spezifikation bedeutet die Bezugnahme auf „eine Ausführungsform“, dass ein/e spezielle/s Merkmal, Struktur oder Eigenschaft, das/die in Verbindung mit der Ausführungsform beschrieben ist, in wenigstens einer Ausführungsform der vorliegenden Erfindung enthalten ist. Somit bezieht sich das Auftreten des Ausdrucks „in einer Ausführungsform“ an verschiedenen Orten durchgehend durch diese Spezifikation nicht notwendigerweise immer auf dieselbe Ausführungsform. Darüber hinaus können die speziellen Merkmale, Strukturen oder Eigenschaften auf irgendeine geeignete Weise in einer oder mehreren Ausführungsformen kombiniert sein.
  • Zur Verdeutlichung können individuelle Komponenten hier auch durch ihre Beschriftungen in den Figuren anstelle durch ein spezielles Bezugszeichen referenziert sein. Zusätzlich können Bezugszeichen, die sich auf einen speziellen Typ einer Komponente beziehen (im Gegensatz zu einer speziellen Komponente) mit einem Bezugszeichen gefolgt von „(Typ)“, das „typisch“ bedeutet, gezeigt sein. Es ist zu verstehen, dass die Konfiguration dieser Komponenten typisch für ähnliche Komponenten sein wird, die existieren können, jedoch der Einfachheit und Deutlichkeit halber nicht in der Zeichnungsfiguren gezeigt sind, oder anderweitigen ähnlichen Komponenten, die nicht mit separaten Bezugszeichen beschriftet sind. Umgekehrt ist „(Typ)“ nicht so zu deuten, dass es bedeutet, dass die Komponente, das Element usw. typischerweise für seine offenbarte Funktion, Implementierung, Zweck usw. verwendet ist.
  • In Übereinstimmung mit Aspekten der Ausführungsformen, die hier beschrieben und dargestellt sind, sind Techniken zum Implementieren von automatischem Umschalten und Einsetzen von Software- und Firmware-basierten USB4-Verbindungsmanagern offenbart. Ein Handshake ist zwischen dem BIOS und dem Betriebssystem (OS) definiert, um unterstützte CM-Fähigkeit zu finden und dynamisch von einem FW-CM zu einem SW-CM und umgekehrt umzuschalten, falls eine Nichtübereinstimmung vorhanden ist. Zusätzlich ist ein Mechanismus definiert, um basierend auf dem Klassencode, 2-Teile- oder 4-Teile-ID den korrekten FW- oder SW-CM-Treiber einzusetzen. Die Unterstützung für fortgesetzten USB4-Betrieb während eines OS-Upgrade oder Downgrade ist bereitgestellt, während sichergestellt ist, dass basierend auf der bekanntgegebenen Plattform- und OS-Fähigkeit die bestmögliche CM-Lösung verwendet wird.
  • Kurzübersicht ausgewählter Aspekte von USB4
  • USB4, wie es in der USB 4.0-Spezifikation definiert ist, ist früheren Versionen von USB darin ähnlich, dass es ein Kabelbus ist, der Datenaustausch zwischen einem Host-Computer oder -Gerät (hier als Host-Plattform bezeichnet) und einer großen Auswahl von gleichzeitig zugänglichen Peripheriegeräten unterstützt. USB4 ermöglicht es jedoch auch, dass ein Host-Computer Datenaustausch zwischen kompatiblen Peripheriegeräten herstellt. Die angeschlossenen Peripheriegeräte verwenden die Bandbreite über ein durch den Host gemanagtes Zeitplanungs-Protokoll gemeinsam. Der Bus ermöglicht, dass Peripheriegeräte angeschlossen, konfiguriert, verwendet und entfernt werden, während der Host und andere Peripheriegeräte im Betrieb sind.
  • Wenn es über eine USB Typ-C-Konnektorschnittstelle konfiguriert ist, ersetzt USB4 funktional USB 3.2, während es den parallel arbeitenden USB 2.0-Bus beibehält. Erweitertes SuperSpeed-USB, wie es in USB 3.2 definiert ist, bleibt die grundlegende Architektur für USB-Datenübertragung auf einem USB4-Fabric. Der Unterschied von USB4 gegenüber USB 3.2 ist, dass USB4 ein verbindungsorientiertes Tunnelarchitektur-Design ist zum Kombinieren mehrerer Protokolle auf einer einzigen physikalischen Schnittstelle, so dass die Gesamtgeschwindigkeit und Leistungsfähigkeit des USB4-Fabric dynamisch gemeinsam verwendet werden können. USB4 ermöglicht, dass USB-Datenübertragungen parallel zu anderen unabhängigen Protokollen, die spezifische für Anzeige, Laden/Speichern und Host-zu-Host-Schnittstellen sind, arbeiten. Zusätzlich erweitert USB4 die Leistungsfähigkeit über 20 Gbps (Gen 2 x 2) von USB 3.2 hinaus auf 40 Gbps (Gen 3 x 2) über die gleiche Doppel-Spur-Doppel-Simplex-Architektur.
  • Die USB 4.0-Spezifikation führt das Konzept von Protokolltunneln in die USB-Busarchitektur ein. Neben dem Tunneln von erweitertem SuperSpeed-USB (USB3) sind Anzeigetunneln basierend auf dem DisplayPort- (DP-) Protokoll und Laden/Speichern-Tunneln basierend auf PCI-Express (PCIe) definiert. Diese Protokolltunnel arbeiten unabhängig über die USB4-Transport- und Bitübertragungsschichten. Zusätzlich weist USB4 Pakete zur Buskonfiguration und Management zu, und Pakete können spezifisch für Host-zu-Host-Datenverbindungen zugewiesen werden.
  • 1 zeigt beispielhafte Komponenten und Blöcke für einen USB4-Host 100 und ein USB4-Peripheriegerät 102, die die Doppelbus-Architektur von USB3.2, wie sie durch USB4 erweitert ist, unterstützen und ferner einen FW-CM enthalten, gemäß einer Ausführungsform. Allgemein wird ein USB4-Host einen Host-Router (104), eine Steuereinheit (106) für einen erweiterten SuperSpeed-USB-Host und eine DisplayPort-Quelle (108) enthalten. Ein USB-Host kann außerdem optional eine PCIe-Steuereinheit (110) enthalten. Der Host-Router 104 enthält einen Host-Schnittstellen- (I/F-) Adapter 112, einen DisplayPort- (DP-) Eingangs- (IN-) Adapter 114, der mit der DP-Quelle 108 gekoppelt ist, einen USB-Abwärts- (DN-) Adapter 116, einen PCIe-DN-Adapter 118, der mit der PCIe-Steuereinheit 110 gekoppelt ist, eine Zeitmanagementeinheit (TMU) 119 und ein Paar von USB-Anschlüssen 120 und 122. Der erweiterte SuperSpeed-Host 106 ist mit einem Multiplexierer (MUX) 124 gekoppelt, dessen einer Ausgang mit dem USB-DN-Adapter 116 gekoppelt ist, während der andere MUX-Ausgang als entsprechende Eingänge für die MUX 126 und 128 gekoppelt ist. Der USB4-Anschluss 120 ist mit dem MUX 128 gekoppelt, während der USB4-Anschluss 122 mit dem MUX 126 gekoppelt ist. Der Ausgang des MUX 128 ist mit einer Abwärts-USB4-Schnittstelle 130 gekoppelt, während der Ausgang des MUX 126 mit einer Abwärts-USB4-Schnittstelle 132 gekoppelt ist. Ein USB 2.0-Host 134 ist ebenfalls mit jeder der Abwärts-USB4-Schnittstellen 130 und 132 gekoppelt.
  • Unter der USB 4.0- (Draft-) Spezifikation kann der Verbindungsmanager in der Host-System-Software implementiert sein (ein „externer Verbindungsmanager“, hier auch als SW-CM bezeichnet), oder er kann in der Host-Router-Firmware oder -Hardware implementiert sein (ein „eingebetteter Verbindungsmanager“, hier auch als ein FW-CM bezeichnet, wenn er in Firmware implementiert ist). Unter der Ausführungsform von 1 ist ein FM-CM eingesetzt, wie durch den FW-Verbindungsmanager 135 abgebildet ist.
  • Ein USB4-Peripheriegerät weist einen einzigen aufwärts gerichteten Anschluss auf und weist keine abwärts gerichteten Anschlüsse auf. Ein USB4-Peripheriegerät beinhaltet einen Geräte-Router und kann außerdem optional eines oder mehrere aus den Folgenden enthalten:
    • • Einen erweiterten SuperSpeed-Hub oder Endpunkt
    • • Einen PCIe-Switch oder Endpunkt
    • • Eine DisplayPort-Quelle oder -Senke
  • Ein in 1 abgebildetes USB4-Peripheriegerät 102 enthält eine Aufwärts-USB4-Schnittstelle 136, die mit einem USB 2.0-Funktionsblock 138 und einem Mux 140 gekoppelt ist. Der Mux 140 ist mit einem USB4-Anschluss 142 auf einem Geräte-Router 144 und mit einem Mux 146, der mit einem erweiterten SuperSpeed-Funktionsblock 148 gekoppelt ist, gekoppelt. Ein USB3-Aufwärts- (UP-) Adapter 150 auf dem Geräte-Router 144 ist ebenfalls mit dem Mux 146 verbunden. Der Geräte-Router 144 enthält ferner einen PCIe-Aufwärts-Adapter 152, der mit einem PCIe-Funktionsblock 154 gekoppelt ist, einen DisplayPort-Ausgangs- (OUT-) Adapter 155, der mit einer DP-Anzeigevorrichtung 156 gekoppelt ist, und eine TMU 157.
  • Die Abwärts-USB4-Schnittstelle 130 ist mit der Aufwärts-USB4-Schnittstelle 136 über ein gemischtadriges Kabel 158 gekoppelt, das eine Verdrahtung zum Implementieren eines USB 2.0-Busses und eines USB4/erweiterten SuperSpeed- (SS-) Busses enthält. In einer Ausführungsform sind sowohl die USB4-Schnittstelle 130 als auch die Aufwärts-USB4-Schnittstelle 136 Buchsen vom USB-Typ-C (USB-C), währen das gemischtadrige Kabel 158 in der dargestellten Ausführungsform ein USB-C-Kabel ist.
  • Der Router ist ein grundlegender Baustein der USB4-Architektur. Der Router bildet Tunnelprotokollverkehr auf USB4-Pakete ab und routet Pakete durch das USB4-Fabric. Ein Router verteilt und synchronisiert außerdem die Zeit durchgehend durch das USB4-Fabric über seine Zeitmanagementeinheit. Ein Router wird durch einen Verbindungsmanager, der sich innerhalb des USB4-Hosts (wie z. B. durch den Verbindungsmanager 135 in 1 abgebildet) gefunden und konfiguriert. Der Router enthält einen glatten konfigurierbaren Punkt-zu-Punkt-Switch, um (konfigurierbare) interne Pfade zwischen Adaptern zu erzeugen. Jede Instanz eines USB4-Hosts, -Hubs oder -Peripheriegeräts enthält allgemein einen Router.
  • Jeder Router beinhaltet bis zu 64 Adapter. Adapter stellen eine Schnittstelle zwischen einem Router und einer externen Entität bereit. Es gibt drei Typen von Adaptern: Protokoll-Adapter, Spur-Adapter und Steuer-Adapter. Ein Protokoll-Adapter wird verwendet, um zwischen einem unterstützten nativen Protokoll und einem USB4-Tunnel zu übersetzen. Es gibt vier Typen von Protokoll-Adaptern: USB3-Adapter, DisplayPort- (DP-) Adapter, PCIe-Adapter und Host-Schnittstellen- (HI-) Adapter.
  • Ein Spur-Adapter stellt eine Schnittstelle für eine Spur bereit. Ein USB4-Anschluss weist einen Spur-Adapter pro Spur auf. Ein Router beinhaltet einen Steuer-Adapter. Der Steuer-Adapter ist ein logischer Adapter und weist keine Bitübertragungsschicht auf. Der Steuer-Adapter ist der letztendliche Verbraucher von Steuerpaketen, die für den Router bestimmt sind. Der Steuer-Adapter erzeugt außerdem Steuerpakete, die zu dem Verbindungsmanager gesendet werden.
  • Ein USB4-Anschluss ist die Entität, die die USB4-Funktionsschnittelle bereitstellt, die auf jedem Ende einer USB4-Strecke vorhanden ist. Er besteht aus den Sende- und Empfangsspuren des USB4-Datenbusses zusammen mit einem Zweidraht-Seitenband- (SB-) Kanal (SBTX/SBRX). USB4-Anschlüsse arbeiten entweder als Einzelspurverbindungsstrecke oder als Doppelspurverbindungsstrecke und sind mit physikalischen USB-Schnittstellen wie z. B. USB-C-Buchsen und USB-C-Steckern gekoppelt.
  • Der primäre Kommunikationskanal des USB4-Fabric ist über die USB4-Verbindungsstrecke, die zwei USB4-Anschlüsse miteinander verbindet. Die USB4-Verbindungsstrecke transportiert Pakete sowohl für Tunnelprotokollverkehrs als auch Busmanagementverkehr zwischen Routern. Der Seitenbandkanal eines USB4-Anschlusses wird verwendet, um die USB4-Verbindungsstrecke zwischen den USB4-Anschlüssen zu initialisieren und zu managen.
  • Die 2a und 2b zeigen die Diagramme 200a bzw. 200b, die USB4-Kommunikation durch eine Funktionsschicht abbilden, wobei das Diagramm 200a einen SW-CM enthält und das Diagramm 200b einen FW-CM enthält. Die Schichten enthalten eine Host-Schnittstellenadapterschicht 202, eine Transportschicht 204, eine Protokolladapterschicht 206, eine Konfigurationsschicht 208, eine Transportschicht 210 und eine Bitübertragungsschicht 212, die eine logische Schicht 216 und eine elektrische Schicht 216 enthält. Jede der vorstehenden Schichten ist in Hardware 218a implementiert. Ein Seitenbandkanal 220 und eine USB4-Verbindungsstrecke 222 sind unten auf dem Diagramm 200 abgebildet. Das Diagramm 200a bildet ferner einen Software-basierten Verbindungsmanager 224s, Steuerpakete 226, nativen Protokollverkehr 228, Tunnelpakete 230, Verbindungsstreckenmanagementpakete 232, Transaktionen 234, LFPS 236 und geordnete Mengen 238 ab. Das Diagramm 200b ist ähnlich dem Diagramm 200a, außer dass ein eingebetteter FW-Verbindungsmanager 224f in Hardware 218b anstelle eines SW-CM implementiert ist.
  • Die elektrische Schicht 216 definiert eine elektrische Signalisierungseigenschaft einer USB4-Verbindungsstrecke, die Verwürfeln, Codieren, Jitter und Spannung enthält. Die logische Schicht 214 baut eine USB4-Verbindungsstrecke zwischen zwei Routern auf und stellt Dienste zum Senden und Empfangen von Byte-Strömen zwischen ihnen bereit. Die logische Schicht 214 behandelt Verkehr zu und von der Transportschicht 212 als einen Byte-Strom.
  • Die Transportschicht 212 leitet Tunnelpakete 230 und Steuerpakete 226 über den Bus weiter. Sie definiert das Paketformat, Routing, Dienstgüte- (QoS-) Unterstützung, Ablaufsteuerung und Zeitsynchronisation und ist die Schicht, in der Protokollmultiplexieren ausgeführt wird.
  • Die Konfigurationsschicht 208 führt Router-Konfigurationsaufgaben aus und handhabt eingehende Steuerpakete 226. Sie stellt ein Adressierungsschema für Steuerpakete innerhalb der Domäne bereit, verarbeitet Steuerpakete und liefert einen zuverlässigen Transportmechanismus für Steuerpakete. Die Steuerpakete 226 versorgen den Verbindungsmanager 224 mit Zugriff auf die Konfigurationsräume eines Routers.
  • Die Protokolladapterschicht 206 führt Abbilden zwischen Tunnelprotokollverkehr und USB4-Transportschichtpaketen aus. Eine Protokolladapterschicht ist durch den Typ von Tunnelprotokollverkehr, den sie sendet und empfängt, definiert.
  • Die Steuerpakete 226 werden durch einen Verbindungsmanager verwendet, um den Verbindungsmanager mit Zugriff auf die Konfigurationsräume eines Routers zu versorgen, um die Router über den Bus zu konfigurieren und zu managen. Sie werden durch einen Router auch verwendet, um mit einem Verbindungsmanager zu kommunizieren. Die Steuerpakete 226 werden über den Bus basierend auf einer Routenkette, die die Position des Routers in einem Spannbaum identifiziert, geroutet. Wenn ein Steuerpaket seinen Ursprung in einem Verbindungsmanager hat, identifiziert die Routerkette den Router, für den das Paket bestimmt ist. Wenn ein Steuerpaket seinen Ursprung in einem Router hat, identifiziert die Routerkette den Router, der das Paket gesendet hat.
  • Protokollverkehr wird eingekapselt und über das USB4-Fabric in Tunnelpaketen 230 getunnelt. Tunnelpakete durchlaufen das USB4-Fabric entlang einem oder mehreren Pfaden. Verbindungsstreckenmanagementpakete 232 sind auf eine einzige USB4-Verbindungsstrecke beschränkt. Verbindungsstreckenmanagementpakete haben ihren Ursprung in der Transportschicht des Routers an einem Ende Verbindungsstrecke und kommen in der Transportschicht des Routers an dem anderen Ende der Verbindungsstrecke an. Verbindungsstreckenmanagementpakete 232 enthalten Zeitsync-Pakete, Ablaufsteuerungspakete und Leerlaufpakete. Die logische Schicht 214 verwendet geordnete Mengen 238 für Aufgaben wie z. B. Symbolsynchronisation, Verbindungsstreckentraining und Entzerren zwischen Spuren. Geordnete Mengen sind 66-Bit-Symbole (bei Gen 2-Geschwindigkeit) oder 132-Bit-Symbole (bei Gen 3-Geschwindigkeit).
  • Der Seitenbandkanal 220 handhabt die Spurinitialisierung, Verbindung oder Trennen auf einem USB4-Anschluss, Spurdeaktivierung und -aktivierung und Eintritt in einen und Verlassen eines Schlafzustands. Der Seitenbandkanal 220 ist ein paketbasierter Kanal; Seitenbandkanalpakete sind als Transaktionen 234 bezeichnet, um sie von USB4-Verbindungsstreckenpaketen zu unterscheiden.
  • Ein Verbindungsmanager 224 ist die Entität, die für Managen und Konfigurieren einer Domäne zuständig ist. Der Verbindungsmanager kommuniziert mit Routern in einer Domäne unter Verwendung von Steuerpaketen 226. Der Verbindungsmanager führt die folgenden Konfigurationsaufgaben innerhalb einer Domäne aus:
    • • Aufzählung von Routern
    • • Router-Installation
    • • Absuchen und Einstellen von Adapter-Konfigurationen
    • • Einstellen und Entfernen von Pfaden
    • • Konfiguration des QoS-Verhaltens in dem USB4-Fabric, einschließlich Ablaufsteuerung und Bandbreitenzuweisung
    • • Domänenübergreifendes Management
    Weitere Einzelheiten zum Implementieren eines USB-Verbindungsmanagers sind in dem USB4-Verbindungsmanager- (CM-) Handbuch bereitgestellt (derzeitige Draft-Version Überarbeitung 0.7, Dezember 2018).
  • Beispielhafte Host-Plattformarchitekturen
  • Um ein besseres Verständnis dafür, wie Ausführungsformen zum automatischen Umschalten und Einsetzen von Software- oder Firmware-basierten USB4-Verbindungsmanagern implementiert sein können, sind Beispiele für die Host-Plattformarchitekturen 300a und 300b in den 3a und 3b präsentiert. Es ist durch Fachleute zu verstehen, dass die Host-Plattformarchitekturen 300a und 300b lediglich Beispiele für Systeme und Geräte sind, unter denen Aspekte der hier offenbarten Ausführungsformen implementiert sein können, und nicht einschränkend sind.
  • 3a zeigt eine Host-Plattformarchitektur 300a, die Plattform-Hardware 302a und verschiedene Firmware- und Software-basierte Komponenten enthält. Die Plattform-Hardware 302a enthält eine zentrale Verarbeitungseinheit (CPU) 304, die mit einer Speicherschnittstelle 306, einem Cache letzter Ebene (LLC) 308 und einer Eingabe/Ausgabe- (I/O-) Schnittstelle 310 über eine Zusammenschaltung 312 gekoppelt ist. In einigen Ausführungsformen können alle oder ein Teil der vorstehenden Komponenten auf einem Einchipsystem (SoC) integriert sein, wie durch das SoC 313a abgebildet ist. Die Speicherschnittstelle 306 ist konfiguriert, den Zugriff auf den Systemspeicher 314, der üblicherweise getrennt von dem SoC sein wird, (wie z. B. DDR4-DIMMs, NVDIMMs usw.) zu ermöglichen.
  • Die CPU 304 enthält einen Kernabschnitt, der M Prozessorkerne 315 enthält, von denen jeder einen lokalen Ebene-1- (L1-) und Ebene-2- (L2-) Cache 316 enthält. Optional kann der L2-Cache als „Cache mittlerer Ebene“ (MLC) bezeichnet sein. Wie dargestellt weist jeder Prozessorkern 314 eine entsprechende Verbindung 318 zu der Zusammenschaltung 312 auf und arbeitet unabhängig von den anderen Prozessorkernen.
  • Zur Vereinfachung ist die Zusammenschaltung 312 als ein einziger Doppelpfeil gezeigt, der eine einzige Zusammenschaltungsstruktur repräsentiert; in der Praxis stellt die Zusammenschaltung 312 jedoch eine oder mehrere Zusammenschaltungsstrukturen innerhalb eines Prozessors oder SoC dar und kann eine Hierarchie von Zusammenschaltungssegmenten oder Domänen umfassen, die separate Protokolle einsetzen und anwendbare Brücken als Schnittstellen zwischen den Zusammenschaltungssegmenten/Domänen enthalten. Beispielsweise kann der Abschnitt einer Zusammenschaltungshierarchie, mit der der Speicher und die Prozessorkerne verbunden sind, eine kohärente Speicherdomäne umfassen, die ein erstes Protokoll einsetzt, während Zusammenschaltungen auf einer tieferen Ebene in der Hierarchie im Allgemeinen für I/O-Zugriff verwendet werden und nicht-kohärente Domänen einsetzen. Die Zusammenschaltungsstruktur auf dem Prozessor oder SoC kann irgendeine existierende Zusammenschaltungsstruktur enthalten, wie z. B. Busse und serielle Einzel- oder Mehrspur-Punkt-zu-Punkt-, Ring-, Toroid- oder Maschenzusammenschaltungsstrukturen.
  • Die I/O-Schnittstelle 310 stellt verschiedene I/O-Schnittstellen dar, die durch die Plattform-Hardware 302a bereitgestellt sind. Allgemein kann die I/O-Schnittstelle 310 als eine diskrete Komponente implementiert sein (z. B. als ICH (I/O-Steuereinheit-Hub) oder dergleichen), oder sie kann auf einem SoC integriert sein. Außerdem kann die I/O-Schnittstelle 310 auch als eine I/O-Hierarchie implementiert sein, wie z. B. eine „Peripheral Component Interconnect Express“- (PCIe™) I/O-Hierarchie. Die I/O-Schnittstelle 310 unterstützt ferner die Kommunikation zwischen verschiedenen I/O-Betriebsmitteln und Vorrichtungen und anderen Plattformkomponenten. Diese enthalten eine Netzschnittstellensteuereinheit (NIC) 320, die konfiguriert ist, den Zugang zu einem Netz 322 zu unterstützen, und verschiedene andere I/O-Vorrichtungen, die einen Firmware-Speicher 324, eine Platten/SSD-Steuereinheit 326 und ein Plattenlaufwerk 328 enthalten. Allgemeiner repräsentiert das Plattenlaufwerk 328 verschiedene Typen von nichtflüchtigen Speichervorrichtungen, die sowohl magnet- als optik-basierte Speichervorrichtungen enthalten, und auch Festkörperspeichervorrichtungen, wie z. B. Festkörperlaufwerke (SSDs) oder Flash-Speicher. Der Firmware-Speicher 324 wird verwendet, um Firmware 332 zu speichern. Firmware für eine Host-Plattform wie z. B. ein Computersystem ist manchmal als BIOS („Basic Input Output System“) bezeichnet. Unter einer Ausführungsform umfasst die Firmware 332 „Universal Extensible Firmware Interface“- (UEFI-) Firmware.
  • Die Plattformarchitektur 300a enthält ferner eine diskrete USB4-Steuereinheit 334a, die konfiguriert ist, hier beschriebene USB4-Operationen zu implementieren und/oder anderweitig konfiguriert ist, verschiedene Operationen in Übereinstimmung mit der USB 4.0-Spezifikation auszuführen. Die USB4-Steuereinheit 334a kann allgemein eine integrierte Schaltung in Form eines Chips oder Moduls umfassen. In einer Ausführungsform ist Firmware 336, die einen FW-CM 339 enthält, in der USB4-Steuereinheit 334a gespeichert und wird auf einem oder mehreren Verarbeitungselementen aufgeführt, wie z. B. durch eine Mikrosteuereinheit 338 abgebildet ist. Allgemeiner kann die hier beschriebene USB4-Funktionalität unter Verwendung verschiedener Typen von eingebetteter Logik implementiert sein, die, ohne jedoch darauf beschränkt zu sein, auf einem oder mehreren Verarbeitungselementen ausgeführte Firmware, eine eingebettete anwendungsspezifische integrierte Schaltung (ASIC) oder vorprogrammierte oder programmierbare Logik, die unter Verwendung eines im Feld programmierbaren Gate-Array (FPGA) oder dergleichen implementiert ist, enthält. Andere Typen von eingebetteter Logik, wie z. B. ein digitaler Signalprozessor (DSP) können ebenfalls verwendet werden. Es wird ferner darauf hingewiesen, dass die elektrische Schicht 216 üblicherweise in einer vordefinierten Schaltungsanordnung implementiert sein wird. In der Beispielkonfiguration der Host-Plattformarchitektur 300a enthält die USB4-Steuereinheit 334a ein Paar von USB4-Anschlüssen (nicht gezeigt), die mit jeweiligen Abwärts-USB-Schnittstellen 340a und 342a verbunden sind.
  • Die USB4-Steuereinheit 334a ist konfiguriert, mit Software und/oder Firmware, die auf der Plattform-Hardware 302a abläuft, über eine anwendbare I/O-Schnittstellenschaltungsanordnung, die kollektiv als eine PCIe-Steuereinheit dargestellt ist, und eine USB-Host-Schnittstelle 344a, die auf einem SoC 313b implementiert ist und mit der Zusammenschaltung 312 gekoppelt ist, zu kommunizieren. Wie vorstehend beschrieben ist das Aufnehmen einer PCIe-Steuereinheit (z. B. der PCIe-Steuereinheit 110 in 1) optional. Zusätzlich können die PCIe-Steuereinheit und die USB-Host-Schnittstelle 344a einen Abschnitt der SoC-Zusammenschaltungshierarchie enthalten (kollektiv durch die I/O-Schnittstelle 310 dargestellt) und sind zu erläuternden Zwecken als separater Block dargestellt.
  • Die mehreren Kerne 314 der CPU 304 sind konfiguriert, Firmware 330 und verschiedene Software-Komponenten 332 in einen oder mehrere Adressräume in einem Systemspeicheradressraum 346 zu laden und die Firmware und Software-Komponenten auszuführen. Im Allgemeinen werden die Software-Komponenten 332 Komponenten enthalten, die einem Host-Betriebssystem (OS) 348 zugeordnet sind, zusammen mit verschiedenen Modulen und Anwendungen. Alle oder ein Teil der Software-Komponenten 332 können in einer oder mehreren nichtflüchtigen Speichervorrichtungen gespeichert sein, wie z. B. durch das Plattenlaufwerk 328 abgebildet ist. Optional können alle oder ein Teil der Software-Komponenten 332 in einer oder mehreren Speichervorrichtungen (nicht gezeigt), auf die über das Netz 322 zugegriffen wird, gespeichert sein.
  • Während Boot- oder Laufzeitoperationen werden verschiedene Software-Komponenten 330 und Firmware 332 in den Systemspeicher 314 geladen und auf Kernen 314 als Prozesse, die Ausführungs-Threads enthalten, oder dergleichen ausgeführt. Abhängig von der speziellen Prozessor- oder SoC-Architektur kann ein gegebener „physikalischer“ Kern als ein oder mehrere logische Kerne implementiert sein, wobei Prozesse den verschiedenen logischen Kernen zugewiesen werden. Beispielsweise ist unter der Intel® Hyperthreading™-Architektur jeder physikalische Kern als zwei logische Kerne implementiert.
  • Unter einem normalen System-Boot für die Plattform-Hardware 302 wird die Firmware 330 geladen und im Systemspeicher 314 konfiguriert, gefolgt durch das Booten des Host-OS 348. Unter UEFI beinhaltet das einen Mehrphasenprozess, wie in 11 dargestellt und nachstehend beschrieben ist. Das Host-OS 348 enthält Kernel-Komponenten, die in einem Kernel-Raum implementiert sind, und verschiedene andere Komponenten, die in einem Nutzerraum implementiert sind. Das Host-OS 348 enthält außerdem verschiedene Treiber 350, die USB-bezogene Treiber enthalten, die in dem Kernel-Raum und/oder dem Nutzerraum implementiert sein können. Anwendungen, wie sie durch „App 1, App 2 ... App N abgebildet sind, sind in ihren eigenen Anwendungsräumen 352 im Nutzerraum implementiert.
  • Wie vorstehend diskutiert kann in einigen Ausführungsformen ein Flag wie z. B. _OSC-Bit verwendet werden, um die Unterstützung des Betriebssystems für einen Software-basierten CM anzugeben und einen Zweiwege-Handshake zwischen dem BIOS und dem OS bereitzustellen. Das _OSC-Bit kann unter Verwendung des ACPI-OSC-Verfahrens implementiert sein, das verwendet wird, um zu kommunizieren, welche Merkmale oder Fähigkeiten, die in der Plattform verfügbar sind, durch das Betriebssystem gesteuert werden können. Das _OSC-Verfahren ist in der „Advanced Configuration and Power Interface“- (ACPI-) Spezifikation, Überarbeitung 4.0, definiert, die eine Industrie-Spezifikation für die effiziente Behandlung von Energieverbrauch in Desktop- und Mobil-Computern ist. ACPI spezifiziert, wie das BIOS, das Betriebssystem und Peripheriegeräte, miteinander über die Energienutzung kommunizieren.
  • Im Allgemeinen kann die ACPI-Funktionalität über einen eingebetteten ACPI-Block auf einem SoC oder unter Verwendung einer (von dem SoC) separaten Off-Chip-Komponente implementiert sein. In den 3a und 3b sind diese als ein On-Chip-ACPI-Block 347 und ein Off-Chip-ACPI-Block 349 abgebildet. Es wird darauf hingewiesen, dass dann, wenn sie in einer separaten Komponente (z. B. Halbleiterchip) implementiert ist, die ACPI-Block/Funktionalität allgemein mit anderen Blöcken und Funktionen in einem Chip, der mehrere Funktionen (zusätzlich zu den ACPI-Funktionen) unterstützt, kombiniert sein kann. Wie in 3b dargestellt ist, kann eine solche Off-Chip-Komponente mit dem SoC 313 über die I/O-Schnittstelle 310 kommunikationstechnisch gekoppelt sein oder anderweitig über eine anwendbare I/O-Schnittstelle kommunikationstechnisch gekoppelt sein.
  • Unter der Host-Plattformarchitektur 300b von 3b enthält die Plattform-Hardware 302b ein SoC 313b mit einem eingebetteten USB 4.0-Host-Block 334b, der eine Mikrosteuereinheit 338 enthält, die konfiguriert ist, die Firmware 337 auszuführen. Die Funktionalität des eingebetteten USB 4.0-Host-Blocks 334b ist ähnlich der Funktionalität für die diskrete USB4-Steuereinheit 334a, außer dass die entsprechende Schaltungsanordnung / eingebettete Logik auf dem SoC 313b anstatt auf einer separaten Komponente implementiert ist. In einer Ausführungsform wird die Firmware 337 während Vor-Boot-Operationen in den Speicher (nicht gezeigt), der durch die Mikrosteuereinheit 338 zugreifbar ist, geladen; optional kann die gesamte oder ein Teil der Firmware 337 in dem eingebetteten USB 4.0-Host-Block 334b gespeichert sein. Der eingebettete USB 4.0-Host-Block 334b enthält ein Paar von USB-Anschlüssen (nicht gezeigt), die mit den Abwärts-USB4-Schnittstellen 340b bzw. 342b verbunden sind, und ist mit der Zusammenschaltung 312 über eine PCIe-Steuereinheit und die USB-Host-Schnittstelle 344b verbunden. Wie vorstehend ist das Aufnehmen einer PCIe-Steuereinheit optional, und die PCIe-Steuereinheit und die USB-Host-Schnittstelle 344b können einen Abschnitt der SoC-Zusammenschaltungshierarchie umfassen und sind zu erläuternden Zwecken als ein separater Block dargestellt.
  • Sowohl die Host-Plattformarchitektur 300a als auch die Host-Plattformarchitektur 300a werden im Allgemeinen zusätzliche Komponenten enthalten, die der Einfachheit halber nicht gezeigt sind, wie z. B. eine Stromversorgung und eine Leistungsaufbereitungsschaltungsanordnung, zusätzliche Peripheriegeräte, Systemmanagementkomponenten (wie z. B. eine Management-Engine, die in dem SoC 313a oder 314b implementiert ist) usw. Außerdem können die hier offenbarten Ausführungsformen auf anderen Typen von Plattformen, die unterschiedliche Architekturen aufweisen, implementiert sein, die, ohne jedoch darauf beschränkt zu sein, Computer, Laptops, Notebooks, Mobiltelefone, Tablets, Chromebooks usw. enthalten.
  • 3c zeigt weitere Einzelheiten der USB4-Steuereinheit 334a gemäß einer Ausführungsform. Wie durch gleich nummerierte Blöcke und Schaltungsanordnung in den 1 und 3c abgebildet ist, enthält die USB4-Steuereinheit 334a einen Kernblock aus eingebetteter Schaltungsanordnung und Logik zum Implementieren ausgewählter Funktionalität und USB4-Schnittstellen eines USB4-Hosts 100. Wie in der Ausführungsform von 3c gezeigt ist, enthält die USB4-Steuereinheit 334a eine PCIe-Schnittstelle 354 (optional), eine DisplayPort-Schnittstelle 356 und eine Host-I/O-Schnittstelle 358, die jeweils mit einer PCIe-Schnittstelle 355, einer DisplayPort-Schnittstelle 357 und einer Host-I/O-Schnittstelle 359 auf dem SoC 313 gekoppelt sind. Auf der USB4-Steuereinheit 334a ist die PCIe-Schnittstelle 354 mit einer PCIe-Steuereinheit 110 gekoppelt, die wiederum mit einem PCIe-DN-Adapter 118 gekoppelt ist, die DisplayPort-Schnittstelle 356 ist mit dem DisplayPort-Eingangsadapter 114 gekoppelt, und die Host-I/O-Schnittstelle 358 ist mit dem Host-Schnittstellenadapter 112 gekoppelt. Auf dem SoC 313 ist die PCIe-Schnittstelle 355 mit einer PCIe-Steuereinheit 361 gekoppelt, während die DP-Schnittstelle 357 mit einer DP-Quelle 108 gekoppelt ist. In einigen Ausführungsformen sind die PCIe-Steuereinheit 361 und die PCIe-Schnittstelle 355 in einem PCIe-Wurzelanschluss integriert.
  • Zusätzlich zu den dargestellten Schnittstellen werden eine USB4-Steuereinheit 334a und ein USB 4.0-Host-Block 334b einen ähnlichen Kernblock aus eingebetteter Schaltungsanordnung und Logik zum Implementieren der USB 4.0-Host-Funktionalität gemeinsam verwenden. Dieser Kernblock wird im Allgemeinen ein oder mehrere Prozessorelemente, wie z. B. eine Mikrosteuereinheit 338, und einen Speicher 360 enthalten. Es wird darauf hingewiesen, dass Mikrosteuereinheiten im Allgemeinen Register und dergleichen enthalten und einen Speicher enthalten können; zu erläuternden Zwecken ist jedoch der Speicher 360 getrennt von der Mikrosteuereinheit 338 gezeigt. Während des Betriebs werden ausgewählte Komponenten der Firmware 336, die einen FM-Verbindungsmanager 135 enthalten, in den Speicher 360 geladen und auf einem oder mehreren Prozessorelementen wie z. B. der Mikrosteuereinheit 338 ausgeführt. Die gesamte oder ein Abschnitt der Firmware 336 kann in einer optionalen nichtflüchtigen (NV-) Firmware-Speichereinheit 362 wie z. B. einem eingebetteten Flash-Speicher oder einem anderen Typ eines NV-Speichers gespeichert sein. Optional kann die gesamte oder ein Teil der Firmware 336 in der Firmware-Speichereinheit 324 als Teil der Firmware 330 gespeichert sein und in den Speicher 360 über die Host-I/O-Schnittstellen 358 und 359 während der Plattform-Boot-Operationen geladen werden.
  • Wenn sie in einer diskreten Komponente wie z. B. einem Halbleiterchip implementiert sind, sind die aufwärts gerichteten I/O-Schnittstellen (PCIe-Schnittstelle 354, DisplayPort-Schnittstelle 356 und Host-I/O-Schnittstelle 358) der USB4-Steuereinheit 334a externe Schnittstellen. Diese externen I/O-Schnittstellen werden im Allgemeinen über Leiterbahnen in einer Leiterplatte, auf die sowohl das Host-SoC als auch die USB4-Steuereinheitchips montiert sind, mit einem Host-Halbleiterchip, wie z. B. dem SoC 313, gekoppelt sein. Wenn eine ähnliche USB4-Steuereinheitfunktionalität in einem eingebetteten USB4-Steuereinheit-Block (z. B. dem USB4-Steuereinheit-Block 334b) auf einem SoC (z. B. dem SoC 313) implementiert ist, sind die PCIe-, DisplayPort- und Host-I/O-Schnittstellen interne Schnittstellen. Außerdem können in einigen Ausführungsformen zwei oder mehr aus der PCIe-, der DisplayPort- und der Host-I/O-Schnittstelle in einer Komposit-Schnittstelle implementiert sein, wenn sie in einer diskreten Komponente oder einem eingebetteten Block implementiert sind.
  • Automatisches Umschalten zwischen Software- und Firmware-Verbindungsmanagern
  • Die folgenden Ausführungsformen offenbaren Aspekte von Verfahren, Einrichtungen und Software/Firmware zum Implementieren von automatischem Umschalten zwischen Software- und Firmware-Verbindungsmanagern. Unter einem Aspekt ist ein Handshake-Mechanismus zwischen dem BIOS (z. B. UEFI) und dem Betriebssystem definiert, um unterstützte CM-Fähigkeit zu finden und von einem Hardware-CM zu einem Software-CM oder umgekehrt dynamisch umzuschalten, falls eine Nichtübereinstimmung vorhanden ist. Zusätzlich ist ein Mechanismus zum Einsetzen des korrekten Treibers basierend auf einem Klassencode, Zwei-Teile- oder Vier-Teile-Identifizierer (ID) definiert.
  • In einer Ausführungsform ist ein neues plattformweites Betriebssystemfähigkeits- (_OSC-) Bit (Teil der ACPI-Spezifikation) definiert, um die Betriebssystemunterstützung für einen Software-basierten CM anzugeben und einen Zweiwege-Handshake zwischen BIOS und OS bereitzustellen. Optional können andere Handshake-Mechanismen eingesetzt werden, wie z. B. Verwenden von „Oslndications“- und „OsIndicationsSupported“-EFI-Variablen (als Teil einer UEFI-Firmware-Implementierung).
  • Das BIOS wird entweder den Firmware- oder den Software-basierten Verbindungsmanager verwenden, basierend auf der früheren (letzten) CM-Einstellung. In einer Ausführungsform wird Plattform-Firmware verwendet, um auf nichtflüchtige Speichermechanismen zuzugreifen, wo die Einstellungen für Plattformvariablen gehalten werden. Es gibt vier mögliche Konfigurationseinstellungen:
    • • Software-CM dynamisch: Verwenden von Software-CM in Plattform-Firmware und OS (falls unterstützt). Falls im OS nicht unterstützt, Rückfall auf FW-CM
    • • Software-CM statisch: Verwenden nur von Software-CM in Plattform-Firmware und OS. Falls OS-SW-CM-Unterstützung nicht verfügbar ist, wird USB4 im OS nicht funktionieren.
    • • Firmware-CM dynamisch: Verwenden von Firmware-CM in Plattform-Firmware und OS (falls SW-CM nicht unterstützt ist). Das wird typischerweise auf einem OS-Downgrade von einem OS, das SW-CM unterstützt, zu einem OS, das SW-CM nicht unterstützt, getriggert.
    • • Firmware-CM statisch: Verwenden von Firmware-CM in Plattform-Firmware und OS. Falls OS native SW-CM-Unterstützung anfordert, Ablehnen der OS-Anforderung.
  • Wenn die Plattform bootet, wird die Einstellung für Software- versus Firmware-CM gelesen und auf den USB4-Host-Router und Plattform-Firmware angewandt, entweder unter Einsatz des FW-CM und nicht Laden des SW-CM, oder umgekehrt. Das Booten des OS wird dann weiter gehen, um das Booten der Plattform fertigzustellen.
  • Nach der _OSC-Bit-Auswertung, und falls erforderlich, wird ein Umschalten zu dem geeigneten FW- oder SW-CM automatisch ausgeführt, zusammen mit dem Aktualisieren von anwendbaren UEFI-Einstellungen. Während der Boot-Sequenz des Betriebssystems wird das _OSC-Verfahren zur Firmware-Bereitstellung durch das OS aufgerufen. Falls der Wert für native OS-Steuerung für USB4, der über das _OSC-Bit weitergegeben wird, mit der Plattform-Firmware-Einstellung übereinstimmt, akzeptiert die Plattform-Firmware die Einstellung. Falls der Wert für native OS-Steuerung für USB 4, der über _OSC weitergegeben wird, nicht mit den Plattform-Firmware-Einstellung übereinstimmt, dann gilt für die Plattform-Firmware:
    1. 1) Falls die Plattform-Firmware-Einstellung statisch ist, keine Änderung der Konfiguration; falls das OS native Steuerung anfordert, keine Genehmigung dafür.
    2. 2) Falls die Plattform-Firmware-Einstellung dynamisch ist:
      1. a. Aktualisierung der Plattformvariableneinstellung, um mit der neuen Einstellung übereinzustimmen - entweder SW-CM dynamisch oder FW-CM dynamisch;
      2. b. Neukonfigurieren des USB4-Host-Routers, um mit der neuen Konfiguration übereinzustimmen
      3. c. (Möglicherweise) Warten auf das Fertigstellen der Host-Router-Konfigurationsänderung und Initialisierung.
  • Nachfolgend den vorstehenden Operationen wird das OS das Booten bis zur Fertigstellung fortsetzen. Während nachfolgenden Laufzeitoperationen werden USB4-Verbindungsmanageroperationen über den SW-CM oder den FW-CM wie jeweils anwendbar implementiert.
  • 4 zeigt einen Ablaufplan 400, der Operationen und Logik zum Implementieren von automatischem Umschalten zwischen Software- und Firmware-Verbindungsmanagern gemäß einer Ausführungsform darstellt. Der Prozess beginnt mit einem Einschaltereignis in einem Startblock 402. In Reaktion darauf wird ein früher BIOS-Prozess initiiert und ausgeführt, wie in einem Block 404 abgebildet ist.
  • In einem Entscheidungsblock 406 wird eine Bestimmung vorgenommen, ob die frühere CM-Einstellung ein FW-CM oder ein SW-CM ist, wobei „früher“ der letzten CM-Einstellung entspricht. Wie vorstehend diskutiert kann die frühere CM-Einstellung gespeichert und über Firmware auf sie zugegriffen werden. Wie durch den linken Zweig gezeigt ist, wird, falls die frühere CM-Einstellung FW-CM war, der FW-CM in einem Block 408 aktiviert, und FW-CM-Aufzählungs- und Konfigurationsprozesse werden in einem Prozessblock 410 ausgeführt. Die Fortsetzung des BIOS-Boot-Prozesses wird dann ausgeführt, wie in einem Block 412 abgebildet ist.
  • Wie durch den rechten Zweig gezeigt ist, wird, falls die frühere CM-Einstellung SW-CM war, der SW-CM in einem Block 414 aktiviert, und SW-CM-Aufzählungs- und Konfigurationsprozesse werden in einem Prozessblock 416 ausgeführt. Die Fortsetzung des BIOS-Boot-Prozesses wird dann wie in Block 412 ausgeführt.
  • In einem Block 418 wird der BIOS-Boot-Prozess an einen Betriebssystem-Boot-Prozess übergeben. In einem Entscheidungsblock 420 wird eine Bestimmung durch das OS vorgenommen, um zu bestimmen, ob es die gleiche CM-Konfiguration unterstützt, die durch die vorstehend beschriebenen BIOS-Boot-Prozesse verwendet werden. Falls ja, fährt die Logik mit dem Fortsetzen des OS-Boot-Prozesses in einem Block 426 fort. Bei der Fertigstellung des OS-Boot-Prozesses werden Laufzeitoperationen auf der Plattform über die Ausführung verschiedener Software ausgeführt, wie durch einen Laufzeitendeblock 428 abgebildet ist. Falls die Antwort für den Entscheidungsblock 420 NEIN ist, fährt die Logik zu einem Block 422 fort, in dem die CM-Änderung auf die USB4-Konfiguration angewandt wird, und die UEFI-CM-Einstellung wird in einem Block 424 aktualisiert, um die Änderung widerzuspiegeln. Die Logik fährt dann zu Block 426 fort, um den OS-Boot-Prozess fortzusetzen.
  • Mechanismus zum Umschalten der CM-Betriebsart in Hardware
  • In einer Ausführungsform sind USB4-Steuereinheiten konfiguriert, zwei Betriebsarten zu unterstützen, die 1) eine „Durchlassbetriebsart“ und 2) eine „FW-CM-Betriebsart“ enthalten. Wie in einem Zustandsdiagramm 500 in 5 gezeigt ist, startet in einer Ausführungsform die USB4-Steuereinheit in der „Durchlassbetriebsart“ (Durchlasszustand 504), während sie aus dem Rücksetzen kommt (in Reaktion auf ein Einschaltereignis aus einem Ausschaltzustand 502). Wie in 6 gezeigt ist, lenkt während des „Durchlass“-Betriebszustands die Host-Steuereinheit-Firmware 602 eingehende Konfigurationsschichtsteuerpakete, die von dem Host-seitigen Software-CM-Treiber 600 empfangen werden, in die USB4.0-Konfigurationsschichtsteuerpakt-Routinglogik zu dem USB4-Fabric 604 um. Ähnlich werden eingehende Konfigurationsschichtsteuerpakete von dem USB4-Fabric 604 durch die Host-Steuereinheit-FW 604 zu dem SW-CM-Treiber 600 umgelenkt.
  • Wie in 7 gezeigt ist, aktiviert die Host-Steuereinheit-Firmware 700 während der „FW-CM-Betriebsart“ eingebettete Firmware-basierte CM-Logik. Konfigurationsschichtsteuerpakete, die von dem USB4.0-Fabric 702 stammen, werden durch einen in der Steuereinheit eingebetteten FW-CM (z. B. den FW-CM 339 in den 3a und 3b) verbraucht und behandelt
  • Wie in dem Zustandsdiagramm 500 gezeigt ist, kann die Betriebsart dynamisch zwischen der Durchlassbetriebsart (dem Durchlasszustand 504) und der FW-CM-Betriebsart (dem FW-CM-Zustand 506) umgeschaltet werden. In einer Ausführungsform ermöglicht eine auf dem PCIe-Konfigurationsraum basierende Mailbox, dass die Steuersystem-SW dynamisch zwischen diesen Betriebsarten umgeschaltet wird. Dieser dynamische Umschaltmechanismus unterstützt das Umschalten zwischen den Betriebsarten, ohne das Rücksetzen der USB4-Steuereinheit zu erfordern, und vermeidet somit Verzögerungen während der System-Boot-Sequenz.
  • Während des Umschaltens von der „Durchlassbetriebsart“ zu der „FW-CM-Betriebsart“ überprüft die Host-Steuereinheit-FW den Konfigurationszustand der USB4-Steuereinheit. Falls die USB4-Steuereinheit nicht initialisiert ist, war der SW-basierte CM vor dem Absenden des Schaltbefehls inaktiv, und die FW-CM-Logik wird aktiviert. Falls die USB4-Steuereinheit initialisiert ist, war der SW-basierte CM vor dem Absenden des Schaltbefehls aktiv. In diesem Fall wird die Host-Steuereinheit-FW die USB4-Topologie durch Rücksetzen der USB4-Abwärtsverbindungsstrecken zurücksetzen. Die Host-Steuereinheit wird außerdem sicherstellen, dass die USB4-Steuereinheitkonfiguration gültig ist, um das Rücksetzen der Host-Steuereinheit-Hardware zu vermeiden. Während des Umschaltens von der „FW-CM-Betriebsart“ zu der „Durchlassbetriebsart“ wird die Host-Steuereinheit-FW einfach die Paketumlenkungslogik aktivieren.
  • Einsetzen des korrekten Treibers basierend auf der CM-Konfiguration
  • Unabhängig von der CM-Konfiguration wird sich die Hardware (d. h. die native Host-Schnittstelle der USB4-Steuereinheit) auf ähnliche Weise präsentieren. Insbesondere werden ihre Geräte-ID, Anbieter-ID, Teilsystemgeräte-ID, Teilsystemanbieter-ID und Klassencode weiterhin gleich sein. Das macht es jedoch schwierig, den korrekten Treiber, der der aktuell konfigurierten CM-Betriebsart entspricht, zu laden.
  • Die folgenden drei Parameter sind zum Bewirken der korrekten Treiberkonfiguration verfügbar:
    • • FW CM: Verwenden des aktuellen FW-CM-Treibers
    • • SW-CM eines Drittanbieters: Verwenden des Software-basierten CM-Treibers durch einen Drittanbieter (z. B. Hersteller von USB4 oder SoC mit eingebettetem USB4-Host-Block)
    • • Natives Betriebssystem SW-CM: Inbox-Software-basierter CM-Treiber, entwickelt durch den OS-Anbieter (z. B. Microsoft für Windows-Betriebssystem oder verschiedene Linux-Anbieter für Linux-basiertes OS)
  • Unter einer Ausführungsform ist die Konfiguration des korrekten Treibers basierend auf der CM-Konfiguration unter Verwendung der folgenden Beispiele, die für ein auf Microsoft Windows basierendes OS implementiert sind, implementiert. Ein Fachmann wird erkennen, dass ähnliche Herangehensweisen für andere Betriebssysteme wie z. B. Linux-basierte Betriebssysteme unter Verwendung eines Treiber-ID-Schemas, das durch dieses Betriebssystem verwendet wird, verwendet werden können.
  • Unter dem Windows-Betriebssystem priorisiert das OS Treiber in der folgenden Reihenfolge:
    1. 1) auf 4-Teile-ID ausgerichtete Treiber
    2. 2) auf 2-Teile-ID ausgerichtete Treiber über
    3. 3) auf Klassencode ausgerichtete Treiber
    Eine 4-Teile-ID besteht aus einer Geräte-ID (DID), einer Anbieter-ID (VID), einer Teilsystemgeräte-ID (SDID) und einer Teilsystemanbieter-ID (SID). Eine 2-Teile-ID besteht aus einer Geräte-ID und einer Anbieter-ID. Der Klassencode wird verwendet, um die System-Software über den Typ (die Klasse) eines Geräts, wie z. B. USB 4.0, zu unterrichten, und spezifiziert weder eine Geräte-ID noch eine Anbieter-ID.
  • 8 zeigt eine/n Ablaufplan/Zustandsdiagramm 800, der/das einer ersten Startkonfiguration entspricht, unter der eine Plattform einen SW-CM-Treiber eines Drittanbieters unter Verwendung einer 2-Teile-ID auf einem Windows-Update (WU) hosten wird. In einem Entscheidungsblock 804 wählt der OEM (Originalgerätehersteller) der Plattform eine Konfiguration: nativer SW-CM des OS, SW-CM eines Drittanbieters oder FW-CM. Falls der OEM den nativen SW-CM-Treiber des OS wählt, wird die CM-Treiberkonfiguration auf den nativen SW-CM-Treiber des OS unter Verwendung der 4-Teile-ID aktualisiert, wie in einem Zustand 806 gezeigt ist. Beispielsweise wird das über ein Windows-Update ausgeführt. Falls der OEM die Option des SW-CM eines Drittanbieters wählt, wird die CM-Treiberkonfiguration nicht geändert, wie in einem Zustand 808 gezeigt ist. Falls der OEM die FW-CM-Option wählt, wird die CM-Treiberkonfiguration auf den FW-CM-Treiber unter Verwendung einer 4-Teile-ID aktualisiert, wie in einem Zustand 810 gezeigt ist.
  • 9 zeigt ein/en Ablaufplan/Zustandsdiagramm 900, der/das einer zweiten Startkonfiguration entspricht, unter der ein OS einen nativen SW-CM-Treiber des OS basierend auf einem Klassencode laden wird. In einem Entscheidungsblock 904 wählt der OEM der Plattform eines aus dem nativen SW-CM-Treiber des OS, dem SW-CM-Treiber eines Drittanbieters oder dem FW-CM-Treiber. Falls der OEM den nativen SW-CM-Treiber des OS wählt, wird die CM-Treiberkonfiguration auf den nativen SW-CM-Treiber des OS unter Verwendung der 4-Teile-ID aktualisiert, wie in einem Zustand 906 gezeigt ist. Falls der OEM die Option des SW-CM-Treibers eines Drittanbieters wählt, wird die CM-Treiberkonfiguration auf den SW-CM-Treiber des Drittanbieters unter Verwendung einer 4-Teile-ID aktualisiert, wie in einem Zustand 908 gezeigt ist. Falls der OEM die Option des FW-CM-Treibers wählt, wird die CM-Treiberkonfiguration nicht verändert, wie in einem Zustand 910 gezeigt ist. Derselbe (derzeitige) FW-CM-Treiber kann unter Verwendung einer 4-Teile-ID auf einem Windows-Update verwendet werden.
  • 10 zeigt ein/en Ablaufplan/Zustandsdiagramm 1000, der/das einer dritten Startkonfiguration entspricht, unter der ein OEM einen nativen SW-CM-Treiber des OS basierend auf einem Klassencode auf entweder einen nativen SW-CM-Treiber des OS, einen SW-CM-Treiber eines Drittanbieters oder einen FW-CM-Treiber basierend auf einer 4-Teil-ID überschreiben wird. Wie zuvor wählt in einem Entscheidungsblock 1004 der OEM der Plattform den nativen SW-CM-Treiber des OS, den SW-CM-Treiber eines Drittanbieters oder den FW-CM-Treiber. Falls der OEM den nativen SW-CM-Treiber des OS wählt, wird derselbe native SW-CM-Treiber des OS verwendet, wobei die CM-Treiberkonfiguration aktualisiert wird, um den Klassencode durch eine 4-Teile-ID zu ersetzen, wie in einem Zustand 1006 gezeigt ist. Falls der OEM die Option des SW-CM-Treibers des Drittanbieters wählt, wird die CM-Treiberkonfiguration auf den SW-CM-Treiber des Drittanbieters unter Verwendung einer 4-Teile-ID aktualisiert, wie in einem Zustand 1008 gezeigt ist. Falls der OEM die FW-CM-Treiber-Option wählt, wird die CM-Treiberkonfiguration auf den FW-CM-Treiber unter Verwendung einer 4-Teile-ID aktualisiert, wie in einem Zustand 810 gezeigt ist.
  • Beispielhafte UEFI-Firmware-Ausführungsformen
  • In einigen Ausführungsformen umfasst die Firmware, die in der vorstehenden Diskussion als „BIOS“ bezeichnet ist, UEFI-Firmware-Komponenten und entsprechende ausführbare Anweisungen. UEFI ist eine öffentliche Industrie-Spezifikation (aktuelle Version UEFI-Spezifikation Version 2.8, März 2019), die eine abstrakte programmgesteuerte Schnittstelle zwischen Plattform-Firmware und Schrumpf-Betriebssystemen oder anderen angepassten Anwendungsumgebungen beschreibt. Die UEFI-Spezifikation enthält außerdem eine Plattforminitialisierungs- (PI-) Spezifikation (aktuelle Version 1.7, Januar 2019). Das UEFI-Framework enthält Vorbereitungen zum Erweitern der BIOS-Funktionalität über das hinaus, was historisch durch den in einer BIOS-Vorrichtung einer Plattform (z. B. einem Flash-Speicher) gespeicherten BIOS-Code bereitgestellt war. Insbesondere ermöglicht das UEFI, dass Firmware in der Form von Firmware-Modulen und Treibern aus einer Vielzahl unterschiedlicher Betriebsmitteln, die primäre und sekundäre Flash-Vorrichtungen, Option-ROMs, verschiedene persistente Speichervorrichtungen (z. B. Festplatten, CD-ROMs usw.) enthalten, und sogar über Computer-Netze geladen werden kann.
  • 11 zeigt ein/e Ereignissequenz/Architekturdiagramm, die/das verwendet wird, um Operationen darzustellen, die durch eine Plattform unter dem Framework in Reaktion auf einen Kaltstart (z. B. ein Abschalten/Anschalten bei Rücksetzen) ausgeführt werden. Der Prozess ist logisch in mehrere Phasen unterteilt, die eine Vor-EFI-Initialisierungsumgebungs- (PEI-) Phase, eine Treiberausführungsumgebungs- (DXE-) Phase, eine Boot-Vorrichtungsauswahl- (BDS-) Phase, eine Transientsystemlade- (TSL-) Phase und eine Betriebssystemlaufzeit- (RT-) Phase enthalten. Eine optionale Sicherheitsphase (nicht gezeigt) kann vor der PEI-Phase implementiert sein. Die aufeinander aufgebauten Phasen dienen zum Bereitstellen einer geeigneten Laufzeitumgebung für das OS und die Plattform.
  • Die PEI-Phase stellt ein standardisiertes Verfahren zum Laden und Aufrufen spezifischer initialer Konfigurationsroutinen für den Prozessor (CPU), den Chipsatz und das Motherboard bereit. Die PEI-Phase ist für das Initialisieren von genug des Systems zuständig, um eine stabile Basis für die nachfolgenden Phasen bereitzustellen. Die Initialisierung der Plattformkernkomponenten, die die CPU, den Chipsatz und die Hauptplatine (d. h. das Motherboard) enthalten, wird während der PEI-Phase ausgeführt. Diese Phase ist auch als die „frühe Initialisierungs-“ Phase bezeichnet. Typische Operationen, die während dieser Phase ausgeführt werden, enthalten die POST-(Einschalt-Selbsttest-) Operationen und Finden der Plattformbetriebsmittel. Insbesondere findet die PEI-Phase den Speicher und bereitet eine Betriebsmittelkarte vor, die an die DXE-Phase übergeben wird. Der Zustand des Systems am Ende der PEI-Phase wird an die DXE-Phase durch eine Liste von positionsunabhängigen Datenstrukturen, die als Übergabeblöcke (HOBs) bezeichnet ist, übergeben.
  • Die DXE-Phase ist eine Phase, während der der Großteil der Systeminitialisierung ausgeführt wird. Die DXE-Phase wird durch mehrere Komponenten unterstützt, die den DXE-Kern 1100, den DXE-Dispatcher 1102 und eine Gruppe von DXE-Treibern 1104 enthalten. Der DXE-Kern 1100 produziert eine Gruppe von Boot-Diensten 1106, Laufzeitdiensten 1108 und DXE-Diensten 1110. Der DXE-Dispatcher 1102 ist für das Finden und Ausführen von DXE-Treibern 1104 in der korrekten Reihenfolge zuständig. Die DXE-Treiber 1104 sind sowohl für das Initialisieren des Prozessors, des Chipsatzes und der Plattformkomponenten als auch für das Bereitstellen von Software-Abstraktionen für Konsole und Boot-Vorrichtungen zuständig. Diese Komponenten arbeiten zusammen, um die Plattform zu initialisieren, und stellen die Dienste bereit, die zum Booten eines Betriebssystems erforderlich sind. Die DXE- und Boot-Vorrichtungsauswahl-Phasen arbeiten zusammen, um Konsolen aufzubauen und das Booten von Betriebssystemen zu versuchen. Die DXE-Phase wird beendet, wenn ein Betriebssystem erfolgreich seinen Boot-Prozess beginnt (d. h. die BDS-Phase startet). Nur für die Laufzeitdienste und ausgewählte DXE-Dienste, die durch den DXE-Kern bereitgestellt sind, und ausgewählte Dienste, die durch Laufzeit-DXE-Treiber bereitgestellt sind, ist es erlaubt, in der OS-Laufzeitumgebung weiter zu bestehen. Das Ergebnis von DXE ist die Präsentation einer vollständig gebildeten EFI-Schnittstelle.
  • Der DXE-Kern ist so konstruiert, dass er vollständig portierbar ist, ohne CPU-, Chipsatz- oder Plattformabhängigkeiten. Das wird durch das Konstruieren in mehreren Merkmalen erreicht. Erstens hängt der DXE-Kern nur von der HOB-Liste für seinen initialen Zustand ab. Das bedeutet, dass der DXE-Kern nicht von irgendwelchen Diensten aus einer früheren Phase abhängt, so dass alle früheren Phasen entladen werden können, sobald die HOB-Liste an den DXE-Kern weitergegeben ist. Zweitens enthält der DXE-Kern keine fest codierten Adressen. Das bedeutet, dass der DXE-Kern irgendwo im physikalischen Speicher geladen werden kann und er korrekt funktionieren kann, unabhängig davon, wo sich der physikalische Speicher oder wo sich Firmware-Segmente in dem physikalischen Adressraum des Prozessors befinden. Drittens enthält der DXE-Kern keine CPU-spezifischen, Chipsatz-spezifischen oder plattformspezifischen Informationen. Vielmehr ist der DXE-Kern von der System-Hardware durch eine Gruppe von architektonischen Protokollschnittstellen abstrahiert. Diese architektonischen Protokollschnittstellen werden durch DXE-Treiber 1104, die durch den DXE-Dispatcher 1102 aufgerufen werden, produziert.
  • Der DXE-Kern produziert eine EFI-Systemtabelle 1200 und ihre zugeordnete Gruppe von Boot-Diensten 1106 und Laufzeitdiensten 1108, wie in 12 gezeigt ist. Der DXE-Kern pflegt außerdem eine Handle-Datenbank 1202. Die Handle-Datenbank umfasst eine Liste aus einem oder mehreren Handles, wobei ein Handle eine Liste aus einem oder mehreren eindeutigen Protokoll-GUIDs („Globally Unique Identifiers“) ist, die auf entsprechende Protokolle 1204 abbilden. Ein Protokoll ist eine Software-Abstraktion für eine Gruppe von Diensten. Einige Protokolle abstrahieren I/O-Vorrichtungen, und andere Protokolle abstrahieren eine allgemeine Gruppe von Systemdiensten. Ein Protokoll beinhaltet typischerweise eine Gruppe von APIs und eine Anzahl von Datenfeldern. Jedes Protokoll wird durch einen GUID benannt, und der DXE-Kern produziert Dienste, die ermöglichen, dass Protokolle in der Handle-Datenbank eingetragen werden. Wenn der DXE-Dispatcher DXE-Treiber ausführt, werden zusätzliche Protokolle der Handle-Datenbank hinzugefügt, die architektonische Protokolle enthalten, die verwendet werden, um den DXE-Kern von plattformspezifischen Einzelheiten zu abstrahieren.
  • Die Boot-Dienste umfassen eine Gruppe von Diensten, die während der DXE- und der BDS-Phase verwendet werden. Unter anderem enthalten diese Dienste Speicherdienste, Protokoll-Handler-Dienste und Treiberunterstützungsdienste. Speicherdienste stellen Dienste zum Zuweisen und Freigeben von Speicherseiten und Zuweisen und Freigeben des Speicher-Pools auf Byte-Grenzen bereit. Sie stellen außerdem einen Dienst zum Abrufen einer Abbildung der gesamten aktuellen physikalischen Speichernutzung in der Plattform bereit. Protokoll-Handler-Dienste stellen Dienste zum Hinzufügen und Entfernen von Handles aus der Handle-Datenbank bereit. Sie stellen außerdem Dienste zum Hinzufügen und Entfernen von Protokollen aus den Handles in der Handle-Datenbank bereit. Zusätzliche Dienste sind verfügbar, die es jeder Komponente ermöglichen, Handles in der Handle-Datenbank nachzuschlagen und Protokolle in der Handle-Datenbank zu öffnen und zu schließen. Unterstützungsdienste stellen Dienste zum Verbinden und Trennen von Treibern mit Vorrichtungen in der Plattform bereit. Diese Dienste verwenden durch die BDS-Phase verwendet, um entweder alle Treiber mit allen Vorrichtungen zu verbinden oder um nur die minimale Anzahl von Treibern mit Vorrichtungen zu verbinden, die erforderlich sind, um die Konsolen aufzubauen und ein Betriebssystem zu booten (d. h. zum Unterstützen eines schnellen Boot-Mechanismus).
  • Im Gegensatz zu Boot-Diensten sind Laufzeitdienste sowohl während der Vor-Boot- als auch der OS-Laufzeitoperationen verfügbar. Einer der Laufzeitdienste, die durch hier offenbarte Ausführungsformen eingesetzt werden, ist die Variablendienste. Wie nachstehend genauer beschrieben ist stellen die Variablendienste Dienste zum Nachschlagen, Hinzufügen und Entfernen von Umgebungsvariablen sowohl aus flüchtigem als auch nichtflüchtigem Speicher bereit. Wie sie hier verwendet sind, sind die Variablendienste als „generisch“ bezeichnet, da sie von irgendwelchen Systemkomponenten, für die Firmware durch Ausführungsformen der Erfindung aktualisiert wird, unabhängig sind.
  • Die DXE-Diensttabelle enthält Daten, die einer ersten Gruppe von DXE-Diensten 1206a, die nur während des Vor-Boot verfügbar sind, und einer zweiten Gruppe von DXE-Diensten 1206b, die während sowohl des Vor-Boot als auch der OS-Laufzeit verfügbar sind, entsprechen. Die Dienste nur während des Vor-Boot enthalten globale Kohärenzdomänendienste, die Dienste zum Managen von I/O-Betriebsmitteln, speicherabgebildeten I/O-Betriebsmitteln und Systemspeicherbetriebsmitteln in der Plattform bereitstellen. Außerdem sind DXE-Dispatcher-Dienste enthalten, die Dienste zum Managen von DXE-Treibern, die durch den DXE-Dispatcher abgesendet werden, bereitstellen.
  • Auf die Dienste, die durch jeden aus den Boot-Diensten 1106, den Laufzeitdiensten 1108 und den DXE-Diensten angeboten werden, wird über entsprechende Gruppen von APIs 1112, 1114 und 1116 zugegriffen. Die APIs stellen eine abstrahierte Schnittstelle bereit, die es nachfolgend geladenen Komponenten ermöglicht, ausgewählte Dienste, die durch den DXE-Kern bereitgestellt sind, einzusetzen.
  • Nachdem der DXE-Kern 1100 initialisiert ist, wird die Steuerung an den DXE-Dispatcher 1102 übergeben. Der DXE-Dispatcher ist für das Laden und Aufrufen von DXE-Treibern, die in Firmware-Datenträgern, die logischen Speichereinheiten entsprechen, aus denen Firmware unter dem EFI-Framework geladen wird, gefunden werden, zuständig. Der DXE-Dispatcher sucht nach Treibern in den Firmware-Datenträgern, die durch die HOB-Liste beschrieben sind. Wenn die Ausführung fortschreitet, können andere Firmware-Datenträger lokalisiert werden. Wenn dem so ist, durchsucht sie der Dispatcher ebenfalls nach Treibern.
  • Es gibt zwei Unterklassen von DXE-Treibern. Die erste Unterklasse enthält DXE-Treiber, die sehr früh in der DXE-Phase ausgeführt werden. Die Ausführungsreihenfolge dieser DXE-Treiber hängt von dem Vorhandensein und den Inhalten einer α-priori-Datei und der Auswertung von Abhängigkeitsausdrücken ab. Diese frühen DXE-Treiber werden typischerweise Prozessor-, Chipsatz- und Plattform-Initialisierungscode enthalten. Diese frühen Treiber werden außerdem typischerweise die architektonischen Protokolle produzieren, die erforderlich sind, damit der DXE-Kern sein vollständiges Komplement von Boot-Diensten und Laufzeitdiensten produziert.
  • Die zweite Klasse von DXE-Treibern sind diejenigen, die mit dem UEFI 2.0-Treibermodell konform sind. Diese Treiber führen keine Hardware-Initialisierung aus, wenn sie durch den DXE-Dispatcher ausgeführt werden. Stattdessen tragen sie eine Treiberbindeprotokollschnittstelle in die Handle-Datenbank ein. Die Gruppe von Treiberbindeprotokollen wird in der BDS-Phase verwendet, um die Treiber mit Vorrichtungen zu verbinden, die erforderlich sind, um Konsolen aufzubauen und den Zugriff auf Boot-Vorrichtungen bereitzustellen. Die DXE-Treiber, die mit dem UEFI 2.0-Treibermodell konform sind, stellen letztlich Software-Abstraktionen für Konsolenvorrichtungen und Boot-Vorrichtungen bereit, wenn sie ausdrücklich dazu aufgefordert werden.
  • Irgendein DXE-Treiber kann die Boot-Dienste und Laufzeitdienste verbrauchen, um ihre Funktionen auszuführen. Die frühen DXE-Treiber müssen jedoch erkennen, dass nicht alle diese Dienste verfügbar sein können, wenn sie ablaufen, weil alle architektonischen Protokolle noch nicht eingetragen worden sein können. Die DXE-Treiber müssen Abhängigkeitsausdrücke verwenden, um zu garantieren, dass die Dienste und Protokollschnittstellen, die sie benötigen, verfügbar sind, bevor sie ausgeführt werden.
  • Die DXE-Treiber, die mit dem UEFI 2.0-Treibermodell konform sind, müssen sich mit dieser Möglichkeit nicht beschäftigen. Diese Treiber tragen einfach das Treiberbindeprotokoll in die Handle-Datenbank ein, wenn sie ausgeführt werden. Diese Operation kann ohne die Verwendung irgendwelcher architektonischen Protokolle ausgeführt werden. In Verbindung mit der Eintragung der Treiberbindeprotokolle kann ein DXE-Treiber eine API durch Verwenden der InstallConfigurationTable-Funktion „veröffentlichen“. Diese veröffentlichten Treiber werden durch APIs 1118 abgebildet. Unter EFI legt die Veröffentlichung einer API die API für Zugriff durch andere Firmware-Komponenten offen. Die APIs stellen Schnittstellen für das Gerät, den Bus oder den Dienst, der/dem der DXE entspricht, während ihrer jeweiligen Lebensdauer bereit.
  • Das architektonische BDS-Protokoll läuft während der BDS-Phase ab. Das architektonische BDS-Protokoll lokalisiert und lädt verschiedene Anwendungen, die in der Vor-Boot-Dienstumgebung ablaufen. Solche Anwendungen können einen herkömmlichen OS-Boot-Lader oder erweiterte Dienste, die anstelle des oder vor dem Laden des endgültigen OS laufen können, repräsentieren. Solche erweiterten Vor-Boot-Dienste könnten Aufbaukonfiguration, erweiterte Diagnose, Flash-Aktualisierungsunterstützung, OEM-Mehrwerte oder den OS-Boot-Code enthalten. Ein Boot-Dispatcher 1120 wird während der BDS-Phase verwendet, um die Auswahl eines Boot-Ziels, z. B. eines OS, das durch das System gebootet werden soll, zu ermöglichen.
  • Während der TSL-Phase läuft ein endgültiger Boot-Lader 1122 ab, um das ausgewählte OS zu laden. Sobald das OS geladen worden ist, werden die Boot-Dienste 1106 und viele der Dienste, die in Verbindung mit den DXE-Treibern 1104 über APIs 1118 bereitgestellt sind, und auch die DXE-Dienste 1206a nicht weiter benötigt. Dementsprechend sind diese reduzierten Gruppen von APIs, auf die während der OS-Laufzeit zugegriffen werden kann, als APIs 116A und 118A in 11 abgebildet.
  • In Übereinstimmung mit Aspekten der Erfindung kann das Prä-Boot/Boot-Framework von 11 implementiert sein, um das Aktualisieren verschiedener Firmware, die System-Firmware (d. h. Firmware, die auf einer Motherboard-Firmware-Vorrichtung oder dergleichen gespeichert ist) und Add-in-Firmware (z. B. Firmware, die üblicherweise Option-ROMs zugeordnet ist) enthält, zu ermöglichen. Das wird teilweise durch APIs, die durch die jeweiligen Komponenten/Vorrichtungen während der DXE-Phase offengelegt sind, und durch die Verwendung des Variablendienste-Laufzeitdienstes unterstützt.
  • Wie vorstehend diskutiert kann in einigen Ausführungsformen ein OSC-(Betriebssystemfähigkeits-) Bit verwendet werden, um die Unterstützung des Betriebssystems für einen Software-basierten CM anzugeben und einen Zweiwege-Handshake zwischen dem BIOS und dem OS bereitstellen. Wie in 12 gezeigt ist, kann ein _OSC-Bit 1208, das ACPI zugeordnet ist, in einer ACPI-Tabelle 1210 gespeichert sein. Wie ebenfalls vorstehend diskutiert kann entweder eine „OsIndications“-EFI-Variable 1212 oder eine „OsIndicationsSupported“-EFI-Variable 1214 in dem Zweiwege-Handshake zwischen BIOS und OS verwendet werden, die jeweils durch die Variablendienste 1216 zugänglich sind.
  • Es ist durch Fachleute zu verstehen, dass andere BIOS-Architekturen, die nicht UEFI sind, auf eine ähnliche Weise verwendet werden können, und dass die Verwendung von UEFI in der vorstehenden Beschreibung und den Zeichnungsfiguren lediglich beispielhaft und nicht einschränkend ist. Zusätzlich ist auch zu verstehen, dass verschiedene Aspekte der Ausführungsformen, die hier offenbart sind, ebenfalls beispielhaft und nicht einschränkend sind.
  • Obwohl einige Ausführungsformen in Bezug auf spezielle Implementierungen beschrieben worden sind, sind andere Implementierungen gemäß einigen Ausführungsformen möglich. Zusätzlich müssen die Anordnung und/oder Reihenfolge von Elementen oder anderen Merkmalen, die in den Zeichnungen dargestellt und/oder hier beschrieben sind, nicht in der speziellen dargestellten und beschriebenen Form angeordnet sein. Viele andere Anordnungen sind gemäß einigen Ausführungsformen möglich.
  • In jedem in einer Figur gezeigten System können die Elemente in einigen Fällen jeweils das gleiche Bezugszeichen oder ein unterschiedliches Bezugszeichen aufweisen, um darauf hinzudeuten, dass das repräsentierte Element unterschiedlich und/oder ähnlich sein könnte. Ein Element kann jedoch flexibel genug sein, um unterschiedliche Implementierungen aufzuweisen und mit einigen der oder allen hier gezeigten oder beschriebenen Systemen zu arbeiten. Die in den Figuren gezeigten verschiedenen Elemente können gleich oder unterschiedlich sein. Es ist beliebig, welches als ein erstes Element bezeichnet ist und welches als ein zweites Element bezeichnet ist.
  • In der Beschreibung und den Ansprüchen können die Begriffe „gekoppelt“ und „verbunden“, zusammen mit ihren Ableitungen, verwendet sein. Es ist zu verstehen, dass diese Begriffe nicht als Synonyme füreinander vorgesehen sind. Vielmehr kann in speziellen Ausführungsformen „verbunden“ verwendet sein, um anzugeben, dass zwei oder mehr Elemente in direktem physikalischem oder elektrischem Kontakt miteinander sind. „Gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem physikalischem oder elektrischem Kontakt sind. „Gekoppelt“ kann jedoch auch bedeuten, dass zwei oder mehr Elemente nicht in direktem Kontakt miteinander sind, jedoch immer noch miteinander zusammenarbeiten oder zusammenwirken. Zusätzlich bedeutet „kommunikationstechnisch gekoppelt“, dass es zwei oder mehr Elementen, die in direktem Kontakt miteinander sein können oder nicht, möglich ist, miteinander zu kommunizieren. Beispielsweise falls die Komponente A mit der Komponente B verbunden ist, die wiederum mit der Komponente C verbunden ist, kann die Komponente A mit der Komponente C unter Verwendung der Komponente B als eine Zwischenkomponente kommunikationstechnisch gekoppelt sein.
  • Eine Ausführungsform ist eine Implementierung oder ein Beispiel der Erfindungen. Bezugnahme in der Spezifikation auf „eine Ausführungsform“, „einige Ausführungsformen“ oder „andere Ausführungsformen“ bedeutet, dass ein/e spezielle/s Merkmal, Struktur oder Eigenschaft, das/die in Verbindung mit den Ausführungsformen beschrieben ist, in wenigstens einigen Ausführungsformen, jedoch nicht notwendigerweise in allen Ausführungsformen, der Erfindung enthalten ist. Das verschiedene Auftreten von „einer Ausführungsform“ oder „einigen Ausführungsformen“ bezieht sich nicht notwendigerweise immer auf dieselben Ausführungsformen.
  • Nicht alle Komponenten, Merkmale, Strukturen, Eigenschaften usw., die hier beschrieben und dargestellt sind, müssen in einer speziellen Ausführungsform oder Ausführungsformen enthalten sein. Falls die Spezifikation feststellt, dass eine Komponente, ein Merkmal, eine Struktur oder eine Eigenschaft enthalten sein „kann“ oder „könnte“, ist es beispielsweise nicht erforderlich, dass diese/s spezielle Komponente, Merkmal, Struktur oder Eigenschaft enthalten ist. Falls sich die Spezifikation oder der Anspruch auf „ein“ Element bezieht, bedeutet das nicht, dass nur ein solches Element vorhanden ist. Falls sich die Spezifikation oder die Ansprüche auf „ein zusätzliches“ Element beziehen, schließt das nicht aus, dass mehr als eines des zusätzlichen Elements vorhanden ist.
  • Kursiv dargestellte Buchstaben, wie z. B. ‚M‘ und ‚N‘ in der vorstehenden ausführlichen Beschreibung sind verwendet, um eine Ganzzahl anzugeben, und die Verwendung eines speziellen Buchstabens ist nicht auf spezielle Ausführungsformen beschränkt. Außerdem kann der gleiche Buchstabe in separaten Ansprüchen verwendet sein, um separate Ganzzahlen zu repräsentieren, oder es können unterschiedliche Buchstaben verwendet sein. Zusätzlich kann die Verwendung eines speziellen Buchstabens in der ausführlichen Beschreibung mit dem Buchstaben, der in einem Anspruch verwendet ist, der zu demselben Gegenstand in der ausführlichen Beschreibung gehört, übereinstimmen oder nicht.
  • Wie vorstehend diskutiert können die verschiedenen Aspekte der Ausführungsformen hier durch entsprechende Software- und/oder Firmware-Komponenten und Anwendungen, wie z. B. Software und/oder Firmware, die durch einen eingebetteten Prozessor ausgeführt wird, oder dergleichen unterstützt werden. Somit können Ausführungsformen dieser Erfindung als ein Software-Programm, Software-Module, Firmware und/oder verteilte Software, die auf einer Form eines Prozessors, Verarbeitungskerns oder eingebetteter Logik in einer virtuellen Maschine, die auf einem Prozessor oder Kern läuft oder auf andere Weise auf einem oder innerhalb eines nichttransitorischen computerlesbaren oder maschinenlesbaren Speichermedium implementiert oder realisiert ist, verwendet sein oder zu deren Unterstützung dienen. Ein nicht-transitorisches computerlesbares oder maschinenlesbares Speichermedium enthält irgendeinen Mechanismus zum Speichern oder Übertragen von Informationen in einer durch eine Maschine (z. B. einen Computer) lesbaren Form. Beispielsweise enthält ein nicht-transitorisches computerlesbares oder maschinenlesbares Speichermedium irgendeinen Mechanismus, der Informationen in einer Form bereitstellt (d. h. speichert und/oder überträgt), die für einen Computer oder eine Berechnungsmaschine (z. B. eine Berechnungsvorrichtung, ein elektronisches System usw.) zugänglich ist, wie z. B. aufzeichnungsfähige/nicht aufzeichnungsfähige Medien (z. B. Festwertspeicher (ROM), Direktzugriffsspeicher (RAM), Magnetplattenspeichermedien, optische Speichermedien, Flash-Speichervorrichtungen usw.). Der Inhalt kann direkt ausführbar („Objekt“ oder „ausführbare“ Form), Quellcode oder Differenzcode („Delta“ oder „Patch“-Code) sein. Ein nicht-transitorisches computerlesbares oder maschinenlesbares Speichermedium kann außerdem einen Speicher oder eine Datenbank enthalten, aus dem/der Inhalt heruntergeladen werden kann. Das nicht-transitorische computerlesbare oder maschinenlesbare Speichermedium kann außerdem eine Vorrichtung oder ein Produkt enthalten, das darauf zur Zeit des Verkaufs oder der Auslieferung gespeicherten Inhalt aufweist. Somit kann das Ausliefern einer Vorrichtung mit gespeichertem Inhalt oder das Anbieten von Inhalt zum Herunterladen über ein Kommunikationsmedium als Bereitstellen eines Herstellungserzeugnisses verstanden werden, das ein nicht-transitorisches computerlesbares oder maschinenlesbares Speichermedium mit solchem hier beschriebenen Inhalt umfasst.
  • Die Operationen und Funktionen, die durch verschiedene hier beschriebene Komponenten ausgeführt werden, können durch Software, die auf einem Verarbeitungselement abläuft, über eingebettete Hardware oder dergleichen oder irgendeine Kombination aus Hardware und Software implementiert sein. Solche Komponenten können als Software-Module, Hardware-Module, Spezial-Hardware (z. B. anwendungsspezifische Hardware, ASICs, DSPs usw.), eingebettete Steuereinheiten, fest verdrahtete Schaltungsanordnung, Hardware-Logik usw. implementiert sein. Software-Inhalt (z. B. Daten, Anweisungen, Konfigurationsinformationen usw.) können über ein Herstellungserzeugnis bereitgestellt sein, das ein nicht-transitorisches computerlesbares oder maschinenlesbares Speichermedium enthält, das Inhalt bereitstellt, der Anweisungen repräsentiert, die ausgeführt werden können. Der Inhalt kann dazu führen, dass ein Computer verschiedene hier beschriebene Funktionen/Operationen ausführt.
  • Wie hier verwendet kann eine Liste von Elementen, die durch den Begriff „wenigstens eines aus“ verbunden sind, irgendeine Kombination der aufgelisteten Elemente bedeuten. Beispielsweise kann der Ausdruck „wenigstens eines aus A, B oder C“ A; B; C; A und B; A und C; B und C; oder A, B und C bedeuten.
  • Die vorstehende Beschreibung dargestellter Ausführungsformen der Erfindung, einschließlich dessen, was in der Zusammenfassung beschrieben ist, ist nicht als vollständig oder zum Einschränken der Erfindung auf die präzisen offenbarten formen vorgesehen. Obwohl spezifische Ausführungsformen der und Beispiele für die Erfindung hier zu erläuternden Zwecken beschrieben sind, sind verschiedene äquivalente Modifikationen innerhalb des Schutzbereichs der Erfindung möglich, wie Fachleute der relevanten Technik erkennen werden.
  • Diese Modifikationen können an der Erfindung im Hinblick auf die vorstehende ausführliche Beschreibung vorgenommen werden. Die in den folgenden Ansprüchen verwendeten Begriffe sollten nicht so gedeutet werden, dass sie die Erfindung auf die in der Spezifikation und den Zeichnungen offenbarten spezifischen Ausführungsformen einschränken. Vielmehr soll der Schutzbereich der Erfindung vollständig durch die folgenden Ansprüche bestimmt werden, die in Übereinstimmung mit eingeführten Doktrinen für die Interpretation von Ansprüchen gedeutet werden sollen.

Claims (24)

  1. Verfahren, das durch eine Host-Plattform implementiert ist, die eine Steuereinheit für den universellen seriellen Bus 4 (USB4) umfasst und einen Firmware-basierten (FW-) USB4-Konfigurationsmanager (CM) und einen Software-basierten (SW-) USB4-CM enthält, wobei das Verfahren Folgendes umfasst: während eines ersten Plattform-Boot-Prozesses Booten eines BIOS der Host-Plattform; Detektieren einer früheren CM-Einstellung für die Host-Plattform und Aktivieren des FW-CM oder SW-CM basierend auf der früheren CM-Einstellung, wobei der FW-CM oder SW-CM, der aktiviert wird, einen BIOS-aktivierten CM umfasst; Ausführen einer Betriebssystem- (OS-) Übergabe von dem BIOS zu einem OS-Boot-Prozess; Bestimmen, ob das OS die Verwendung des BIOS-aktivierten CM unterstützt; wenn das OS die Verwendung des BIOS-aktivierten CM nicht unterstützt, Umschalten zu einem CM, der durch das OS unterstützt wird, der eines aus einem FW-CM oder SW-CM umfasst, wobei der CM, zu dem umgeschaltet wird, einen OS-geschalteten CM umfasst; und Aktualisieren der früheren CM-Einstellung; Fertigstellen des Bootens des OS; und Verwenden des OS-geschalteten CM während des Laufzeitbetriebs der Host-Plattform.
  2. Verfahren nach Anspruch 1, das ferner Folgendes umfasst: während eines zweiten Plattform-Boot-Prozesses Booten des BIOS der Host-Plattform; Detektieren einer früheren CM-Einstellung für die Host-Plattform und Aktivieren der Verwendung des FW-CM oder SW-CM basierend auf der früheren CM-Einstellung, wobei der FW-CM oder SW-CM, der aktiviert ist, einen BIOS-aktivierten CM umfasst; Ausführen einer Betriebssystem- (OS-) Übergabe zu dem OS-Boot-Prozess; Bestimmen, ob das OS die Verwendung des BIOS-aktivierten CM unterstützt; wenn das OS die Verwendung des BIOS-aktivierten CM unterstützt Fertigstellen des Bootens des OS; und Verwenden des BIOS-aktivierten CM während des Laufzeitbetriebs der Host-Plattform.
  3. Verfahren nach Anspruch 1 oder 2, wobei die Host-Plattform eine/n „Advanced Configuration and Power Interface“- (ACPI-) Komponente oder Block enthält und die frühere CM-Einstellung ein Betriebssystemfähigkeits- (OSC-) Bit umfasst, auf das über das BIOS zugegriffen wird.
  4. Verfahren nach einem der vorhergehenden Ansprüche, wobei das BIOS „Universal Extensible Firmware Interface“- (UEFI-) Firmware umfasst und die frühere CM-Einstellung als eine EFI-Variable gespeichert ist.
  5. Verfahren nach einem der vorhergehenden Ansprüche, das ferner das Neukonfigurieren eines Host-Routers in der USB4-Steuereinheit in Übereinstimmung mit dem OS-geschalteten CM umfasst.
  6. Verfahren nach einem der vorhergehenden Ansprüche, wobei der OS-geschaltete CM der SW-CM ist, die USB4-Steuereinheit Host-Steuereinheit-Firmware enthält und die USB4-Steuereinheit direkt oder indirekt mit einem USB4-Fabric gekoppelt ist, das ferner das Betreiben der USB4-Steuereinheit in einer Durchlassbetriebsart, unter der Konfigurationsschichtsteuerpakete, die von einem SW-CM-Treiber stammen, der dem SW-CM zugeordnet ist, durch die Host-Steuereinheit-Firmware zu dem USB4-Fabric umgelenkt werden und wobei die Konfigurationsschichtsteuerpakete, die von dem USB4-Fabric stammen, durch die Host-Steuereinheit-Firmware zu dem SW-CM-Treiber umgelenkt werden, umfasst.
  7. Verfahren nach einem der vorhergehenden Ansprüche, wobei der OS-geschaltete CM der FW-CM ist, die USB4-Steuereinheit Host-Steuereinheit-Firmware enthält und die USB4-Steuereinheit direkt oder indirekt mit einem USB4-Fabric gekoppelt ist, das ferner das Betreiben der USB4-Steuereinheit in einer FW-CM-Betriebsart, unter der Konfigurationsschichtsteuerpakete von der Host-Steuereinheit-Firmware zu dem USB4-Fabric weitergeleitet werden und wobei Konfigurationsschichtsteuerpakete, die von dem USB4-Fabric stammen, zu der Host-Steuereinheit-Firmware weitergeleitet werden, umfasst.
  8. Verfahren nach einem der vorhergehenden Ansprüche, das ferner Folgendes umfasst: Ermöglichen, dass ein Originalgerätehersteller (OEM) die USB4-Steuereinheit konfiguriert, eines aus einem nativen SW-CM eines OS, einem SW-CM eines Drittanbieters oder eines FM-CM zu implementieren; und in Reaktion auf das Starten eines CM für die Host-Plattform, der von dem CM, der für die USB4-Steuereinheit konfiguriert ist, verschieden ist, Umschalten des CM, der gestartet wird, auf den CM, der für die USB4-Steuereinheit konfiguriert ist.
  9. Verfahren nach Anspruch 8, das ferner Aktualisieren von Konfigurationsinformationen für den CM, der für die USB4-Steuereinheit konfiguriert ist, unter Verwendung eines 4-Teile-Bezeichners (ID) umfasst.
  10. Verfahren nach einem der vorhergehenden Ansprüche, wobei das OS für die Host-Plattform, das für ein früheres Booten verwendet wurde, das der früheren CM-Konfiguration entspricht, eine erste Version eines Microsoft Windows OS ist, die keinen SW-CM enthält, und das ferner Folgendes umfasst: Booten des BIOS der Host-Plattform; Detektieren, dass die frühere CM-Einstellung für die Host-Plattform dem FW-CM entspricht; Ausführen einer Betriebssystem- (OS-) Übergabe von dem BIOS zu einem OS-Boot-Prozess für eine zweite Version eines Microsoft Windows OS, die ein Upgrade der ersten Version eines Microsoft Windows OS umfasst, das einen SW-CM enthält; Umschalten des CM auf den SW-CM; Aktualisieren der früheren CM-Einstellung; Fertigstellen des Bootens des OS; und Verwenden des SW-CM während des Laufzeitbetriebs der Host-Plattform.
  11. Host-Plattform, die Folgendes umfasst: einen Einchipsystem- (SoC-) Prozessor, der Folgendes enthält: mehrere Prozessorkerne; eine Speichersteuereinheit; eine oder mehrere Eingabe/Ausgabe- (I/O-) Schnittstellen; Speicher, der mit der Speichersteuereinheit kommunikationstechnisch gekoppelt ist, eine USB4-Steuereinheit, die Folgendes umfasst: eine diskrete Komponente, die mit dem SoC-Prozessor über wenigstens eine I/O-Schnittstelle kommunikationstechnisch gekoppelt ist, oder einen USB4-Steuereinheit-Block, der in den SoC-Prozessor eingebettet ist; wobei die USB4-Steuereinheit einen Firmware-basierten (FW-) Verbindungsmanager (CM) aufweist; eine oder mehrere Speichervorrichtungen, in denen Firmware-Anweisungen, die ein BIOS enthalten, gespeichert sind; eine oder mehrere Speichervorrichtungen, in denen Software-Anweisungen für ein Betriebssystem (OS) gespeichert sind, die Software-Anweisungen enthalten, die einem Software-basierten (SW-) CM zugeordnet sind; wobei beim Laden der Firmware-Anweisungen und Software-Anweisungen in den Speicher und Ausführen der Firmware-Anweisungen und Software-Anweisungen der Host-Plattform Folgendes ermöglicht wird: während eines ersten Plattform-Boot-Prozesses Booten des BIOS; Detektieren einer früheren CM-Einstellung für die Host-Plattform und Aktivieren des FW-CM oder SW-CM basierend auf der früheren CM-Einstellung, wobei der FW-CM oder SW-CM, der aktiviert ist, einen BIOS-aktivierten CM umfasst; Ausführen einer OS-Übergabe von dem BIOS zu einem OS-Boot-Prozess; Bestimmen, ob das OS die Verwendung des BIOS-aktivierten CM unterstützt; wenn das OS die Verwendung des BIOS-aktivierten CM nicht unterstützt, Umschalten zu einem CM, der durch das OS unterstützt wird, der eines aus einem dem FW-CM oder SW-CM umfasst, wobei der CM, zu dem umgeschaltet wird, einen OS-geschalteten CM umfasst; und Aktualisieren der früheren CM-Einstellung; Fertigstellen des Bootens des OS; und Verwenden des OS-geschalteten CM während des Laufzeitbetriebs der Host-Plattform.
  12. Host-Plattform nach Anspruch 11, wobei das Ausführen der Firmware-Anweisungen und Software-Anweisungen der Host-Plattform ferner Folgendes ermöglicht: während eines zweiten Plattform-Boot-Prozesses Booten des BIOS der Host-Plattform; Detektieren einer früheren CM-Einstellung für die Host-Plattform und Aktivieren der Verwendung des FW-CM oder SW-CM basierend auf der früheren CM-Einstellung, wobei der FW-CM oder SW-CM, der aktiviert ist, einen BIOS-aktivierten CM umfasst; Ausführen einer Betriebssystem- (OS-) Übergabe zu dem OS-Boot-Prozess; Bestimmen, ob das OS die Verwendung des BIOS-aktivierten CM unterstützt; wenn das OS die Verwendung des BIOS-aktivierten CM unterstützt Fertigstellen des Bootens des OS; und Verwenden des BIOS-aktivierten CM während des Laufzeitbetriebs der Host-Plattform.
  13. Host-Plattform nach Anspruch 11 oder 12, wobei die Host-Plattform eine/n „Advanced Configuration and Power Interface“- (ACPI-) Komponente oder Block enthält und die frühere CM-Einstellung ein Betriebssystemfähigkeits- (OSC-) Bit umfasst, wobei die Ausführung der Firmware-Anweisungen der Host-Plattform ferner ermöglicht, auf das OSC-Bit zuzugreifen.
  14. Host-Plattform nach einem der Ansprüche 11-13, wobei das BIOS „Universal Extensible Firmware Interface“- (UEFI-) Firmware umfasst und die frühere CM-Einstellung als eine EFI-Variable gespeichert ist, wobei die Ausführung der Firmware-Anweisungen der Host-Plattform ferner ermöglicht, auf die frühere CM-Einstellung über die EFI-Variable zuzugreifen.
  15. Host-Plattform nach einem der Ansprüche 11-14, wobei die Ausführung der Firmware-Anweisungen und/oder der Software-Anweisungen der Host-Plattform ferner ermöglicht, einen Host-Router in der USB4-Steuereinheit in Übereinstimmung mit dem OS-geschalteten CM neu zu konfigurieren.
  16. Host-Plattform nach einem der Ansprüche 11-15, wobei der OS-geschaltete CM der SW-CM ist, die USB4-Steuereinheit Host-Steuereinheit-Firmware enthält und die USB4-Steuereinheit direkt oder indirekt mit einem USB4-Fabric gekoppelt ist, wobei die Ausführung der Firmware-Anweisungen der Host-Plattform ferner ermöglicht, die USB4-Steuereinheit in einer Durchlassbetriebsart zu betreiben, unter der Konfigurationsschichtsteuerpakete, die von einem SW-CM-Treiber stammen, der dem SW-CM zugeordnet ist, zu dem USB4-Fabric umgelenkt werden und wobei Konfigurationsschichtsteuerpakete, die von dem USB4-Fabric stammen, zu dem SW-CM-Treiber umgelenkt werden.
  17. Host-Plattform nach einem der Ansprüche 11-16, wobei der OS-geschaltete CM der FW-CM ist, die USB4-Steuereinheit Host-Steuereinheit-Firmware enthält und die USB4-Steuereinheit direkt oder indirekt mit einem USB4-Fabric gekoppelt ist, wobei das Ausführen der Firmware-Anweisungen der Host-Plattform ferner ermöglicht, die USB4-Steuereinheit in einer FW-CM-Betriebsart zu betreiben, unter der Konfigurationsschichtsteuerpakete von der Host-Steuereinheit-Firmware zu dem USB4-Fabric weitergeleitet werden, und wobei Konfigurationsschichtsteuerpakete, die von dem USB4-Fabric stammen, zu der Host-Steuereinheit-Firmware weitergeleitet werden.
  18. Host-Plattform nach einem der Ansprüche 11-17, wobei die USB4-Steuereinheit durch einen Originalgerätehersteller (OEM) der Host-Plattform konfiguriert ist, eines aus einem nativen SW-CM eines OS, einem SW-CM eines Drittanbieters oder einem FM-CM zu implementieren, und wobei die Ausführung der Firmware-Anweisungen und/oder der Software-Anweisungen der Host-Plattform ferner Folgendes ermöglicht: Detektieren, dass ein CM für die Host-Plattform, der von dem CM, der für die USB4-Steuereinheit konfiguriert ist, verschieden ist, gestartet worden ist; und Umschalten des CM, der gestartet wird, auf den CM, der für die USB4-Steuereinheit konfiguriert ist.
  19. Host-Plattform nach einem der Ansprüche 11-18, wobei die Ausführung der Firmware-Anweisungen und/oder der Software-Anweisungen der Host-Plattform ferner ermöglicht, Konfigurationsinformationen für den CM, der für die USB4-Steuereinheit konfiguriert ist, unter Verwendung eines 4-Teile-Bezeichners (ID) zu aktualisieren.
  20. Halbleiterchip, der konfiguriert ist, in eine Host-Plattform implementiert zu sein, der Folgendes umfasst: einen USB4-Steuereinheit-Block, der Folgendes enthält: ein Verarbeitungselement; Speicher; eine Host-Schnittstelle; eine DisplayPort- (DP-) Schnittstelle; eine oder mehrere USB4-Schnittstellen; und Firmware-Anweisungen, die konfiguriert sind, auf dem Verarbeitungselement ausgeführt zu werden, um dem USB4-Steuereinheit-Block Folgendes zu ermöglichen: Implementieren eines Firmware-basierten (FW-) Verbindungsmanagers (CM); und Betreiben in einer Durchlassbetriebsart, unter der Steuerpakete, die von einem Software-basierten (SW-) CM, der auf der Host-Plattform arbeitet, über die Host-Schnittstelle empfangen werden, zu einem USB4-Fabric, das mit einer USB4-Schnittstelle aus der einen oder den mehreren USB4-Schnittstellen gekoppelt ist, umgelenkt werden; und Steuerpakete, die von dem USB4-Fabric über die USB4-Schnittstelle empfangen werden, zu dem SW-CM über die Host-Schnittstelle umgelenkt werden, wobei die Steuerpakete verwendet werden, um ein USB4-Peripheriegerät und/oder einen USB4-Hub in dem USB4-Fabric zu konfigurieren.
  21. Halbleiterchip nach Anspruch 20, wobei die Ausführung der Firmware-Anweisungen auf dem Verarbeitungselement dem USB4-Steuereinheit-Block ferner Folgendes ermöglicht: Arbeiten in einer FW-CM-Betriebsart, unter der der FW-CM verwendet wird zum: Erzeugen von Steuerpaketen und Senden der Steuerpakete zu einem USB4-Fabric, das mit einer USB4-Schnittstelle aus der einen oder den mehreren USB4-Schnittstellen gekoppelt ist; und Empfangen von Steuerpaketen von dem USB4-Fabric über die USB4-Schnittstelle.
  22. Halbleiterchip nach Anspruch 20 oder 21, wobei der Halbleiterchip ein Einchipsystem (SoC) ist, das mehrere Prozessorkerne enthält, die mit einer Zusammenschaltungshierarchie kommunikationstechnisch gekoppelt sind, mit der die Host-Schnittstelle und die DP-Schnittstelle gekoppelt sind, und wobei der USB4-Steuereinheit-Block in dem SoC eingebettet ist.
  23. Halbleiterchip nach einem der Ansprüche 20-22, wobei der Halbleiterchip eine diskrete Komponente ist und die Host-Schnittstelle und die DP-Schnittstelle externe Schnittstellen sind.
  24. Halbleiterchip nach einem der Ansprüche 20-23, wobei der USB4-Steuereinheit-Block durch einen Originalgerätehersteller (OEM) der Host-Plattform konfiguriert ist, eines aus einem nativen SW-CM eines OS, einem SW-CM eines Drittanbieters oder einem FM-CM zu implementieren, und wobei die Ausführung der Firmware-Anweisungen dem USB4-Steuereinheit-Block ferner Folgendes ermöglicht: Detektieren des CM, der für den USB4-Steuereinheit-Block konfiguriert ist, und Bereitstellen von Informationen, die den CM identifizieren, der für den USB4-Steuereinheit-Block konfiguriert ist, für ein Betriebssystem auf der Host-Plattform.
DE102020115453.4A 2019-06-28 2020-06-10 Automatisches Umschalten und Einsetzen von Software- oder Firmware-basierten USB-Verbindungsmanagern Pending DE102020115453A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/456,931 US11513808B2 (en) 2019-06-28 2019-06-28 Automatic switching and deployment of software or firmware based USB4 connection managers
US16/456,931 2019-06-28

Publications (1)

Publication Number Publication Date
DE102020115453A1 true DE102020115453A1 (de) 2020-12-31

Family

ID=68161800

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020115453.4A Pending DE102020115453A1 (de) 2019-06-28 2020-06-10 Automatisches Umschalten und Einsetzen von Software- oder Firmware-basierten USB-Verbindungsmanagern

Country Status (2)

Country Link
US (1) US11513808B2 (de)
DE (1) DE102020115453A1 (de)

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11176074B2 (en) * 2019-10-22 2021-11-16 Via Labs, Inc. Chip and interface conversion device
US11308050B2 (en) * 2019-11-15 2022-04-19 Bank Of America Corporation Conversion mechanism for complex cohabitation databases
US20200192832A1 (en) * 2020-02-21 2020-06-18 Intel Corporation Influencing processor governance based on serial bus converged io connection management
TWI768493B (zh) * 2020-03-02 2022-06-21 威鋒電子股份有限公司 連接介面轉換晶片、連接介面轉換裝置與操作方法
CN112231268A (zh) * 2020-03-02 2021-01-15 威锋电子股份有限公司 连接接口转换芯片、连接接口转换装置与操作方法
US11126518B1 (en) * 2020-03-16 2021-09-21 Quanta Computer Inc. Method and system for optimal boot path for a network device
US11995022B2 (en) * 2020-04-27 2024-05-28 Intel Corporation Transmitting displayport 2.0 information using USB4
US20200320026A1 (en) * 2020-04-27 2020-10-08 Intel Corporation Bandwidth management allocation for displayport tunneling
JP2022032660A (ja) * 2020-08-13 2022-02-25 ザインエレクトロニクス株式会社 通信装置およびアクティブケーブル
JP7408593B2 (ja) * 2021-03-23 2024-01-05 株式会社東芝 制御装置、情報処理装置、および情報処理システム
US11263083B1 (en) * 2021-03-26 2022-03-01 Quanta Computer Inc. Method and apparatus for selective boot-up in computing devices
US11669618B2 (en) * 2021-04-21 2023-06-06 Dell Products L.P. Systems and methods for securing and loading bios drivers and dependencies in a predefined and measured load order
US20230034633A1 (en) * 2021-07-30 2023-02-02 Advanced Micro Devices, Inc. Data fabric c-state management
US20230077706A1 (en) * 2021-09-14 2023-03-16 Targus International Llc Independently upgradeable docking stations
US20230119332A1 (en) * 2021-10-18 2023-04-20 Celerity Technologies Inc. Usb connector for fiber optic cable and related usb extender
TWI802065B (zh) * 2021-10-29 2023-05-11 飛捷科技股份有限公司 可控制周邊裝置電源與訊號的通信介面轉接器、動態分配通信介面轉接器識別碼的方法及自動化診斷周邊裝置並修復問題的方法
TWI839804B (zh) * 2021-12-08 2024-04-21 威鋒電子股份有限公司 Usb積體電路、測試平台以及usb積體電路的操作方法
CN115391252A (zh) 2021-12-08 2022-11-25 威锋电子股份有限公司 Usb集成电路、测试平台及usb集成电路的操作方法
WO2023159339A1 (en) * 2022-02-22 2023-08-31 Intel Corporation System, method and apparatus for scalable connection management of interface
CN117407347B (zh) * 2023-12-15 2024-03-12 成都电科星拓科技有限公司 一种PCIe转接芯片及其控制方法与电子设备

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070157015A1 (en) * 2005-12-29 2007-07-05 Swanson Robert C Methods and apparatus to optimize boot speed
US9253034B1 (en) * 2009-06-01 2016-02-02 Juniper Networks, Inc. Mass activation of network devices
US10122576B2 (en) * 2015-03-17 2018-11-06 Microsoft Technology Licensing, Llc Intelligent role selection for dual-role devices
KR102634505B1 (ko) * 2016-06-24 2024-02-06 타호 리서치 리미티드 컴퓨팅 장치의 분리가능한 부분을 위한 이중 역할 가능 커넥터

Also Published As

Publication number Publication date
US20190317774A1 (en) 2019-10-17
US11513808B2 (en) 2022-11-29

Similar Documents

Publication Publication Date Title
DE102020115453A1 (de) Automatisches Umschalten und Einsetzen von Software- oder Firmware-basierten USB-Verbindungsmanagern
US20210232528A1 (en) Configurable device interface
DE102020133738A1 (de) Firmware-update-techniken
US7865908B2 (en) VM network traffic monitoring and filtering on the host
US8595723B2 (en) Method and apparatus for configuring a hypervisor during a downtime state
DE112020006859T5 (de) Beibehaltung von speicher-namensraum-identifizierern für die migration von virtualisierten ausführungsumgebungen im laufenden betrieb
US8645605B2 (en) Sharing multiple virtual functions to a host using a pseudo physical function
CN101765225B (zh) 一种虚拟化的集群管理方法和集群节点
DE102020125046A1 (de) Konfigurationsschnittstelle zum auslagern von fähigkeiten an eine netzwerkschnittstelle
DE112010001469B4 (de) Flexible Integration von Endpunktlogik in unterschiedlichen Plattformen
US7222339B2 (en) Method for distributed update of firmware across a clustered platform infrastructure
DE112013007752B3 (de) Hochleistungsverdrahtungs-Bitübertragungsschicht
US20190235890A1 (en) Method for dynamically provisioning virtualized functions in a usb device by means of a virtual usb hub
US12008359B2 (en) Update of boot code handlers
DE102010001985A1 (de) Vorrichtung zum Schalten des Betriebs einer virtuellen Maschine zwischen mehreren Computern, die der gleichen Computerplattform zugeordnet sind, und entsprechende Schaltverfahren
DE102009031126A1 (de) Aktivieren der funktionalen Abhängigkeit in einem Multifunktionsgerät
WO2020055921A1 (en) Methods and apparatus for high-speed data bus connection and fabric management
US20120284437A1 (en) Pci express sr-iov/mr-iov virtual function clusters
DE112008001957B4 (de) Systeme und Verfahren zum Verbessern der Leistungsfähigkeit eines routfähigen Netzwerks
DE112012005209T5 (de) Brückenfunktion zwischen Virtual Machine Monitor und Bare-Metal-Bootvorgang
JPH11316747A (ja) 多数のオペレ―ティングシステムインスタンス及びソフトウェア制御式リソ―ス割り当てを伴うマルチプロセッサコンピュ―タア―キテクチャ
DE112020006858T5 (de) Dynamische interrupt-bereitstellung
DE112007003206T5 (de) Neukonfigurieren eines sicheren Systems
CN108139937B (zh) 多根i/o虚拟化系统
DE102020101958A1 (de) Dynamisches spurzugriffswechseln zwischen pcie-wurzelräumen