-
TECHNISCHES
GEBIET
-
Die
vorliegende Erfindung betrifft Datenverarbeitungssysteme und insbesondere
die Ausfüh- rung
von Boot-Code.
-
ALLGEMEINER
STAND DER TECHNIK
-
Das
Laden eines Betriebssystems erfordert traditionell Code zum Booten
oder "anfänglichem Programmladen". In der Vergangenheit
wurde solcher Code mindestens teilweise auf einem Computersystem
vor der Initialisierung des Permanentspeichers ausgeführt und
mußte
folglich so geschrieben werden, daß er in einer speicherlosen
Umgebung funktioniert. Bei einer typischen Datenverarbeitungsplattform
wird das frühe
BIOS bzw. die Firmware heutzutage häufig in einem als "stapelloser Assembler" bezeichneten Modus
ohne Speicher, in dem ein Aufrufstapel initialisiert werden kann,
ausgeführt. Solcher
stapelloser Hochfahrcode in Assemblersprache ist jedoch leider nicht
portierbar und in bezug auf Wartung und Merkmalerweiterung sehr
empfindlich. Aufgrund des begrenzten verfügbaren Zustands und der primitiven
Programmierumgebung ist es außerdem
schwierig, Merkmale hinzuzufügen
oder nützliche
Algorithmen wie zum Beispiel kryptographische Berechnungen zur Authentifikation
von Firmware-Komponenten, zu implementieren.
-
Die
mit komplexem und merkmalarmem Boot-Code verbundenen Probleme sind
besonders akut, wenn in einem Datenverarbeitungssystem moderne 64-Bit-Prozesoren
(einschließlich
der Itanium-Prozessorfamilie) verwendet werden. Es muß sehr viel
Code von Hand in Assemblersprache erstellt werden. Außerdem muß im Kontext
einer modernen BIOS-Architektur
wie etwa der verfügbaren Extensible
Firmware Interface (z.B. auf EFI basierende Tiano-Firmware) dieser
frühe Code
außerdem komplexe
Aktivitäten
ausführen,
wie zum Beispiel das Analysieren der Metadaten des Firmware-Dateisystems,
um die Plug-In-Umgebungsinitialisierungsmodule
(PEIMs) zu finden und Abhängigkeiten
zum Zweck der legalen Modulabfertigung usw. auszuwerten. Diese letzteren
Aufgaben waren in einer stapellosen Legacy-BIOS-Umgebung niemals
erforderlich und sind in Umgebungen mit Registern schwierig zu implementieren.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die
Erfindung wird aus der nachfolgend angegebenen ausführlichen
Beschreibung und aus den beigefügten
Zeichnungen von Ausführungsformen der
Erfindungen, die jedoch nicht als die Erfindungen auf die spezifischen
beschriebenen Ausführungsformen
beschränkend
sondern nur als Erläuterung
zum Verständnis
aufgefaßt
werden sollen, besser verständlich.
-
1 zeigt
schematisch ein Mehrprozessorsystem;
-
2 zeigt
eine Speichermigration während des
Bootens mehrerer Prozessoren;
-
3 zeigt
mehrere mögliche
Interaktionen zwischen Software für einen Cache als RAM (CAR) und
einer Prozessorabstraktionsschicht (PAL); und
-
4 zeigt
eine für
Prozessoren der Itanium-Familie (IPF) geeignete Ausführungsform
einer Interaktion zwischen Software für einen Cache als RAM (CAR)
und einer Prozessorabstraktionsschicht (PAL).
-
AUSFÜHRLICHE
BESCHREIBUNG
-
Wie
mit Bezug auf 1 zu sehen ist, enthält ein System 10 zum
Booten eines Computers mehrere Prozessoren 12, 13, 14 und 15.
Diese Prozessoren eignen sich für
die Ausführung
von Anweisungen von Programmiercode (einschließlich von Anweisungen des BIOS
(Basic Input/Output System), Betriebssystemanweisungen und Anwendungscode)
und werden miteinander verbunden und teilweise durch eine Baseboard-Verwaltungssteuerung 22 gesteuert. Die
Prozessoren sind ferner mit einem schnellen lokalen Cache-Speicher 16 und
einem etwas langsameren Hauptspeicher 18 verbunden. Das
System-BIOS wird aus dem angeschlossenen aktualisierbaren Firmware-Speicher 20 geladen.
-
Bei
der Anschlußverbindung
kann es sich um allgemeine Informationseingabe-/ausgabeleitungen, herkömmliche
adressierbare Busse oder eigene serielle oder parallele Datenleiterbahnen
handeln. Die Baseboard-Verwaltungssteuerung 22 verwaltet
in der Regel die Schnittstelle zwischen Systemverwaltungssoftware
und der Plattformverwaltungshardware, stellt eine autonome Überwachung,
eine Ereignisprotokollierung und Behebungssteuerung bereit und dient
als Gateway zwischen Systemverwaltungssoftware und unterstützten Bussystemen,
die Plattformkomponenten miteinander verbinden. Eine Baseboard-Verwaltungssteuerung
kann in vielfältige Datenverarbeitungsplattformen
integriert werden, die verschiedene Verwaltungsmerkmale aufweisen,
und kann eine einzige integrierte Komponente auf einem Motherboard
enthalten oder kann alternativ dazu durch ein verteiltes System
repräsentiert
werden, das kollektiv aus mehreren diskreten Steuerungen zusammengesetzt
ist. Zum Beispiel kann ein komplexer Mehrfach-Board-Satz in einem
Server der Unternehmens- klasse mehrere Verwaltungssteuerungen verwenden,
um verschiedene Subsysteme zu überwachen,
wie zum Beispiel Überwachung
und Steuerung einer redundanten Stromversorgung, RAID, Erweiterungs-E/A
usw. Im Betrieb wirkt die Baseboard-Verwaltungssteuerung 22 als
Richtlinien-Agentur, die entscheidet, an welchen Prozessor ein Einschaltrücksetzen
angelegt wird, wann INIT und NMI gesetzt werden und wann Boot-Prozesse
eingeleitet oder beendet werden usw.
-
Zu
Beispielen für
ein System zählen
u.a. ohne Begrenzung oder Einschränkung ein Computer (z.B. Desktop,
Laptop, Server, Blade-Server, Workstation, persönlicher digitaler Assistent
usw.) oder beliebige damit assoziierte Peripheriegeräte; Kommunikationsgeräte (z.B.
Telefonapparat, Pager usw.); ein Fernseh-Digitalreceiver und dergleichen.
Eine "Verbindung" oder "Verknüpfung" wird allgemein als ein
logischer oder physikalischer Kommunikationsweg definiert, wie zum
Beispiel elektrischer Draht, optische Faser, Kabel, Busleiterbahn
oder sogar ein drahtloser Kanal der Infrarot, Hochfrequenz (HF) oder
einen beliebigen anderen drahtlosen Signalisierungsmechanismus verwendet.
Zusätzlich
wird der Begriff "Information" definiert als ein
oder mehrere Bit von Daten, Adressen und/oder Steuerung. "Code" umfaßt Software
oder Firmware, die bei Ausführung bestimmte
Funktionen durchführt.
Beispiele für
Code sind etwa eine Anwendung, ein Applet, Boot-Code oder eine beliebige
andere Reihe von Anweisungen.
-
Wie
in 2 in bezug auf den Entwurf (Cartoon) 30,
der Adressenmigration in einem Mehrprozessorsystem zeigt, zu sehen
ist, kann ein vereinheitlichter Cache 16 der Größe von "N" Byte, der mit einer Satzassoziativität (set associativity)
von "X" Möglichkeiten
bzw. Wegen ausgelegt ist, als ein Array, das "X" Spalten
jeweils mit einer Größe von "N/X" Byte umfaßt, visualisiert
werden. Um einen solchen Computer vom Cache-Speicher aus zu booten,
wird eine Datenblockausrichtung für einen Cache als N/X gewählt. Mindestens
eine Cache-RAM-Spalte
eines Cache wird als RAM-System vorgeladen, wobei ein Tag verwendet
wird, um unbeabsichtigte Cache-Zeilenausräumungen zu verhindern. Dann
wird Boot-Code ausgeführt,
wobei der vorgeladene Cache-RAM den ausgeführten Boot-Code-Strömen jeweils
als Speicher 32, 33, 34 und 35 erscheint.
-
Solch
eine Cache-als-RAM (CAR)-Software kann einen Datenadressbereich
so wählen,
daß er mit
keinen vordefinierten Plattformadressbereichen in Konflikt kommt.
Die Datenblockausrichtung erfolgt unter Verwendung eines Weiterreichungsregisters zum Übermitteln
der Implementierungs-Cachegröße N und
der Satzassoziativität
X. Alternativ dazu kann die Datenblockausrichtung unter Verwendung
eines Prozeduraufrufs zur Bestimmung der Implementierungs-Cachegröße N und
der Satzassoziativität
vorgenommen werden.
-
Bei
bestimmten Ausführungsformen
muß, damit
der Cache-Speicher eines solchen Hochleistungsprozessors durch Früh-Boot-Code
als RAM verwendet werden kann, der Cache-RAM dem ausgeführten Codestrom
dergestalt als Speicher erscheinen, daß alle Datenspeicherzugriffe
ein Treffer sind und keine Cache-Ausräumungen verursachen. "Keine Ausräumungen" ist insofern wichtig,
als eine Ausräumung
zu einem Rückschreiben
an den Hauptspeicher führen
würde,
bevor die Speichersteuerung und die Systemkonfiguration initialisiert
werden. Im besten Fall hätte
die oben erwähnte
Aktion keine Nebenwirkung und im ungünstigsten Fall könnte das System
abstürzen
oder einen Fehlerzustand erreichen, wie zum Beispiel einen Maschinenprüfabbruch.
Der Unterstützungsmechanismus
von dem Prozessor während
des CAR-Modus muß also
dergestalt sein, daß keine
Frontside-Bus (FSB)-Zyklen zu dem Datenadressenraum auftreten.
-
Bei
bestimmten Ausführungsformen,
wie zum Beispiel mit Bezug auf 3 gezeigt,
kann CAR-Software spezifische Methoden verwenden, die von einer
Prozessorabstraktionsschicht (PAL) bereitgestellt werden, um sicherzustellen,
daß keine FSB-Zyklen
eingeleitet werden und daß eine
Datenblockausrichtung unter Verwendung eines Weiterreichungsregisters
erfolgt, um die Implementierungs-Cachegröße N und die Satzassoziativität X zu übermitteln.
Diese PAL-Codeschicht wird vom Prozessorhersteller hergestellt und
enthält
Prozessorinitia lisierungscode und eine Aufrufschnittstelle, die
die Prozessorhardware, einschließlich aller verfügbarer Prozessor-Cache-Speicher,
abstrahiert. PAL-Software kann mit ordnungsgemäßen Tags eine oder zwei (so
viele wie notwendig) Cache-RAM-Spalten vorladen. Nachdem dies geschehen
ist, kommen keine unbeabsichtigten Cache-Zeilenausräumungen
und daher keine Frontside-Bus-Zyklen vor, solange die CAR-Software
keine Maximalgrößeneinschränkungen übersteigt.
Abhängig
von der spezifischen Prozessorimplementierung kann das auf PAL basierende
Verfahren, das den Cache mit Tags für Datenbenutzung vorlädt, einen
Cache-Bereich (eine Spalte) wählen,
der für
die gegebene maximale CAR-Codegröße NICHT
ausgeräumt
wird und daher dem Anwender ermöglicht,
den Codestrom Cache-gespeichert auszuführen.
-
Bei
den auf PAL basierenden Verfahren kann eine bestimmte Hardwareunterstützung von
dem Prozessor auftreten, oder sie können alternativ dazu direkt
in PAL-Code implementiert werden. Bei bestimmten Ausführungsformen
kann man einen neuen PAL-Aufruf und eine Weiterreichungszustandserweiterung
für PAL-Code
verwenden. Die Weiterreichungszustandserweiterung fügt ein neues
Weiterreichungsregister hinzu, das die Implementierungstopologie
des Cache (die oben besprochenen Parameter N und X) zu dem CAR-Einrichtcode übermittelt, der
Teil des Firmwarecodes ist, der die Schnittstelle mit PAL-Code aufweist.
Alternativ dazu könnte
der PAL-Code einen Prozeduraufruf für Datenblockausrichtung unterstützen, der
die Implementierungs-Cachegröße N und
die Satzassoziativität
direkt liefert, anstatt den Weiterreichungszustand zu modifizieren. Bei
dieser Ausführungsform
wählt CAR-Einrichtcode die
Informationen zur Auswahl der CAR-Datenblockposition und -ausrichtung.
-
Bei
bestimmten Ausführungsformen
ist die Verwendung eines neuen PAL-Aufrufs eine der Möglichkeiten,
der PAL-Schicht anzuzeigen, den Cache-Bereich der notwendigen Größe mit ordnungsgemäßen Tag-Bits
auszuwählen
und zu laden. Die Eingaben für
diesen neuen PAL-Aufruf
sind die Größe und der
Adressenbereich von CAR-Daten und die maximale Größe von CAR-Code.
Die Verwendung von auf PAL basierenden Verfahren gestattet außerdem eine
Isolation des CAR-Einrichtcodes von etwaigen zukünftigen Entwicklungen der Prozessor-Cache-Architektur,
da auf PAL basierende Verfahren alle Implementierungseinzelheiten
des Prozessor-Cache abstrahieren.
-
Die
Verwendung von CAR ermöglicht
außerdem
die Unterstützung
mehrerer Prozessoren in einem Parallelausführungsmodus unter Verwendung des
Cache-Kohärenzprotokolls
MESI (Modified/Exclusive/Shared/Invalid) und des Datenverarbeitungsmodells,
das zur Ausnutzung dieser CAR-Fähigkeit erforderlich
ist. Dies ist besonders dann nützlich, wenn
alle Prozessoren gleichzeitig aus einem Rücksetzen herauskommen und eine
volle Topologie der SMP (symmetrischen Mehrfachverarbeitung) in
Software sichtbar sein muß.
Bei SMP würde
nun das MESI-Protokoll versuchen, Cache-Kohärenz aufrechtzuerhalten, falls
alle Verarbeitungs-Agents auf dieselbe Cache-Leitung zugreifen sollten.
MESI ist den neueren Protokollen, wie zum Beispiel MOESI (Modified/Owned/Exclusive/Shared/Invalid)
insofern unähnlich,
als bei letzterem die Möglichkeit
zum Transfer einer Cache-Leitung von einem Prozessor zum anderen
besteht. Im Fall von MESI erfolgt das Rückschreiben immer bevor die
Leitung in dem Alternativprozessor aktualisiert wird.
-
Folglich
erfordert CAR-Unterstützung
eine Partitionierung des für
die CAR-Datenregion verwendeten Adressenbereichs. Wenn jeder Prozessor
einen 256 K-CAR-Datenbereich unterstützen muß, der in diesem Nicht-Ausräumungs-Modus
benutzbar ist und maximal vier Prozessoren in dem lokalen SMP-Komplex
vorliegen, würde
genauer gesagt dann der CAR-Datenadressenraum
so partitioniert, daß jeder
Prozessor nur seinen 256 kb-Bereich sehen kann. Anders ausgedrückt tragen
durch PAL/Prozessor zugeführte
Verfahren eindeutige Tag-Bits
dergestalt in jeden Prozessor-Cache ein, daß sie jeweils mit ihrem eigenen
256 K-Bereich operieren. Jeder Prozessor sähe den Stapel als eine eindeutige
Adresse, wobei sich das Ausmaß der
Adresse plus 256 kb mit keinem der anderen Ausmaße der 3 Peer-Prozessoren überlappen
würde.
Daher besteht keine Chance der Aktualisierung eines etwaigen Datensatzes,
der zu dem Datenraum eines anderen Prozessors gehört, so daß keine
Synchronisationsprobleme zwischen Prozessoren auftreten würden, obwohl
jeder mit seiner eigenen Geschwindigkeit ausführen kann. Der Cache enthält Datensätze, die
am selben Datenadressenraum für
alle Prozessoren nicht modifiziert werden und verursachen daher keine
Probleme.
-
Bei
einer teilweise mit Bezug auf das Flußdiagramm 50 von 3 dargestellten
typischen Ausführungsform
empfängt
der CAR-Einrichtcode Informationen über die Größe des CAR und die Organisation
(Anzahl der Wege bzw. Möglichkeiten)
aus einer PAL-A-Schicht als Teil des Weiterreichungszustands. Er
berechnet die Minimalausrichtungskriterien für Daten durch Dividieren der
L2-Cache-Größe durch die
Anzahl der Arten der Organisation des Cache. Außerdem kennt er die maximale
Größe von Daten und
die Länge
des CAR-Codes von dem Plattformdienstemodul. Dann ruft er den PAL-A-CAR-Dienstaufruf
PAL CAR INITIALIZE auf, um PAL-A einen Cache-Bereich als RAM zur
Verwendung als Datenbereich durch CAR-Software auswählen und
initialisieren zu lassen. Der CAR-Modus wird vorübergehend durch den Boot-Code
verwendet, bis der Permanentspeicher gefunden und initialisiert
wird. Nach einer solchen Phase werden alle notwendigen Daten aus CAR
in Realspeicher kopiert und der CAR-Modus wird verlassen. Um den
CAR-Modus zu verlassen, erfolgt der Aufruf mit den Eingangsargumenten Data_Address,
Data_Size und Code Size, die alle auf NULL gesetzt werden. Zu diesem
Zeitpunkt entfernt der Aufruf die Hardware-Behelfslösungen (Workarounds), so daß der Prozessor-Cache
vollständig ausgestattet
ist, wenn der CAR-Modus verlassen wird. Daher besteht keine nachteilige
Auswirkung der vorliegenden Erfindung auf den normalen Prozessorbetriebsmodus
unter der Steuerung des Betriebssystems (OS).
-
Genauer
gesagt arbeiten die obigen Verfahren in Verbindung mit Prozessoren
der Intel-Itanium-Prozessorfamilie
(IPF), die bei einer Tiano- oder tianoartigen Implementierung einer
erweiterten Firmware-Schnittstelle (EFI) modifiziert werden können, um
den Cache als RAM zu verwenden. Vom Softwarestandpunkt aus gesehen
wird der verfügbare Cache
als RAM (CAR) für
die folgenden drei Zwecke benutzt. Der erste Block ist die Bereitstellung
von 64 kb des BSP (Backing Store Pointer) für lokal gestapelte Register.
Der zweite Block dient zur Konfiguration von 128 kb eines Stapels
(R12 als Datenstapelzeiger) für
den C-Compiler zur Erzeugung einer auf Stapeln basierenden Aktivierungsrahmendatenbenutzung.
Der dritte 64 kb-Block des linear abgebildeten RAMs, der als globaler
Datenstapel (heap) adressierbar ist, ermöglicht eine modulare Konfiguration des
System-RAM.
-
Im
Betrieb muß der
Teil des Cache, der als CAR benutzt wird, so konfiguriert und verwendet
werden können,
daß durch
Software in ihn geschriebene Daten erst dann ersetzt/invalidiert
werden, wenn es durch Software ausdrücklich befohlen wird. Anders ausgedrückt, wird
durch den als CAR verwendeten Cache folgendes sichergestellt:
- 1. Alle Datenladeoperationen werden immer aus dem
Cache gelesen und erzeugen keine Frontside-Buszyklen (FSB).
- 2. Cache-Datenleseverfehlungen können den Cache aktualisieren.
- 3. Cache-Schreibtreffer aktualisieren immer den Cache, obwohl
FSB-Zyklen erzeugt werden können.
- 4. Cache-Schreibverfehlungen können den Cache aktualisieren
und können
auf Speicher zugreifen, um sicherzustellen, daß keine Cache-Schreibverfehlungen
auftreten.
- 5. Cache-Zeilen werden niemals ersetzt oder invalidiert; obwohl
Code-Cache-Zeilen ersetzt werden können.
-
Wie
allgemein mit Bezug auf das Boot-Prozeßflußdiagramm 60 von 4 zu
sehen ist, führen in
einer typischen IPF-Architektur alle Prozessoren Firmwarecode aus,
bis der Code einen Bootstrap-Prozessor (BSP) auswählt. Während des Zeitraums,
in dem alle Prozessoren Firmwarecode ausführen, ist es also möglich, daß der CAR
zwischen den Prozessoren inkohärent
wird. Das Kohärenthalten
der CARs über
alle Prozessoren hinweg ist keine Anforderung. Man beachte, daß Firmwarecode so
gewählt
werden kann, daß er
in dem nichtkohärenten
Modell durch entsprechendes Auswählen
verschiedener CAR-Adressen für
jeden der Prozessoren arbeitet.
-
Die
Cache- und Speichersteuerung muß so konfiguriert
und verwendet werden, daß vor
oder während
der Speicherinitialisierung keine unerwünschten Speicherzyklen an der
Speicherschnittstelle verursacht werden. Nebenbedingungen in dem uninitialisierten
Chipsatz können
dazu führen,
daß Speicherzyklen
aus dem FSB, die auf die Speicherschnittstelle abzielen, die Speichersteuerung
abstürzen
lassen oder ihren Zustand so ändern,
daß sie nicht
ordnungsgemäß arbeiten
kann. Die "Müll"-Daten in dem Cache
müssen
beim Herauffahren durch den frühen
PAL-A-Code invalidiert werden, ohne daß Speicherzyklen in der Speicherschnittstelle
des Chipsatzes resultieren. Wenn aus einem bestimmten Grund der
PAL-A-Code den Cache vor dem Transfer nicht invalidiert, muß er den
Aufruf PAL_CACHE_INIT in der PAL-A-Schicht unterstützen.
-
In
vielen IPF-Prozessoren erzeugt ein Cache-Schreibtreffer Frontbus-Zyklen.
Um die Erzeugung von FSB-Zyklen zu vermeiden, lädt Software, die CAR verwendet,
die Cache-Speicher nach der Invalidierung des Cache mit entsprechenden TAG-Werten
vor. Die PAL-A-Schicht soll nicht nur Cache-Informationsbits weiterleiten,
sondern auch ein Verfahren zum Laden der Cache-Speicher mit notwendigen
Daten bereitstellen, so daß FSB-Zyklen völlig vermieden
werden können.
Dies ist besonders für
Prozessoren wichtig, die der "back-snoop-me"-Bedingung unterliegen, wobei eine Cache-Zeile,
die aus L1 herausgeopfert wird, auf den FSB gelegt wird, obwohl
sie im L2 vorliegt und in den L2 zurückgeschrieben worden sein sollte.
Diese unerwartete FSB-Transaktion für das L1-Opferrückschreiben
kann eine falsche CAR-Funktionsweise verursachen.
Dieser Zustand kann vermieden werden, indem man einen PAL-Aufruf zum Konfigurieren des
L1-Cache als Entwurf in der Reihenfolge mit einem Zugriff auf einmal
konfiguriert.
-
Um
einen beständigen
und zuverlässigen Betrieb
des Cache des Prozessors als temporärer Datenspeicher während der
Systemspeicherinitialisierung sicherzustellen, müssen vom Initialisierungsalgorithmus
die folgenden Anforderungen und Einschränkungen beachtet werden. Die
Firmware muß Änderungen
dieses Mechanismus erlauben und alle Szenarien behandeln können, wenn
er sich ändert. Die
Initialisierung durchführende
Firmware ist im allgemeinen ein separat aktualisierbares Modul,
wie mit Bezug auf 1 zu sehen ist.
-
PAL-A
muß den
von der CAR-Software benötigten
L2-Cache initialisieren, indem entweder die frühen Mülldaten in dem Cache vor seiner
Weiterreichung an EFI-Code (bei SALE_ENTRY) invalidiert werden,
oder es muß ein
Verfahren zum Invalidieren der Cache-Speicher unterstützen, so daß das CAR-Einrichtmodul den
Cache invalidieren kann. Außerdem
muß PAL-A-Code
Informationen über
L2-Cachegröße und die
Anzahl der Wege bzw. Möglichkeiten
(Assoziativität)
des L2-Cache für
das CAR-Codemodul bereitstellen, um es dem CAR-Modul zu ermöglichen,
die optimale CAR-Datenadresse zu wählen und sie dem PAL-Verfahren
zur Verfügung
zu stellen, so daß das
PAL entsprechende Tag-Informationen in den Cache laden kann. Dies
kann entweder als Weiterreichungsinformationen für den CAR-Code zum Zeitpunkt
der PAL-A-Weiterreichung an SALE_ENTRY geschehen, oder durch Unterstützen eines
prozeduralen Aufrufs, so daß CAR-Code
den Cache mit den richtigen Tags für die CAR-Daten laden kann.
-
Alle
Prozessoren kommen aus PAL-A heraus und führen eine Behebungsprüfung an
dem System aus. Der Codefluß während dieses
Zyklus findet Speicher und bestimmt, ob eine Behebung entweder von
PAL-B oder der Systemsoftware notwendig ist oder nicht. Wenn eine
Behebungsaktion nicht notwendig ist, werden alle Prozessoren zum
weiteren Prüfen
und Initialisieren an PAL-Code zurückgegeben. Sobald PAL-B dies
abgeschlossen hat, werden alle Prozessoren für ein normales Booten an SALE_ENTRY
zurückgegeben.
Die Cache-Speicher müssen
während
dieses Codeübergangs
in PAL-B und zurück
nicht kohärent
gehalten werden. Anders ausgedrückt
gehören
die Cache-Speicher für
die Initialisierung und Prüfung
dem PAL-Code, wenn die Steuerung im PAL-Code liegt. Der Tiano-Abfertigungscode
startet immer frisch und baut seine Variablen jedes Mal auf, wenn
er heraufgefahren wird.
-
Mehrere
logische CPUs in Mehrfach-Thread- und Mehrkernpaketen werden von
der auf CAR basierenden Firmware als separate Prozessoren behandelt
und erhalten ihre eigenen, sich nicht überlappenden CAR-Datenbereiche.
In solchen Fällen
ist die Gesamt-CAR-Datenbereichsanforderung an das CPU-Paket die
Summe der Größen der
einzelnen CAR-Datenbereiche. Außerdem
ist zu beachten, daß diese
Anforderung leicht erfüllt
werden kann, da die Mehrkern-CPUs im allgemeinen größere L2-Cache-Speicher
besitzen.
-
Alle
Daten, die die auf CAR basierende Software benötigt, dürfen nur in dem für eine bestimmte Plattform
zugeteilten zusammenhängenden CAR-Adressenraum
verankert sein. Die auf Stapel basierenden Daten, der durch Backing
store Pointer adressierte Bereich und ein etwaiger globaler Datenbereich
müssen
alle in dieses Paradigma passen. Der Start dieser Datenblockadresse
wird eine Ausrichtungseinschränkung
aufweisen, die für
verschiedene Prozessoren verschieden sein kann. Die gesamte auf
CAR basierende Software und Datenlänge in Byte darf die für die Verwendung
verfügbare
Gesamt-CAR-Cache-Länge
nicht überstei-
gen, da IPF-Prozessoren vereinheitlichte Cache-Architekturen aufweisen.
In einem MP-System
nimmt die CAR-Software nicht an, daß die Daten über die
Prozessoren in einem Knoten hinweg kohärent sind. Das heißt, daß CAR-Software
keine MP-Semaphoren in dem CAR-Datenbereich
ausübt
und von diesen abhängt.
CAR-Software kann jedoch Chipsatz- und andere Hardwarebetriebsmittel
verwenden, um Semaphoren und andere MP-Codeausführungssteuermechanismen zu
implementieren. Wenn die auf CAR basierende Software für irgendeinen
Zweck (wie zum Beispiel Bemessung oder Abstimmung von Speicher)
in den durch die Knotenspeichersteuerung gesteuerten Realspeicher
schreiben muß,
muß dies
als nicht cache-gespeicherter Zugriff geschehen. Das bedeutet Einschalten
des Bit 63, wenn der Code im physikalischen Modus operiert, oder
Einrichten eines ordnungsgemäßen TC-Eintritts
im Fall des virtuellen Adressierungsmodus.
-
Wie
bereits erwähnt,
kann CAR-Software eine Datenblockausrichtung von "N/X" Byte wählen. Die
CAR-Software wählt
eine Datenadresse für
CAR DATA und lädt
dann (unter Verwendung von durch PAL-A bereitgestellten Verfahren)
eine oder zwei (so viel wie notwendig) Datenspalten mit ordnungsgemäßen Tags
vor. Bei IPF-Prozessoren können
die übrigen
Cache-Spalten aufgrund der Beschaffenheit der Funktionsweise von
Pseudo-LRU- Algorithmen,
die zur Steuerung des Zugriffs auf L2-Cache-Zeilen verwendet werden,
nicht für
die Ausführung
von Code verwendet werden. Wenn der Anfang des CAR-Codes NICHT auf "N/X" Byte wie Datenspalte
ausgerichtet ist, dann kann die effektive Codegröße durch ein Maximum von: (Größe der Code-Spalten)-(eine Cache-Zeilengröße) reduziert
werden.
-
Wenn
dies tolerierbar ist, ist es nicht notwendig den CAR-Code auszurichten.
CAR DATA wird immer auf die erforderliche Grenze ausgerichtet. Außerdem sollte
der Adressbereich nicht mit dem größten durch die Plattform verbrauchten
Adressbereich in Konflikt stehen. Bei dem größten Bereich handelt es sich
im allgemeinen um die höchsten
adressierbaren Speicher und mögliche
zugeteilte PCI-Bereiche des Systems. Der gewählte Adressbereich wird so gewählt, daß er nicht
mit den anderen Architekturadressen von auf IPF basierenden Prozessoren
in Konflikt kommt. Die Bereiche enthalten Adressbereiche, die für EA-Block,
IPI-Adressenblock,
ROM und chipsatzreservierte Adressenbereiche gewählt werden.
-
Es
gibt zwei verschiedene Szenarien, in denen PAL-A-Code und das CAR-Einrichtmodul
kommunizieren müssen.
PAL-A muß Informationen über die
L2-Cache-Größe und die
Anzahl der Möglichkeiten
bzw. Wege (Cache-Topologie) in den CAR-Einrichtcode abgeben. Später muß CAR-Code
mit PAL-A kommunizieren, um den Cache zu invalidieren und damit
die Tag-Bits eingetragen werden. Zusätzlich leitet die PAL-A-Softwareschicht
eine Anzahl von Parametern wie zum Beispiel Selbstprüfzustand, physikalischer
Adressenzeiger, um einen PAL-Prozeduraufruf durchzuführen, und
so weiter an das am SALE_ENTRY-Punkt befindliche OEM-Codemodul weiter.
Der CAR-Einrichtcode befindet sich an diesem Eintrittpunkt und erhält die Steuerung
von PAL-A. Es können
zusätzliche
Parameter zu dem PALE_RESET-Autrittszustand zur Beschreibung der notwendigen
Cache-Parameter zu der CAR-Einrichtcodeumgebung hinzugefügt werden.
In der Umgebung der IPF (Itanium-Prozessorfamilie)
beginnen alle Prozessoren in dem System gleichzeitig mit der Ausführung, und
dies führt
dazu, daß die
Entwurfsanforderung eines frühen
Boot-Codes MP-sicher sein muß.
Diese zu der traditionellen Komplexität einer IPF-Plattform hinzugefügte Anforderung
kann nur extrem schwer erfüllt
werden.
-
Die
Implementierung der obigen Methoden und Prozeduren erleichtert die
Erfüllung
verschiedener Prozessorsicherheitsanforderungen, darunter u.a. ohne
Einschränkung
sichere Boot-Methoden, die üblicherweise
auf den derzeitigen Datenverarbeitungsplattformen durchgesetzt werden.
Es versteht sich, daß solche
Boot-Techniken Programmierkomplexitäten er zeugen, mit denen eine
speicherlose Umgebung nicht fertig werden kann. Die meisten Sicherheitsalgorithmen,
wie zum Beispiel SHA, benötigen einige
wenige KB Speicher zur Anwendung auf Sicherheitsschlüssel, die
wie beschrieben unter Verwendung von Cache als RAM verfügbar sind.
-
Zusätzlich besitzen
derzeitig Datenverarbeitungsplattformen außerdem sehr komplexe Bustopologien,
die sehr früh
initialisiert werden müssen,
bevor Speicher gefunden werden kann. Die Initialisierung von Busstrukturen
wie zum Beispiel USB (universeller serieller Bus) erfordert das
Streamen von mehreren Befehls- und Statusbyte zu und von den Bussteuerungsgeräten. Ähnlich verlangen
hochverdichtete Speichertechnologien auch eine sehr komplexe Initialisierung
und Größenscanningalgorithmen.
Diese Operationen werden in einer Umgebung, die Stapel und mindestens
einen begrenzten Speicher unterstützt, vereinfacht, wobei ein
zusätzlicher Vorteil
dadurch entsteht, daß von
der Architektur ISA (Instructions Set Architecture) unabhängiger Code
in einer höheren
Sprache wie C (oder einem Äquivalent)
verwendet werden kann. Dadurch wird zum Beispiel eine Wiederverwendung
von für übliche Hardwareblöcke zwischen
32-Bit-Intel-Architekturprozessorsystementwürfen und auf IPF (IA-64-)basierenden Systemen
anwendbarer Software ermöglicht.
-
Die
obigen Methoden und das System implementierende Software kann im
Speicher eines Computersystems als eine Menge von auszuführenden Anweisungen
gespeichert werden. Die Anweisungen zur Durchführung des oben beschriebenen
Verfahrens und Systems könnten
als Alternative auch auf anderen Formen von maschinenlesbaren Medien
gespeichert werden, wie zum Beispiel magnetischen und optischen
Datenträgern.
Zum Beispiel könnte das
Verfahren der vorliegenden Erfindung auf maschinenlesbaren Medien,
wie zum Beispiel Flash-Speichern,
magnetischen Datenträgern
oder optischen Datenträgern,
die über
ein Plattenlaufwerk (oder ein Laufwerk für computerlesbare Medien) zugänglich sind,
gespeichert werden. Ferner können die
Anweisungen in Form einer ausführbaren
Version zur Selbstinstallation über
ein Datennetzwerk in eine Datenverarbeitungseinrichtung heruntergeladen werden.
-
Alternativ
dazu könnte
die Logik zur Durchführung
der oben besprochenen Verfahren und Systeme in zusätzlichen
Computer- und/oder maschinenlesbaren Medien implementiert werden,
wie zum Beispiel diskreten Hardwarekomponenten als hochintegrierte
Schaltungen (LSIs), anwendungsspezifische integrierte Schaltungen
(ASICs) oder Firmware, wie etwa elektrisch löschbarer programmierbarer Nurlesespeicher
(EEPROMs); oder in räumlich
ent fernten Computern, die durch elektrische, optische, akustische
oder andere Formen ausgebreiteter Signale (z.B. Funkwellen oder
Infrarot-Lichtsignale) Informationen weiterleiten.
-
In
der Beschreibung bedeuten die Ausdrücke "Ausführungsform"; "eine Ausführungsform", "bestimmte Ausführungsformen" oder "andere Ausführungsformen", daß ein bestimmtes
Merkmal, eine bestimmte Struktur oder eine beschriebene Eigenschaft,
die in Verbindung mit den Ausführungsformen beschrieben
werden, mindestens in bestimmten Ausführungsformen, aber nicht unbedingt
in allen Ausführungsformen
der Erfindung enthalten ist. Die verschiedenen Ausdrücke "Ausführungsform", "eine Ausführungsform" oder "bestimmte Ausführungsformen" beziehen sich nicht
unbedingt auf dieselben Ausführungsformen.
-
Wenn
die Beschreibung davon spricht, daß eine Komponente, ein Merkmal,
eine Struktur oder eine Eigenschaft "eventuell", "möglicherweise" oder "im Prinzip" enthalten kann,
ist es nicht notwendig, daß diese
bestimmte Komponente, dieses bestimmte Merkmal, diese bestimmte
Struktur oder diese bestimmte Eigenschaft enthalten sind. Wenn die
Beschreibung oder der Anspruch von "einem" oder "einem bestimmten" Element spricht, soll dies nicht heißen, daß nur eines
von dem Element vorliegt. Wenn die Beschreibung oder die Ansprüche von "einem zusätzlichen "Element" sprechen, soll dies
nicht ausschließen,
daß es
mehr als eines des zusätzlichen Elements
gibt.
-
Für Fachleute
wird anhand der vorliegenden Offenlegung erkennbar sein, daß innerhalb
des Schutzumfangs der vorliegenden Erfindung viele andere Varianten
aus der obigen Beschreibung und den Zeichnungen hergestellt werden
können.
Der Schutzumfang der Erfindung wird folglich durch die folgenden
Ansprüche,
einschließlich
etwaiger Ergänzungen
dieser, definiert.
-
Zusammenfassung
-
Gemäß einer
Ausführungsform
läßt ein Computer-Bootverfahren
die Auswahl einer vorbestimmten Datenblockausrichtung für einen
Cache zu, der mehrere Prozessor-übergreifende
Interaktionen aufweist. Eine Cache-RAM-Spalte eines Cache als RAM-Systems
wird mit einem Tag geladen, um unbeabsichtigte Cache-Zeilenausräumungen
zu verhindern und ein Boot-Code wird ausgeführt, wobei der vorgeladene
Cache-RAM dem ausgeführten Boot-Code-Strom als ein
Speicher erscheint.