DE10297281B4

DE10297281B4 - Verfahren zum elementaren Aktualisieren einer Vielzahl von Dateien

Info

Publication number: DE10297281B4
Application number: DE10297281T
Authority: DE
Inventors: Kirk D. Brannock; William A. Stevens
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2001-09-28
Filing date: 2002-09-27
Publication date: 2012-02-02
Anticipated expiration: 2022-09-28
Also published as: CN1273891C; DE10297281T5; GB0407054D0; GB2396938B; US20110307878A1; US8839226B2; US20070288914A1; TW583586B; US20030066062A1; HK1062726A1; GB2396938A; WO2003029970A2; WO2003029970A3; US8028282B2; US7299463B2; CN1561483A

Abstract

Verfahren zum elementaren Aktualisieren einer Vielzahl von vorhandenen Plattform-Firmware-Dateien in einem dauerhaften Firmware-Speicher, wobei wenigstens ein Teil von vorhandenen Plattform Firmwaredaten Kopfdaten beinhalten, die angeben, ob die vorhandenen Plattform-Firmware-Daten gültig und aktualisiert sind, gekennzeichnet durch die Schritte: Erstellen einer Fülldatei; Modifizieren von Kopfdaten der vorhandenen Plattform-Firmware-Datendaten um anzugeben, dass die vorhandenen Plattform-Firmware-Daten gültig sind und zu aktualisieren sind; Schreiben von aktualisierten Plattform-Firmware-Daten-Dateien in die Fülldatei in dem dauerhaften Firmware-Speicher, so dass der dauerhafte Firmware-Speicher sowohl die vorhandenen Plattform Firmware-Daten als auch die aktualisierten Firmware-Daten aufweist, wobei die aktualisierten Firmware-Daten-Dateien Kopfdaten beinhalten, die angeben, dass die aktualisierten Plattform-Firmware-Daten nicht gültig und nicht zu aktualisieren sind; und Ausführen einer elementaren Operation zum Modifizieren der Kopfdaten der Plattform-Firmware-Dateien, um anzugeben, daß die aktualisierten Plattform-Firmware-Dateien anstelle der vorhandenen Plattform-Firmware-Dateien verwendet werden sollen.

Description

ALLGEMEINER STAND DER TECHNIK
Gebiet der Erfindung
Die vorliegende Erfindung betrifft ein Verfahren zum Aktualisieren von Plattform-Firmware-Dateien.
Informationen zum Stand der Technik
Firmware von Computer-Plattformen wird beim Initialisieren von Computersystemen zum Überprüfen von System-Integrität und -Konfiguration verwendet. Im allgemeinen stellt sie auf niedriger Ebene auch die grundlegende Schnittstelle zwischen Hardware- und Software-Komponenten bei denjenigen Computern bereit, die das Implementieren bestimmter Hardware-Funktionen über die Ausführung von Software-Anweisungen auf höherer Ebene gestatten, die in Computer-Programmen enthalten sind, die auf den Computersystemen ausgeführt werden. Bei Computern ist ein primärer Teil dieser Firmware als der Basic Input/Output System(BIOS)-Code eines Computersystems bekannt. Der BIOS-Code umfaßt eine Gruppe von permanent gespeicherten (oder im Fall von Systemen, die ein Flash-Speicher-BIOS verwenden, semipermanent gespei-cherten) Software-Routinen, die das System mit seinen grundlegenden Betriebsmerkmalen ausstatten, einschließlich den Anweisungen, die dem Computer angeben, wie er beim Einschalten einen Selbsttest ausführt, und wie er die Konfigurationen für verschiedene eingebaute Komponenten und Zusatz-Peripheriegeräte festlegt.
In einer typischen PC-Architektur wird das BIOS im allgemeinen als die Firmware definiert, die zwischen dem Rücksetzen des Prozessors und der ersten Anweisung des Betriebssystem(OS)-Ladeprogramms läuft. Wie in 1 dargestellt, wird in einem typischen PC 10 der Basisteil des BIOS-Codes in einer Art von ROM(Festwertspeicher)-Einrichtung auf der Hauptplatine 12 des PCs gespeichert, wie beispielsweise einem standardmäßigen PROM 14 oder einem Flash-Speicher 16. In einigen Konfigurationen kann dieser Basisabschnitt erweitert werden, indem ein Code verwendet wird, der in ROM-BIOS-Chips 18 gespeichert ist, die in einer oder mehreren Zusatz-Peripheriekarten 20 enthalten sind, wie beispielsweise SCSI-Kontroller und Busmaster-Einrichtungen. Dieser Teil des BIOS wird in Komponenten gespeichert, die im allgemeinen als ”Options-ROMs” bezeichnet werden. Der BIOS-Code in ROM-BIOS-Chips 18 von Peripheriekarten betrifft normalerweise eine bestimmte Funktionalität, die durch ihre entsprechende Peripheriekarte bereitgestellt und während der Initialisierung dieser Peripheriekarte gemäß einer (meistens) eindeutig definierten Regelgruppe ausgeführt wird. In allen von den vorgenannten Konfigurationen ist die gesamte BIOS-Firmware lokal gespeichert, entweder auf der Hauptplatine oder in Options-ROMS auf der bzw. den zu einem System hinzugefügten Peripheriekarten.
In vielen Fällen wird die grundlegende Funktionalität einer Computersystem-Plattform durch die Firmware der Plattform definiert. Um diese Funktionalität dementsprechend zu erweitern, muß ein entsprechender Code zur Firmware hinzugefügt oder in dieser modifiziert werden. In den heutigen PCs kann dies entweder durch Austauschen des bzw. der BIOS-Chips auf der Hauptplatine (und/oder den Peripheriekarten) erreicht werden, oder, falls der BIOS-Code in überschreibbaren Chips enthalten ist, (z. B. einem Flash-Speicher), durch Ausführen eines Software-Programms zum Aktualisieren des BIOS, das den BIOS-Code neu schreibt (überschreibt).
Derartige Verfahren sind prinzipiell z. B. aus der EP 1 087 294 A2 und der US 6 088 759 A bekannt.
Die bekannten Verfahren können fehleranfällig sein. Das Austauschen eines BIOS-Chips durch einen unerfahrenen Benutzer kann zu mehreren Problemen führen, einschließlich unsachgemäßem Einsetzen des neuen Chips, Beschädigen des neuen Chips, Beschädigen der Fassung, elektrostatischem Beschädigen des neuen Chips und/oder von auf der Hauptplatine vorhandenen Chips. Beliebte Verfahren zum Aktualisieren des auf einer Flash-Komponente gespeicherten BIOS-Codes weisen auch Risiken auf. Beispielsweise kann ein Benutzer versuchen, den BIOS-Code mit einer ungeeigneten Gruppe von neuen Codes zu aktualisieren, oder ein Absturz kann mitten im Aktualisierungsprozeß erfolgen. Typischerweise wird der BIOS-Code als ein monolithischer Code-Block gespeichert, der in seiner Gesamtheit durch einen neuen monolithischen Code-Block ersetzt wird. Wenn der BIOS-Code auf einer Flash-Komponente gespeichert ist, müssen die Speicherblöcke, die den Teilen des Speichers entsprechen, die den neuen BIOS-Code enthalten sollen, zuerst gelöscht werden, (d. h. alle werden auf 1 zurückgesetzt), bevor der Speicher überschrieben wird. Dieser Löschprozeß vernichtet den bestehenden BIOS-Code. Wenn demzufolge ein Ausfall mitten in einem Überschreib- oder Aktualisierungsvorgang auftritt, ist der BIOS-Code beschädigt. Angenommen, es tritt ein Stromausfall ein, der verursacht, daß der Benutzer das Computersystem neu booten muß. Da der BIOS-Code normalerweise benötigt wird, um den Boot-Prozeß abzuschließen, kann es sein, daß der Benutzer das Computersystem nicht booten kann, um das Problem zu beheben, oder daß eine Notfall-Reparaturdiskette, (die der Benutzer häufig nicht besitzt), benötigt wird, um das Problem beheben zu können.
Aufgabe der Erfindung ist es daher, ein fehlerunanfälliges Verfahren zum Aktualisieren der Firmware von Computer-Plattformen zu schaffen.
Diese Aufgabe wird durch das Verfahren mit den Merkmalen von Anspruch 1 gelöst. Die Unteransprüche geben vorteilhafte Ausgestaltungen der Erfindung an.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorgenannten Gesichtspunkte und die Vorteile der Erfindung werden im Folgenden unter Bezugnahme in Zusammenhang mit den folgenden begleitenden Zeichnungen erläutert.
1 ist eine schematische Darstellung, die veranschaulicht, wie die BIOS-Firmware in einem herkömmlichen Personal Computer gespeichert wird;
2 ist eine schematische Darstellung, die einen beispielhaften Firmware-Speicherplan des Firmware-Datenträgers und das dazugehörige Dateisystem veranschaulicht, unter dem die Erfindung implementiert werden kann;
3 ist ein Ablaufplan zur Veranschaulichung der von der Erfindung verwendeten Logik, wenn eine neue Datei in dem Firmware-Datenträger erstellt wird;
4 und 5 sind schematische Darstellungen, welche die sequentiellen Änderungen in einem Dateikopf und im Speicherplatz eines Firmware-Datenträgers veranschaulichen, wenn eine neue Datei in dem Firmware-Datenträger erstellt wird;
6 ist eine schematische Darstellung, die veranschaulicht, wie eine Datei unter dem Firmware-Dateisystem in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung gelöscht wird;
7 ist ein Ablaufplan, der die Logik veranschaulicht, die von einer Ausführungsform der Erfindung beim Aktualisieren einer bestehenden Datei in dem Firmware-Datenträger verwendet wird;
8 und 9 sind schematische Darstellungen, welche die sequentiellen Änderungen in einem Dateikopf und im Speicherplatz eines Firmware-Datenträgers veranschaulichen, wenn eine neue Datei in dem Firmware-Datenträger erstellt wird;
10 ist ein Ablaufplan, der die Logik veranschaulicht, die von einer Ausführungsform der Erfindung beim Erstellen einer Datei unter Verwendung einer temporären Fülldatei verwendet wird;
11 ist ein Ablaufplan, der die Logik veranschaulicht, die von einer Ausführungsform der Erfindung beim Aktualisieren einer Datei unter Verwendung einer temporären Fülldatei verwendet wird;
12 ist ein Ablaufplan, der die Logik veranschaulicht, die von der Erfindung beim Aktualisieren einer Vielzahl von Dateien verwendet wird;
13–15 sind schematische Darstellungen, welche die sequentiellen Änderungen in einem Dateikopf und im Speicherplatz eines Firmware-Datenträgers veranschaulichen, wenn eine Vielzahl von Dateien in dem Firmware-Datenträger aktualisiert wird; und
16 ist eine schematische Darstellung eines Personal Computer-Systems, das für die Implementierung der vorliegenden Erfindung geeignet ist.
DETAILLIERTE BESCHREIBUNG DER VERANSCHAULICHTEN AUSFÜHRUNGSFORMEN
In der folgenden Beschreibung werden zahlreiche spezifische Details angegeben, um für ein vollständiges Verständnis der Ausführungsformen der Erfindung zu sorgen. Der entsprechende Fachmann wird jedoch erkennen, daß die Erfindung ohne eines oder mehrere der spezifischen Details oder mit anderen Verfahren, Komponenten usw. ausgeführt werden kann. In anderen Fällen werden bekannte Strukturen oder Abläufe nicht gezeigt oder im Detail beschrieben, um Gesichtspunkte von verschiedenen Ausführungsformen der Erfindung nicht unklar zu machen.
Die durchgehende Bezugnahme auf ”eine Ausführungsform” in dieser Beschreibung bedeutet, daß ein bestimmtes Merkmal, eine bestimmte Struktur oder ein bestimmtes Kennzeichen, das/die in Verbindung mit der Ausführungsform beschrieben wird, in wenigstens einer Ausführungsform der vorliegenden Erfindung enthalten ist. Daher bezieht sich die vorkommende Wendung ”in – einer Ausführungsform” an verschiedenen Stellen in der gesamten Beschreibung nicht notwendigerweise immer auf die gleiche Ausführungsform. Des weiteren können die bestimmten Merkmale, Strukturen oder Kennzeichen in geeigneter Weise in einer oder mehreren Ausführungsformen kombiniert werden.
Erweiterbare Firmware-Schnittstelle und Firmware-Datenträger
Vor kurzem hat die Intel Corporation einen neuen Firmware-Denkansatz vorgestellt, bei dem es möglich ist, die Firmware-Speicherung über die herkömmlichen monolithischen Speichersysteme hinaus zu erweitern, die beim bisherigen Stand der Technik zu finden sind. Dies wird teilweise durch das Extensible Firmware Interface (Erweiterbare Firmware-Schnittstelle) oder EFI ermöglicht. Wie die Bezeichnung angibt, ermöglicht das EFI, daß die Firmware durch Verwendung einer genormten Software-Schnittstelle ”erweitert” werden kann.
Eine Möglichkeit zum Erweitern von Firmware wird durch eine standardmäßige Software-Abstraktion für eine Firmware-Speichereinrichtung vereinfacht, die als ein Firmware-Datenträger (FV) bekannt ist. Da die FV-Firmware-Speicherabstraktion nicht an einen spezifischen Typ von Hardware gebunden ist, kann sie verwendet werden, um Firmware-Komponenten zum BIOS von fast jedem Typ von Firmware-Einrichtung aus herzustellen. Beispielsweise kann ein Firmware-Datenträger in einem vorgegebenen System ein Flash-Speicherteil sein, während ein anderer eine Plattenpartition sein kann, und ein dritter ein entferntes Verzeichnis auf einem Server sein kann. Ein einzelnes Computersystem kann einen oder mehrere Firmware-Datenträger auf einem oder mehreren Typen von Hardware umfassen.
Die Teile des Codes der BIOS-Firmware, die Bestandteil eines Firmware-Datenträgers sind, werden von einem Firmware-Dateisystem (FFS) verwaltet. Das Firmware-Dateisystem ermöglicht es, Firmware-Dateien zu manipulieren, die einen Firmware-Datenträger bilden. Das Firmware-Dateisystem kann zum Abrufen, Erstellen, Aktualisieren und Löschen von Firmware-Dateien verwendet werden. Im allgemeinen kann ein Firmware-Dateisystem auf jeder Dauerspeichereinrichtung, einschließlich Flash-Einrichtungen, Plattenpartitionen und entfernten Speichereinrichtungen gespeichert werden, auf die von einem Netzwerk aus zugegriffen wird.
In den folgenden Abschnitten und dazugehörigen Figuren werden verschiedene Ausführungsformen der Erfindung unter Bezugnahme auf einen Firmware-Datenträger erläutert, der in einer Flash-Speichereinrichtung gespeichert ist. Dem Fachmann ist klar, daß die Erfindung in anderen Arten von Dauerspeichereinrichtungen zum Verwalten von Firmware-Code und/oder Daten implementiert werden kann, und die Ausführungsformen der Erfindung, welche die im folgenden erläuterten Flash-Speichereinrichtungen verwenden, nur beispielhafte Modelle für die Ausführung der Erfindung sind.
Ein Flash-Speicher ist eine nichtflüchtige Speichertechnologie, die es den Herstellern und den Endanwendern (mit der entsprechenden Hardware/Software) ermöglicht, Informationen elektrisch zu programmieren und zu löschen. Ein Flash-Speicher wird typischerweise in Speichereinheiten gelöscht, die als Blöcke bezeichnet werden, anstatt auf der Bit-Ebene gelöscht zu werden, wobei alle Bits in einem vorgegebenen Block auf eine vorher festgelegte Polarität (d. h. Logik-Ebene) umgeschaltet werden, wenn ein Block gelöscht wurde. Bei einem gebräuchlichen Typ von Flash-Speicher, wie beispielsweise den von Intel hergestellten Flash-Speichereinrichtungen, werden Speicherblöcke elektronisch gelöscht, indem alle Bits in einem Block auf 1 gesetzt werden. Daten können dann in den Block geschrieben werden, indem einzelne Bits auf 0 gekippt werden. Bei anderen Typen von Flash-Einrichtungen ist der Status der gelöschten Logik insgesamt Null, und das Schreiben von Daten in diese Einrichtungen umfaßt das Ändern einzelner Bits in 1. Es wird angemerkt, daß in herkömmlichen Flash-Einrichtungen einzelne Bits von einer geänderten (d. h. eingestellten) Logik-Ebene nicht auf die Ebene der gelöschten Logik zurückgestellt werden können; um Daten in einem Block zu aktualisieren, müssen zunächst alle Bits gelöscht und anschließend neu geschrieben werden.
Ein beispielhafter Firmware-Datenträger 22, der in einer Flash-Einrichtung gespeichert ist, die für ihren gelöschten Status 1 verwendet, ist in 2 dargestellt. Der Firmware-Datenträger 22 umfaßt einen FV-Kopf 24 und eine Vielzahl von FFS-Dateien 25. Der Anfang des FV-Kopfs 24 ist auf der niedrigsten Speicheradresse der Flash-Einrichtung gespeichert, wobei jede FFS-Datei 25 an der nächsten Byte-Grenze nach dem Ende einer unmittelbar vorhergehenden Datei oder eines Dateikopfs (falls zutreffend) beginnt. In einer Ausführungsform treten Byte-Grenzen alle 8 Bytes auf, und Dateigrößen weisen 8-Byte-Inkremente auf. In den FFS-Dateien 25 ist eine gelöschte Datei 26 enthalten. Wie im folgenden detaillierter erläutert wird, umfaßt die gelöschte Datei 26 einen Dateikopf, der erkennt, daß die Datei vom Firmware-Dateisystem als gelöscht betrachtet wird, obwohl die Daten der gelöschten Datei immer noch im Firmware-Datenträger in dem gleichen Status vorhanden sein können, in dem sie sich befanden, bevor die Datei als gelöscht gekennzeichnet wurde. Im allgemeinen werden FFS-Dateien 25 sequentiell geschrieben, wobei ein freier Speicherplatz 28 einen verbleibenden verfügbaren Speicherplatz in dem Firmware-Datenträger darstellt und zum oberen Adressenabschnitt (d. h. den höheren Speicheradressen) der Flash-Einrichtung hin positioniert ist.
Der FV-Kopf 24 umfaßt eine Vielzahl von Datenfeldern, einschließlich eines Felds Attribute 30, eines Felds Kopflänge 32, eines Felds FV-Länge 34, eines Felds FileSystemID 36, eines Felds Prüfsumme 38 und eines Felds FVBlockMap 40. Das Feld Attribute 30 umfaßt eine Vielzahl von Bits, die Lese-/Schreib-Fähigkeiten, den Einschalt-Status, ”klebende” Schreibdaten, ein Kennzeichen für zugeordneten Speicher und eine Kennung für Löschpolarität umfassen. Das Feld Kopflänge 32 enthält die Länge des FV-Kopfs in Bytes. Das Feld FV-Länge 34 enthält die Länge des gesamten Firmware-Datenträgers in Bytes. Das Feld FileSystemID 36 erklärt, mit welchem Dateisystem der Firmware-Datenträger formatiert ist. Das Feld Prüfsumme 38 umfaßt eine 16-Bit-Prüfsumme des gesamten FV-Kopfs. Das Feld FVBlockMap 40 umfaßt eine Reihe von Laufzeitlänge-codierten Blockstruktur-Deskriptoren, einschließlich einer Vielzahl von Tupeln (NumBlocks, Blocklength), die durch ein {0,0}-Tupel beendet werden.
Jede FFS-Datei 25 umfaßt einen FFS-Kopf 42 und Dateidaten 44. Optional können Dateidaten 44 eine Endmarkierung 45 umfassen, die zu Zwecken der Prüfung der Datei-Integrität verwendet wird. Der FFS-Kopf 42 umfaßt verschiedene Datenfelder, einschließlich eines Felds Bezeichnung 46, eines Felds IntegrityCheck 47, eines Felds Typ 48, eines Felds Attribute 49, eines Felds Größe 50 und eines Felds Status 51. In einer Ausführungsform umfaßt das Feld Bezeichnung 46 eine GUID-Kennung (Global Unique Identifier), die vom Firmware-Dateisystem ausgegeben wird und für die garantiert wird, daß sie innerhalb des Firmware-Datenträgers eindeutig ist. Das Feld IntegrityCheck 47 enthält Daten, die zum Überprüfen der Integrität von Dateien verwendet werden, wie im folgenden detaillierter erläutert wird. Das Feld Typ 48 identifiziert den Dateityp und das interne Format der Datei, wie beispielsweise einen DXE-Treiber, PEIM usw. Das Feld Größe 50 enthält die Länge der Datei (einschließlich Dateikopf) in Bytes.
Dateien in dem Firmware-Datenträger werden unter Verwendung eines Verkettungsmechanismus angeordnet, wobei die Länge einer aktuellen Datei zu der Startadresse der Datei hinzugefügt wird, um den Beginn der nächsten Datei in der Kette anzuordnen. Außerdem befindet sich die erste Datei in dem Firmware-Datenträger unmittelbar vor dem Ende des FV-Kopfs 24, wobei die Adresse der ersten Datei auf der Basis des Werts im Feld FV-Länge 34 ermittelt wird.
Wie in der oberen rechten Ecke in 2 dargestellt, umfaßt das Feld Attribute 49 sechs Datenbits (plus zwei reservierte Bits), die verschiedene Attribute der Datei definieren. Diese Attributbits umfassen ein Bit Datei-Endmarkierung vorhanden 52, ein Bit Wiederherstellung 53, ein Bit Kopfdatenerweiterung 54 und ein Teilfeld 3-Bit-Datenabgleich 55, das die Bits 2, 3 und 4 des Felds Attribute 49 umfaßt. Das Feld Attribute 49 umfaßt auch zwei reservierte Bits 56 und 57. Das Bit Datei-Endmarkierung vorhanden 52 gibt an, daß eine 16-Bit-Datei-Endmarkierung am Ende der Datei vorhanden ist. Das Bit Wiederherstellung 53 gibt an, daß die Datei eine Krisen-Wiederherstellung ausführen muß. Das Bit Kopfdatenerweiterung 54 ist für künftige Erweiterungen reserviert. Das Teilfeld Datenabgleich 55 umfaßt ein Feld von 3 Bits, das angibt, wie der Anfang der Daten an einer bestimmten Grenze in Bezug auf die FV-Basis abgeglichen werden muß. Die drei Bits in diesem Feld stellen eine Aufzählung von Abgleichmöglichkeiten bereit, wie beispielsweise einen 8-Byte-Abgleich.
Weitere Details des Felds Status 51 sind im unteren rechten Abschnitt von 2 gezeigt. Das Feld Status 51 ist ein 8-Bit-Feld, das sechs Status-Bits umfaßt, die zum Verfolgen des aktuellen Status eines Datei-Arbeitsablaufs verwendet werden, und die beim Erstellen, Löschen und Aktualisieren der Datei verwendet werden. Die Status-Bits umfassen ein Bit Firmware-Dateisystem im Aufbauzustand 58 (Bit 0), ein Bit FFS-Kopf gültig 59 (Bit 1), ein Bit Datenbereich gültig 60 (Bit 2), ein Bit Datei zum Aktualisieren gekennzeichnet 61 (Bit 3), ein Bit Datei gelöscht 62 (Bit 4) und ein Bit FFS-Kopf ungültig 63 (Bit 5). Zusätzlich zu diesen Status-Bits bleiben die (nicht gezeigten) Bits 6 und 7 bei allen Vorgängen im Status gelöscht (d. h. Logik-Ebene FALSCH). Bei allen im folgenden beschriebenen Abläufen für Statusänderungen sind alle Übergänge von Status-Bits elementare Abläufe, d. h. es wird jeweils nur die Logik-Ebene von einem Status-Bit für eine vorgegebene Dateistatus-Änderung geändert. Außerdem muß der Übergang eines vorgegebenen Bits zu WAHR vollkommen abgeschlossen sein, bevor weitere Eintragungen in den Firmware-Datenträger vorgenommen werden. Außer in Fällen, in denen dies speziell angegeben ist, besitzt des weiteren nur das Status-Bit mit dem höchsten Stellenwert, das auf WAHR gesetzt ist, eine Bedeutung. Dementsprechend treten höherwertige Status-Bits an die Stelle von niederwertigen Status-Bits.
Dateierstellung
Unter Bezugnahme auf den Ablaufplan in 3 und 4 und 5 läuft die Erstellung einer neuen Datei wie folgt ab. Ein neues Feld wird erstellt, indem unmittelbar nach dem Ende einer vorhergehenden Datei, (oder eines Firmware-Datenträger-Kopfs 24, wenn die neue Datei die erste Datei ist, die auf den Firmware-Datenträger geschrieben wird), Speicherplatz aus dem Firmware-Datenträger zugewiesen wird. Angenommen, der Firmware-Datenträger 22 umfaßt eine einzelne Datei X (68) und eine neue Datei Y soll hinzugefügt werden. Dementsprechend umfaßt der restliche Speicherplatz über der letzten (höchsten) Adresse, die von einer Datei X belegt wird, einen freien Raum 28, wobei alle Bits, die diesen Speicherteil belegen, entsprechend dem Gelöscht-Status der Firmware-Einrichtung auf die Logik-Ebene FALSCH gesetzt sind. Infolge des Vorhergehenden umfaßt der Speicherplatz, der von der neuen Datei Y, einschließlich der Kopfdaten der Datei, anfänglich nur auf 1 gesetzte Werte, wie durch den Anfangsstatus 70 einer Datei Y in 4 dargestellt ist.
Der Dateierstellungs-Prozeß beginnt in einem Block 100, in dem das Bit Dateikopf im Aufbauzustand (58) auf WAHR gesetzt wird, wodurch in dem Firmware-Datenträger Speicherplatz für den neuen Dateikopf zugewiesen wird. Daraus ergibt sich ein Status = 11111110b für Datei Y, der angibt, daß der Kopfdaten-Aufbau für Datei Y begonnen hat, aber noch abgeschlossen werden muß. Dieser Zustand ist in 4 dargestellt als Status Kopf im Aufbau 72. Dies hat ein ”Beanspruchen” des FFS-Kopf-Speicherplatzes aus dem freien Speicherplatz 28 des Firmware-Datenträgers zur Folge, der jetzt durch einen Kopf 74 einer Datei Y belegt wird. In diesem Status werden alle anderen Kopf-Felder in einem Block 102 initialisiert, indem entsprechende Daten in jedes Feld geschrieben werden. Dazu gehört die Initialisierung des Felds Bezeichnung 46, des Felds IntegrityCheck 47, des Felds Typ 48, des Felds Attribute 49 und des Felds Größe 50. In einer Ausführungsform umfaßt das Feld Bezeichnung 46 eine GUID-Kennung, die vom Firmware-Dateisystem ausgegeben wird. Typischerweise kann die GUID-Kennung eine 32-Bit-, 64-Bit- oder 128-Bit-GUID-Kennung aufweisen, obwohl jede Bit-Länge der GUID-Kennung verwendet werden kann, solange die GUID-Kennung eine Eindeutigkeit in dem Firmware-Datenträger sicherstellt.
Das Feld IntegrityCheck 47 ist ein 16-Bit-Feld mit drei Teilfeldern: ein IntegrityCheck.Checksum.Header-Teilfeld, ein Teilfeld IntegrityCheck.Checksum.File und ein Teilfeld IntegrityCheck.TailReference. Das Teilfeld IntegrityCheck.Checksum.Header belegt die niedrigeren 8 Bits des Felds IntegrityCheck 47 und umfaßt eine 8-Bit-Prüfsumme für den Dateikopf. Die Felder Status und IntegrityCheck.Checksum.File werden als Null angenommen, und die Prüfsumme wird so berechnet, daß der gesamte Kopf auf Null summiert wird. Der Wert für IntegrityCheck.Checksum.Header ist immer gültig, wenn das Bit Dateikopf gültig 59 im Feld Status 51 auf WAHR gesetzt ist.
Das Teilfeld IntegrityCheck.Checksum.File belegt die höheren 8 Bits des Felds IntegrityCheck 47 und umfaßt eine 8-Bit-Prüfsumme für die gesamte Datei. Das Feld Status 51 und Datei-Endmarkierung 45 werden als Null angenommen, und die Prüfsumme wird so berechnet, daß die gesamte Datei auf Null summiert wird. Der Wert für IntegrityCheck.Checksum.File ist immer gültig, wenn das Bit Dateidaten gültig 60 im Feld Status 51 auf WAHR gesetzt ist.
Das Teilfeld IntegrityCheck.TailReference umfaßt die vollen 16 Bits des Felds IntegrityCheck 47. Es wird zum Berechnen des Werts für Datei-Endmarkierung 45 verwendet, wenn das Bit Datei-Endmarkierung vorhanden 52 im Feld Attribute 49 auf WAHR gesetzt ist.
Nachdem die Initialisierung der Felder für den FFS-Kopf abgeschlossen ist, wird der neue Dateikopf als vollständig gekennzeichnet, indem das Bit Dateikopf gültig 59 in einem Block 104 auf WAHR gesetzt wird. Daraus ergibt sich ein Status = 11111100b, wie dies von einem Status Kopf gültig 76 in 5 dargestellt wird, der angibt, daß der Kopfaufbau abgeschlossen ist, die Dateidaten jedoch noch nicht geschrieben sind. Dies hat ein ”Beanspruchen” der vollen Länge der Datei aus dem freien Speicherplatz 28 des Firmware-Datenträgers zur Folge. Sobald das Bit Dateikopf gültig 59 auf WAHR gesetzt ist, lassen sich keine weiteren Änderungen für Feld Bezeichnung 46, Feld Typ 48, Feld Attribute 49, Feld Größe 50 oder den Wert für IntegrityCheck.Checksum.Header mehr vornehmen.
In diesem Status werden die Dateidaten, der Wert für IntegrityCheck.Checksum.File und die Datei-Endmarkierung (falls zutreffend) in den Firmware-Datenträger 22 in einen Block 106 geschrieben, wie dies durch die Daten 78 und die optionale Datei-Endmarkierung 79 dargestellt wird. Ob eine Datei-Endmarkierung geschrieben wird, hängt vom Status des Bits Datei-Endmarkierung vorhanden 52 im Feld Attribute 49 ab – sie wird geschrieben, wenn der Wert WAHR lautet, sie wird nicht geschrieben, wenn der Wert FALSCH lautet. Die Datei-Endmarkierung, die zum Prüfen der Datei-Integrität verwendet wird, folgt nach den Daten und umfaßt die letzten zwei Bytes der Abbildung der Datei im Firmware-Datenträger 22.
Sobald entsprechende Daten in Block 106 geschrieben worden sind, kann eine optionale Integritätsprüfung in einem Block 108 ausgeführt werden. Es gibt verschiedene Datei- oder Daten-Integritätsprüfungen, die der Fachwelt ein Begriff sind und zu diesem Zweck verwendet werden können. Wenn beispielsweise ein Quellabbild für die Datei verfügbar ist, kann ein Vergleich Bit für Bit oder ein Prüfsummen-Vergleich mit dem Quellabbild und dem geschriebenen Abbild, (d. h. der Version der Datei, die gerade in den Firmware-Datenträger 22 geschrieben wurde), ausgeführt werden. In einigen Fällen kann es vorkommen, daß das Quellabbild nicht zur Verfügung steht, wie beispielsweise in dem Fall, daß die Dateidaten aus einem Pufferspeicher geschrieben wurden, der in der Zwischenzeit geräumt wurde. In diesem Fall kann eine Datei-Integritätsprüfung durchgeführt werden durch das Bereitstellen einiger Indizien, die für die Quelldatei spezifisch sind (z. B. ein Prüfsummenwert), die mit ähnlichen, in der neu geschriebenen Datei enthaltenen Indizien verglichen werden können.
Der Dateierstellungs-Prozeß wird in einem Block 110 abgeschlossen, in dem das Bit Dateidaten gültig 60 auf WAHR gesetzt wird, wodurch angegeben wird, daß die Dateidaten gültig sind. Daraus ergibt sich der Status = 11111000b, wie dies von einem Status Dateidaten gültig 80 in 5 dargestellt wird.
Dateilöschung
Zusätzlich zur Dateierstellung können Dateien durch eine elementare Änderung des Felds Status 51 gelöscht werden. Jede Datei, deren Bit Dateikopf gültig 59 auf WAHR gesetzt ist und deren Bit Datei gelöscht 62 auf FALSCH gesetzt ist, ist ein Kandidat für eine Löschung. Zum Löschen einer Datei wird das Bit Datei gelöscht 62 auf WAHR gesetzt, wie in 6 dargestellt. Wie vorher muß der Übergang dieses Bits in den Status WAHR elementar und vollständig abgeschlossen sein, bevor weitere Eintragungen in den Firmware-Datenträger 22 vorgenommen werden. Daraus ergibt sich ein Status = 1110xx00b, wie durch einen Status Datei gelöscht 82 dargestellt, der angibt, daß die Datei als gelöscht gekennzeichnet ist. Die ”x”-Werte in den hier enthaltenen Figuren geben an, daß der Wert 1 oder 0 sein kann, was vom aktuellen Status abhängt. Aber obwohl die Datei als gelöscht gekennzeichnet ist, ist ihr Kopf immer noch insofern gültig, als das Feld für die Länge der Dateigröße 50 dazu verwendet wird, den Anfang der nächsten Datei im Firmware-Datenträger 22 festzustellen.
Dateiaktualisierung
Ein weiteres Merkmal, das vom Firmware-Dateisystem bereitgestellt wird, ist die Fähigkeit, vorhandene Dateien zu aktualisieren. Eine Dateiaktualisierung ist ein spezieller Fall von Dateierstellung, wobei die hinzugefügte Datei bereits auf dem Firmware-Datenträger vorhanden ist. Kurz gesagt umfaßt der Aktualisierungsablauf das transparente Schreiben einer neuen (aktualisierten) Version einer Datei in einem freien Speicherplatzabschnitt des Firmware-Datenträgers, wobei eine elementare Änderung an den FV-Dateikopfdaten vorgenommen wird, um gleichzeitig die neue Datei für gültig zu erklären und die ursprüngliche Datei ungültig zu machen und anschließend die ursprüngliche Datei als gelöscht zu kennzeichnen. Beim Ausführen dieses Vorgangs werden die Status-Bits im Feld Status 51 beider Dateien Bit für Bit in einer vorgegebenen Reihenfolge geändert, die ein vollständiges Wiedergewinnen in dem Fall einer Unregelmäßigkeit, wie beispielsweise eines Stromausfalls, während der Aktualisierung ermöglicht. Dementsprechend ist zu jedem Zeitpunkt nur eine der Dateien, entweder die aktualisierte Datei (z. B. Datei X') oder die ursprüngliche Datei (z. B. Datei X) gültig.
Unter Bezugnahme auf 7–9 verläuft eine Ausführungsform einer Dateiaktualisierung durch das Firmware-Dateisystem, bei der eine ursprüngliche Datei X mit einem Dateikopf 84 und Dateidaten 86 in eine Datei X' aktualisiert wird, wie folgt. Der Prozeß beginnt in einem Block 112 in 7, in dem das Bit Datei zum Aktualisieren gekennzeichnet 61 in dem Dateikopf (84) der zu aktualisierenden Datei, also der ursprünglichen Datei X, auf WAHR gesetzt wird. Der Übergang dieses Bits in den Status WAHR muß elementar und vollständig abgeschlossen sein, bevor weitere Eintragungen in den Firmware-Datenträger 22 vorgenommen werden. Daraus ergibt sich ein Status = 11110000b, wodurch angegeben wird, daß die Datei zum Aktualisieren gekennzeichnet ist, wie durch einen Status Datei zum Aktualisieren gekennzeichnet 88 in 8 dargestellt ist. Eine Datei mit diesem Status bleibt gültig, solange es keine weitere Datei in dem Firmware-Datenträger mit dieser gleichen Bezeichnung und einem Status = 111110xxb gibt.
Als nächstes wird in einem Block 114 die neue aktualisierte Datei, die Datei X', in der gleichen Weise erstellt, wie oben unter Bezugnahme auf 4–5 und die Prozeßblöcke 100, 102, 104, 106, 108 und 110 in 3 erläutert wurde. Dazu gehört das Erstellen und Initialisieren der Felder in einem neuen Dateikopf 90 und das Schreiben des aktualisierten Abbilds der Datei in einen Teil des Speichers, der die Dateidaten 92 umfaßt. Nach der Validierung der neuen Datei, wie durch den Status Dateidaten gültig 80 angegeben, wird die ursprüngliche Datei, die zum Aktualisieren gekennzeichnet worden ist, ungültig. Wie oben erläutert, erfolgt dies, weil jetzt eine andere Datei im Firmware-Datenträger 22 vorhanden ist, welche die gleiche Bezeichnung wie die ursprüngliche Datei und einen Status aufweist, der nicht = 111110xxb ist. Das Vorgehen, das Bit Dateidaten gültig in das Feld Status 51 des neuen Dateikopfs 90 zu schreiben, wirkt sich zusätzlich so aus, daß die ursprüngliche Datei X ungültig gemacht wird. Der Datei-Aktualisierungsprozeß wird in einem Block 116 abgeschlossen, in dem das Bit Datei gelöscht 62 im Dateikopf für die ursprüngliche Datei, also dem Dateikopf 84, auf WAHR gesetzt ist, wie dies durch einen Status Datei gelöscht 94 in 9 dargestellt ist.
Fülldateien
Unter dem Firmware-Dateisystem können verschiedene Dateitypen verwendet werden. Der Typ jeder Datei wird durch den Wert im Feld Typ 48 des Dateikopfs identifiziert. Zu diesen verschiedenen Dateitypen gehört eine Fülldatei. Eine Fülldatei erhält ihre Bezeichnung aufgrund eines ihrer üblichen Verwendungszwecke. Sie kann zum Füllen des Speicherplatzes der Datei verwendet werden, die im Speichermedium auf sie folgt. Dies kann aus einer Reihe von Gründen geschehen, einschließlich dem Festlegen des Speicherplatzes einer Datei in einem Firmware-Datenträger, dem Belegen von Speicherplatz vor einer obersten Datei des Datenträgers, (einer Datei, die am Ende des Speicherplatzes hinzugefügt wird, um den Firmware-Datenträger zu füllen), und dem Sicherstellen eines Datenabgleichs für eine Datei, um den Abgleichkriterien zu entsprechen, die durch die Abgleich-Bits vorgegeben sind, die im Teilfeld Datenabgleich 55 im Feld Attribute 49 eingestellt sind. Eine Fülldatei kann auch beim Ausführen von Datei-Aktualisierungsvorgängen verwendet werden, wobei mehrere Dateien in einem Firmware-Datenträger im Gleichschritt aktualisiert werden, wie im folgenden beschrieben.
Der normale Status jeder gültigen (nicht gelöschten oder ungültig gemachten) Datei ist, daß beide, ihr Kopf und ihre Daten gültig sind. Dies wird angegeben, indem die Status-Bits im Feld Status 51 auf Status = 11111000b gesetzt werden. Fülldateien unterscheiden sich von allen anderen Dateitypen dadurch, daß jede Fülldatei in diesem Status keine Daten aufweisen sollte, die in ihren Datenbereich geschrieben sind. Im wesentlichen handelt es sich um eine Datei, die mit freiem Speicherplatz gefüllt ist. Außerdem muß das Bit Datei-Endmarkierung vorhanden 52 im Feld Attribute 49 bei Fülldateien frei sein. Diese Einschränkung besteht, da es nicht möglich wäre, wenn dieses Bit gesetzt wäre, den freien Speicherplatz von der Fülldatei zurückzufordern. Da die Daten aus der Fülldatei stammen, die freien Speicherplatz umfaßt, ist eine erweiterte Prüfung der Datei nur eine Prüfung, ob nicht-freie Daten vorhanden sind.
Weil der Datenbereich einer Fülldatei nicht verwendet wird, ist es wünschenswert, diesen freien Speicherplatz zur Verwendung zurückzufordern, falls möglich. Dies geschieht, indem zwei der Status-Bits der Fülldatei verwendet werden. Da beim Datenbereich einer Fülldatei mit einem Status = 11111000b garantiert wird, daß es sich um einen ungestörten freien Speicherplatz handelt, würde die herkömmliche Verwendung des Bits Datei zum Aktualisieren gekennzeichnet 61 (d. h. wie oben verwendet) keinen Sinn ergeben. In Fülldateien wird die Bedeutung dieses Bits überladen, um anzugeben, daß der Datenbereich kein ungestörter freier Speicherplatz ist, sondern einige Daten aufgewiesen haben kann, die in ihn geschrieben waren. Dies ist der Schlüssel zum Zurückfordern des in einer Fülldatei enthaltenen freien Speicherplatzes.
Unter Bezugnahme auf 10 kann ein freier, in einer Fülldatei enthaltener Speicherplatz durch Ausführen des folgenden Prozesses zurückgefordert werden. Der Prozeß beginnt in einem Block 120, in dem das Bit Datei zum Aktualisieren gekennzeichnet 61 im Kopf der Fülldatei auf WAHR gesetzt ist. Wie vorher muß der Übergang von diesem und jedem anderen Bit im Fülldateikopf in den Status WAHR elementar und vollständig abgeschlossen sein, bevor weitere Eintragungen in den Firmware-Datenträger vorgenommen werden. Daraus ergibt sich ein Status = 11110000b, der angibt, daß der Datenbereich der Fülldatei nicht als ungestörter freier Speicherplatz garantiert ist.
Danach wird in einem Block 122 eine vollständige neue Datei erstellt und in den Datenbereich der Fülldatei (d. h. den freien Speicherplatz) geschrieben. Wenn die neue Datei keine besonderen Abgleichanforderungen aufweist, wird sie in der Fülldatei an der niedrigsten Adresse erstellt. Wenn dagegen eine Abgleichanforderung vorhanden ist, kann es notwendig sein, der gewünschten Datei eine weitere Fülldatei voranzustellen, wobei alle in den Datenbereich der ursprünglichen Fülldatei geschrieben werden. Trotzdem muß bzw. müssen die neuen Dateien vollständig geschrieben werden, einschließlich des Dateikopfs und der Daten. Die Status-Bits dieser Datei sind so geschrieben, daß der Status = 11111000b lautet. Da der Kopf (und daher das Feld Status) für die neue Datei tatsächlich Bestandteil des Datenbereichs der Fülldatei ist, ist er noch nicht als Bestandteil des Firmware-Dateisystems sichtbar.
Wenn die in Block 122 erstellte neue Datei den Datenbereich der Fülldatei nicht vollständig ausfüllt, muß eine weitere Fülldatei zum Füllen dieses Speicherplatzes erstellt werden, wie durch einen Block 124 vorgesehen ist. Diese Datei wird auf die gleiche Weise erstellt wie in Block 122, außer, daß der Anfang des Kopfs der neuen Fülldatei auf die Daten für die Datei folgt, die gerade erstellt wurde.
Der Prozeß wird in einem Block 126 abgeschlossen, in dem das Bit Dateikopf ungültig 63 in der ursprünglichen Fülldatei auf WAHR gesetzt ist. Daraus ergibt sich ein Status = 11010000b, der angibt, daß der Kopf der Fülldatei ungültig ist. Da der Kopf der Fülldatei jetzt ungültig ist, ist auch das Feld Länge im Kopf der Fülldatei nicht mehr gültig. Dies wirkt sich so aus, daß das Firmware-Dateisystem nur den Kopf der Fülldatei überspringt und nach einem anderen Dateikopf an der Stelle sucht, die vorher der Datenbereich der Fülldatei war. Da der Kopf der neuen Datei an dieser Stelle vorhanden ist, wird sie korrekterweise als eine gültige Datei interpretiert.
Dateiaktualisierung unter Verwendung einer Fülldatei
Eine Dateiaktualisierung unter Verwendung des freien Speicherplatzes einer Fülldatei ist dem oben erläuterten normalen Datei-Aktualisierungsprozeß sehr ähnlich, außer, daß die aktualisierte Datei in den ”freien” Speicherplatz einer Fülldatei geschrieben wird anstatt in den ”normalen” freien Speicherplatz 28. Unter Bezugnahme auf den Ablaufplan von 11 läuft eine Dateiaktualisierung unter Verwendung einer Fülldatei wie folgt ab. Der Prozeß beginnt in einem Block 130, in dem das Bit Datei zum Aktualisieren gekennzeichnet 61 im Kopf der Fülldatei auf WAHR gesetzt ist. Daraus ergibt sich ein Status = 11110000b, der angibt, daß nicht garantiert ist, daß der Datenbereich der Fülldatei ein freier ungestörter Speicherplatz ist.
Danach wird in einem Block 132 eine vollständige neue Datei im Datenbereich (freien Speicherplatz) der Fülldatei an deren niedrigster Adresse (nach ihrem Kopf) erstellt. Wenn die neue Datei besondere Abgleichanforderungen aufweist, muß dies in der gleichen Weise behandelt werden wie unter Bezugnahme auf Block 122 in 10 oben erläutert. Diese neue Datei muß vollständig geschrieben werden, einschließlich des Dateikopfs und der Daten. Die Statusbits des Dateikopfs für diese neue Datei werden so geschrieben, daß ein Status = 11111000b angegeben wird. Da er tatsächlich Bestandteil des Datenbereichs der Fülldatei ist, ist er noch nicht als Bestandteil des Firmware-Dateisystems sichtbar.
Wenn die in Block 132 erstellte neue Datei den Datenbereich der Fülldatei nicht vollständig ausfüllt, muß eine weitere Fülldatei zum Füllen dieses Speicherplatzes erstellt werden, wie durch einen Block 134 vorgesehen ist. Diese Datei wird auf die gleiche Weise erstellt wie in Block 132, außer, daß der Anfang des Kopfs der neuen Fülldatei auf die Daten für die gerade erstellte Datei folgt. Das Bit Datei zum Aktualisieren gekennzeichnet 61 wird dann in der ursprünglichen Datei auf WAHR gesetzt, die das Ziel der Aktualisierung in einem Block 136 ist.
Danach wird in einem Block 138 das Bit Dateikopf ungültig 63 in der ursprünglichen Fülldatei auf WAHR gesetzt. Daraus ergibt sich ein Status = 11010000b, der angibt, daß der Kopf der Fülldatei ungültig ist. Da der Kopf der Fülldatei jetzt ungültig ist, ist auch das Feld Länge im Kopf der Fülldatei nicht mehr gültig. Dies wirkt sich so aus, daß das Firmware-Dateisystem nur den Kopf der Fülldatei überspringt und nach einem anderen Dateikopf an der Stelle sucht, die vorher der Datenbereich der Fülldatei war. Da der Kopf der neuen Datei an dieser Stelle vorhanden ist, wird sie korrekterweise als eine gültige Datei interpretiert. Der Prozeß wird in einem Block 140 abgeschlossen, in dem die ursprüngliche Datei, die aktualisiert werden sollte, gelöscht wird.
Elementare Aktualisierung von mehreren Dateien
Ein wichtiger Gesichtspunkt der Erfindung ist deren Fähigkeit zum elementaren Aktualisieren einer Vielzahl von FFS-Dateien in einer Weise, die das vollständige Wiedergewinnen für den Fall gestattet, daß während des Aktualisierungsprozesses eine Unregelmäßigkeit, wie zum Beispiel ein Stromausfall, eintritt. Beispielsweise werden während eines Aktualisierungsprozesses neue Daten auf einen Firmware-Datenträger geschrieben. Wenn während dieses Prozesses aufgrund eines Ausfalls des Stromversorgungssystems oder eines anderen Systemausfalls ein Schreibfehler auftritt, kann das Firmware-Dateisystem in einem inkonsistenten Status hinterlassen werden. Durch die Verwendung der Status-Bits und des Felds IntegrityCheck werden diese Fehlerarten jedoch vom Firmware-Dateisystem erkannt, das dann versucht, den Aktualisierungsprozeß an der Stelle fortzusetzen, an welcher der Fehler aufgetreten ist, oder die Firmware-Dateien wieder in ihren ursprünglichen Zustand zurückzuversetzen, den sie vor dem Start des Aktualisierungsprozesses hatten.
Eine Ausführungsform für eine elementare Aktualisierung einer Vielzahl von Dateien in einem Firmware-Dateisystem ist in 12–15 gezeigt. Mit einer elementaren Aktualisierung wird eine Vielzahl von Dateien in einem Firmware-Datenträger zur gleichen Zeit im Gleichschritt aktualisiert. Wenn ein Systemausfall während der elementaren Aktualisierung auftritt, behält das Firmware-Dateisystem entweder einen vollständigen Satz der alten Firmware-Dateien bei, die aktualisiert werden sollen, oder einen vollständigen Satz der neuen aktualisierten Firmware-Dateien. Die elementare Aktualisierung verhindert, daß der Firmware-Datentrager die aktualisierten Dateien als eine Mischung aus alten und neuen Versionen nach einem Systemausfall während des Aktualisierungsprozesses von Firmware-Dateien aufweist. Es ist klar, daß bei einem elementaren Aktualisieren nicht alle der Firmware-Dateien in einem Firmware-Datenträger aktualisiert werden müssen. Im allgemeinen kann eine elementare Aktualisierung mit zwei oder mehr Dateien in dem gleichen Firmware-Datenträger ausgeführt werden. Wenn im folgenden Beispiel zwei Dateien elementar aktualisiert werden, muß jeweils eine neue Ersatzdatei für jede bestehende Datei vorhanden sein. Im allgemeinen ist die Anzahl von neuen Dateien gleich oder größer als die Anzahl der ursprünglichen Dateien, die elementar aktualisiert werden sollen. In Fällen, in denen mehr neue Daten als bestehende Dateien vorhanden sind, wird bzw. werden die zusätzlichen neuen Dateien dem Firmware-Datenträger einfach als neue Datei und nicht als aktualisierte Datei hinzugefügt.
Das elementare Aktualisieren einer Vielzahl von Dateien umfaßt einen Prozeß, der im wesentlichen dem Datei-Aktualisierungsprozeß gleicht, der oben unter Bezugnahme auf 11 erläutert wurde, außer, daß in diesem Fall eine Vielzahl von ursprünglichen Dateien mit Firmware-Daten aktualisiert wird, die in den Datenbereich der Fülldatei statt in eine einzelne Datei geschrieben werden. Unter Bezugsnahme auf 13 wird eine anfängliche Konfiguration eines Firmware-Datenträgers 160 angenommen, der zwei Dateien X und Y enthält, die jeweils in die Dateien X' und Y' aktualisiert werden sollen. Die Datei X umfaßt einen Dateikopf 162 und einen Datenbereich 164, während die Datei Y einen Dateikopf 166 und einen Datenbereich 168 aufweist. Das Feld Status 51 für jeden der Dateiköpfe 162 und 166 ist so eingestellt, daß der Status = 11111000b lautet, der angibt, daß jede Datei X und Datei Y gültig ist, wie jeweils durch den Status Dateidaten gültig 80X und 80Y gezeigt wird.
Unter Bezugnahme auf den Ablaufplan von 12 beginnt der Prozeß der elementaren Aktualisierung einer Vielzahl von Dateien in einem Block 142, in dem eine Fülldatei an einer Byte-Grenze, die unmittelbar auf das Ende der FFS-Datei folgt, die den höchsten Adressen-Speicherplatz (d. h. die niedrigste Adresse des freien Speicherplatzes 28) belegt, in der Weise erstellt wird, wie sie oben unter Bezugnahme auf 3–5 zum Erstellen einer Datei erläutert wurde. Nachdem die Fülldatei erstellt ist, umfaßt sie einen Fülldateikopf 170 und einen Datenbereich 172. Idealerweise sollte die Fülldatei so groß sein, daß sie die kombinierte Größe der aktualisierten Datei-Abbilder und ihrer entsprechenden Dateiköpfe aufnehmen kann. In diesem Zusammenhang wird eine maximale Speicherauslastung wahrgenommen. Anfänglich lautet der Status für die Fülldatei 11111000x, der angibt, daß die Fülldateidaten gültig sind, wie durch den Status Dateidaten gültig 80P in 13 dargestellt.
Danach wird das Bit Datei zum Aktualisieren gekennzeichnet 61 in einem Block 144 im Kopf der Fülldatei auf WAHR gesetzt. Dies wird durch einen Status Datei zum Aktualisieren gekennzeichnet 88P in 13 und 14 veranschaulicht. An dieser Stelle wird in einem Block 146 für jede der zu aktualisierenden Dateien eine neue Datei nach der anderen in den Datenbereich 172 der Fülldatei geschrieben, (d. h. eine nächste Datei beginnt unmittelbar nach der zuletzt geschriebenen Datei). Dies umfaßt beides, das Schreiben des Kopfs und der Daten für jede Datei. Die Daten für eine Datei umfassen ein Dateiabbild, das dem aktualisierten Teil von Firmware entspricht, der an die Stelle der ursprünglichen Firmware treten soll, die in der aktualisierten Datei gespeichert ist. Wie in 14 dargestellt, werden die neuen Dateien X' und Y' während dieses Vorgangs geschrieben, wobei die Datei X' einen Dateikopf 174 und einen Datenbereich 176 umfaßt, in den ein Abbild für ihre aktualisierte Firmware geschrieben ist, und die Datei Y' umfaßt einen Dateikopf 178 und einen Datenbereich 180, in den ein Abbild für ihre aktualisierte Firmware geschrieben ist. In einer Weise, die der oben erläuterten gleicht, sind beide dieser Dateien vor dem Firmware-Dateisystem an dieser Stelle ”verborgen”, da die Fülldatei immer noch als gültig gekennzeichnet ist.
Nachdem die aktualisierten Dateien erstellt sind, kann eine optionale Daten-Integritätsprüfung in einem Block 148 für eine oder mehr der aktualisierten Dateien ausgeführt werden. Wie oben beschrieben kann die Daten-Integritätsprüfung eine Prüfung durch bitweises Vergleichen zwischen dem neu geschriebenen Dateiabbild und dessen Quelle, einen Prüfsummenvergleich oder eine andere Art von Datei-Integritätsprüfung umfassen, die in der Fachwelt ein Begriff ist.
Die Logik fährt danach mit einem Block 150 fort, in dem das Bit Datei zum Aktualisieren gekennzeichnet 61 im Kopf für jede der ursprünglichen Dateien, die aktualisiert werden sollen, auf WAHR gesetzt wird. Jeder der Status für die ursprünglichen Dateien X und Y lautet jetzt = 11110000x, wie durch die Status Datei zum Aktualisieren gekennzeichnet 88X und 88Y in 14 und 15 dargestellt wird. Danach wird das Bit Dateikopf ungültig 63 in einem Block 152 in der ursprünglichen Fülldatei auf WAHR gesetzt, die jetzt den Status = 11010000x aufweist, wie durch den Status Dateikopf ungültig 182 in 15 gezeigt wird. Damit wird der Fülldateikopf ungültig gemacht, wodurch die neu aktualisierten Dateien (z. B. Datei X' und Y') für das Firmware-Dateisystem sichtbar werden. Diese Sichtbarkeit wird wie folgt hergestellt. Obwohl der Fülldateikopf ungültig ist, wird er immer noch zum Bereitstellen des Speicherorts verwendet (über die Nominalgröße des Kopfs, z. B. 6 Bytes). Wenn das Firmware-Dateisystem den Fülldateikopf 170 liest, erkennt es dementsprechend, daß der Kopf ungültig ist und bewegt sich weiter zum Anfang des Dateikopfs für die erste aktualisierte Datei, die in den Datenbereich der Fülldatei geschrieben ist (in diesem Beispiel die Datei X'). Dieser Dateikopf enthält Informationen (über sein Feld Größe 50), die vom Firmware-Dateisystem ebenfalls zum Ermitteln des Anfangs des Kopfs für die nächste Datei im Firmware-Datenträger verwendet wird.
Die elementare Aktualisierung einer Vielzahl von Dateien wird in einem Block 154 abgeschlossen, wobei jede der ursprünglichen Dateien, die aktualisiert werden sollten, gelöscht wird, indem ihr Bit Datei gelöscht 62 auf WAHR gesetzt wird. Damit wird der Status dieser Dateien in 11100000x geändert, wie durch die Status Datei gelöscht 82X und 82Y in 15 gezeigt wird.
Der oben genannte Prozeß stellt sicher, daß mehrere Datei-Aktualisierungen im Gleichschritt ausgeführt werden, um so zu gewährleisten, daß das Firmware-Dateisystem entweder die ursprüngliche Version der Dateien oder die aktualisierte Version der Dateien verwendet, ohne jede Möglichkeit einer falschen Zuordnung zwischen den beiden Versionen. Für den Fall einer Unregelmäßigkeit im System können die Köpfe der verschiedenen Dateien geprüft werden, um festzustellen, in welchem Status sich jede der Dateien befunden hat, als die Unregelmäßigkeit im System auftrat. Damit wird ein Wiederherstellungspfad bereitgestellt, der es ermöglicht, den Datei-Aktualisierungsprozeß wieder an der Stelle aufzunehmen, an der er abgebrochen wurde, bis die Datei-Aktualisierungen erfolgreich abgeschlossen sind. Da im Gegensatz zu Systemen des bisherigen Stands der Technik der Firmware-Datenträger immer ein gültiges Set von Firmware-Dateien enthält, werden Computersysteme, welche die Erfindung implementieren, nicht an einem erneuten Boot-Vorgang gehindert für den Fall, daß während eines Firmware-Aktualisierungsprozesses eine Unregelmäßigkeit im System auftritt.
Beispielhaftes Computersystem für die Implementierung der Erfindung
Unter Bezugnahme auf 16 wird ein im allgemeinen herkömmlicher Personal Computer 200 gezeigt, der für die Verwendung in Zusammenhang mit der Ausführung der vorliegenden Erfindung geeignet ist. Das System kann unter Verwendung einer lokalen Plattform-Firmware-Architektur implementiert werden (z. B. wird die gesamte Firmware lokal im Computer gespeichert unter Verwendung von Firmware-Speichereinrichtungen, wie beispielsweise Flash-Einrichtungen und Options-ROMs), oder es kann auch eine verteilte Plattform-Firmware-Architektur implementiert werden, wie in 16 dargestellt. Die Erfindung kann auch in anderen Computersystemen implementiert werden, einschließlich Workstations, Laptops und Computer-Servern.
Der Personal Computer 200 umfaßt ein Prozessorgehäuse 202, in dem ein Diskettenlaufwerk 204, ein Festplattenlaufwerk 206, eine Hauptplatine 208, die mit entsprechenden integrierten Schaltungen bestückt ist, einschließlich einem oder mehreren Mikroprozessoren und Speichermodulen (beide sind nicht dargestellt), und eine (ebenfalls nicht dargestellte) Energieversorgung untergebracht sind, wie sie dem Fachmann im allgemeinen gut bekannt sind. Die Hauptplatine 208 umfaßt auch eine lokale Firmware-Speichereinrichtung 210 (z. B. einen Flash-Speicher), auf welcher der Basisteil der BIOS-Firmware gespeichert ist. Um den Zugang zu dem Teil der BIOS-Firmware zu erleichtern, der von einer entfernten Firmware-Speichereinrichtung 212 über ein Netzwerk 214 abgerufen wird, umfasst der Personal Computer 200 eine Netzwerk-Schnittstellenkarte 216 oder eine äquivalente Schaltung, die in die Hauptplatine 208 eingebaut ist. Das Netzwerk 214 kann ein LAN, WAN und/oder das Internet umfassen und eine verkabelte oder drahtlose Verbindung zwischen dem Personal Computer 200 und der entfernten Firmware-Speichereinrichtung 212 umfassen.
Ein Bildschirm 218 ist inbegriffen zum Anzeigen von Graphiken und Text, die von Software-Programmen generiert werden, die auf dem Personal Computer ausgeführt werden, und die im allgemeinen während des POST-Tests und anderen Aspekten beim Laden/Ausführen von Firmware angezeigt werden können. Eine Maus 220 (oder eine andere Zeigeeinrichtung) ist an einen seriellen Anschluss (oder an einen Busanschluss) an der Rückseite des Prozessorgehäuses 202 angeschlossen, und Signale von der Maus 220 werden an die Hauptplatine 208 geleitet, um einen Cursor auf der Anzeige zu steuern und Text, Menüoptionen und Graphikkomponenten auszuwählen, die auf dem Bildschirm 218 durch Software-Programme angezeigt werden, die auf dem Personal Computer ausgeführt werden. Außerdem ist eine Tastatur 222 mit der Hauptplatine für Benutzereingaben von Text und Befehlen gekoppelt, die sich auf den Lauf von Software-Programmen auswirken, die auf dem Personal Computer ausgeführt werden.
Der Personal Computer 200 umfasst optional auch ein Laufwerk 224 für einen Compact-Disk-Speicher ohne Schreibmöglichkeit (CD-ROM), in das eine CD-ROM-Diskette eingelegt werden kann, so dass ablauffähige Dateien und Daten auf der Diskette für den Transfer in den Speicher und/oder in die Speichereinrichtung auf der Festplatte 206 des Personal Computers 200 gelesen werden können. Wenn die grundlegende BIOS-Firmware auf einer überschreibbaren Einrichtung gespeichert ist, wie beispielsweise einem Flash-Speicher, können Maschinenbefehle zum Aktualisieren des Basisteils der BIOS-Firmware auf einer CD-ROM-Diskette oder einer Diskette gespeichert und vom Prozessor des Computers gelesen und verarbeitet werden, um die auf dem Flash-Speicher gespeicherte BIOS-Firmware neu zu schreiben. Aktualisierbare BIOS-Firmware kann auch über das Netzwerk 214 geladen werden.
Dem Computer 200 ähnliche Maschinen können für die verschiedenen Server in dem System verwendet werden. Allerdings ist es vorzuziehen, daß Maschinen, die speziell für Web-, Datei- und Anwendungs-Serverfunktionen ausgelegt sind, als solche implementiert werden.
Vom Standpunkt von Hardware- und Software-Komponenten aus, die auf dem Computersystem betrieben werden, sind solche Komponenten im allgemeinen nicht in der Lage, zwischen den jeweiligen Teilen der BIOS-Firmware zu unterscheiden, die auf lokalen und entfernten Speichereinrichtungen gespeichert sind. Abgesehen vom Laden und der Anwendung der BIOS-Firmware beim Hochfahren zum Testen der Systemintegrität und zum Ermitteln/Überprüfen der Systemkonfiguration und anderen, dem Betriebssystem vorgeschalteten Boot-Prozessen arbeitet ein Computersystem, das die Erfindung implementiert, in einer Weise, die mit derjenigen eines herkömmlichen Computersystems identisch ist, das die gleichen Komponenten verwendet und die gleiche Software ausführt.

Claims

Verfahren zum elementaren Aktualisieren einer Vielzahl von vorhandenen Plattform-Firmware-Dateien in einem dauerhaften Firmware-Speicher, wobei wenigstens ein Teil von vorhandenen Plattform Firmwaredaten Kopfdaten beinhalten, die angeben, ob die vorhandenen Plattform-Firmware-Daten gültig und aktualisiert sind, gekennzeichnet durch die Schritte: Erstellen einer Fülldatei; Modifizieren von Kopfdaten der vorhandenen Plattform-Firmware-Datendaten um anzugeben, dass die vorhandenen Plattform-Firmware-Daten gültig sind und zu aktualisieren sind; Schreiben von aktualisierten Plattform-Firmware-Daten-Dateien in die Fülldatei in dem dauerhaften Firmware-Speicher, so dass der dauerhafte Firmware-Speicher sowohl die vorhandenen Plattform Firmware-Daten als auch die aktualisierten Firmware-Daten aufweist, wobei die aktualisierten Firmware-Daten-Dateien Kopfdaten beinhalten, die angeben, dass die aktualisierten Plattform-Firmware-Daten nicht gültig und nicht zu aktualisieren sind; und Ausführen einer elementaren Operation zum Modifizieren der Kopfdaten der Plattform-Firmware-Dateien, um anzugeben, daß die aktualisierten Plattform-Firmware-Dateien anstelle der vorhandenen Plattform-Firmware-Dateien verwendet werden sollen.
Verfahren nach Anspruch 1, dadurch gekennzeichnet dass jede Plattform-Firmware-Datei einen Dateikopf und einen Datenbereich umfasst, in den Plattform-Firmware-Daten, die dieser Datei entsprechen, geschrieben werden, und wobei jeder Dateikopf eine Vielzahl von Status-Bits enthält, die zum Verfolgen eines aktuellen Status jeder Plattform-Firmware-Datei während des Aktualisierungsprozesses verwendet werden.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Fülldatei erstellt wird, indem ein Dateikopf erstellt wird, der die Fülldatei kennzeichnet, die einen Datenbereich aufweist, der so groß ist, daß er alle der aktualisierten Plattform-Firmware-Dateien aufnehmen kann, wobei der Datenbereich einem Speicherbereich auf einer Firmware-Speichereinrichtung zugeordnet ist, die zum Speichern der vorhandenen und der aktualisierten Plattform-Firmware-Dateien verwendet wird.
Verfahren nach Anspruch 3, gekennzeichnet durch das Verändern eines Status-Bits im Dateikopf der Fülldatei, um anzugeben, dass die Fülldatei ungültig ist, nachdem Daten, die den aktualisierten Plattform-Firmware-Dateien entsprechen, in den Datenbereich der Fülldatei geschrieben wurden.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass ein Dateisystem verwendet wird, um auf die Plattform-Firmware-Dateien zuzugreifen, und die aktualisierten Firmware-Dateien für das Dateisystem vor dem Zeitpunkt unsichtbar erscheinen, an dem das Status-Bit geändert wird, und für das Dateisystem sichtbar werden, nachdem das Status-Bit geändert ist.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass jede vorhandene Plattform-Firmware-Datei eine Bezeichnung aufweist, die gemeinsam mit einer entsprechenden aktualisierten Plattform-Firmware-Datei benutzt wird, des Weiteren umfassend: das Verändern der Status-Bits in jeder der vorhandenen Plattform-Firmware-Dateien, um anzugeben, daß sie zu aktualisieren sind; das Einstellen der Status-Bits in jeder der aktualisierten Plattform-Firmware-Dateien, um anzugeben, daß sie gültig sind, wobei, nachdem sie für das Dateisystem sichtbar geworden sind, die Status-Bits in den Dateiköpfen der aktualisierten Plattform-Dateien in Kombination mit den Status-Bits in den vorhandenen Plattform-Firmware-Dateien das Dateisystem gleichzeitig informieren, daß die ursprünglichen Plattform-Dateien ungültig und die aktualisierten Plattform-Dateien gültig sind.
Verfahren nach Anspruch 1, gekennzeichnet durch das Ausführen einer Integritätsprüfung der aktualisierten Plattform-Firmware-Dateien, um sicherzustellen, daß die aktualisierten Firmware-Dateien gültig sind, bevor eine elementare Veränderung der Konfigurationsinformationen der Plattform-Firmware-Datei vorgenommen wird, um anzugeben, daß die aktualisierten Plattform-Firmware-Dateien anstelle der vorhandenen Plattform-Firmware zu verwenden sind.
Verfahren nach Anspruch 1, gekennzeichnet durch das Aktivieren einer vollständigen Wiederherstellung der vorhandenen Plattform-Firmware-Dateien, die während des Aktualisierungsprozesses aktualisiert werden sollen, als Reaktion auf eine Systemunregelmäßigkeit, die eine Beendigung des Aktualisierungsprozesses verhindert.
Verfahren nach Anspruch 2, gekennzeichnet durch das Einstellen der Status-Bits in jedem Dateikopf der vorhandenen Plattform-Firmware-Dateien, um anzugeben, daß die Datei gelöscht wird, nachdem der Aktualisierungsprozeß abgeschlossen ist.
Maschinenlesbares Medium, auf dem eine Vielzahl von maschinenausführbaren Anweisungen gespeichert ist, die eine Vielzahl von in einem dauerhaften Firmware-Speicher vorhandenen Plattform-Firmware-Dateien aktualisieren, indem die folgenden Operationen ausgeführt werden: Erstellen einer Fülldatei; Verändern der Kopfdaten einer jeden existierenden Plattform-Firmware-Datei, um anzugeben, dass die existierende Plattform-Firmware-Dateien gültig und zu aktualisieren ist; Schreiben von Daten, die einer Vielzahl von aktualisierten Plattform-Firmware-Dateien entsprechen, die neue Versionen der Vielzahl der vorhandenen Plattform-Firmware-Dateien umfassen, in die Fülldatei, so dass der dauerhafte Firmware-Speicher sowohl die Mehrzahl der existierenden Plattform-Firmware-Dateien als auch die Mehrzahl von aktualisierten Plattform-Firmware-Dateien aufweist, wobei jede aus der Mehrzahl von aktualisierten Plattform-Firmware-Dateien Kopfdaten aufweist, die anzeigen, dass die aktualisierte Plattform-Firmware-Dateien gültig und nicht zu aktualisieren sind; Ausführen einer elementaren Operation zum Modifizieren der Kopfdaten der Fülldatei, um anzuzeigen, dass die Fülldatei nicht gültig ist, wodurch angezeigt wird, dass die aktualisierten Plattform-Firmware-Dateien, die in den Datenbereich der temporären Datei geschrieben werden, zu laden und anstelle der vorhandenen Plattform-Firmware-Dateien auszuführen sind.
Maschinenlesbares Medium nach Anspruch 10, dadurch gekennzeichnet, dass jede Plattform-Firmware-Datei einen Dateikopf und einen Datenbereich umfasst, in den Plattform-Firmware-Daten, die dieser Datei entsprechen, geschrieben werden, und wobei jeder Dateikopf eine Vielzahl von Status-Bits enthält, die zum Verfolgen eines aktuellen Status jeder Plattform-Firmware-Datei während des Aktualisierungsprozesses verwendet werden.
Maschinenlesbares Medium nach Anspruch 11, dadurch gekennzeichnet, dass die Fülldatei erstellt wird, indem ein Dateikopf erstellt wird, der die Fülldatei kennzeichnet, die einen Datenbereich aufweist, der so groß ist, daß er alle der aktualisierten Plattform-Firmware-Dateien aufnehmen kann, wobei der Datenbereich einem Speicherbereich auf einer Firmware-Speichereinrichtung zugeordnet ist, die zum Speichern der vorhandenen und der aktualisierten Plattform-Firmware-Dateien verwendet wird.
Maschinenlesbares Medium nach Anspruch 12, dadurch gekennzeichnet, dass das Ausführen der Vielzahl von Maschinenbefehlen des weiteren den Arbeitsablauf der Veränderung eines Status-Bits in dem Dateikopf der Fülldatei ausführt, um anzugeben, daß die Fülldatei ungültig ist, nachdem Daten, die den aktualisierten Plattform-Firmware-Dateien entsprechen, in den Datenbereich der Fülldatei geschrieben worden sind.
Maschinenlesbares Medium nach Anspruch 13, dadurch gekennzeichnet, dass ein Dateisystem verwendet wird, um auf die Plattform-Firmware-Dateien zuzugreifen, und die aktualisierten Firmware-Dateien für das Dateisystem vor dem Zeitpunkt unsichtbar erscheinen, an dem das Status-Bit geändert wird, und für das Dateisystem sichtbar werden, nachdem das Status-Bit geändert ist.
Maschinenlesbares Medium nach Anspruch 14, dadurch gekennzeichnet, dass jede vorhandene Plattform-Firmware-Datei eine Bezeichnung aufweist, die gemeinsam mit einer entsprechenden aktualisierten Plattform-Firmware-Datei benutzt wird, und wobei das Ausführen der Vielzahl von Maschinenbefehlen des weiteren die folgenden Arbeitsabläufe ausführt: das Verändern der Status-Bits in jeder der vorhandenen Plattform-Firmware-Dateien, um anzugeben, daß sie zu aktualisieren sind; und das Einstellen der Status-Bits in jeder der aktualisierten Plattform-Firmware-Dateien, um anzugeben, daß sie gültig sind, wobei, nachdem sie für das Dateisystem sichtbar geworden sind, die Status-Bits in den Dateiköpfen der aktualisierten Plattform-Dateien in Kombination mit den Status-Bits in den vorhandenen Plattform-Firmware-Dateien das Dateisystem gleichzeitig informieren, daß die vorhandenen Plattform-Dateien ungültig und die aktualisierten Plattform-Dateien gültig sind.
Maschinenlesbares Medium nach Anspruch 10, dadurch gekennzeichnet, dass das Ausführen der Vielzahl von Maschinenbefehlen des weiteren den Arbeitsablauf des Ausführens einer Integritätsprüfung der aktualisierten Plattform-Firmware-Dateien ausführt, um sicherzustellen, daß die aktualisierten Firmware-Dateien gültig sind, bevor eine elementare Veränderung der Konfigurationsinformationen der Plattform-Firmware-Datei vorgenommen wird, um anzugeben, daß die aktualisierten Plattform-Firmware-Dateien anstelle der vorhandenen Plattform-Firmware zu verwenden sind.
Maschinenlesbares Medium nach Anspruch 10, dadurch gekennzeichnet, dass das Ausführen der Vielzahl von Maschinenbefehlen des weiteren den Arbeitsablauf des Aktivieren einer vollständigen Wiederherstellung der vorhandenen Plattform-Firmware-Dateien, die während des Aktualisierungsprozesses aktualisiert werden sollen, als Reaktion auf eine Systemunregelmäßigkeit ausführt, die eine Beendigung des Aktualisierungsprozesses verhindert.
Maschinenlesbares Medium nach Anspruch 11, dadurch gekennzeichnet, dass das Ausführen der Vielzahl von Maschinenbefehlen des weiteren das Einstellen der Status-Bits in jedem Dateikopf der vorhandenen Plattform-Firmware-Datei ausführt, um anzugeben, dass die Datei gelöscht ist, nachdem der Aktualisierungsprozess abgeschlossen ist.