DE60223418T2

DE60223418T2 - Bootprozeß

Info

Publication number: DE60223418T2
Application number: DE60223418T
Authority: DE
Inventors: Samanna Hillsboro DATTA; Kirk Hillsboro BRANNOCK; Vincent Federal Way Zimmer
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2001-12-20
Filing date: 2002-12-17
Publication date: 2008-09-04
Anticipated expiration: 2022-12-18
Also published as: HK1068972A1; WO2003054697A2; WO2003054697A3; EP1485797A2; DE60223418D1; EP1485797B1; ATE377790T1; CN1606731A; US20030120909A1; US7392371B2; CN100353320C; AU2002353168A1

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft einen Bootprozeß.
HINTERGRUND
Typische Computersysteme weisen ein Basic-Input-Output-Programm (BIOS) zum Starten des Computers sowie zum Verwalten des Datenflusses zwischen dem Betriebssystem (OS) und verschiedenen Arten von angeschlossenen Geräten (z. B. Festplatte, Tastatur, Maus, Drucker) auf. Das BIOS ist für die Verarbeitungseinheiten des Computers zum Beispiel auf einem lösch- und programmierbaren Festwertspeicherchip zugänglich. Wenn das BIOS den Computer bootet (hochfährt), stellt es fest, ob die angeschlossenen Geräte vorhanden und betriebsbereit sind, woraufhin es dann das Betriebssystem (oder wichtige Teile davon) von der Festplatte in den Direktzugriffsspeicher (RAM) des Computers lädt. Bei einer Änderung der angeschlossenen Geräte muß auch das BIOS-Programm verändert werden, entweder beim Setup des Computersystems oder manuell.
ZUSAMMENFASSUNG DER ERFINDUNG
Nach einem ersten Aspekt umfaßt die vorliegende Erfindung ein Verfahren, bei dem in einem Computer eine Bootroutine initialisiert wird; zum Booten eine oberste Speicherdatei geladen wird, die sich an einer beim Initialisieren der Bootroutine zugänglichen ersten adressierbaren Stelle befindet, wobei die oberste Speicherdatei einer EPI-Spezifikation (Extensible Firmware Interface, Erweiterbares Firmware-Interface) entspricht und einen Mechanismus zum Lokalisieren von Code und Daten an festen, von der Architektur aber nicht bestimmten Stellen bereitstellt, die von der Prozessorarchitektur sowie zum Laden anderer in einem Firmware-Volumen liegender Firmwaremodule benötigt werden; und bei dem die oberste Speicherdatei beim Booten einen Satz von Firmwaremodulen lädt.
Nach einem anderen Aspekt umfaßt die vorliegende Erfindung eine Vorrichtung mit einem nichtflüchtigen Speicher eines Computers zum Initialisieren einer Bootroutine in dem Computer; mit einer Verarbeitungsarchitektur des Computers, die so konfiguriert ist, daß sie eine oberste Speicherdatei lädt, die einer EPI-Spezifikation (Erweiterbares Firmware-Interface) entspricht und die sich an einer beim Initialisieren der Bootroutine zugänglichen ersten adressierbaren Stelle befindet; wobei die oberste Speicherdatei so konfiguriert ist, daß sie den Computer in die Lage versetzt, beim Booten einen Satz von Firmwaremodulen zu laden, wozu sie einen Mechanismus bereitstellt, um Code und Daten an festen, von der Architektur aber nicht bestimmten Plätzen zu lokalisieren, die von der Prozessorarchitektur benötigt werden, und daß sie beim Booten den Satz von in einem Firmwarevolumen liegenden Firmwaremodulen lädt.
BESCHREIBUNG DER ZEICHNUNGEN
1 ist eine Blockdarstellung eines Computersystems.
2 ist eine Blockdarstellung des Bootsystems des Computersystems der 1.
3 ist ein Flußdiagramm für den Bootprozeß bei dem Bootsystem der 2.
GENAUE BESCHREIBUNG
Im allgemeinen umfaßt die Erfindung nach einem ersten Aspekt eine Bootroutine, die dadurch in einem Computer initialisiert wird, daß beim Booten eine oberste Speicherdatei (VTF) geladen wird, die sich an einer ersten adressierbaren Stelle befindet, die beim Initialisieren der Bootroutine zugänglich ist, wobei die oberste Speicherdatei beim Booten einen Satz von Firmwaremodulen lädt.
Wie in der 1 gezeigt, umfaßt ein beispielhafter Computer 10 einen oder mehrere Prozessoren 23(1)–23(n) (zusammen die Prozessoren 23), die über einen Prozessorbus 16 mit einer Systemlogik 14 verbunden sind. Der Systemspeicher 18 ist über einen Speicherbus 20 mit der Systemlogik 14 verbunden. Der Systemspeicher 18 enthält einen Betriebssystemstapel (OS) 22 und Anwendungsprogramme 24. Ein Peripheriebus 30 verbindet einen nichtflüchtigen Speicher 26 und ein oder mehrere Peripheriegeräte 28(1)–28(m) (zusammen die Peripheriegeräte 28) mit der Systemlogik 14. Die Peripheriegeräte 28 umfassen zum Beispiel eine Eingabe/Ausgabevorrichtung 32 mit einem graphischen Nutzerinterface (GUI) 34 für einen Benutzer 36.
Das darunterliegende Computersystem, auf dem die Anwendungsprogramme 24 laufen können, wird von der Rechenplattform 38 dargestellt. Die Rechenplattform 38 wird von den Peripheriegeräten 28 und der Systemlogik 14 gebildet. Während des Bootprozesses lädt der Computer 10 den Betriebssystemstapel 22 in den Systemspeicher 18 oder nichtflüchtigen Speicher 26. Nachdem das Betriebssystem 22 geladen ist, können die Benutzer auf dem Computer 10 Anwendungsprogramme 24 ausführen.
Wie in der 2 gezeigt, umfaßt der nichtflüchtige Speicher 26 ein Firmwaresystem 40. Das Firmwaresystem 40 enthält einen Resetvektor 51, eine VTF-Datei 42 und ein Firmwarevolumen 88.
Der Resetvektor 51 ist eine adressierbare Stelle im nichtflüchtigen Speicher 26, die die erste Anweisung enthält, die nach einem Reset des Prozessors von diesem auszuführen ist. Die Prozessorarchitektur hält die adressierbare Stelle des Resetvektors 51 fest.
Die VTF-Datei 42 ermöglicht es dem Prozessor 23, das Firmwarevolumen 88 beim Booten korrekt zu laden, wodurch wiederum beim Booten das Betriebssystem (OS) des Computers 10 geladen wird. Die VTF-Datei 42 sichert einen Mechanismus zum Lokalisieren des richtigen Code und der richtigen Zeiger im Firmwarevolumen 88 und zum Zugreifen darauf.
Im Gegensatz zu den adressierbaren Stellen der VTF-Datei 42, deren Adressen durch die Prozessorarchitektur festgehalten wird, haben der Code und die Zeiger in der VTF-Datei 42 keine von der Architektur angegebenen Plätze.
Das Firmwarevolumen 88 enthält Firmwaremodule 44(a)–44(b) und ein Dispatchermodul 46. Die Firmwaremodule 44(a)–44(b) umfassen einen Routinenblock 64 und eine Datenstruktur 66 und dienen als Kerncode und spezialisierte Plug-In-Systeme, die das Firmwaresystem an die Rechenplattform 38 anpassen. Das Dispatchermodul 46 ist ein Modul, das die Speicherstellen oder Speicheradressen der Firmwaremodule 44(a)–44(b) identifiziert und die Firmwaremodule 44(a)–44(b) in vorhersehbarer nützlicher Reihenfolge ausführt, das heißt in einer nicht zufälligen Reihenfolge.
Das Firmwaresystem 40 umfaßt auch einen zur Verfügung stehenden (d. h. nicht benutzten) Block des nichtflüchtigen Speichers 26a. Die Reihenfolge der adressierbaren Stellen der Firmwaremodule 44(a)–44(b) und des Dispatchermoduls 46 im nichtflüchtigen Speicher werden nicht vorab festgelegt. Jedes Modul und jeder Dispatcher kann sich irgendwo im Speicher 26 befinden, die Stelle dafür kann sich von Computer zu Computer unterscheiden. Die VTF-Datei 42 enthält "Brücken" zwischen Code, der von der Architektur des Prozessors 23 vorgegeben wird, und Plattformcode, der nicht von der Architektur des Prozessors 23 vorgegeben wird.
Die VTF-Datei 42 stellt einen Mechanismus zum Lokalisieren von Code und Daten an festen Plätzen wie von der Prozessorarchitektur gefordert und zum Laden von anderen, im Firmwarevolumen 88 liegenden Firmwaremodulen 44(a)–44(b) beim Booten bereit.
Die Datenstruktur 66 enthält ein Label, das zum Identifizieren der Datenstruktur 66 durch einen Identifikatorblock 68 im Systemspeicher 18 vergeben wird (d. h. die Datenstruktur wird markiert), wodurch die Datenstruktur von einem anderen Firmwaremodul, etwa dem Firmwaremodul 44(b), identifiziert und bestätigt werden kann. Die Datenstruktur 66 umfaßt viele Speicherstellen, die Werte enthalten, die dazu verwendet werden, auf Komponenten des Firmwaresystems 40 zu verweisen. Zum Beispiel ermöglichen es die in den Speicherstellen der Datenstruktur 66 gespeicherten Werte, daß Routinen vom Firmwaremodul 44(a) auf Routinen im Firmwaremodul 44(b) zugreifen können. Die VTF-Datei 42 enthält Vorabinformationen für den Zugriff auf eine Basis des Firmwaresystems 40, die von den Firmwaremodulen 44(a)–44(b) dazu verwendet werden, einen allgemeinen Satz von Zugriffsdiensten zu veröffentlichen, um weitere Volumina zu erfassen. Die Speicherstellen können auch Zeiger zum Dispatchermodul 46 und zu anderen Arten von Adressen enthalten. Die Werte, die die Speicherstellen bestimmen, unterscheiden sich je nach Art der Plattform und Lieferant. Zum Beispiel kann ein Serverlieferant ein größeres Volumen mit Komponenten vorsehen, die für eine größere Fehlertoleranz oder eine SCSI-Unterstützung Server-Chipsätze und Server-Merkmale abstrahieren, wohingegen ein Desktop oder eine Workstation mehr konsumerorientierte Merkmale wie eine stärkere Graphikunterstützung aufweisen kann.
Der Identifikatorblock 68 ist mit der Datenstruktur 66 verbunden und enthält Informationen, mit denen ein Routinenblock des Firmwaremoduls 44(a) die Datenstruktur 66 lokalisieren und bestätigen kann. Der Identifikatorblock 68 enthält eine Identifikations-Zeichenfolge 72 wie einen garantiert einmaligen 16-Byte-Identifikator (GUID), ein statistisch einmaliger Wert, der dazu verwendet wird, ein gegebenes Dienstinterface oder eine gegebene Speicherdatei zu "bezeichnen". Der Identifikatorblock 68 enthält des weiteren einen Größenparameter 74 (DS_SIZE) und einen Prüfsummenwert 76 (CHK_SUM). Die Zeichenfolge ID_STRING 72 ist eine Folge von Zeichen, nach denen eine Routine 84 im Routinenblock 64 abgesucht und abgerufen werden kann. Das DS_SIZE 74 gibt die Größe der Datenstruktur 66 an, und das CHK_SUM ist ein Wert, der zum Zwecke der Sicherstellung, daß sich die Datenstruktur 66 nicht verändert hat, von der Datenstruktur 66 abgeleitet wird.
Der Routinenblock 64 des Firmwaremoduls 44(a) stellt eine Unterstützung auf Firmwareebene für Ressourcen dar, die mit entsprechenden Geräten verbunden sind. Zum Beispiel enthält der Routinenblock 64 Codesequenzen, die Tastaturen, Eingabevorrichtungen, Videoanzeigegeräte und ähnliche Geräte initialisieren und konfigurieren, die von verschiedenen unabhängigen Hardwarelieferanten (IHVs), unabhängigen BIOS-Lieferanten (IBVs) und Herstellern von Originalausrüstung (OEMs) für die Verwendung auf der Rechenplattform 38 entwickelt wurden.
Das Firmwaremodul 44(a) enthält auch eine Aufruftabelle 70, die Indexe für und Zeiger auf Routinen im Routinenblock 64 speichert. Zum Beispiel ist einem Zeiger 82 ein Index 80 zugeordnet, durch den über einen logischen Link 86 auf eine zugehörige Routine 84 zugegriffen werden kann.
Die VTF-Datei 42 des Firmwaresystems 40 enthält einen Operationscode 50, der vom Resetvektor 51 "konsumiert" wird. Das heißt, daß das Firmwaresystem 40 in Reaktion auf eine erste Operationscode-Zuführoperation der Prozessoren 12 nach einem Neustartereignis (d. h. einem Ereignis, das einen Bootprozeß auslöst, durch den der Prozessor seine Operationen wieder aufnimmt) in einem "Abruf/Ausführungszyklus" ausgeführt wird. Der Resetvektor 51 wird von einer bestimmten CPU-Mikroarchitektur festgelegt. Die VTF-Datei 42 muß daher so aufgebaut sein, daß sie den Hardwareanforderungen der jeweils verwendeten CPU-Mikroarchitektur entspricht. Die VTF-Datei 42 befindet sich in einer Architektur mit variablen Dateistellen im Firmwaresystem 40 ganz oben.
Im "Abruf/Ausführungszyklus" der ersten Operationscode-Zuführoperation der Prozessoren 23(n) werden die Anweisungen zuerst durch Auslesen einer Anweisung aus dem nichtflüchtigen Speicher 26 und dann durch entsprechendes Ausführen der Anweisung verarbeitet. Dann nimmt jeder der Prozessoren 23(n) die nächste Anweisung aus dem Systemspeicher 18 auf und so weiter. Das Neustartereignis, das einen vollständigen Systemreset ("Kaltstart") oder nur einen CPU-Reset ("Warmstart") umfaßt, enthält einen POST (Power On Self Test, Einschalt-Selbsttest). Insbesondere testet der Computer 10 im POST-Test seine Hardware, die Prozessoren 12 und den Systemspeicher 18, wenn die Stromversorgung eingeschaltet wird. Der Operationscode 50 kann zum Beispiel eine Sprunganweisung oder indirekte Sprunganweisung umfassen, die der Computer 10 zuerst mittels einer der festen Stellen in der VTF-Datei 42 (z. B. durch Versetzen in eine Sicherheitscodekomponente (SEC) 54) ausführt, um auf weitere Behälter für Dateien zuzugreifen oder Anweisungen zu verfolgen, die sich in der VTF-Datei 42 befinden. Wenn der Computer 10 zum ersten Mal eingeschaltet wird, ist der Operationscode 50 daher ein erforderli cher Zugangspunkt für die Übergabe der Steuerung an andere Behälter von Dateien, die in der VTF-Datei 42 liegen, etwa den Zeiger 52 (2).
Die VTF-Datei 42 enthält eine VTF-Aufzeichnungsliste 56, den Sicherheitscode (SEC) 54, einen Zeiger 52 für die VTF-Aufzeichnungsliste 56 und eine Boot-Firmware-Speicherbasis (BFV-Basis) 58. Die VTF-Datei 42 ist eine Datei, die den Spezifikationen für ein erweiterbares Firmware-Interface (EFI) entspricht, die dafür vorgesehen sind, es den Entwicklern zu ermöglichen, leicht verschiedene Rechenplattformen zu realisieren. Zum Beispiel geben die EFI-Spezifikationen einen gemeinsamen Rahmen mit einem Satz von Kernkomponenten vor, etwa eine Plug-In-Umgebungsinitialisierung (PEI) und Kerndateien für Treiberausführungsumgebungen (DXE). Die EFI-Spezifikationen geben einen Kernrahmen und eine Kernumgebung vor, der bzw. die plattform- und betriebssystemunabhängig ist. Darüberhinaus sind die EFI-Spezifikationen sowohl ein binäres Interface als auch ein API-Set.
Entsprechend stellen die EFI-Spezifikationen ein Interface zwischen dem Betriebssystem OS 22 und der Plattform 38 dar, das im nichtflüchtigen Speicher 26 liegt. Das von der EFI-Spezifikation gebildete Interface umfaßt plattformspezifische Informationen und Boot/Laufzeit-Dienstaufrufe, die dem Betriebssystem 22 und dessen Lader zur Verfügung stehen.
Die VTF-Aufzeichnungsliste 56 bezeichnet die Stelle, an der die VTF-Datei 42 eine Liste von vorgegebenen Punkten enthält, wie etwa bezeichnete Aufzeichnungsarten, die die Stelle von wenigstens einem Firmwaremodul 44, den SEC-Code (SEC) 54 in der VTF-Datei 42 und dergleichen enthalten. Der Startup-Preambel-Code am Bootvektor kann die Stelle für wenigstens ein Firmwaremodul 44 oder den SEC-Code (SEC) 54 in der VTF-Datei 4 "entdecken". Die VTF-Aufzeichnungsliste 56 unternimmt die erforderlichen Schritte, damit der Cache-Speicher des Prozessors 12 als Datencache dienen kann, und durchsucht die Boot-Firmware-Speicherbasis 58 in der VTF-Aufzeichnungsliste 56, um die Firmwaremodule 44(a)–44(b) zu authentifizieren.
Der SEC 54 ist so konfiguriert, daß der Maschinenzustand festgelegt und der Prozessorcache als Datenaufrufstapel freigegeben wird, er ruft optionale Authentifizierungsdienste auf und bereitet Übergabezustände vor, etwa durch Lokalisieren der Firmware-Speicherbasis wie der Boot-Firmware-Speicherbasis (BFV-Basis) 58, und er übergibt die Steuerung an das Dispatchermodul 46. Der SEC 54 gibt auch die Vertrauenskette frei. Die Freigabe der "Vertrauenskette" bildet eine transitive Beziehung aus, in der die erste Softwarekomponente bestimmte Operationen an den folgenden Komponenten ausführt, um Firmwaremodule 44(a)–44(b) zu authentifizieren und auch um eine integrierte Unterstützung für den Zugriff auf oder das programmatische Erfassen anderer, erforderlicher Dateien zum Ausführen weiterer Anweisungen sicherstellt.
Der Zeiger 52 auf die VTF-Aufzeichnungsliste 56 ist ein Punkt mit fester Stelle, der das "Entdecken" der Aufzeichnungsliste variabler Größe in der VTF-Aufzeichnungsliste 56 ermöglicht. Das Dispatchermodul 46 ist erforderlich, um die Stellen von verschiedenen Firmwaremodulen 44 zu kennen. Die Boot-Firmware-Speicherbasis (BFV-Basis) 58 ist ein Behälter, der ein Codevolumen oder Dateivolumen enthält, das zur Initialisierung der VTF-Datei 42 verwendet wird. Die Boot-Firmware-Speicherbasis 58 umkapselt Dateien, auf die durch den Zeiger 52 zugegriffen wird. Die Boot-Firmware-Speicherbasis (BFV-Basis) 58 enthält eine Routine, Subroutine oder einen geordneten Satz von Anweisungen für ein Programm, das eine bestimme Aufgabe ausführt. Die Boot-Firmware-Speicherbasis 58 kombiniert daher eine Reihe von Computeranweisungen und umkapselt die Dateien, auf die durch den Zeiger 52 zugegriffen werden kann, so daß der Prozessor 12 den Code oder die Dateien ausführen kann, die in der Boot-Firmware-Speicherbasis 58 enthalten sind.
Die VTF-Datei 42 enthält auch einen Start 62 für das Volumen. Der SEC 54 befindet sich zwischen der VTF-Aufzeichnungsliste 56 und dem Zeiger 52, der unmittelbar unter dem Resetvektor 51 liegt. Die Adresse der VTF-Datei 42 und insbesondere die Adressen des Operationscodes 50 und der Boot-Firmware-Speicherbasis 58 stehen relativ zum Zeiger 52 fest, auch wenn sich die Größe des Operationscodes 50 und der Boot-Firmware-Speicherbasis 58 ändert.
Anhand der 2 und 3 wird nun der Bootprozeß 100 des Computers 10 beschrieben.
Wie in der 3 gezeigt, wird im Bootprozeß 100 des Computers 10 bei der Ausführung des POST-Testes der Resetvektor 51 erfaßt. Auf die Erfassung des Resetvektors 51 hin initialisiert (102) das Firmwaresystem 40 die Bootsequenz für die Prozessoren 12. In Abhängigkeit von der verwendeten Rechenplattform 38 kann dies zum Beispiel einen eingebauten Selbsttest (BIST) und eine Prüfung der Prozessoridentität (ID) umfassen. Diese Bootschritte werden in den Prozessoren 12 ausgeführt, die zum Beispiel 64-Bit-Itanium^TM-Prozessoren von Intel^® Corporation, Santa Clara, Kalifornien sein können, wobei die Bootsteuerung mit der PAL-Firmwarekomponente für die Prozessor-Abstraktionsschicht beginnt, die die Steuerung an einer andere adressierbare Stelle übergibt. Während der Anfangs-Bootsequenz oder Anfangsroutine wie dem Bootprozeß 100 nehmen die Prozessoren 12 Anweisungen aus der VTF-Datei 42 auf, die in Reaktion auf den "Abruf/Ausführungszyklus" ausgeführt werden, der durch einen Prozessor-Reset ausgelöst wird.
Es folgt die Ausführung eines Prozesses zum Ausbilden (106) eines Anfangsdateisystems, mit dem das Firmwaremodul 44(a) im Anfangsdateisystem festgestellt werden kann. Das Ausbilden (106) des Anfangsdateisystems umfaßt auch die Verwendung von z. B. des Firmwaredispatchers 46 (auf den durch die Datenstruktur 66 gezeigt wird), um auf die geeigneten Routinen 64 des Firmwaremoduls 44(a) zuzugreifen, um den Zugriff auf andere Firmwaremodule wie das Firmwaremodul 44(b) zu erhalten. Zum Beispiel ermöglicht das Dispatchermodul 46 dadurch einen Zugriff auf die Routinen 64, daß ein mit einem Index versehenes Eingangssignal von einem der Formwaremodule aufgenommen und dieser Index dann dazu verwendet wird, um über die Aufruftabelle 70 den Zugriff auf eine der Routinen im Routinenblock 64 zu erhalten. Nachdem das Firmwaremodul 44(a) ent deckt wurde, erfolgt die Authentifizierung dadurch, daß geprüft wird (108), ob das entdeckte Firmwaremodul 44(a) zu der Vertrauenskette gehört. Die Vertrauenskette ist eine transitive Beziehung, in der das Firmwaremodul 44(a) das Firmwaremodul 44(b) bestätigen oder authentifizieren muß. Das Firmwaremodul 44(b) bestätigt dann nachfolgende Firmwaremodule 44 und so weiter. Der Steuerfluß der Vertrauenskette-Übergaben enthält eine Authentifizierung oder Verifikation der nachfolgenden Komponenten, um eine logische Verbindung der "Kette" aufrecht zu erhalten. Der Authentifizierungsprozeß für die Vertrauenskette wird vom SEC 54 ausgeführt. Nach der Entdeckung und Authentifizierung des Firmwaremoduls 44(a) führt ein architekturaler Übergabezustand zum Startup des Firmwaredispatchers 46, und die Steuerung auf den Firmwaredispatcher 46 über (110). Die Übergabeinformationen enthalten dabei Zustandsinformationen über die Anordnung der Firmwarevolumen, über Autorisierungsergebnisse und andere Zustandsinformationen, die durch die optionale Authentifizierung bekannt sind, die das Firmwaremodul 44(a) anfordert.
Nachdem die Steuerung an den Firmwaredispatcher 46 abgegeben wurde (110), werden die Firmwaremodule 44(a) und 44(b) in den Systemspeicher 18 geladen (112) und in den verbleibenden Prozessen des Bootprozesses 100 ausgeführt. Es kann eine optionale Validationsprüfung erfolgen (114), und durch Suchen (118) nach dem letzten Modul werden alle übrigen Firmwaremodule 44 (nicht gezeigt) ausgeführt (116). Daraufhin führt der Bootprozeß 100 schließlich den Systemstart des Computers 10 aus (120).
Bei bestimmen Ausführungsformen umfaßt der Peripheriebus 30 des Computers 10 zum Beispiel einen oder mehrere Peripheriekomponenten-Verbindungsbusse (PCI-Busse), Industrie-Standard-Architekturbusse (ISA-Busse), erweitere ISA-Busse (EISA-Busse) und vergleichbare Peripheriebusse. Der nichtflüchtige Speicher 26 kann eine statische Speichervorrichtung wie ein Festwertspeicher (ROM) oder ein Flash-Speicher sein. Die Peripheriegeräte 28 können auch Massenspeichergeräte wie Festplatten und Digital Video Disks (DVDs) umfassen. Diese Geräte bilden zusammen mit der Systemlogik 14 die Rechenplattform 38 des Computers 10, wie Intel^®-Architektur-Plattformen (IA^®-Plattformen) von Intel^® Corporation, einschließlich der Intel Architektur-32 (IA-32) und der XScale^TM- und Intel^®-Itanium^TM-Chipsätze. Entsprechend können für den Computer 10 die Prozessoren 12 Instruktionssatzarchitekturen (ISA) z. B. auf der Basis von IA-32-, XScale^TM- und Intel^®-Itanium^TM-Prozessoren ausführen.
Eine wichtige Plattform-Infrastruktur unterstützt Plattformen auf der Basis von IA-32, XScale^TM und Intel^®-Itanium^TM. Diese Infrastruktur beinhaltet Peripheriegeräte 28 und die zum Booten, Konfigurieren und Unterstützen dieser Geräte erforderlichen Basic-Input-Output-Systeme (BIOS oder Firmware). Die Routinen 64 enthalten zum Beispiel IA-32-, XScale^TM- oder Itanium^TM-Codesequenzen, die den/die Prozessor(en) 12, die Systemlogik 14, den Systemspeicher 18 und die anderen Ressourcen initialisieren und konfigurieren, die in nativen IA-32-, XScale^TM- oder Itanium^TM-Umgebungen arbeiten.
Bei bestimmten Ausführungsformen ist im nichtflüchtigen Speicher 26 das Firmwaresystem 40 gespeichert, das Binärelemente enthält, die bei verschiedenen Arten von Peripheriegeräten und Plattformen vorgesehen sind. Um bei der Ausführung von diversen Architekturen und Komponenten und für neue Funktionen eine Integration auf Quellenebene zu erreichen, wird ein gemeinsames Kern-Rahmenwerk vorgesehen, das eine Plattform oder ein agnostischer Chipsatz ist. Statt für das Firmwaresystem 40 ein monolithisches Binärsystem zu unterstützen, wird daher über ein Binärinterface eine binäre Interoperabilität für verschiedene Komponenten vorgesehen.
Wie beschrieben ergeben sich aus der EFI-Spezifikation das Kern-Rahmenwerk und die Umgebung, die Plattform- und API-unabhängig sein können, so daß eine gemeinsame Kern-Standard-Umgebung zum Booten des Betriebssystems 22 geschaffen wird. Die EFI-Spezifikation wird zum Beispiel als reine Interface-Spezifikation entworfen und definiert als solche einen Satz von Interfaces und Strukturen, die die Firmware der Rechenplattform ausführen muß. Gleichermaßen definiert die EFI-Spezifikation einen Satz von Interfaces und Strukturen, die das Betriebssystem 22 in einem Bootprozeß wie dem oben beschriebenen Bootprozeß 100 verwendet. Entsprechend brauchen das Betriebssystem 22 und das Firmwaresystem 40 nur die zum Unterstützen des Bootprozesses 100 erforderlichen und notwendigen Informationen austauschen.
Die sich aus dem Übergang von einem Rahmenwerk aus monolithischen Binärelementen zu einem modularisierten Firmwaredesign ergebende Abstraktion konzentriert sich auf die Vermeidung von Laufzeitaufrufen an das BIOS, so daß eine Boot-Infrastruktur und ein Satz von Diensten gebildet werden, die eine gemeinsame Plattformdefinition und Plattformspezifikation bilden. Insbesondere wird der Zugriff auf die Peripheriegeräte 28 durch "Handhaben" und "Protokolle" abstrahiert. Dadurch wird die Verwendung und Wiederverwendung von vorhandenem Firmwarecode erleichtert, da die darunterliegenden Ausführungsanforderungen aus der Spezifikation herausgehalten werden, ohne daß der Zugriff auf das Gerät kompliziert wird.
Die EFI-Spezifikation kann eine Abstraktion für eine gemeinsame Bootumgebung definieren, die von geladenen EFI-Images verwendet werden kann. Die EFI-Images umfassen EFI-Treiber, EFI-Anwendungen und EFI-Betriebssystemlader. In bestimmten Ausführungsformen umfaßt die EFI-Spezifikation unter anderem auch Laufzeitdienste, Systempartitionen und die Wiederverwendung von vorhandenen Interfaces auf Tabellenbasis.
Bei bestimmten Ausführungsformen bestimmt der Ablauf des Bootprozesses 100 für einen Computer 10 den Aufbau der VTF-Datei 42. Zum Beispiel laden die Prozessoren 12 bei der IA-32-Plattform Operationscodes 50, die sich an der Adresse 4 GB minus 16 befinden (2). Außerdem muß der Bootvorgang 100 vom Resetvektor 51 an genau beschrieben sein. Zum Beispiel muß bei Mikroprozessoren auf der Basis von IA-32 und Itanium der Resetvektor 51 in der Nähe der Oberseite des 32-Bit-Adressenraums liegen. Bei einer 32-Bit-Prozessorfamilie wie IA-32 steht diese Adresse mit 4 GByte ("Gigabyte") minus 16 fest. Entsprechend stellt das Firmwaresystem 40 ein besonderes Modul bereit, das die erste Datei ist, die ausgeführt wird und deren Ende mit der 4 GByte-Grenze zusammenfallen muß. Das besondere Modul ist die VTF-Datei 42. Die VTF-Datei 42 ist daher nicht nur deshalb etwas besonderes, weil es erforderlich ist, beim Booten den nichtflüchtigen Speicher 26 zu laden, sondern sie muß auch die letzte Datei des Firmwaresystems 40 sein.
Die obigen Ausführungsformen wurden mit ISAs (Instruktionssatzarchitekturen) auf der Basis von IA-32, XScale^TM und Itanium^TM ausgeführt. Das oben beschriebene System und das oben beschriebene Verfahren können aber auch mit anderen ISAs, für mobile Systeme bis hin zu Servern, ausgeführt werden. Weitere Ausführungen liegen innerhalb des Umfangs der folgenden Patentansprüche.

Claims

Verfahren, bei dem eine Bootroutine in einem Computer (10) initialisiert wird (102); beim Booten eine oberste Speicherdatei (42) geladen wird, die sich an einer beim Initialisieren der Bootroutine zugänglichen ersten adressierbaren Stelle befindet, einer EFI-Spezifikation (Erweiterbares Firmware-Interface) entspricht und einen Mechanismus zum Lokalisieren von Codes und Daten an festen, von der Architektur aber nicht spezifizierten Stellen bereitstellt, die von der Prozessorarchitektur sowie zum Laden weiterer in einem Firmware-Volumen (88) liegenden Firmwaremodulen (44) benötigt werden; und bei dem die oberste Speicherdatei (42) beim Booten einen Satz von Firmwaremodulen (44) lädt.
Verfahren nach Anspruch 1, wobei die oberste Speicherdatei (42) zum Lokalisieren eines Dispatchermoduls (46) verwendet wird.
Verfahren nach Anspruch 2, wobei das Dispatchermodul (46) für den Zugriff auf den Satz von Firmwaremodulen (44) verwendet wird.
Verfahren nach Anspruch 3, wobei der Satz von Firmwaremodulen (44) den Computer (10) initialisiert.
Verfahren nach einem der vorhergehenden Ansprüche, wobei ein Resetvektor (51) für den Zugriff auf die oberste Speicherdatei (42) verwendet wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die oberste Speicherdatei (42) Adressen des Satzes von Firmwaremodulen (44) enthält.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die oberste Speicherdatei (42) die Adresse einer Basis des ersten Firmwaremoduls (44) enthält.
Verfahren nach Anspruch 7, wobei die Basis des ersten Firmwaremoduls (44) eine Boot-Firmware-Speicherbasis (58) enthält, die die von einem Zeiger (52) zugänglichen Dateien einkapselt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die oberste Speicherdatei (42) einen Sicherheitscode (54) umfaßt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die oberste Speicherdatei (42) die Gültigkeit des Satzes von Firmwaremodulen (44) bestätigt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die oberste Speicherdatei (42) als letzte Datei in dem Satz von Firmwaremodulen (44) bestimmt wird.
Verfahren nach Anspruch 11, wobei zum Bestimmen das Ende der obersten Speicherdatei (42) auf eine Speichergrenze ausgerichtet wird.
Verfahren nach Anspruch 12, wobei die Speichergrenze zwischen 4 und 10 Gigabyte (GByte) des Speichers liegt.
Vorrichtung mit einem nichtflüchtigen Speicher (26) eines Computers (10) zum Initialisieren einer Bootroutine in dem Speicher (10); und mit einer Prozeßarchitektur des Computers (10), die so konfiguriert ist, daß sie beim Booten eine oberste Speicherdatei (42) lädt, die einer EFI-Spezifikation (Erweiterbares Firmware-Interface) entspricht und sich an einer beim Initialisieren der Bootroutine zugänglichen ersten adressierbaren Stelle befindet; wobei die oberste Speicherdatei (42) so konfiguriert ist, daß sie den Computer (10) in die Lage versetzt, beim Booten einen Satz von Firmwaremodulen (44) zu laden, wozu sie einen Mechanismus zum Lokalisieren von Codes und Daten an festen, von der Architektur aber nicht spezifizierten Stellen bereitstellt, die von der Prozessorarchitektur sowie zum Laden weiterer in einem Firmware-Volumen (88) liegender Firmwaremodule (44) benötigt werden.
Vorrichtung nach Anspruch 14, wobei die oberste Speicherdatei (42) so konfiguriert ist, daß sie ein Dispatchermodul (46) lokalisiert.
Vorrichtung nach Anspruch 14 oder 15, wobei der Satz von Firmwaremodulen (44) so konfiguriert ist, daß er den Computer (10) initialisiert.
Vorrichtung nach Anspruch 14, 15 oder 16, wobei die oberste Speicherdatei (42) Adressen des Satzes von Firmwaremodulen (44) enthält.
Vorrichtung nach einem der Ansprüche 14 bis 17, wobei die oberste Speicherdatei die Adresse einer Basis des ersten Firmwaremoduls (44) enthält.
Vorrichtung nach einem der Ansprüche 14 bis 18, wobei die Prozeßarchitektur einen Prozessor (23) umfaßt; und wobei die oberste Speicherdatei (42) in dem nichtflüchtigen Speicher (26) gespeichert ist und sich an einer ersten adressierbaren Stelle des nichtflüchtigen Speichers (26) befindet, auf den die Zentralverarbeitungseinheit (CPU) des Computers (10) Zugriff hat, wobei die oberste Speicherdatei (42) unter Verwendung eines Resetvektors (51) zugänglich ist und einen Mechanismus zum Laden weiterer in einem Firmware-Volumen (88) liegender Firmwaremodule (44) bereitstellt; wobei in dem nichtflüchtigen Speicher (26) ferner gespeichert sind eine einem ersten Firmwaremodul (44a) zugeordnete Datenstruktur (66) und ein zweites Firmwaremodul (44b), auf das von der obersten Speicherdatei (42) zugegriffen werden kann.
Vorrichtung nach Anspruch 19, wobei das erste Firmwaremodul (44a) die oberste Speicherdatei (42) mit einem besonderen, auf eine 4-GByte-Grenze ausgerichteten Firm waremodul umfaßt, und wobei die oberste Speicherdatei (42) die letzte Datei eines an die Zentralverarbeitungseinheit angepaßten Firmwaresystems ist.
Vorrichtung nach Anspruch 19 oder 20, mit einem von der obersten Speicherdatei (42) lokalisierbaren Dispatchermodul (46).
Vorrichtung nach Anspruch 15 oder 21, wobei das Dispatchermodul (46) so konfiguriert ist, daß es auf den Satz von Firmwaremodulen (44) zugreift.
Vorrichtung nach Anspruch 19, 20 oder 21, wobei die oberste Speicherdatei (42) die Adresse einer Basis des zweiten Firmwaremoduls (44) enthält.
Vorrichtung nach Anspruch 23, wobei die Basis des zweiten Firmwaremoduls (44) eine Boot-Firmware-Speicherbasis (58) umfaßt, die die von einem Zeiger (52) zugänglichen Dateien einkapselt.
Vorrichtung nach Anspruch 19, 20 oder 21, wobei die oberste Speicherdatei (41) einen Sicherheitscode (54) umfaßt.
Vorrichtung nach Anspruch 19, 20 oder 21, wobei die oberste Speicherdatei (42) so konfiguriert ist, daß sie die Gültigkeit des Satzes von Firmwaremodulen (44) bestätigt.
Computerlesbares Medium, in dem auf einem Computer ausführbare Befehle gespeichert sind, die bewirken, daß ein programmierbares Computergerät sämtliche Schritte nach einem der Ansprüche 1 bis 13 ausführt.