DE102021101460A1

DE102021101460A1 - Prozessoren zur Konfiguration von Subsystemen während andere Prozessoren im Reset gehalten werden

Info

Publication number: DE102021101460A1
Application number: DE102021101460.3A
Authority: DE
Inventors: Naysen Robertson; Kenneth T. Chin; Theodore F. Emerson
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2020-01-30
Filing date: 2021-01-25
Publication date: 2021-08-05
Also published as: US11360782B2; CN113205838A; CN113205838B; US20210240485A1

Abstract

Ein Gerät enthält ein Subsystem, einen ersten Prozessor, einen Speicher, eine Schaltung und einen zweiten Prozessor. Der erste Prozessor soll Bootstrap-Befehle ausführen, und der Speicher soll zweite Befehle speichern. Die Schaltung soll den ersten Prozessor als Reaktion auf das Einschalten des Geräts im Reset-Zustand halten; und der zweite Prozessor soll, während der erste Prozessor im Reset-Zustand gehalten wird, die zweiten Anweisungen ausführen, um das Subsystem zu initialisieren.

Description

HINTERGRUND
Ein anwendungsspezifischer integrierter Schaltkreis (ASIC) ist ein integrierter Schaltkreis (IC), der für eine bestimmte Anwendung entwickelt wurde. Um den Platz auf der Leiterplatte zu reduzieren, kann ein eingebettetes Verarbeitungssubsystem, wie z. B. ein Subsystem, das ein System on Chip (SoC), einen Baseboard Management Controller (BMC) oder einen Mikroprozessor mit mehreren Funktionen enthält, einen oder mehrere ASICs enthalten. Im Allgemeinen kann ein ASIC „gehärtet“ sein und es ist schwierig, ihn nach der Herstellung zu ändern. Die monetären und personellen Kosten für den Spin (d. h. den Neuaufbau, einschließlich Redesign und Refabrication) eines neuen oder modifizierten ASICs können erheblich sein.
Figurenliste

ist eine schematische Darstellung eines Computersystems gemäß einer Beispielimplementierung.
ist eine schematische Darstellung eines Baseboard-Management-Controllers des Computersystems von gemäß einer Beispielimplementierung.
ist eine Tabelle mit Anweisungen, die von einem Hauptverarbeitungskern des Basisplatinen-Management-Controllers von gemäß einer Beispielimplementierung ausgeführt werden können.
ist eine Tabelle, die Felder eines Headers einer Patch-Set-Tabelle gemäß einer Beispielimplementierung darstellt.
ist eine Tabelle, die Felder eines Patch-Tabellendatensatzes gemäß einer Beispielimplementierung darstellt.
In den , , , und ist ein Zustandsdiagramm eines Hauptverarbeitungskerns des Baseboard-Management-Controllers aus gemäß einer Beispielimplementierung dargestellt.
ist ein schematisches Diagramm eines Geräts, das einen Prozessor enthält, um, während ein anderer Prozessor, der Bootstrap-Befehle ausführt, im Reset-Zustand gehalten wird, zweite Befehle auszuführen, um ein Subsystem des Geräts gemäß einer Beispielimplementierung zu initialisieren.
ist ein schematisches Diagramm eines Systems, das einen Konfigurator eines Geräts enthält, der, während ein Prozessor des Geräts im Reset-Zustand gehalten wird, Befehle ausführt, um ein Subsystem des Geräts gemäß einer Beispielimplementierung zu initialisieren.
ist ein Flussdiagramm, das einen Prozess veranschaulicht, der, während ein erster Prozessor eines eingebetteten Verarbeitungssystems im Reset gehalten wird, einen zweiten Prozessor des eingebetteten Verarbeitungssystems verwendet, um ein Subsystem des eingebetteten Verarbeitungssystems gemäß einer Beispielimplementierung zu konfigurieren.

DETAILLIERTE BESCHREIBUNG
Ein bestimmter anwendungsspezifischer integrierter Schaltkreis (ASIC) kann in verschiedenen Versionen eines Produkts verwendet werden, und jede dieser Versionen stellt eine andere Umgebung für den ASIC dar. Aus verschiedenen Gründen (z. B. monetäre Kosten, Personalkosten und Produktentwicklungszeiten) kann es vorteilhaft sein, den ASIC für eine bestimmte Umgebung zu modifizieren, ohne einen ASIC-Spin (d. h. ohne einen weiteren Round Trip durch einen Design-, Engineering- und Fertigungszyklus).
Als spezifischeres Beispiel kann der ASIC ein Baseboard-Management-Controller sein, der in einer Reihe von Computersystemumgebungen verwendet werden kann, z. B. in den Umgebungen, die einer Reihe von verschiedenen Servermodellen entsprechen, die den Baseboard-Management-Controller enthalten. Der Baseboard-Management-Controller kann verschiedene Komponenten enthalten, die mit der Umgebung außerhalb des Baseboard-Management-Controllers interagieren. Beispielsweise ermöglichen ein Speicher-Controller und eine physische Speicherschnittstelle des Baseboard-Management-Controllers, dass der Baseboard-Management-Controller auf externe Speichergeräte, die mit dem Baseboard-Management-Controller verbunden sind, zugreifen kann (z. B. Lesen von und Schreiben in diese). Der Speicher-Controller und die Speicherschnittstelle können eine relativ große Anzahl von Einstellungen haben, die von den spezifischen Eigenschaften der externen Speichergeräte abhängen. Beispielsweise können die Einstellungen für die Speicherschnittstelle davon abhängen, ob es sich bei den externen Speichergeräten um Geräte mit doppelter Datenrate 3 (DDR3) oder DDR4 handelt, vom verwendeten Fehlerkorrekturcode (ECC), vom Typ des dynamischen Direktzugriffsspeichers (DRAM), von der Speicherlatenz, von der Terminierungsstärke und so weiter. Darüber hinaus können sich die Einstellungen der Speicherschnittstelle zusätzlich zu den Schnittstellen mit verschiedenen Komponenten und der Anpassung an die Eigenschaften dieser Komponenten für unterschiedliche Umgebungen aus anderen Gründen ändern. Zum Beispiel kann eine unterschiedliche physikalische Gehäuseplatzierung zwischen dem Baseboard-Management-Controller und den angeschlossenen Speichergeräten zu unterschiedlichen Einstellungen für die Speicherschnittstelle führen.
Ein Ansatz, um eine benutzerdefinierte Konfiguration eines ASIC zu ermöglichen, besteht darin, dass ein Mikrocontroller oder Prozessor des ASICs Firmware-Befehle ausführt, die verschiedene Parameter der Subsysteme des ASICs festlegen. Zum Beispiel kann ein Baseboard-Management-Controller einen oder mehrere Allzweck-Verarbeitungskerne (z. B. Advanced RISC Machine (ARM)-Verarbeitungskerne) enthalten, die Firmware für den Baseboard-Management-Controller ausführen. Die Firmware kann für eine bestimmte Computersystemumgebung modifiziert werden, so dass die modifizierte Firmware darauf zugeschnitten ist, die Subsysteme des Baseboard-Management-Controllers für diese bestimmte Umgebung zu konfigurieren. Die Verwendung solcher Firmware-Modifikationen kann jedoch auf bestimmte Herausforderungen stoßen. Beispielsweise ist die vom Baseboard-Management-Controller ausgeführte Firmware typischerweise relativ komplex, und die Modifizierung der Firmware für jede Computersystemumgebung kann Risiken mit sich bringen, zusätzlichen Aufwand verursachen und die Zeit für die Integration des Baseboard-Management-Controllers in das Produkt erhöhen
Die Verwendung des/der Allzweck-Verarbeitungskerns/Core(s) zur Konfiguration von Subsystemen des Baseboard-Management-Controllers kann das Computersystem sicherheitsrelevanten Problemen aussetzen. Wenn z. B. für die Initialisierung des Speicher-Controllers oder der Speicherschnittstelle des Basisplatinen-Verwaltungscontrollers auf Firmware zurückgegriffen wird, kann die Freigabe des/der Allzweck-Verarbeitungskerns/Core(s) nach dem Zurücksetzen, um die Firmware vor der Speicherinitialisierung auszuführen, Sicherheitsbedenken aufwerfen und nicht zulassen, dass auf den Speicher für bestimmte Funktionen zurückgegriffen werden kann.
Darüber hinaus kann der Basisplatinen-Verwaltungscontroller beim Einschalten auf ein Problem stoßen (ein Root-of-Trust-bezogener kryptografischer Fehler, ein Hardware-Fehler usw.), das verhindert, dass die Allzweckverarbeitungskerne aus dem Reset freigegeben werden. In diesem Fall werden die Subsysteme des Basisplatinen-Verwaltungs-Controllers von der Firmware nicht konfiguriert, was dazu führen kann, dass das Problem nicht gemeldet werden kann. Beispielsweise kann der Baseboard-Management-Controller einen Video-Controller enthalten, der auf den Videospeicher zugreift, der mit dem Baseboard-Management-Controller verbunden ist. Auf den Video-Controller kann von einer zentralen Verarbeitungseinheit (CPU) des Computersystems zugegriffen werden. Obwohl die CPU des Computersystems erkennen kann, dass der Basisplatinen-Verwaltungscontroller eine Fehlfunktion aufweist, kann die CPU nicht auf den Videospeicher zugreifen, um Fehlermeldungen zu melden, wenn die Speicherschnittstelle des Basisplatinen-Verwaltungscontrollers nicht konfiguriert wurde (weil der/die Allzweckverarbeitungskern(e) des Basisplatinen-Verwaltungscontrollers nicht aus dem Reset freigegeben wurden).
Gemäß Beispielimplementierungen kann ein eingebettetes Verarbeitungssystem (z. B. ein Baseboard-Management-Controller, ein System on a Chip (SoC) usw.) einen Konfigurator und einen oder mehrere Allzweckverarbeitungskerne enthalten. Der Konfigurator konfiguriert beim Einschalten autonom ein oder mehrere Subsysteme des eingebetteten Verarbeitungssystems, während der/die Allzweckverarbeitungskern(e) im Reset verbleiben. In diesem Zusammenhang bezieht sich ein „eingebettetes Verarbeitungssystem“ auf ein prozessorbasiertes System, das einen oder mehrere Allzweckverarbeitungskerne enthält und eine oder mehrere dedizierte Funktionen in einem größeren System, wie einem Computersystem (z. B. einem Desktop, einem Laptop, einem Server usw.), ausführt. In Übereinstimmung mit einigen Implementierungen kann das eingebettete Verarbeitungssystem ein oder mehrere Halbleiterpakete (oder „Chips“) enthalten, und das/die Halbleiterpaket(e) kann/können ein oder mehrere Halbleiterchips enthalten. Darüber hinaus bezieht sich im Kontext dieser Anwendung der „autonom“ agierende Konfigurator auf den Konfigurator, der separat oder unabhängig von einem der allgemeinen Verarbeitungskerne des eingebetteten Verarbeitungssystems arbeitet.
In Übereinstimmung mit Beispielimplementierungen enthält der Konfigurator einen Master-Prozessor, der ein bestimmtes Subsystem des eingebetteten Verarbeitungssystems konfiguriert, und der Konfigurator enthält einen oder mehrere Slave-Prozessoren, die ein oder mehrere andere Subsysteme des eingebetteten Verarbeitungssystems konfigurieren. In Übereinstimmung mit einigen Implementierungen kann der Master-Prozessor beispielsweise einen Speicher-Controller des eingebetteten Verarbeitungssystems konfigurieren, und ein bestimmter Slave-Prozessor kann eine physische Speicherschnittstelle des eingebetteten Verarbeitungssystems konfigurieren.
Die Master- und Slave-Prozessoren können unterschiedlichen Bus-Kommunikationsprotokollen zugeordnet sein, so dass z. B. der Master-Prozessor über ein bestimmtes Bus-Protokoll (z. B. ein Advanced High-Performance Bus (AHB)-Protokoll) kommunizieren kann, um einen Speicher-Controller des eingebetteten Verarbeitungssystems zu konfigurieren, während ein bestimmter Slave-Prozessor über ein anderes Bus-Protokoll (z. B. ein Advanced Peripheral Bus (APB)-Protokoll) kommunizieren kann, um eine physikalische Speicherschnittstelle des eingebetteten Verarbeitungssystems zu konfigurieren.
Wie hierin verwendet, bezieht sich ein „Subsystem“ auf einen bestimmten Teil des eingebetteten Verarbeitungssystems, der eine bestimmte Funktion für die eingebettete Funktion ausführt, wie z. B. ein Speicher-Controller, eine physische Speicherschnittstelle, ein Video- oder Display-Controller, ein Spannungsregelungs-Subsystem, eine serielle Hochgeschwindigkeitsschnittstelle (z. B. eine Peripheral Component Interconnect Express (PCIe)-Schnittstelle, eine Ethernet-Schnittstelle, eine Serial Attached SCSI (SAS)-Schnittstelle, eine Serial AT Attachment (SATA)-Schnittstelle oder eine Universal Serial Bus (USB) 3-Schnittstelle) usw. Im Allgemeinen konfiguriert der Konfigurator, wie hier beschrieben, die Subsysteme des eingebetteten Verarbeitungssystems für die spezifische Computersystemumgebung, in der das eingebettete Verarbeitungssystem verwendet wird.
In Übereinstimmung mit Beispielimplementierungen kann der Hauptprozessor einen Hauptverarbeitungskern (z. B. einen eingebetteten Mikrocontroller) enthalten, der maschinenausführbare Befehle ausführt, die in einem nichtflüchtigen Speicher (z. B. einem Festwertspeicher (ROM)) des Hauptprozessors gespeichert sind. In diesem Zusammenhang bezieht sich eine „Anweisung“ auf eine Gruppe von Bits, die von einem Prozessor (z. B. einem Verarbeitungskern) verarbeitet bzw. ausgeführt werden, um den Prozessor zu veranlassen, eine Funktion auszuführen. Die Anweisung enthält einen Befehl, der die auszuführende Funktion oder Aktion darstellt, und einen oder mehrere Operanden, die eine oder mehrere Entitäten (z. B. Adressen, Daten, Masken) darstellen, mit denen gearbeitet wird, um die Funktion oder Aktion auszuführen. Darüber hinaus kann, wie hier beschrieben, der Befehlsoperand auch einen eingebetteten Befehl für einen Slave-Prozessor enthalten.
Der nichtflüchtige Speicher des Hauptprozessors kann Gruppen von Befehlen speichern, wobei die Gruppen verschiedenen möglichen Konfigurationen des Subsystems entsprechen können, das vom Hauptprozessor konfiguriert wird. So kann eine Gruppe von Anweisungen beispielsweise dem Setzen eines oder mehrerer Konfigurations- und Statusregister (CSRs) einer Speicherschnittstelle des eingebetteten Verarbeitungssystems für eine Version eines Servers entsprechen, der das eingebettete Verarbeitungssystem enthält, und eine andere Gruppe von Anweisungen kann dem Setzen der CSRs für eine andere Version eines Servers entsprechen, der das eingebettete Verarbeitungssystem enthält.
Der nichtflüchtige Speicher des Hauptprozessors kann auch Fallbefehle speichern, wobei die Ausführung eines bestimmten Fallbefehls die Auswahl einer bestimmten Gruppe von auszuführenden Befehlen durch den Hauptverarbeitungskern anweist, basierend auf einem Bitvektor von Daten, die dem eingebetteten Verarbeitungssystem bereitgestellt werden. Auf diese Weise kann, wie hierin weiter beschrieben, in Übereinstimmung mit einigen Implementierungen eine Komponente, die sich außerhalb des eingebetteten Verarbeitungssystems befindet, wie z. B. eine programmierbare Logikvorrichtung (PLD), Daten speichern, die einen Bitvektor von Daten darstellen, und die PLD liefert den Bitvektor von Daten an das eingebettete Verarbeitungssystem beim Einschalt-Reset des eingebetteten Verarbeitungssystems. Wie hier weiter beschrieben, identifiziert die Fallanweisung gemäß Beispielimplementierungen bestimmte Bitpositionen des Bitvektors von Daten, und die den identifizierten Bits entsprechenden Bits wählen eine bestimmte Gruppe von Anweisungen (die der Fallanweisung folgen) aus, die auszuführen sind.
In Übereinstimmung mit Beispielimplementierungen kann der Master-Verarbeitungskern einen Befehl ausführen, der Operanden enthält, die zusammen einen Befehl für einen bestimmten Slave-Prozessor darstellen. Genauer gesagt, kann der Master-Prozessor gemäß einigen Implementierungen über einen Befehlsbus mit den Slave-Prozessoren verbunden sein; und der Befehlsbus kann Dekodiersignale enthalten, die zur Auswahl verschiedener Slave-Prozessoren verwendet werden. Genauer gesagt kann eine bestimmte Anweisung, die vom Master-Verarbeitungskern ausgeführt wird, Operanden enthalten, die eine eingebettete Anweisung festlegen, die von einem bestimmten Slave-Prozessor ausgeführt werden soll, und der Master-Verarbeitungskern kann die eingebettete Anweisung an den Anweisungsbus liefern und das entsprechende Dekodierungssignal aktivieren, so dass der Slave-Prozessor die Anweisung vom Anweisungsbus abrufen und anschließend die Anweisung ausführen kann.
In Übereinstimmung mit einigen Implementierungen kann der Slave-Prozessor einen Slave-Verarbeitungskern (z. B. einen eingebetteten Mikrocontroller) sowie einen Speicher (z. B. einen nichtflüchtigen Speicher) enthalten, der Befehle zur Ausführung durch den Slave-Prozessor speichert. In Übereinstimmung mit einigen Implementierungen kann der Slave-Prozessor Befehle ausführen, die über den Befehlsbus an den Slave-Prozessor weitergeleitet werden.
Bezug nehmend auf , als spezifischeres Beispiel, kann ein elektronisches System in Übereinstimmung mit einigen Implementierungen ein eingebettetes Verarbeitungssystem umfassen, das einen Konfigurator 140 zum Zwecke der Initialisierung oder Konfiguration eines oder mehrerer Subsysteme 150 des eingebetteten Verarbeitungssystems umfasst. Bei der in dargestellten Beispielimplementierung ist das elektronische System ein Computersystem 100, wie z. B. ein Server, ein Client, ein Desktop-Computer, ein Laptop-Computer, ein Tablet-Computer, ein Smartphone, ein tragbarer Computer, ein rackmontiertes Modul usw. Bei der in dargestellten Beispielimplementierung ist das eingebettete Verarbeitungssystem ein Baseboard-Management-Controller 130, obwohl das eingebettete Verarbeitungssystem in Übereinstimmung mit weiteren Implementierungen eine beliebige Anzahl anderer eingebetteter Verarbeitungssysteme sein kann, wie z. B. ein ASIC, der kein Baseboard-Management-Controller ist, ein SoC, ein Mikroprozessor, ein Mikrocontroller und so weiter.
Wie hierin verwendet, ist ein „Baseboard-Management-Controller“ ein spezialisierter Serviceprozessor, der den physischen Zustand eines Servers oder anderer Hardware mithilfe von Sensoren überwacht und mit einem Managementsystem über ein Management-Netzwerk kommuniziert. Der Baseboard-Management-Controller kann auch mit Anwendungen kommunizieren, die auf Betriebssystemebene über einen IOCTL-Schnittstellentreiber (Input/Output Controller), eine REST-Anwendungsprogrammschnittstelle (API) oder einen anderen Systemsoftware-Proxy ausgeführt werden, der die Kommunikation zwischen dem Baseboard-Management-Controller und den Anwendungen erleichtert. Der Baseboard-Management-Controller kann auf Hardware-Ebene auf Hardware-Geräte zugreifen, die sich in einem Server-Chassis befinden, einschließlich Systemspeicher. Der Baseboard-Management-Controller kann in der Lage sein, die Hardware-Geräte direkt zu modifizieren. Der Baseboard-Management-Controller kann unabhängig vom Betriebssystem des Systems arbeiten, in dem der Baseboard-Management-Controller angeordnet ist. Der Baseboard-Management-Controller kann sich auf der Hauptplatine oder der Hauptplatine des Servers oder eines anderen zu überwachenden Geräts befinden. Die Tatsache, dass ein Baseboard-Management-Controller auf einer Hauptplatine des zu überwachenden Servers/der zu überwachenden Hardware montiert oder anderweitig mit dem zu überwachenden Server/der zu überwachenden Hardware verbunden oder daran angebracht ist, verhindert nicht, dass der Baseboard-Management-Controller als „getrennt“ vom Server/der Hardware betrachtet wird. Wie hierin verwendet, hat ein Baseboard-Management-Controller Verwaltungsfunktionen für Subsysteme eines Computergeräts und ist getrennt von einer Verarbeitungsressource, die ein Betriebssystem eines Computergeräts ausführt. Der Baseboard-Management-Controller ist von einem Prozessor, wie z. B. einer Zentraleinheit, getrennt, der ein High-Level-Betriebssystem oder einen Hypervisor auf einem System ausführt.
Gemäß Beispielimplementierungen enthält das Computersystem 100 eine oder mehrere Zentraleinheiten (CPUs) 102 (z. B. CPU-Verarbeitungskerne, Halbleiter, die CPU-Prozessorkerne enthalten) und Speichervorrichtungen, die mit der/den CPU(s) verbunden sind, um einen Systemspeicher 104 zu bilden. Die CPU(s) 102 kann/können mit einer Eingangs-/Ausgangsbrücke (I/O) 106 gekoppelt sein. Darüber hinaus kann das Computersystem 100, wie ebenfalls in dargestellt, ein oder mehrere Peripheral Component Interconnect Express (PCIe)-Geräte 110 (z. B. PCIe-Erweiterungskarten) enthalten, die über entsprechende individuelle PCIe-Busse 108 mit der/den CPU(s) 102 gekoppelt sein können. Gemäß einer weiteren Beispielimplementierung kann das/die PCIe-Gerät(e) 110 mit der E/A-Brücke 106 gekoppelt sein, anstatt mit der/den CPU(s) 102 gekoppelt zu sein.
Im Allgemeinen können die Speichervorrichtungen, die den Systemspeicher 104 bilden, sowie andere hierin beschriebene Speichervorrichtungen aus nicht transitorischen Speichervorrichtungen gebildet werden, wie z. B. Halbleiterspeichervorrichtungen, Flash-Speichervorrichtungen, Memristoren, Phasenwechselspeichervorrichtungen, einer Kombination aus einer oder mehreren der vorgenannten Speichertechnologien usw. Darüber hinaus können die Speichervorrichtungen flüchtige Speichervorrichtungen (z. B. dynamische Direktzugriffsspeicher (DRAM)-Vorrichtungen, statische Direktzugriffsspeicher (SRAM)-Vorrichtungen und so weiter) oder nichtflüchtige Speichervorrichtungen (z. B. Flash-Speicher-Vorrichtungen, Festwertspeicher (ROM)-Vorrichtungen und so weiter) sein, sofern hier nicht anders angegeben.
Im Allgemeinen kann die E/A-Brücke106 die CPU(s) 102 mit dem Baseboard-Management-Controller 130, einem oder mehreren Speichergeräten 122, einem oder mehreren Netzwerkschnittstellen-Controllern (NICs) 124, einem oder mehreren USB-Geräten (Universal Serial Bus) 126 usw. verbinden.
Im Allgemeinen enthält der Basisplatinen-Verwaltungscontroller 130 Allzweck-Verarbeitungskern(e) 154 (z. B. ARM-Verarbeitungskerne), die der Basisplatinen-Verwaltungscontroller 130 beim Einschalten im Reset hält. Nach der Durchführung anfänglicher Root-of-Trust-Sicherheitsprüfungen sowie anderer Prüfungen (z. B. Hardware-Fehlerprüfungen) gibt der Baseboard-Management-Controller 130 den/die Allzweck-Verarbeitungskern(e) 154 aus dem Reset frei. Genauer gesagt ist der Baseboard-Management-Controller 130 gemäß Beispielimplementierungen mit einem externen nichtflüchtigen Speicher 168 gekoppelt, der Firmware 170 speichert, die von dem Baseboard-Management-Controller 130 validiert und von einer CPU 102 ausgeführt wird, um das Computersystem 100 zu starten. In Übereinstimmung mit Beispielimplementierungen enthält der Baseboard-Management-Controller 130 eine Hardware Root of Trust (RoT)-Engine 143. Gemäß Beispielimplementierungen speichert die RoT-Engine 143 einen unveränderlichen Fingerabdruck, der verwendet wird, um maschinenausführbare Anweisungen zu validieren. Genauer gesagt lädt die RoT-Engine 143 als Reaktion auf das Booten des Baseboard-Management-Controllers 130 einen Teil der Firmware 170 und legt den Teil der Firmware in einem Speicher 297 des Baseboard-Management-Controllers 130 ab, sichert den Speicher 297, validiert den Teil der Firmware 170 (unter Verwendung des unveränderlichen Fingerabdrucks) und sperrt den Inhalt des Speichers 297, so dass der Inhalt nicht verändert werden kann. Wenn der/die Allzweckverarbeitungskern(e) 154 aus dem Reset herausgenommen werden, rufen der/die Kern(e) 154 die Anweisungen im sicheren Speicher 297 ab (der validiert und gegen zukünftige Änderungen gesperrt wurde). Die Firmware-Befehle im Speicher 297 werden von dem (den) Mehrzweck-Verarbeitungskern(en) ausgeführt, um den nächsten Teil der Firmware 170 zu validieren, der aus dem Speicher 168 ausgeführt werden kann oder nach Beendigung der Ausführung von Patch-Befehlen (hierin weiter beschrieben) aus einem flüchtigen Speicher 164 (z. B. einem Speicher, der aus Double Data Rate (DDR) 4 DRAM-Bauteilen gebildet wird) kopiert und ausgeführt werden kann, der sich außerhalb des Basisplatinen-Management-Controllers 130 befindet. In Übereinstimmung mit Beispielimplementierungen kann die Validierung von Komponenten des Computersystems 100 stufenweise erfolgen (Teil 1 validiert Teil 2, bevor er ausgeführt werden darf, usw.), und die „Wurzel“ des Prozesses wird in Hardware von der RoT-Engine 143 ausgeführt.
Wie ebenfalls in dargestellt, kann der Baseboard-Management-Controller 130 einen Video-Controller 131 enthalten, der von der/den CPU(s) 102 des Computersystems 100 konfiguriert werden kann. Der Speicher 164 kann von dem Videocontroller 131 und dem/den Allzweckverarbeitungskern(en) 154 gemeinsam genutzt werden, so dass gemäß Beispielimplementierungen ein Videocontroller-Bildpuffer in dem Speicher 164 gespeichert werden kann. In Übereinstimmung mit Beispielimplementierungen ist der Videocontroller 131 mit einer Anzeige 105 gekoppelt.
Wie hierin beschrieben, arbeitet der Konfigurator 140 in Übereinstimmung mit Beispielimplementierungen autonom oder unabhängig in Bezug auf den/die Mehrzweck-Verarbeitungskern(e) 154 des Basisplatinen-Management-Controllers 130, um die Subsysteme 150 des Basisplatinen-Management-Controllers 130 zu initialisieren oder zu konfigurieren. Genauer gesagt arbeitet der Konfigurator 140 in Übereinstimmung mit Beispielimplementierungen, um die Subsysteme 150 zu konfigurieren, während der Basisplatinen-Verwaltungscontroller 130 den/die Mehrzweck-Verarbeitungskern(e) 154 beim Einschalten oder Hochfahren des Basisplatinen-Verwaltungscontrollers 130 in einem Reset-Zustand hält.
Darüber hinaus steuert der Baseboard-Management-Controller 130, wie hier weiter beschrieben, Schalter 141 des Controllers 130, um den Konfigurator 140 mit den Subsystemen 150 zu koppeln und den/die Allzweckverarbeitungskern(e) 154 von den Subsystemen 150 zu isolieren, während der Konfigurator 140 die Subsysteme 150 konfiguriert. So haben der/die Allzweckverarbeitungskern(e) 154 des Basisplatinenmanagement-Controllers 130 keinen Zugriff auf die Subsysteme 150, bis die Subsysteme 150 vom Konfigurator 140 auf die entsprechenden grundlegenden Funktionsebenen konfiguriert worden sind. Diese Basisfunktionalität kann vorteilhaft sein, um ein „Bricking“ des Baseboard-Management-Controllers 130 (und möglicherweise ein Bricking des Computersystems 100) zu vermeiden, ohne dass ein Hinweis darauf vorliegt, warum dies geschehen ist. Beispielsweise können die Subsysteme 150 Schnittstellen sein (z. B. eine physische Speicherschnittstelle und ein Speicher-Controller), die die Anzeige von Informations- und Fehlermeldungen an den Endbenutzer über den Speicher 164 ermöglichen. Genauer gesagt, gemäß Beispielimplementierungen, wenn der Baseboard-Management-Controller 130 eine Fehlfunktion aufweist (z. B. eine Fehlfunktion aufgrund eines Hardwarefehlers, eines Fehlers bei der kryptografischen Schlüsselüberprüfung usw.), dann können die CPU(s) 102 die Fehlfunktion erkennen und Fehlermeldungen auf dem Display 105 unter Verwendung des Videocontrollers 131 innerhalb des Baseboard-Management-Controllers 130 anzeigen, da der Speichercontroller und die physischen Speicherschnittstellen jeweils durch den Konfigurator 140 auf eine Grundstufe initialisiert wurden.
Wie ebenfalls in dargestellt, kann gemäß Beispielimplementierungen ein programmierbares Logikgerät (PLD) 160 (z. B. ein komplexes PLD (cPLD)) mit dem Basisboard-Verwaltungs-Controller 130 verbunden sein und, wie hierin weiter beschrieben, verwendet werden, um Daten, die einen Bitvektor von Daten darstellen, an den Basisboard-Verwaltungs-Controller 130 als Reaktion auf den Übergang des Basisboard-Verwaltungs-Controllers 130 von einem Einschalt-Reset zu übermitteln. Dieser Bitvektor von Daten, wie hierin weiter beschrieben, kann verwendet werden, um die Freigabe des/der Allzweckverarbeitungskerns/-kerne 154 aus dem Reset zu steuern, und kann verwendet werden, um Gruppen von Anweisungen zu identifizieren, die vom Konfigurator 140 ausgeführt werden sollen, um anzupassen, wie die bestimmten Subsysteme 150 konfiguriert sind. Darüber hinaus kann das PLD 160, wie ebenfalls hierin beschrieben, Daten speichern, die eine „Patch-Tabelle“ darstellen, wobei Datensätze der Patch-Tabelle von dem/den Allzweckverarbeitungskern(en) 154 ausgeführt werden können (nachdem der/die Kern(e) 154 aus dem Reset freigegeben wurde(n)), um ein oder mehrere Subsysteme 150 weiter zu konfig u rieren.
In ist eine bestimmte Beispielarchitektur für den Baseboard-Management-Controller 130 dargestellt, obwohl der Baseboard-Management-Controller 130 eine beliebige von einer Reihe von Architekturen haben kann, die von der in dargestellten Architektur in Übereinstimmung mit weiteren Implementierungen abweichen. Bei der in dargestellten Implementierung kommuniziert der Baseboard-Management-Controller 130 mit dem externen PLD 160 über eine cPLD-Schnittstelle (hier als „CIF-Bus 212“ bezeichnet) unter Verwendung einer CIF-Bus-Engine 280. Der Baseboard-Management-Controller 130 umfasst eine Reset-Steuerungsschaltung 284, um zu steuern, wann der/die Allzweck-Verarbeitungskern(e) 154 im Reset-Zustand gehalten wird/werden; und eine SPI-Engine (Serial Peripheral Interface) 290, die es dem Baseboard-Management-Controller 130 ermöglicht, mit dem externen Speicher 168 zu kommunizieren, der die Firmware 170 speichert.
Wie in dargestellt, enthält die Firmware 170 in Übereinstimmung mit Beispielimplementierungen Boot-Befehle 294, die den anfänglichen Teil der Befehle enthalten, die von der RoT-Engine 143 in den Speicher 297 geladen und von dem/den allgemeinen Verarbeitungskern(en) 154 ausgeführt werden, wenn sie aus dem Reset freigegeben werden. Wie oben beschrieben, holen der/die allgemeine(n) Verarbeitungskern(e) 154 gemäß Beispielimplementierungen Anweisungen in den sicheren Speicher 297 und führen die Anweisungen aus, um den nächsten Teil der Firmware 170 zu validieren, der aus dem Speicher 168 ausgeführt werden kann oder nach Beendigung der Ausführung von Patch-Anweisungen (hierin weiter beschrieben) aus dem flüchtigen Speicher 164 kopiert und ausgeführt werden kann.
Wie in dargestellt, kann die Firmware 170 Systemverwaltungsanweisungen 296 enthalten, die aus dem Speicher 168 in den Speicher 164 kopiert werden, wo die Anweisungen 296 von dem/den Mehrzweckverarbeitungskern(en) 154 ausgeführt werden, um Laufzeit-Systemverwaltungsfunktionen des Basisplatinen-Verwaltungscontrollers 130 auszuführen, wie z. B. die Kommunikation mit einem Fernverwaltungsserver, die Kommunikation mit, die Überwachung und möglicherweise die Änderung von Hardwarekomponenten des Computersystems 100, die Kommunikation mit Anwendungen, die auf dem Computersystem 100 ausgeführt werden, usw.
In Übereinstimmung mit Beispielimplementierungen enthält der Konfigurator 140 einen Master-Prozessor 230, der speziell für die Konfiguration oder Initialisierung eines bestimmten Subsystems 150 (hier Subsystem 150-1 für das in dargestellte Beispiel) von N Subsystemen 150 des Basisplatinen-Management-Controllers 130 konstruiert sein kann. Der Hauptprozessor 230 umfasst gemäß Beispielimplementierungen einen Hauptverarbeitungskern 236, bei dem es sich um einen eingebetteten Mikrocontroller handeln kann, der autonom oder unabhängig in Bezug auf den/die Mehrzweckverarbeitungskern(e) 154 arbeitet. Gemäß einer Beispielimplementierung kann der Hauptverarbeitungskern 236 unter Verwendung einer Register Transfer Language (RTL)-Abstraktion in der Hardware Design Language (HDL) implementiert werden.
Im Allgemeinen kann der Hauptverarbeitungskern 236 relativ stark auf die spezifische Aufgabe der Konfiguration eines bestimmten Teilsystems 150, wie z. B. des Teilsystems 150-1, wie in dargestellt, zugeschnitten sein. Der Hauptverarbeitungskern 236 führt gemäß Beispielimplementierungen Anweisungen 234 aus, die in einem nichtflüchtigen Speicher des Hauptprozessors 230 gespeichert sind, z. B. in einem Hauptfestwertspeicher (ROM) 232, wie in dargestellt. Das Speichern der ausführbaren Befehle 234 in einem nichtflüchtigen Speicher, der aktualisiert werden kann, wie dem Master-ROM 232, im Gegensatz zu beispielsweise fest kodierten Befehlen für den Verarbeitungskern 236, ermöglicht Flexibilität für die Änderung der Konfiguration des Teilsystems 150-1 ohne die Notwendigkeit eines vollständigen Metallschicht-Spins (d. h. ohne eine weitere Reise durch einen Design-, Engineering-Fertigungszyklus).
Als spezifischeres Beispiel kann in Übereinstimmung mit einigen Implementierungen das Subsystem 150-1 ein Speicher-Controller für den externen Speicher 164 sein, und ein anderes Subsystem 150, wie z. B. Subsystem 150-N, kann eine physikalische Speicherschnittstelle für den Speicher 164 sein. Wenn beispielsweise eine Zeitverzögerung zwischen dem Einstellen eines Parameters für den Speicher-Controller und dem Einschalten der physischen Speicherschnittstelle geändert werden soll, kann der Master-ROM 232 relativ einfach und ohne Auswirkungen auf einen nachfolgenden Freigabeplan für den Baseboard-Management-Controller 130 aktualisiert werden.
In Übereinstimmung mit weiteren Beispielimplementierungen kann der Master-Prozessor 230 (und der Master-Verarbeitungskern 236) verwendet werden, um ein anderes Subsystem als einen Speicher-Controller zu konfigurieren. In Übereinstimmung mit Beispielimplementierungen können die Subsysteme 150, die vom Konfigurator 140 (entweder über den Master-Prozessor 230 oder über einen Slave-Prozessor 260, wie hierin weiter beschrieben) konfiguriert werden können, beispielsweise eine physikalische Speicherschnittstelle, den Videocontroller 131 oder eine Spannungsversorgung umfassen. Darüber hinaus kann gemäß einigen Implementierungen eine serielle Hochgeschwindigkeits-Kommunikationsschnittstelle 292 des Baseboard-Management-Controllers 130 ein Subsystem 150 sein, das vom Konfigurator 140 konfiguriert wird. Auf diese Weise kann die serielle Hochgeschwindigkeitskommunikationsschnittstelle 292 über eine physikalische und eine Verbindungsschicht verfügen, die (über CSR-Register) so programmiert werden können, dass sie eine beliebige Anzahl verschiedener Protokolle implementieren, wie z. B. PCIe- und Infiniband-Protokolle. In Übereinstimmung mit einigen Implementierungen kann die CPU(s) 102 über die Kommunikationsschnittstelle 292 mit Komponenten des Basisband-Verwaltungscontrollers 130, wie z. B. dem Videocontroller 131, kommunizieren.
Als Beispiel kann der Master-ROM 232 gemäß einigen Implementierungen eine Breite von 84 Bit und eine Tiefe von 128 Einträgen haben, wodurch 128 Befehle 234 im Master-ROM 232 gespeichert werden können. Der Master-ROM 232 kann gemäß weiteren Implementierungen andere Breiten und Eintragstiefen haben.
Wie in dargestellt, kann der Hauptverarbeitungskern 236 in Übereinstimmung mit einigen Implementierungen mit dem Subsystem 150-1 unter Verwendung eines Advanced High-Performance Bus (AHB) kommunizieren, und der Hauptverarbeitungskern 236 kann den AHB mit dem/den Mehrzweckverarbeitungskern(en) 154 in einer Zeitmultiplexweise teilen. Auf diese Weise kann der Hauptverarbeitungskern 236 gemäß Beispielimplementierungen einen Schalter oder Multiplexer 242 (einen der Schalter 141) steuern, um zu kontrollieren, ob 1. der Hauptverarbeitungskern 236 mit einem AHB-Segment 246 verbunden ist, das mit dem Subsystem 150-1 verbunden ist, oder 2. alternativ, ob der/die Mehrzweckverarbeitungskern(e) 154 mit dem AHB-Segment 246 verbunden sind. Genauer gesagt ist gemäß Beispielimplementierungen der Hauptverarbeitungskern 236 mit einem AHB-Segment 240 gekoppelt, das ein Eingang des Multiplexers 242 ist; und der/die Allzweckverarbeitungskern(e) 154 sind mit einem anderen AHB-Segment 244 gekoppelt, das einem anderen Eingang des Multiplexers 242 entspricht. Das Subsystem 150-1 ist mit einem weiteren AHB-Segment 246 gekoppelt, das mit einem Ausgang des Multiplexers 242 gekoppelt ist.
Während der Anfangsphase beim Einschalt-Reset, in der der Konfigurator 140 die Subsysteme 150 konfiguriert (und während der der/die Mehrzweckverarbeitungskern(e) 154 im Reset gehalten werden), steuert der Hauptverarbeitungskern 236 den Multiplexer 242, um die AHB-Bussegmente 240 und 246 miteinander zu koppeln und den/die Mehrzweckverarbeitungskern(e) 154 vom Subsystem 150-1 zu isolieren. Mit dieser Multiplexerkonfiguration kann der Hauptverarbeitungskern 236 mit dem Subsystem 150-1 kommunizieren, um das Subsystem 150-1 zu konfigurieren, d. h. um Steuer- und Statusregister 248 des Subsystems 150-1 zu lesen und zu beschreiben. In ähnlicher Weise kann der Hauptverarbeitungskern 236 andere Multiplexer steuern (d. h. andere Schalter 141 steuern), um andere Subsysteme 150 von den Allzweckverarbeitungskernen 150 zu isolieren und die Konfiguration dieser anderen Subsysteme zu ermöglichen, wie hierin weiter beschrieben. Wenn die Konfiguration der Subsysteme 150 abgeschlossen ist, kann der Hauptverarbeitungskern 236 gemäß Beispielimplementierungen die Multiplexer weiter steuern, um die Komponenten des Konfigurators 140 von den Subsystemen 150 zu isolieren und den/die Mehrzweckverarbeitungskern(e) 154 physisch mit dem Subsystem 150 zu verbinden, so dass der/die Kern(e) 154 die nun konfigurierten Subsysteme 150 verwenden kann/können.
Gemäß Beispielimplementierungen können die Befehle 234, die im Master-ROM 232 gespeichert sind, ein Befehlsformat haben, das in einer Tabelle 300 von dargestellt ist. Unter Bezugnahme auf in Verbindung mit stellen die ersten drei Bits (CMD [2:0]) des Befehls einen Befehl dar, und Beispielbefehle, zusammen mit einer Beispiel-Bitkodierung, die jedem Befehl entspricht, sind in Spalte 302 der Tabelle 300 dargestellt. Bezogen auf die Spalte 302 entspricht „RMW“ einem Lese-Änderungs-Schreib-Befehl; „POL“ entspricht einem Abfragebefehl; „JMP“ entspricht einem Sprungbefehl; „DLY“ entspricht einem Verzögerungsbefehl; „NOP“ entspricht einem Befehl für keine Operation; „CAS“ entspricht einem Fallbefehl eines Fallbefehls (weiter unten beschrieben); und „DFI“ entspricht einem Befehl für einen Befehl (weiter unten beschrieben), der einen eingebetteten Befehl für einen Slave-Prozessor 260 enthält.
In den Spalten 306, 308 und 310 sind Operandenfelder für die Befehle gemäß einer Beispielimplementierung dargestellt, und Spalte 312 enthält Beschreibungen für die Befehle Lesen-Ändern-Schreiben, Schreiben und Abfragen. Für den Sprungbefehl beispielsweise enthält das 16-Bit-Operandenfeld OP1[19:4] (dargestellt in Spalte 306) Bits, die einen Zeiger auf den nächsten auszuführenden Befehl darstellen. Als weiteres Beispiel für den Verzögerungsbefehl enthält das Operandenfeld [5:4] Bits, die eine bestimmte Verzögerung darstellen, z. B. eine Verzögerung von einer Anzahl von Mikrosekunden (d. h., [5:4]=„b10“, wobei „b“ eine binäre Darstellung bezeichnet), wobei die Anzahl der Mikrosekunden durch die Bits in einem 32-Bit-Operandenfeld OP2[51:20] festgelegt wird. Wie in Spalte 310 dargestellt, kann ein weiteres Zweiunddreißig-Bit-Operandenfeld OP3[83:52] Bits enthalten, die eine Zweiunddreißig-Datenmaske darstellen.
Gemäß Beispielimplementierungen kann die Anweisung ein einzelnes Bitfeld (LC[3], dargestellt in Spalte 304) enthalten, das (abhängig vom Wert des Bits) dazu verwendet werden kann, einen bestimmten Satz von Anweisungen, die als Gruppe ausgeführt werden sollen, zu kennzeichnen
Im Allgemeinen veranlasst die Ausführung des Fallbefehls (d. h. eines Befehls 234 mit dem CAS-Befehl) den Hauptverarbeitungskern 236, unter den Gruppen von Befehlen, die unmittelbar auf den Fallbefehl folgen, eine bestimmte Gruppe von Befehlen 234 zur Ausführung durch den Kern 236 auszuwählen. Genauer gesagt, gemäß einer Beispielimplementierung identifiziert das Sechs-Bit-Operandenfeld Op1[9:4] des Fallbefehls eine Start-Bitposition eines Bitvektors 282 (siehe ), und das Zwei-Bit-Operandenfeld Op1[11:10] des Operandenfelds identifiziert eine Länge oder Anzahl von zusammenhängenden Bitpositionen (beginnend mit der Start-Bitposition) des Bitvektors 282. Daher identifiziert die Kombination der Operandenfelder Op1[9:4] und Op1[11:10] der Case-Anweisung einen zusammenhängenden Satz von Bits des Bitvektors 282. Der Wert, der durch diesen Satz von Bits dargestellt wird, ist wiederum ein Index oder Selektor, der die bestimmte Gruppe von Anweisungen identifiziert, die der Hauptverarbeitungskern 236 ausführen soll. Die Anzahl der Bits, die durch die Bits im Feld Op1[11:10] dargestellt werden, gibt auch die Anzahl der Befehlsgruppen (2 ^Längen) an, die auf den Fallbefehl folgen. Wenn die Anzahl der Bits beispielsweise „3“ ist, geht der Hauptverarbeitungskern 236 davon aus, dass ²³ = 8 Anweisungsgruppen auf die Fallanweisung folgen; und als weiteres Beispiel, wenn die Anzahl der Bits „2“ ist, geht der Hauptverarbeitungskern 236 davon aus, dass ²² = 4 Anweisungsgruppen auf die Fallanweisung folgen.
Der Hauptverarbeitungskern 236 durchläuft gemäß Beispielimplementierungen die Befehlsgruppen in laufender binärer Reihenfolge und führt die Befehlsgruppe aus, die mit dem Selektor übereinstimmt. Das Ende jeder Anweisungsgruppe kann durch das Bitfeld LC[3] abgegrenzt bzw. mit einem Lesezeichen versehen werden. Daher ist gemäß Beispielimplementierungen die Anzahl der Anweisungen in einer Gruppierung innerhalb der Grenzen der Größe des Master-ROM 232 variabel. In Übereinstimmung mit Beispielimplementierungen fährt der Master-Verarbeitungskern 236 fort, alle verbleibenden Befehlsgruppen zu durchlaufen, die auf die ausgeführte Befehlsgruppe folgen.
Als spezifischeres Beispiel wird im Folgenden eine Beispielsfallanweisung aufgeführt:

CMD[2:0] = CAS, Op1[9:4]=6'd22, Op1[11:10]=2'd2

In dieser Notation bedeutet „6'd22“ sechs Bits, die zusammen einem Dezimalwert von „22“ entsprechen; und „2'd2“ bedeutet zwei Bits, die zusammen einem Dezimalwert von „2“ entsprechen. Daher entsprechen in diesem Beispiel die Bitpositionen 22 und 23 des Bitvektors der Daten 282 dem Gruppenbefehlsselektor. Da der Selektor aus zwei Bits gebildet wird, gibt es außerdem vier Gruppen von Anweisungen, die auf die Case-Anweisung folgen. Die Case-Anweisung kann daher im Pseudocode wie folgt dargestellt werden:

                             case (SSTRAP[23:22])
                        2'b00: Befehlsgruppe 1 ausführen
                        2'b01: Befehlsgruppe 2 ausführen
                        2'b10: Befehlsgruppe 3 ausführen
                     2'b11: Ausführen Anweisungsgruppe 4

Wie oben erwähnt, hat das Master-ROM 232 eine Tiefe von 128 Einträgen, obwohl das ROM 232 in Übereinstimmung mit Beispielimplementierungen auch andere Tiefen haben kann. Der Master-Verarbeitungskern 236 behandelt gemäß Beispielimplementierungen die letzte Adresse des Master-ROM 232 (z. B. die 128. ROM-Adresse bei einer Implementierung mit 128 Einträgen) als etwas Besonderes, indem der Master-Verarbeitungskern 236 nach der Ausführung eines beliebigen Befehls an der letzten Adresse die Ausführung anhält und bei Ausführung des Befehls innerhalb der letzten ROM-Zeile in einen Leerlaufzustand zurückkehrt. Darüber hinaus kann der Hauptverarbeitungskern 236 gemäß Beispielimplementierungen bei Erreichen des letzten Eintrags und vor der Rückkehr in den Ruhezustand den Auswahleingang des Multiplexers 242 steuern, um den Hauptprozessor 230 vom Subsystem 150-1 zu entkoppeln und das Subsystem 150-1 mit dem AHB-Bussegment 245 zu koppeln, so dass der/die Mehrzweckverarbeitungskern(e) 154 danach für den Zugriff auf das Subsystem 150-1 angeschlossen werden kann/können.

Unter Bezugnahme auf , wie hier weiter beschrieben, kann der Konfigurator 140 gemäß Beispielimplementierungen null, einen oder mehrere Slave-Prozessoren 260 (siehe ) enthalten, die auf die Konfiguration entsprechender Subsysteme 150 des Baseboard-Management-Controllers 130 zugeschnitten sind. Als Beispiele können die von den Slave-Prozessoren 260 konfigurierten Subsysteme 150 einer physikalischen Speicherschnittstelle, einem Bus-Controller, einer Spannungsversorgung usw. entsprechen. Außerdem kann ein bestimmter Slave-Prozessor 260 mit seinem Subsystem 150 unter Verwendung eines Busprotokolls kommunizieren, das sich von dem Protokoll unterscheidet, das von den anderen Slave-Prozessoren 260 und/oder den Master-Prozessoren 230 verwendet wird. So kommuniziert bei der in dargestellten Beispielimplementierung ein Slave-Prozessor 260 mit dem Subsystem 150-N über einen Advanced Peripheral Bus (APB), was z. B. der Fall sein kann, wenn der Slave-Prozessor 260 eine physikalische Speicherschnittstelle konfiguriert.

Die Slave-Prozessoren 260 kommunizieren mit dem Master-Prozessor 230 über einen Befehlsbus 250. Im Allgemeinen enthält der Befehlsbus 250 Kommunikationsleitungen, die vom Master-Verarbeitungskern 236 verwendet werden können, um einen bestimmten Befehl an einen bestimmten Slave-Prozessor 260 zu übermitteln, und enthält Dekodierleitungen, die vom Master-Verarbeitungskern 236 verwendet werden, um den bestimmten Slave-Prozessor 260 auszuwählen, so dass der Slave-Prozessor 260 den Befehl zur Ausführung erhalten kann. Auf diese Weise kann der Master-Verarbeitungskern 236 in der Lage sein, die Slave-Prozessoren 260 zu steuern.

Unter Bezugnahme auf in Verbindung mit ist der „DFI“-Befehl (mit dem „DFI“-Befehl) gemäß Beispielimplementierungen ein Beispiel für einen Befehl, der innerhalb seiner Operanden einen unabhängigen Befehl kodiert, der von einem bestimmten Slave-Prozessor 260 des Konfigurators 140 auszuführen ist. Der DFI-Befehl kann im Master-ROM 232 gespeichert und vom Master-Verarbeitungskern 236 ausgeführt werden, um einen kodierten Befehl darzustellen, der von einem bestimmten Slave-Prozessor 260 auszuführen ist. In Übereinstimmung mit einigen Implementierungen kann der Slave-Prozessor 260 Befehle ausführen, die den Befehlen RMW, WR, POLL und NOP entsprechen.

Als Beispiel kann ein Befehl (hier als „eingebetteter Befehl“ bezeichnet) eines Slave-Prozessors 260 wie folgt in einen DFI-Befehl kodiert werden. Das Zwei-Bit-Operandenfeld Op1 [5:4] enthält die Bits, die den Befehl für den eingebetteten Befehl darstellen, und andere Operandenfelder können je nach Bedarf Bits enthalten, die die Adresse, die Daten und die Maske des eingebetteten Befehls darstellen. Für einen eingebetteten Schreib-Lese-Befehl kann das Operandenfeld Op1[5:4] beispielsweise den Wert „00b“ enthalten (wobei „b“ eine binäre Darstellung bezeichnet), um den RMW-Befehl darzustellen; und andere Operandenfelder des DFI-Befehls können eine 10-Bit-Adresse, 16-Bit-Daten und eine 16-Bit-Maske für den eingebetteten Schreib-Lese-Befehl, ein letztes Befehlsbitfeld und ein Operandenfeld mit Bits enthalten, die den spezifischen Slave-Prozessor 260 zur Ausführung des eingebetteten Schreib-Lese-Befehls darstellen. Als weitere Beispiele für einen DFI-Befehl kann das Operandenfeld Op1[5:4] einen weiteren Satz von Bitwerten enthalten, die einen anderen Befehl darstellen (z. B., ein WR-Schreibbefehl, ein POLL-Abfragebefehl und ein NOP-Befehl für keine Operation); andere Operandenfelder des DFI-Befehls können gegebenenfalls Operanden für den eingebetteten Befehl darstellen, wie z. B. eine Adresse, Daten, Maske usw.; und der DFI-Befehl kann auch ein Operandenfeld enthalten, das Bits enthält, die darstellen, ob der eingebettete Befehl ein letzter Befehl ist, und Bits, die den spezifischen Slave-Prozessor 260 zur Ausführung des eingebetteten Befehls darstellen.

Gemäß Beispielimplementierungen kann der Basisplatinen-Verwaltungscontroller 130 mehrere, doppelte Subsysteme 150 enthalten, die denselben Aufbau und dieselbe Konfiguration haben; und jedes dieser doppelten Subsysteme 150 kann von einem entsprechenden Slave-Prozessor 260 konfiguriert werden. Bei diesen Implementierungen kann der Master-Verarbeitungskern 236 einen DFI-Befehl verarbeiten, der einen eingebetteten Befehl enthält, der an alle diese Slave-Prozessoren 260 decodiert wird.

Zurück zu : Gemäß Beispielimplementierungen enthält der Slave-Prozessor 260 einen Speicher 264 und einen Slave-Verarbeitungskern 262, der Anweisungen 266 ausführt, die im Speicher 264 gespeichert sind, um ein zugehöriges Subsystem 150 autonom oder unabhängig zu konfigurieren. Der Speicher 264 speichert in Übereinstimmung mit Beispielimplementierungen Anweisungen 266, die vom Master-Verarbeitungskern 236 an den Slave-Prozessor 260 übermittelt werden, wie oben beschrieben. In Übereinstimmung mit einigen Implementierungen kann der Speicher 264 ein flüchtiger Speicher sein, der keine anderen Befehle als die Befehle enthält, die über den Befehlsbus 250 an den Slave-Prozessor 260 übermittelt werden (z. B. als Reaktion auf die Ausführung eines DFI-Befehls durch den Hauptverarbeitungskern 236). In Übereinstimmung mit weiteren Beispielimplementierungen kann der Speicher 264 einen nichtflüchtigen Speicher umfassen, der mit bestimmten Befehlen 264 vorcodiert ist, die vom Slave-Verarbeitungskern 262 ausgeführt werden sollen.

Ähnlich wie der Master-Prozessor 230 kann der Slave-Verarbeitungskern 262 in Übereinstimmung mit einigen Implementierungen einen zugehörigen Schalter 141 oder Multiplexer 270 steuern, der den Slave-Verarbeitungskern 262 mit dem zugehörigen Sub-Subsystem 150 koppelt. Der Multiplexer 270 hat einen Eingang, der mit einem APB-Segment 272 verbunden ist, und einen anderen Eingang, der mit einem APB-Bussegment 224 verbunden ist, das über eine Brücke 267 mit dem AHB-Bussegment 244 verbunden ist. Der Ausgang des Multiplexers 270 ist mit einem APB-Segment 276 verbunden, das mit dem zugehörigen Subsystem 150 verbunden ist. Der Slave-Verarbeitungskern 262 kann den Multiplexer 270 steuern, um zu kontrollieren, ob 1. der Slave-Verarbeitungskern 262 mit dem APB-Segment 276 verbunden ist, oder 2. alternativ, ob der/die Allzweck-Verarbeitungskern(e) 154 mit dem APB-Segment 276 verbunden sind.

In Übereinstimmung mit einigen Implementierungen kann der Slave-Verarbeitungskern 262 ein ähnliches Design wie der Master-Verarbeitungskern 236 haben. In dieser Hinsicht können beide Verarbeitungskerne 236 und 262 gemäß Beispielimplementierungen z. B. unter Verwendung einer RTL-Abstraktion in HDL implementiert sein. In Übereinstimmung mit einigen Implementierungen kann der Slave-Verarbeitungskern 262 einen zugehörigen Befehlssatz haben, der kleiner ist als der Befehlssatz des Master-Verarbeitungskerns 236. In Übereinstimmung mit einigen Implementierungen führt der Slave-Verarbeitungskern 262 beispielsweise keinen Befehl aus, der einen eingebetteten Befehl, wie den DFI-Befehl, enthält. In Übereinstimmung mit einigen Implementierungen führt der Slave-Verarbeitungskern 262 möglicherweise keine Case-Anweisung aus. Der Slave-Verarbeitungskern 262 kann in Übereinstimmung mit Beispielimplementierungen Lese-Änderungs-Schreib-, Schreib-, Lese-, Keine-Operation-, Sprung- und Abfragebefehle sowie möglicherweise andere Befehle ausführen.

Wie in dargestellt, kann der PLD 160 den Bitvektor der Daten 215 speichern, der dem Bitvektor der Daten 282 entspricht, die dem Hauptprozessor 230 zugeführt werden. Gemäß Beispielimplementierungen kommuniziert eine Engine 280 des Basisplatinen-Verwaltungscontrollers 130 als Reaktion auf einen Power-On-Reset des Basisplatinen-Verwaltungscontrollers mit dem PLD 160 (über den CIF-Bus 212), um den Bitvektor der Daten 282 abzurufen. Wie auch mit der Bezugszahl 281 angegeben, kann die Engine 280 auch Daten, die den Bitvektor der Daten darstellen, an eine Reset-Steuerschaltung 284 des Basisplatinen-Verwaltungscontrollers weiterleiten. Gemäß Beispielimplementierungen setzt die Rücksetzsteuerschaltung 284 den/die Mehrzweckverarbeitungskern(e) 154 als Reaktion auf das Einschalt-Reset des Basisplatinen-Verwaltungscontrollers 130 in den Reset-Zustand, und die Rücksetzsteuerschaltung 284 hält den/die Mehrzweckverarbeitungskern(e) 154 im Reset-Zustand, bis bestimmte Bedingungen erfüllt sind. Gemäß einer Beispielimplementierung kann der Bitvektor der Daten 281 eine oder mehrere solcher Bedingungen festlegen. Als Beispiele kann der Bitvektor der Daten 281 eine oder mehrere bezeichnete Bitpositionen haben, die es dem Konfigurator 140 ermöglichen, die Subsysteme 150 mit spezifischen Bedingungen zu konfigurieren, damit der/die Mehrzweckverarbeitungskern(e) 154 aus der Rücksetzung freigegeben werden können, wie z. B. dass alle Prozessoren 230 und 260 des Konfigurators 140 in den Ruhezustand zurückkehren, dass eine bestimmte Zeitspanne verstreicht, dass ein Flag abgefragt wird, um anzuzeigen, dass die Konfiguration der Subsysteme 150 durch den Konfigurator abgeschlossen ist, und so weiter. Gemäß Beispielimplementierungen kann die Reset-Steuerschaltung 284 Bedingungen für die Freigabe des/der Mehrzweckverarbeitungskerns/-kerne 154 aus dem Reset vorgeben, die unabhängig von den Aktionen des Konfigurators 140 sind, wie z. B. Bedingungen bezüglich der Feststellung, ob Hardwarefehler vorliegen, Bedingungen bezüglich der Frage, ob Root-of-Trust-Sicherheitsprüfungen bestanden wurden, usw.

In Übereinstimmung mit Beispielimplementierungen konfiguriert der Konfigurator 140 die Subsysteme 150 zumindest bis zu einem Punkt, um die Subsysteme 150 auf ein grundlegendes Funktionsniveau für einfache Operationen zu bringen. In Übereinstimmung mit einigen Implementierungen können die Subsysteme 150 beispielsweise einen Speicher-Controller (ein Subsystem 150) und eine physische Speicherschnittstelle (ein anderes Subsystem 150) umfassen, und der Konfigurator 140 konfiguriert den Speicher-Controller und die physische Speicherschnittstelle auf grundlegende Funktionsebenen, während die Allzweckverarbeitungskerne 154 im Reset gehalten werden. Sollte daher ein bestimmtes Problem auftreten (z. B. ein Hardwarefehler, ein Fehler bei der kryptografischen Prüfung usw.), das verhindert, dass der/die Allzweckverarbeitungskern(e) 154 aus dem Reset freigegeben werden, kann/können die CPU(s) 102 die Fehlfunktion erkennen und Fehlermeldungen auf dem Display 105 mithilfe des Videocontrollers 131 innerhalb des Baseboard-Management-Controllers 130 anzeigen.

Gemäß Beispielimplementierungen ermöglicht der Basisplatinen-Verwaltungscontroller 130 eine weitere Konfiguration der Subsysteme 150, nachdem der/die Allzweckverarbeitungskern(e) 154 aus dem Reset-Zustand freigegeben wurden (und nach der Konfiguration der Subsysteme 150 durch den Konfigurator 140). Genauer gesagt speichert das PLD 160 in Übereinstimmung mit Beispielimplementierungen Patch-Daten 214, die eine Patch-Tabelle darstellen, die Patch-Datensätze enthält, die von dem/den Allzweckverarbeitungskern(en) 154 zum Zwecke der weiteren Konfiguration der Subsysteme 150 ausgeführt werden sollen. Zum Beispiel kann ein bestimmter Patch-Datensatz Anweisungen enthalten, um verschiedene Felder für die Ergebnisqualität (QoR) in einem Speicher-Controller zu setzen, um die Systembusleistung für den Speicher-Controller zu optimieren. Andere Optimierungen auf relativ niedriger Ebene können für einen Speicher-Controller sowie für andere Subsysteme über die Ausführung der Anweisungen, die in den Patch-Tabellen-Datensätzen enthalten sind, durchgeführt werden. Als weiteres Beispiel kann ein Patch-Datensatz eine Verzögerungsoperation enthalten, um Initialisierungsroutinen zu ermöglichen, die zeitliche Elemente enthalten.

In Übereinstimmung mit einigen Implementierungen bilden die Bootstrap-Befehle 294, wenn sie von einem oder mehreren Allzweckverarbeitungskernen 154 ausgeführt werden, einen Datensatzinterpreter, der die Datensätze der Patch-Tabelle verarbeitet und Informationen erhält, die für die Initialisierung und/oder das Patchen einer Einstellung für ein oder mehrere Subsysteme 150 relevant sind. Es gibt viele verschiedene Arten von Operationen, die gemäß Beispielimplementierungen durch die Datensätze der Patch-Tabelle gesteuert werden können. Der Datensatzinterpreter tastet die Kopfdaten im Patch-Datensatz ab, um zu erfahren, wie viele gültige Datensätze in der Patch-Tabelle existieren. In Übereinstimmung mit Beispielimplementierungen wird der Datensatzinterpreter von dem/den Allzweckverarbeitungskern(en) 154 zu Beginn der Ausführung der Bootstrap-Befehle ausgeführt. Wenn der Datensatzinterpreter die Verarbeitung der Datensätze der Patch-Tabelle abgeschlossen hat, kann der/die Allzweckverarbeitungskern(e) 154 dann mit der Ausführung weiterer Bootstrap-Anweisungen 294 fortfahren.

Bezug nehmend auf kann die Patch-Tabelle gemäß Beispielimplementierungen eine Kopfzeile enthalten, wie z. B. eine Kopfzeile, die durch eine Tabelle 400 von veranschaulicht wird. Die Tabelle 400 illustriert beispielhafte Header-Felder (in Spalte 402) und Definitionen (in Spalte 404) der Header-Felder. Wie gezeigt, kann der Kopf der Patch-Tabelle ein Feld (NUM_PATCH_SET_BYTES[15:0]) enthalten, das Daten enthält, die die Anzahl der Bytes der Patch-Tabelle darstellen; ein Feld (NUM_PATCH SET_ENTRIES[15:0]), das Daten enthält, die die Anzahl der Einträge oder Datensätze der Patch-Tabelle darstellen; ein Feld (MEM_CONFIG_CHECKSUM[31:0]), das Daten enthält, die eine Prüfsumme der Patch-Tabelle und des Headers darstellen; ein Feld (MEM_CONFIG_GEN_REV[15:0]), das Daten enthält, die eine Schema-Generation darstellen; und ein Feld (MEM_CONFIG_TABLE_REV[15:0]), das Daten enthält, die eine Revisionsnummer der Patch-Tabelle darstellen.

ist eine Tabelle 500, die Felder (Spalte 502) und Beschreibungen (Spalte 504) eines Patch-Tabelleneintrags oder -datensatzes in Übereinstimmung mit Beispielimplementierungen darstellt. Wie gezeigt, kann der Patch-Tabellen-Datensatz ein Feld (REG_CLASS[2:0]) enthalten, das eine Klasse des Datensatzes definiert; ein Feld (FIELD_START_BIT[4:0]), das die Startbitposition des zu modifizierenden Registers 248 definiert; ein Feld (REG_OP_CODE[2:0]), das einen Befehl (z. B., RMW, POLL und DELAY), der ausgeführt werden soll; ein Feld (FIELD_BIT_LENGTH[4:0]), das die Länge des zu schreibenden oder zu patchenden Feldes im Konfigurationsregister 248 in Bits definiert; ein Feld (REG_OFFSET[15:0]), das einen Register-Offset oder eine Verzögerung definiert (je nachdem, ob es sich um einen RMW-Befehl oder DELAY-Befehl handelt); und ein Feld (FIELD_PATCH_DATA[31:0]), das die zu schreibenden Daten oder eine Verzögerung definiert (je nachdem, ob es sich um einen RMW-Befehl oder DELAY-Befehl handelt).

In den , , , und sind die entsprechenden Teile 600A, 600B, 600C bzw. 600E eines Zustandsdiagramms dargestellt, das die Verarbeitung von Anweisungen durch den Hauptverarbeitungskern 236 gemäß Beispielimplementierungen veranschaulicht. Gemäß Beispielimplementierungen hat der Master-Verarbeitungskern 236 die folgenden Zustände: einen IDLE-Zustand 602 ( und ), der der Zustand ist, in dem der Master-Verarbeitungskern 236 im Leerlauf ist und keine Befehle ausführt; einen INIT_CMD-Zustand 608 ( und , der den Zustand darstellt, in dem der Master-Verarbeitungskern 236 im Leerlauf ist und keine Befehle ausführt; einen INIT_CMD-Zustand 608 ( und , der den Zustand darstellt, in dem der Master-Verarbeitungskern 236 im Leerlauf ist. 6A und 6B), bei dem es sich um den Zustand handelt, in dem der Hauptverarbeitungskern 236 die Befehle aus den Anweisungen parst; einen STALL-Zustand 632 ( ; einen DELAY-Zustand 638 ( ; einen WACCESS-Zustand 613 ( und ), in dem der Hauptverarbeitungskern 236 einen Schreibzugriff durchführt; und einen RACCESS-Zustand 683 ( und ), in dem der Hauptverarbeitungskern 236 einen Lesezugriff durchführt. In den , und bezieht sich „AI“ auf eine gegebene Subsystemfunktion, „CND“ auf ein gegebenes bedingtes Sequenzgatter, „SEQ“ auf eine gegebene Gruppe oder Sequenz von auszuführenden Befehlen, „N“ auf die Anzahl der Operanden der Sequenz, „Z“ auf die maximale Anzahl von zusammenhängenden Bits des Bitvektors von Daten, die vom CAS-Befehl unterstützt werden, und „SSTRAPS“ auf den Bitvektor von Daten 282.

Unter Bezugnahme auf zeigt der Abschnitt 600A Entscheidungen, die den Übergang in den INIT_CMD-Zustand 608 betreffen, in dem der Hauptverarbeitungskern 236 mit der Verarbeitung eines Befehls beginnt, einschließlich des Parsens des Befehls aus dem Befehl. Insbesondere sind in Entscheidungen dargestellt, die der Hauptverarbeitungskern 236 trifft, um vom Zustand IDLE 602 in den Zustand INIT_CMD 608 überzugehen. Wie in dargestellt, geht der Hauptverarbeitungskern 236 beim Einschalt-Reset 601 des Basisplatinen-Management-Controllers 130 in den IDLE-Zustand 602 über. Der Hauptverarbeitungskern 236 kann aus dem IDLE-Zustand 602 in den INIT_CMD-Zustand 608 übergehen, um eine beliebige aus einer Anzahl verschiedener Sequenzen der Befehle 234 auszuführen, wie in den Entscheidungsblöcken 604, 612 und 616 dargestellt, wodurch Flexibilität bei der Konfiguration des Konfigurators 140 für die besondere Umgebung des Computersystems, in das der Basisplatinen-Verwaltungscontroller 130 eingebaut ist, ermöglicht wird. Je nach der über die Entscheidungsblöcke 604, 612 und 616 ausgewählten speziellen Befehlssequenz 234 wird der Befehlszeiger (CMD_PTR) in den Blöcken 606, 614 bzw. 618 auf den entsprechenden Wert gesetzt, und die Steuerung geht in den Zustand INIT_CMD 608 über.

zeigt ferner den Übergang in den INIT _CMD-Zustand 608 als Reaktion auf die Auswahl des nächsten Befehls im Master-ROM 232; und den Übergang in den INIT_CMD-Zustand 608 als Reaktion darauf, dass ein Befehl nicht erkannt wurde, der Befehlszeiger aber nicht am Ende des Master-ROM 232 steht (Entscheidungsblock 622). Außerdem geht der Master-Verarbeitungskern 236, wie durch die kombinatorische Logik 625, einen Countdown-Timer 626 und einen Befehlsfilter 627 dargestellt, als Reaktion auf die Ausführung einer Gruppe von Befehlen, die einer Übereinstimmung des Bitvektors des Datenselektors entsprechen, in den Zustand INIT_CMD über.

In sind Entscheidungen dargestellt, die der Hauptverarbeitungskern 236 im Zustand INIT_CMD auf der Grundlage der Analyse des Befehls der Anweisung trifft. Insbesondere, wenn der Befehl ein Stall-Befehl ist (wie im Entscheidungsblock 630 bestimmt), dann geht der Hauptverarbeitungskern 236 in den STALL-Zustand 632 über. Gemäß Beispielimplementierungen geht die Steuerung nach einem Takt aus dem STALL-Zustand 632 zurück in den vorherigen Zustand über, was jedoch in den Figuren aus Gründen der Übersichtlichkeit nicht dargestellt ist. Wenn der Hauptverarbeitungskern 236 feststellt (Entscheidungsblock 634), dass der Befehl ein Verzögerungsbefehl ist, dann verbleibt der Hauptverarbeitungskern 236, wie durch die Blöcke 636, 640 und 642 dargestellt, für eine bestimmte Anzahl in einem DELAY-Zustand 638, bevor er feststellt (Entscheidungsblock 697) ( ), ob sich der Befehlszeiger am Ende des Haupt-ROM 232 befindet. Wenn nicht, inkrementiert der Hauptverarbeitungskern 236 den Befehlszeiger (Block 698) ( ) und kehrt in den INIT_CMD-Zustand 608 zurück. Andernfalls, wenn der Hauptverarbeitungskern 236 feststellt (Entscheidungsblock 697), dass sich der Befehlszeiger am Ende des Master-ROM 232 befindet, kehrt die Steuerung zum Block 624 ( zurück. Wenn der Hauptverarbeitungskern 236 feststellt (Entscheidungsblock 644) ( , dass es sich bei dem Befehl um einen JMP-Befehl handelt, dann setzt der Hauptverarbeitungskern 236 den Befehlszeiger auf die durch den Operanden des Befehls dargestellte Position (Block 646) und kehrt in den INIT_CMD-Zustand 608 zurück.

Wenn der Hauptverarbeitungskern 236 feststellt (Entscheidungsblock 650), dass es sich bei dem Befehl um einen WR-Schreibbefehl handelt, wechselt der Hauptverarbeitungskern 236 in den WACCESS-Zustand 613, um einen Schreibzugriff durchzuführen, wie hierin weiter beschrieben. Wenn der Hauptverarbeitungskern 236 feststellt (Entscheidungsblock 654), dass es sich bei dem Befehl um einen POLL-Befehl oder einen RMW-Befehl handelt, setzt der Hauptverarbeitungskern 236 je nach Bedarf ein Poll-Timer-Flag (Block 656) und geht in den RACCESS-Zustand 683 über, der hier weiter beschrieben wird.

Wenn der Master-Verarbeitungskern 236 feststellt (Entscheidungsblock 660), dass der Befehl ein CAS-Befehl ist, dann stellt der Master-Verarbeitungskern 236 fest (Entscheidungsblock 661), ob sich der Befehlszeiger am Ende des Master-ROM 232 befindet (d. h. in Entscheidungsblock 661 bezieht sich „[END]“ auf den letzten Eintrag im Master-ROM 232), und wenn dies der Fall ist, kehrt die Steuerung zu Block 624 zurück ( . Andernfalls, wenn sich der Befehlszeiger nicht am Ende des Master-ROM 232 befindet, inkrementiert der Master-Verarbeitungskern 236 gemäß Block 662 den Befehlszeiger und setzt ein CAS-Zählerflag und kehrt die Steuerung zum INIT_CMD-Zustand 608 zurück. Wenn der Hauptverarbeitungskern 236 feststellt (Entscheidungsblock 664), dass es sich bei dem Befehl um einen DFI-Befehl handelt, fordert der Hauptverarbeitungskern 236 gemäß den Blöcken 666, 668 und 670 den Befehlsbus 250 an und sendet den eingebetteten Befehl, sobald er erteilt wurde, gemäß Block 672 an den Slave-Prozessor 260. Wie in gezeigt, bestimmt der Hauptverarbeitungskern 236 dann (Entscheidungsblock 693), ob sich der Befehlszeiger am Ende des Haupt-ROM 232 befindet, und wenn nicht, inkrementiert er den Befehlszeiger gemäß Block 699, bevor er in den INIT_CMD-Zustand 608 zurückkehrt. Andernfalls, wenn der Hauptverarbeitungskern 236 feststellt (Entscheidungsblock 693), dass sich der Befehlszeiger am Ende des Master-ROM 232 befindet, kehrt der Hauptverarbeitungskern 236 zum Block 624 zurück ( .

In sind die Aktionen im WACCESS-Zustand 613 und im RACCESS-Zustand 683 dargestellt. Im WACCESS-Zustand 613 stellt der Master-Verarbeitungskern 236 fest (Entscheidungsblock 675), ob es sich bei dem Befehl um einen RMW-Befehl handelt, und wenn ja, führt er (Block 677) das Schreiben der modifizierten Daten an die angegebene Adresse durch. Andernfalls, wenn der Hauptverarbeitungskern 236 feststellt (Entscheidungsblock 675), dass der Befehl ein WR-Befehl ist, schreibt (Block 676) der Hauptverarbeitungskern 236 die angegebenen Daten an die angegebene Adresse. Als Reaktion darauf, dass der Master-Verarbeitungskern 236 feststellt (Entscheidungsblock 681), dass der Schreibvorgang abgeschlossen ist, fährt der Master-Verarbeitungskern 236 mit dem Entscheidungsblock 697 fort ( ). Wenn der Hauptverarbeitungskern 236 feststellt (Entscheidungsblock 679), dass der Schreibvorgang ein abnormal langer Schreibvorgang ist (d. h. eine vorbestimmte Dauer überschreitet, wie durch Dekrementieren eines Zählers angezeigt, wie in Block 695 dargestellt), dann setzt der Hauptverarbeitungskern 236 ein Fehlerflag gemäß Block 680 und kehrt in den IDLE-Zustand 602 zurück.

Im RACCESS-Zustand 683 führt der Master-Verarbeitungskern 236 eine Leseanforderung (Block 684) der angegebenen Adresse durch und bestimmt (Entscheidungsblock 685), ob das Lesen abgeschlossen ist. Bei dieser Bestimmung kann der Master-Verarbeitungskern 236 feststellen (Entscheidungsblock 686), ob ein Timer abgelaufen ist (per Block 687), und wenn ja, ein Fehlerflag setzen (Block 688) und in den IDLE-Zustand 602 zurückkehren. Wenn der Hauptverarbeitungskern 236 feststellt (Entscheidungsblock 689), dass das Lesen mit einem POLL-Befehl verbunden war, dann stellt der Hauptverarbeitungskern 236 fest (Entscheidungsblock 690), ob die gelesenen Daten mit den Daten übereinstimmen, die Teil des entsprechenden Befehls sind, und kehrt, wenn dies der Fall ist, zum Entscheidungsblock 697 zurück ( ). Andernfalls, wenn die gelesenen Daten nicht übereinstimmen (Entscheidungsblock 690), wartet der Hauptverarbeitungskern 236 für die Dauer eines Timers (wie durch die Entscheidungsblöcke 691 und 692 dargestellt) auf die Ausführung nachfolgender Lesungen, bis die POLL-Daten übereinstimmen. Wenn der Poll-Timer abläuft (wie in Entscheidungsblock 691 bestimmt), dann setzt der Hauptverarbeitungskern 236 ein Fehlerflag (Block 694) und kehrt in den IDLE-Zustand 602 zurück. Wie ebenfalls in dargestellt, geht der Hauptverarbeitungskern 236 in den WACCESS-Zustand 613 über, um den Schreibbefehl zu verarbeiten, wenn das Lesen Teil eines Lese-Änderungs-Schreibbefehls war (wie im Entscheidungsblock 693 entschieden). Andernfalls geht der Master-Verarbeitungskern 236 über die Blöcke 620 und 622 (wie unten beschrieben) zurück in den INIT_CMD-Zustand 308, wenn das Ende des Master-ROM 232 noch nicht erreicht ist.

Zurück zu : Wenn der Hauptverarbeitungskern 236 feststellt (Entscheidungsblock 622), dass sich der Befehlszeiger nicht am Ende des Haupt-ROMs 232 befindet, dann führt der Hauptverarbeitungskern 236 keine Operation durch (Block 620) und kehrt in den INIT_CMD-Zustand 608 zurück. Andernfalls, wenn der Master-Verarbeitungskern 236 das Ende des Master-ROM 232 erkennt, setzt der Master-Verarbeitungskern 236 das entsprechende Sequenzende-Flag (Block 624) und kehrt in den IDLE-Zustand 602 zurück.

Gemäß Beispielimplementierungen kann der Slave-Verarbeitungskern 262 (siehe ) Befehle in ähnlicher Weise wie der Master-Verarbeitungskern 236 verarbeiten, mit der Ausnahme, dass die Befehlsverarbeitung durch den Slave-Verarbeitungskern 262 modifiziert werden kann, um bestimmte Befehle auszulassen, die nicht vom Slave-Verarbeitungskern 262 verarbeitet werden, wie z. B. Befehle, die den DFI-Befehl und/oder CAS-Befehl enthalten.

Bezug nehmend auf enthält ein Gerät 700 gemäß Beispielimplementierungen ein Subsystem 704, einen ersten Prozessor 708, einen Speicher 712, eine Schaltung 720 und einen zweiten Prozessor 724. Der erste Prozessor 708 führt Bootstrap-Befehle aus, um das Gerät 700 zu starten. Der Speicher 712 speichert zweite Anweisungen 716. Die Schaltung 720 hält den ersten Prozessor 708 als Reaktion auf das Einschalten des Geräts 700 im Reset-Zustand; und der zweite Prozessor 724 führt, während der erste Prozessor 708 im Reset-Zustand gehalten wird, die zweiten Anweisungen 716 aus, um das Subsystem 704 zu initialisieren.

Bezug nehmend auf enthält ein System 800 gemäß Beispielimplementierungen eine Vorrichtung 810, einen zweiten Speicher 840, der sich außerhalb der Vorrichtung 810 befindet, und einen dritten Speicher 850, der sich außerhalb der Vorrichtung 810 befindet. Die Vorrichtung 810 umfasst ein Subsystem 814, einen Verarbeitungskern 818, eine Schaltung 822, einen Konfigurator 826 und einen ersten Speicher 830. Das Subsystem 814 stellt eine Funktion bereit, die von der Vorrichtung 810 während und nach einem Bootvorgang der Vorrichtung 810 verwendet wird. Die Schaltung 822 hält den Verarbeitungskern 818 als Reaktion auf das Einschalten des Geräts 810 im Reset; und der erste Speicher 830 speichert erste Anweisungen 834, die vom Konfigurator 826 ausgeführt werden, um das Subsystem 814 zu konfigurieren, während der Verarbeitungskern 818 im Reset gehalten wird. Der zweite Speicher 840 speichert ein Firmware-Boot-Image 844, das vom Verarbeitungskern 818 ausgeführt wird, um das Gerät 810 als Reaktion auf die Freigabe des Verarbeitungskerns 818 aus dem Reset zu starten. Der dritte Speicher 850 speichert zweite Anweisungen 852, die vom Verarbeitungskern 818 ausgeführt und vom Verarbeitungskern 818 unter Verwendung des Firmware-Boot-Images 844 interpretiert werden, nachdem der Verarbeitungskern 818 aus dem Reset freigegeben wurde, um das Subsystem 814 weiter zu konfigurieren.

Bezugnehmend auf umfasst ein Prozess 900 gemäß Beispielimplementierungen das Halten (Block 904) eines ersten Prozessors eines eingebetteten Verarbeitungssystems in einem Rücksetzzustand als Reaktion auf das Einschalten des eingebetteten Verarbeitungssystems; und während der erste Prozessor in dem Rücksetzzustand gehalten wird, führt ein zweiter Prozessor des eingebetteten Verarbeitungssystems Befehle aus (Block 908), die in einem Speicher des eingebetteten Verarbeitungssystems gespeichert sind, um ein Teilsystem des eingebetteten Verarbeitungssystems zu konfigurieren. Der Prozess 900 umfasst das Freigeben (Block 912) des ersten Prozessors aus dem Rücksetzzustand; und als Reaktion auf das Freigeben aus dem Rücksetzzustand führt der erste Prozessor Bootstrap-Befehle aus (Block 916), wobei das Ausführen der Bootstrap-Befehle den Zugriff des ersten Prozessors auf das Subsystem umfasst.

In Übereinstimmung mit Beispielimplementierungen greift der zweite Prozessor auf Daten zu, die in einem Speicher gespeichert sind und als Reaktion auf das Einschalten des Geräts an das Gerät übertragen werden. Die Daten stellen eine Auswahl einer Gruppe der zweiten Anweisungen dar; und der zweite Prozessor führt die Gruppe der zweiten Anweisungen in Reaktion auf die Daten aus. Ein besonderer Vorteil dieser Anordnung ist, dass die Befehle, die ausgeführt werden, um ein bestimmtes Subsystem zu konfigurieren, gesteuert werden können, ohne die im Gerät gespeicherten Befehle zu verändern.

Gemäß Beispielimplementierungen durchsucht der erste Prozessor als Reaktion auf die Freigabe des ersten Prozessors aus dem Reset einen Speicher, der sich außerhalb des Geräts befindet, nach Patch-Anweisungen. Ein besonderer Vorteil dieser Anordnung ist, dass ein Allzweckverarbeitungskern ein Subsystem, wie z. B. einen Speichercontroller oder eine Speicherschnittstelle, weiter konfigurieren kann, das bereits für eine grundlegende Funktionsebene initialisiert wurde, bevor der Allzweckverarbeitungskern aus dem Reset freigegeben wurde.

Gemäß Beispielimplementierungen sind die ersten Befehle Teil einer Vielzahl von Befehlen, die in dem ersten Speicher gespeichert sind, und die Vielzahl von Befehlen umfasst einen Fallbefehl und Gruppen von Befehlen, die mit dem Fallbefehl verbunden sind. Eine gegebene Gruppe von Befehlen der Gruppen von Befehlen entspricht den ersten Befehlen, und der Konfigurator wählt als Reaktion auf die Ausführung des Fallbefehls die ersten Befehle zur Ausführung aus, basierend auf einem Vektor, der von der Vorrichtung empfangen wird und die gegebene Gruppe identifiziert. Ein besonderer Vorteil dieser Anordnung besteht darin, dass dem Gerät ein Vektor zur Verfügung gestellt werden kann, um eine bestimmte Gruppe von Befehlen zur Ausführung auszuwählen, ohne die Befehle, die in einem Speicher des Geräts gespeichert sind, zu verändern.

Gemäß Beispielimplementierungen kann das Subsystem eine Speicherschnittstelle, einen Speicher-Controller, einen Bus-Controller, eine serielle Busschnittstelle oder eine Spannungsversorgung umfassen. Ein besonderer Vorteil dieser Anordnung ist, dass der Konfigurator auf die Konfiguration einer Vielzahl von Subsystemen zugeschnitten werden kann.

Während die vorliegende Offenbarung in Bezug auf eine begrenzte Anzahl von Implementierungen beschrieben wurde, wird der Fachmann, der die Vorteile dieser Offenbarung kennt, zahlreiche Modifikationen und Variationen davon schätzen. Es ist beabsichtigt, dass die beigefügten Ansprüche alle derartigen Modifikationen und Variationen abdecken.

Claims

Eine Vorrichtung, die Folgendes umfasst: ein Teilsystem; einen ersten Prozessor zur Ausführung von Bootstrap-Befehlen; einen Speicher zum Speichern von zweiten Befehlen; eine Schaltung, um den ersten Prozessor als Reaktion auf das Einschalten des Geräts im Reset-Zustand zu halten; und einen zweiten Prozessor, um, während der erste Prozessor im Reset-Zustand gehalten wird, die zweiten Anweisungen auszuführen, um das Subsystem zu initialisieren.
Die Vorrichtung nach Anspruch 1, wobei: der zweite Prozessor auf Daten zugreift, die in einem Speicher gespeichert sind und als Reaktion auf das Einschalten des Geräts an das Gerät übertragen werden; die Daten eine Auswahl aus einer Gruppe der zweiten Befehle darstellen; und der zweite Prozessor führt die Gruppe der zweiten Befehle in Reaktion auf die Daten aus.
Die Vorrichtung nach Anspruch 2, wobei: das Subsystem umfasst einen Speicher-Controller oder eine Speichersch n ittstelle; die Auswahl einem konfigurierbaren Merkmal des Speicher-Controllers oder der Speicherschnittstelle entspricht; und die Ausführung der Gruppe der zweiten Anweisungen konfiguriert das Merkmal.
Die Vorrichtung nach Anspruch 1, wobei das Subsystem eine Speicherschnittstelle, einen Speichercontroller, einen Buscontroller, eine serielle Busschnittstelle oder eine Spannungsversorgung umfasst.
Die Vorrichtung nach Anspruch 1, wobei der erste Prozessor als Reaktion auf die Freigabe des ersten Prozessors aus dem Reset einen Speicher außerhalb der Vorrichtung nach Patch-Anweisungen durchsucht.
Die Vorrichtung nach Anspruch 1, wobei: die Vorrichtung umfasst ferner eine Root-of-Trust-Maschine, die einen unveränderlichen Fingerabdruck speichert; und die Root-of-Trust-Engine validiert die ersten Anweisungen auf der Grundlage des unveränderlichen Fingerabdrucks.
Die Vorrichtung nach Anspruch 1, wobei: der erste Prozessor greift auf Daten zu, die in einem Speicher außerhalb des Geräts gespeichert sind; die Daten einen Patch-Datensatz darstellen, der dritte Anweisungen enthält; und der erste Prozessor führt die dritten Anweisungen aus, um das Subsystem weiter zu konfigurieren.
Die Vorrichtung nach Anspruch 7, wobei: der Patch-Datensatz enthält einen Header, der die Nummer der dritten Anweisung enthält und der erste Prozessor als Reaktion auf die Freigabe aus dem Reset auf die Daten zugreift und die dritten Anweisungen ausführt.
Ein System, bestehend aus: eine Vorrichtung, die Folgendes umfasst: ein Subsystem zur Bereitstellung einer Funktion, die vom Gerät während und nach einem Bootvorgang des Geräts verwendet wird; einen Verarbeitungskern; eine Schaltung, um den Verarbeitungskern als Reaktion auf das Einschalten des Geräts im Reset zu halten; einen Konfigurator; und einen ersten Speicher zum Speichern erster Befehle, die vom Konfigurator ausgeführt werden, um das Subsystem zu konfigurieren, während der Verarbeitungskern im Reset-Zustand gehalten wird; einen zweiten Speicher außerhalb des Geräts, um ein Firmware-Boot-Image zu speichern, das vom Verarbeitungskern als Reaktion darauf ausgeführt wird, dass der Verarbeitungskern aus der Rücksetzung freigegeben wird; und einen dritten Speicher außerhalb des Geräts, um zweite Befehle zu speichern, die von dem Verarbeitungskern ausgeführt und von dem Verarbeitungskern unter Verwendung des Firmware-Boot-Images interpretiert werden, nachdem der Verarbeitungskern aus der Rücksetzung freigegeben wurde, um das Subsystem weiter zu konfigurieren.
Das System nach Anspruch 9, wobei die Vorrichtung einen Baseboard-Management-Controller umfasst.
Das System nach Anspruch 9, wobei die ersten Anweisungen sind Teil einer Vielzahl von Anweisungen, die im ersten Speicher gespeichert sind; die Vielzahl von Anweisungen eine Fallanweisung und Gruppen von Anweisungen umfasst, die mit der Fallanweisung verbunden sind; eine bestimmte Gruppe von Befehlen der Befehlsgruppen den ersten Befehlen entspricht; und der Konfigurator als Reaktion auf die Ausführung des Fallbefehls die ersten Befehle zur Ausführung auswählt, basierend auf einem vom Gerät empfangenen Vektor, der die gegebene Gruppe identifiziert.
Das System nach Anspruch 9, wobei: Das Subsystem umfasst einen Speicher-Controller; der Konfigurator führt die ersten Anweisungen aus, um den Speicher-Controller zu konfigurieren; und der Verarbeitungskern die zweiten Befehle ausführt, um eine Qualität des Ergebnisfeldes des Speicher-Controllers zu konfigurieren.
Das System nach Anspruch 9, wobei: die Vorrichtung umfasst ferner eine Root-of-Trust-Maschine, die einen unveränderlichen Fingerabdruck speichert; und Die Root-of-Trust-Engine validiert das Boot-Image anhand des unveränderlichen Fingerabdrucks.
Das System nach Anspruch 9, wobei: wobei das Gerät einen Dienst unter Verwendung des Subsystems, wie vom Konfigurator konfiguriert, bereitstellen soll, nachdem eine dem Gerät zugeordnete Fehlfunktion verhindert, dass der Prozessorkern aus dem Reset freigegeben wird.
Ein Verfahren, das Folgendes umfasst: Halten eines ersten Prozessors eines eingebetteten Verarbeitungssystems in einem Reset-Zustand in Reaktion auf das Einschalten des eingebetteten Verarbeitungssystems; während der erste Prozessor in dem Rücksetzzustand gehalten wird, ein zweiter Prozessor des eingebetteten Verarbeitungssystems erste Anweisungen ausführt, die in einem Speicher des eingebetteten Verarbeitungssystems gespeichert sind, um ein Subsystem des eingebetteten Verarbeitungssystems zu konfigurieren; Freigeben des ersten Prozessors aus dem Rücksetzzustand; und als Reaktion auf die Freigabe aus dem Rücksetzzustand führt der erste Prozessor Bootstrap-Befehle aus, wobei das Ausführen der Bootstrap-Befehle den Zugriff des ersten Prozessors auf das Subsystem umfasst.
Das Verfahren nach Anspruch 15, wobei der erste Prozessor einen Allzweckverarbeitungskern mit einer zugehörigen ersten Befehlssatzgröße umfasst und der zweite Prozessor eine endliche Registertransferlogikmaschine (RTL) mit einer zugehörigen zweiten Befehlssatzgröße umfasst, die kleiner ist als die erste Befehlssatzgröße.
Das Verfahren nach Anspruch 15, wobei der zweite Prozessor die Anweisungen ausführt: der zweite Prozessor auf einen Vektor zugreift, der eine Teilmenge der ersten Anweisungen identifiziert.
Das Verfahren nach Anspruch 17, das ferner das Übertragen von Daten, die den Vektor repräsentieren, an das eingebettete Verarbeitungssystem in Reaktion auf das Einschalten des eingebetteten Verarbeitungssystems umfasst.
Das Verfahren nach Anspruch 15, wobei das Ausführen der Bootstrap-Befehle umfasst, dass der erste Prozessor einen Speicher außerhalb des eingebetteten Verarbeitungssystems nach Patch-Befehlen durchsucht, wobei das Verfahren ferner umfasst, dass der erste Prozessor die Patch-Befehle ausführt, um das Subsystem weiter zu konfigurieren.
Das Verfahren nach Anspruch 15, wobei das Subsystem eine Speicherschnittstelle, einen Speicher-Controller, einen Bus-Controller, eine serielle Busschnittstelle oder eine Spannungsversorgung umfasst.