-
ALLGEMEINER
STAND DER TECHNIK
-
Gebiet der
Erfindung
-
Die vorliegende Erfindung betrifft
Computersysteme im allgemeinen und insbesondere die Verwaltung von
Plattform-Firmware.
-
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 gespeicherten)
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).
-
Beide dieser 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.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die vorgenannten Gesichtspunkte und
viele der begleitenden Vorteile dieser Erfindung werden besser geschätzt, wenn
selbige unter Bezugnahme auf die folgende detaillierte Beschreibung
besser verstanden werden, wenn sie in Zusammenhang mit den folgenden
begleitenden Zeichnungen gelesen wird:
-
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 Endanwen dern (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 38 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 Dateiwiedergewinnung 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 Wiedergewinnung 53 gibt an, daß die Datei eine Krisen-Wiederherstellung
ausführen
muß. Das
Bit Kopfdatenerweiterung 54 ist für künftige Erweite rungen 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 linken 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 65 (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 Integrity-Check.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 auf grund 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 Bezug nahme 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-Datenträger
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 Daten bereich 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 80P 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, umfaßt
der Personal Computer 200 eine Netzwerk-Schnittstellenkarte 116 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-Teusts und anderen Aspekten beim Laden/Ausführen von
Firmware angezeigt werden können.
Eine Maus 220 (oder eine andere Zeigeeinrichtung) ist an
einen seriellen Anschluß (oder
an einen Busanschluß)
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 umfaßt 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 daß 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.
-
Obwohl die vorliegende Erfindung
in Verbindung mit einer bevorzugten Form ihrer Ausführung und
Abwandlungen davon beschrieben wurde, ist dem durchschnittlichen
Fachmann klar, daß viele
andere Veränderungen
an der Erfindung innerhalb des Umfangs der folgenden Ansprüche vorgenommen werden
können.
Dementsprechend ist nicht beabsichtigt, den Umfang der Erfindung
durch die obige Beschreibung in irgendeiner Weise einzuschränken, sondern
sie statt dessen in ihrer Gesamtheit unter Bezugnahme auf die folgenden
Ansprüche
festzulegen.
-
ZUSAMMENFASSUNG
DER BESCHREIBUNG
-
Es wird ein Verfahren zum Aktualisieren
von Plattform-Firmware
offenbart. Diese Möglichkeit
wird durch eine standardmäßige Software-Abstraktion
für eine
Firmware-Speichereinrichtung
vereinfacht, die als ein Firmware-Datenträger (FV) bekannt ist und durch
ein Firmware-Dateisystem (FFS) verwaltet wird. Das Firmware-Dateisystem
ermöglicht
es, Firmware-Dateien zu erstellen, zu löschen und einzeln zu aktualisieren.
Das Firmware-Dateisystem ermöglicht es
ebenfalls, eine Vielzahl von Firmware-Dateien elementar zu aktualisieren,
indem Datei-Statusinformationen über
Status-Bits verwaltet werden, die in einem Dateikopf jeder Firmware-Datei
gespeichert sind, wobei eine elementare Veränderung eines einzelnen Status-Bits
gleichzeitig verursacht, daß das Firmware-Dateisystem
ein aktualisiertes Set von Firmware-Dateien anstatt eines ursprünglichen
Sets von Firmware-Dateien verwendet.