-
QUERVERWEIS AUF VERWANDTE ANMELDUNG
-
Diese Anmeldung beansprucht den Nutzen der am 29. August 2013 beim US-Patent- und Markenamt eingereichten vorläufigen US-Anmeldung Nr. 61/871,618, deren Offenbarung hiermit durch Inbezugnahme in ihrer Gesamtheit mit aufgenommen wird.
-
HINTERGRUND
-
1. Gebiet
-
Verfahren und Programme, die in Übereinstimmung mit beispielhaften Ausführungsformen sind, beziehen sich auf eine vereinheitlichte erweiterbare Firmware-Schnittstelle (UEFI) und insbesondere auf das Laden und Ausführen eines gerätelosen und systemunabhängigen UEFI-Treibers, der konfiguriert ist zum Filtern von Eingaben/Ausgaben (I/O) an Speichervorrichtungen ohne Abhängigkeit von einer Vorrichtung vom Peripheral-Component-Interconnect(PCI)-Typ und/oder Abwandeln eines System-UEFI-Ein/Ausgabe-Systems (BIOS) zu erfordern, wodurch ein Nur-Software-Produkt ermöglicht wird, welches das Hochfahren eines Betriebssystems (OS) unterstützt.
-
2. Beschreibung der verwandten Technik
-
Allgemein gibt es zwei Verfahren zum Laden eines UEFI-Treibers in einer UEFI-Umgebung.
-
Bei einem ersten Verfahren verwendet eine PCI-Vorrichtung einen Option-Festwertspeicher(Option-ROM)-UEFI-Treiber, der sich in einem ROM/Flashspeicher auf der PCI-Vorrichtung befindet. Dieser Option-ROM-UEFI-Treiber ist Eigentum des PCI-Vorrichtungsherstellers und kann kurzzeitig an das PCI-Vorrichtungs-ROM abgebeben werden, und kann nicht durch Software Dritter abgewandelt werden.
-
Der Zweck dieses Option-ROM-UEFI-Treibers ist es, auf die PCI-Vorrichtung und ihre Children-Vorrichtungen zuzugreifen, während einer Vor-OS-Umgebung. Zum Beispiel wird auf einen PCI-basierten Speichercontroller und die mit dem PCI-basierten Speichercontroller verbundene Platten zugegriffen durch ein System-UEFI-BIOS, welches das UEFI-Treiber-BIOS verwendet. Somit wird das Option-ROM-BIOS für eine PCI-Vorrichtung benötigt zum Hochfahren eines Betriebssystems. Diese Voraussetzung einer physikalischen PCI-Vorrichtung zum Laden eines Option-ROM-BIOS macht es für ein Nur-Software-Produkt, wie z. B. eine „Rückschreibe-Caching”-Software oder eine RAID-Software, das Hochfahren eines Betriebssystems zu unterstützen, da diese Software nur geladen werden können, während des Betriebssystem-Ladens als ein Betriebssystem-Treiber.
-
Bei einem zweiten Verfahren kann der zu ladenden UEFI-Treiber in einem nichtflüchtigen UEFI-BIOS-Direktzugriffsspeicher (NVRAM) gesichert werden, und das System-UEFI-BIOS kann den UEFI-Treiber während des anfänglichen Hochfahrverfahrens laden. Dieser NVRAM-Bereich kann nicht von Fremdsoftwareentwicklern verwendet werden, da jeder Systemhersteller sein eigenes firmeneigenes Format besitzt. Dementsprechend kann Software Dritter, die versucht, in diesen NVRAM zu schreiben, das System irreparabel beschädigen, und abwandeln des UEFI-Treibers erfordert System-BIOS-Abwandlungen, die nur durch den System-Hersteller durchgeführt werden können.
-
KURZFASSUNG
-
Aspekte der beispielhaften Ausführungsformen sehen ein Verfahren zum Implementieren eines computerlesbaren Mediums vor, das ein Programm für einen gerätelosen und systemunabhängigen UEFI-Treiber speichert.
-
Gemäß einem Aspekt einer beispielhaften Ausführungsform wird ein Verfahren bereitgestellt zum Laden eines individuellen Treibers für eine vereinheitlichte erweiterbare Firmware-Schnittstelle (UEFI), wobei das Verfahren beinhaltet, dass ein Computerprozessor eine originale erweiterbare-Firmware-Schnittstellen(EFI)-Boot-Anwendung, die an einem ersten Ort gespeichert ist, an einen zweiten Ort kopiert, die originale EFI-Boot-Anwendung an dem ersten Ort durch eine individuelle EFI-Boot-Anwendung ersetzt, eine an einem dritten Ort gespeicherte originale Globally-Unique-Identifier(GUED)-Partitionstabelle (GPT) an einen vierten Ort kopiert und die originale GPT an dem dritten Ort mit einer individuellen GPT ersetzt.
-
Die individuelle GPT kann einen EFI-Systempartitions(ESP)-Partitionseintrag enthalten, der auf die ESP zeigt, wobei die ESP die individuelle EFI-Boot-Anwendung enthält und die EFI-Boot-Anwendung konfiguriert sein kann zum Bewirken einer Installation eines Block-Eingabe-Ausgabe(I/O)-Protokolls für die ESP, die Einsprungpunkte aufweist, durch die das I/O für Betriebssystem(OS)-Partitionen der originalen GPT gefiltert wird.
-
Die individuelle GPT kann OS-Partitionseinträge weglassen.
-
Die individuelle EFI-Boot-Anwendung kann weiter konfiguriert sein zum Bewirken der Ausführung der originalen EFI-Boot-Anwendung, sobald das Block-I/O-Protokoll für die ESP installiert ist.
-
Die originale EFI-Boot-Anwendung kann das OS laden.
-
Die originale EFI-Boot-Anwendung kann konfiguriert sein zum Bewirken einer Installation der Block-I/O-Protokolle für OS-Partitionseinträge in die originale GPT.
-
Gemäß einem Aspekt einer beispielhaften Ausführungsform ist ein computerlesbares Aufzeichnungsmedium vorgesehen, auf dem ein individueller Treiber für eine vereinheitlichte erweiterbare Firmware-Schnittstelle (UEFI-Treiber) enthalten ist, wobei der individuelle UEFI-Treiber einen computerlesbaren Code enthält, der konfiguriert ist zum Bewirken, dass ein Computerprozessor eine an einem ersten Ort gespeicherte originale erweiterbare-Firmware-Schnittstellen(EFI)-Boot-Anwendung an einen zweiten Ort kopiert, die originale EFI-Boot-Anwendung an dem ersten Ort mit einer individuellen EFI-Boot-Anwendung ersetzt, eine an einem dritten Ort gespeicherte originale Globally-Unique-Idientifiers(GUID)-Partitionstabelle (GPT) an einen vierten Ort kopiert und die originale GPT an dem dritten Ort mit einer individuellen GPT ersetzt.
-
Gemäß einem Aspekt einer beispielhaften Ausführungsform ist ein computerlesbares Aufzeichnungsmedium vorgesehen, auf dem ein Treiber für eine vereinheitlichte erweiterbare Firmware-Schnittstelle (UEFI) enthalten ist, wobei der individuelle UEFI-Treiber eine individuelle Globally-Unique-Identifier(GUID)-Partitionstabelle (GPT) und eine individuelle EFI-Boot-Anwendung enthält, die individuelle GPT auf eine EFI-Systempartition (ESP) zeigt, welche die individuelle EFI-Boot-Anwendung speichert, und wobei die individuelle EFI-Boot-Anwendung konfiguriert ist zum Installieren eines Block-Eingabe/Ausgabe (I/O)-Protokolls für die ESP mit Einsprungpunkten, durch die I/O für Betriebssystem(OS)-Partitionen gefiltert wird.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
Die obigen und weitere Aspekte von den beispielhaften Ausführungsformen werden anschaulich und leichter verstanden werden anhand der folgenden Beschreibung von den beispielhaften Ausführungsformen im Zusammenhang mit den Zeichnungen, in denen:
-
1 ein Ablaufdiagramm eines Verfahrens zum Laden und Ausführen eines UEFI-Treibers gemäß einer beispielhaften Ausführungsform darstellt, und
-
2 ein Ablaufdiagramm eines Verfahrens zum Durchführen von „Rückschreib-Caching” gemäß einer beispielhaften Ausführungsform darstellt.
-
DETAILLIERTE BESCHREIBUNG DER BEISPIELHAFTEN AUSFÜHRUNGSFORMEN
-
Im Folgenden werden beispielhafte Ausführungsformen im Detail beschrieben werden mit Bezug auf die Zeichnungen.
-
In der folgenden Beschreibung werden gleiche Zeichnungs- und Bezugsziffern verwendet für gleiche Elemente, selbst in verschiedenen Zeichnungen. Die in der Beschreibung definierten Gegenstände, wie z. B. detaillierte Strukturen und Elemente werden bereitgestellt, zum Unterstützen eines umfassenden Verständnisses der beispielhaften Ausführungsformen. Jedoch kann das vorliegende erfinderische Konzept praktiziert werden ohne diese speziell definierten Gegenstände. Außerdem sind gut bekannte Funktionen oder Strukturen nicht im Detail beschrieben, da sie die Erfindung mit unnötigen Details verunklaren würden.
-
Die Schritte der unten beschriebenen Verfahren können in irgendeiner Reihenfolge durchgeführt werden außer es ist anders angegeben. Alternativ können die Schritte gleichzeitig durchgeführt werden.
-
1 veranschaulicht ein Ablaufdiagramm eines Verfahrens zum Laden und Ausführen eines UEFI-Treibers zum Filter von I/O an Speichervorrichtungen ohne Abhängigkeit von einer PCI-Vorrichtung zu benötigen und/oder das System UEFI-BIOS abzuändern. Durch Laden eines individuellen UEFI-Treibers ohne eine PCI-Vorrichtung oder System-UEFI-BIOS-Abwandlung, wird ein Nur-Software-Produkt zum Unterstützen des Hochfahrens eines Betriebssystems aktiviert.
-
Das Verfahren aus 1 kann durchgeführt werden durch Ausführen einer Software-Anwendung oder eines Softwaremoduls, das auf einem Computersystem ausgeführt wird, zum Laden des UEFI-Treibers.
-
Wenn eine UEFI-System von einer Speicherplatte bootet, lädt das System-UEFI-BIOS den Master-Boot-Record (MBR) der Platte, der immer vorhanden ist in dem Sektor 0 der Boot-Platte. Wenn der MBR anzeigt, dass es eine Globally-Unique-Identifiers(GUID)-Partitionstabellen(GPT)-Platte ist, dann liest das System-BIOS die GPT, zählt die Partitionen auf der Platte durch und installiert Block-Eingabe/Ausgabe(I/O)-Protokolle für jede der Partitionen. Das Block-I/O-Protokoll ist eine Schnittstelle zum Zugreifen auf die Partitionen auf einer Platte. Ohne das Block-I/O-Protokoll kann nicht auf die Partitionen auf einer Platte zugegriffen werden.
-
Sobald das Block-I/O-Protokoll für jede der Partitionen installiert ist, sucht das System-UEFI-BIOS nach der EFI-System-Partition (ESP), die den OS-Boot-Manager (z. B. für Microsoft Windows ist bootx64.efi die Kopie des Microsoft Windows Boot Managers, der sich bei ...EFI\microsoft\boot\bootmgfw.efi befindet) enthält. Das System-UEFI-BIOS greift auf die ESP zu unter Verwendung des Block-I/O-Protokolls, lädt den OS-Boot-Manager in den Speicher und überträgt Steuerungen an den OS-Boot-Manager, der das Block-I/O-Protokoll verwendet, zum Zugreifen auf die OS-Partitionen (z. B. C:) und lädt den OS-Lader (z. B. für Microsoft Windows winload.efi), der das Laden und Ausführen des Rests des Betriebssystems (z. B. Microsoft Windows) fortführt.
-
Gemäß der in 1 dargestellten beispielhaften Ausführungsform kann ein individueller OS-Boot-Manager bereitgestellt werden und kann der originale OS-Boot-Manager in dem Speicher gesichert werden. Der OS-Boot-Manager wird als eine EFI-Boot-Anwendung bezeichnet werden.
-
Gemäß der in 1 dargestellten beispielhaften Ausführungsform kann auch eine individuelle GPT bereitgestellt werden. Die originale GPT kann abgewandelt werden durch Beibehalten nur des ESP-Partitionseintrags, und alle anderen Partitionseinträge können von der GPT entfernt werden zum Erhalten der individuellen GPT. Zum Beispiel kann eine für das Booten des Betriebssystems nicht benötigte Partition eine Wiederherstellungs- oder Sicherungspartition sein. Die originale GPT kann an dem Ende der Platte gesichert werden.
-
Wie in 1 dargestellt, wird in Schritt S105 eine aktuelle EFI-Boot-Anwendung in dem Speicher gesichert, wodurch eine Kopie der EFI-Boot-Anwendung erzeugt wird. In dem Betriebssystem Microsoft Windows kann die EFI-Boot-Anwendung bootx64.efi oder bootmgfw.efi sein.
-
In Schritt S110 wird die aktuelle EFI-Boot-Anwendung ersetzt durch eine individuelle EFI-Boot-Anwendung. Die aktuelle EFI-Boot-Anwendung kann ersetzt werden durch Überschreiben der aktuellen EFI-Boot-Anwendung mit der individuellen EFI-Boot-Anwendung oder durch Editieren der aktuellen EFI-Boot-Anwendung. Die individuelle EFI-Boot-Anwendung kann, wenn sie ausgeführt wird, eine in dem Speicher gespeicherte originate GPT abrufen und ein Block-I/O-Protokoll für alle gültigen Partitionseinträge (z. B. C:) in der GPT mit Ausnahme des ESP-Partitionseintrags installieren, wobei individuelle Einsprungpunkte verwendet werden, welche I/O filtern können. Die individuelle EFI-Boot-Anwendung kann die UEFI-Treiber-Einsprungpunkte enthalten, die geladen werden müssen für die individuellen Block-I/O-Protokolle. Sobald die Block-I/O-Protokolle für alle gültigen Partitionseinträge geladen sind, kann die individuelle EFI-Boot-Anwendung, die originale EFI-Bootanwendung von dem Speicher abrufen, die originale EFI-Boot-Anwendung laden und die Steuerung an die originale EFI-Boot-Anwendung übertragen zum Laden des Betriebssystems.
-
In Schritt S115 wird die GPT in dem Speicher gesichert, wodurch eine Kopie der GPT erzeugt wird. Die Kopie der originalen GPT kann an dem Ende der Platte gesichert werden.
-
In Schritt S120 werden alle anderen GPT-Einträge als der SP-Eintrag von der GPT entfernt. Optional können zusätzlich zu dem ESP-Eintrag auch Einträge in der GPT belassen werden, die für das Booten des Betriebssystems nicht benötigte Partitionen betreffen. Dementsprechend kann die abgewandelte GPT eine individuelle GPT bilden.
-
Zu diesem Zeitpunkt wird der UEFI-Treiber geladen und wird das System zur Ausführung des neuen UEFI-Treibers vorbereitet.
-
Während des Startens oder Neu-Bootens bootet das UEFI-System im Schritt S125 von der GPT-Platte.
-
In Schritt S130, wenn das UEFI-System von einer Speicherplatte gebootet wird, lädt das System UEFI-BIOS den MBR der Platte, der immer vorhanden ist in dem ersten Sektor (d. h. Sektor 0) der Boot-Platte.
-
Wenn der MBR anzeigt, dass die Platte eine GPT-Platte ist, dann lädt das System-BIOS optional Nicht-Gerate-UEFI-Treiber in Schritt S135.
-
In Schritt S140 beginnt das System-BIOS das Block-I/O-Protokoll für Partitionen der Platte zu installieren.
-
In Schritt S145 liest das System-BIOS die GPT, welche die individuelle GPT aus Schritt S120 ist, und zählt die durch die GPT angezeigten Partitionen auf der Platte durch, welche nur der ESP-Partitionsbeitrag bei der individuellen GPT aus Schritt S120 sein kann. Wie oben diskutiert, können andere für das Booten des Betriebssystems unnötige Partitionseinträge beibehalten werden, wie z. B. eine Sicherungs- oder Wiederherstellungs-Partition, und somit können solche Partitionsbeiträge auch gelesen werden in Schritt S145.
-
Im Schritt S150 installiert das System-UEFI-BIOS die Block-I/O-Protokolle für die gelesenen Partitionen, nämlich das Block-I/O-Protokoll für die ESP-Partition. Wiederum können andere Partitionseinträge, die für das Booten des Betriebssystems unnötig sind, beibehalten werden, wie z. B. eine Sicherungs- oder Wiederherstellungspartition, und somit können Block-I/O-Protokolle für solche Partitionen auch installiert werden in Schritt S150.
-
In Schritt S155 liest das System-BIOS den EFI-Boot-Manager von der ESP-Partition unter Verwendung des installierten Block-I/O-Protokolls. Der EFI-Boot-Manager ist der individuelle EFI-Boot-Manager aus Schritt S110.
-
In Schritt S160 überträgt das System-BIOS die Steuerung an den EFI-Boot-Manager.
-
Wie oben angemerkt, ist das Block-I/O-Protokoll eine Schnittstelle zum Zugreifen auf die Partition einer Platte, ohne die auf die Partitionen einer Platte nicht zugegriffen werden kann. Da andere Partitionseinträge als der ESP-Partitionseintrag weggelassen werden von der individuellen GPT, wird das Block-I/O-Protokoll nur für die EPS-Partition installiert. Dementsprechend erscheint zu diesem Zeitpunkt die Platte roh mit keinen anderen gültigen Partitionen.
-
In Schritt S165 ruft die EFI-Boot-Anwendung die originale GPT ab, die an einem nur der individuellen EFI-Boot-Anwendung bekannten Ort in Schritt S115 gesichert wird.
-
In Schritt S170 liest die EFI-Boot-Anwendung die Partitionseinträge der originalen GPT und installiert Block-I/O-Protokolle mit individuellen Einsprungpunkten für jeden der gültigen Partitionseinträge, die den Partitionen (z. B. OS-Partitionen wie C:) mit Ausnahme der ESP, die vorher geladen wurde. Da Block-I/O-Protokolle für diese Partitionen nicht installiert wurden, waren diese neu geladenen Partitionen bis jetzt nicht sichtbar für das System-UEFI-BIOS oder irgendeine andere UEFI-Anwendung.
-
Nach diesem Zeitpunkt gehen, da Block-I/O-Protokolle für jede der Partitionen (einschließlich OS-Partitionen wie z. B. C:\) danach installiert werden, all die I/O, die zu diesen Partitionen geleitet werden, durch das Block-I/O-Protokoll für die in Schritt S150 geladene ESP, welche die individuellen Einsprungpunkte enthält. Dies ermöglicht Filtern der I/O zu diesen neu geladenen Partitionen.
-
In Schritt S175 lädt die EFI-Boot-Anwendung, sobald die Block-I/O-Protokolle für all die verbleibenden gültigen Partitionen in der originalen GPT installiert sind, den originalen EFI-Boot-Manager von dem Speicher und überträgt die Steuerung an den originalen EFI-Boot-Manager, der den OS-Lader lädt. Dieser OS-Lader führt das Laden und die Ausführung des Betriebssystems in Schritt S180 fort.
-
All die I/O an die OS-Partitionen und andere Partitionen, für welche Block-I/O-Protokolle installiert sind, können nun gefiltert werden.
-
2 veranschaulicht ein Verfahren zum Durchführen von „Rückschreib-Caching” unter Verwendung eines UEFI-Treibers gemäß einer beispielhaften Ausführungsform.
-
Gemäß einem Aspekt einer beispielhaften Ausführungsform kann eine Verwendung des UEFI-Treibers ein „Rückschreib-Caching”-Nur-Software-Produkt sein. Solch eine Software muss vorhanden sein in einer Vor-OS-UEFI-Umgebung zum Unterstützen des Bootens eines Betriebssystems, da einige der Daten auf der Cache-Vorrichtung vorhanden sein können und nicht vorhanden sein können auf der Zielspeicherplatte (der Platte, die gecached wird).
-
Eine traditionelle Vorgehensweise verwendet einen PCI-basierten Speichercontroller, auf dem ein Option-ROM-UEFI installiert ist. Da all die I/O durchgeführt wird unter Verwendung dieses UEFI-Treibers, kann der PCI-basierte Speichercontroller die I/O umleiten zu der Cache-Vorrichtung wann immer es benötigt wird. Aber dies erfordert, dass die Caching-Logik innerhalb des UEFI-Treibers des PCI-basierten Speichercontrollers ist, was nicht möglich ist für Software von Dritten.
-
Andererseits kann gemäß Aspekten der beispielhaften Ausführungsformen durch Verwenden eines/einer in den Speicher geladenen separaten UEFI-Treibers/Anwendung die I/O gefiltert werden ohne die Notwendigkeit des Abwandelns des firmeneigenen UEFI-Treibers oder System-UEFI-BIOS.
-
Gemäß Aspekten der beispielhaften Ausführungsform besitzt diese Vorgehensweise außerdem den Vorteil des Filters von I/O an irgendeine PCI-Vorrichtung und ihre Children, während ein auf einer PCI-Vorrichtung befindlicher UEFI-Treiber nur auf die zu der bestimmten PCI-Vorrichtung und ihre Children gerichtete I/O zugreifen kann. Aspekte der beispielhaften Ausführungsformen sind sogar noch interessanter für Nur-Software-Produkte wie „Rückschreib-Caching”, „Software und RAID” und „Festplattenverschlüsselung”, in dem den involvierten Speicherplatten ermöglicht wird (z. B. einer Zielplatte und einer Cache-Platte), auf verschiedenen Speichercontrollern vorhanden zu sein. In dem Fall des „Rückschreib-Cachings” kann diese Vorgehensweise weiter verwendet werden zum Booten von nahezu ausschließlich von der Cache-Platte, wodurch Drehen der Zielspeicherplatte abgeschwächt auf das Nötigste werden kann. Das Verfahren des „Rückschreib-Caching” ist in 2 dargestellt.
-
In Schritt S210 wird eine Kopie der GPT der Zielplatte gespeichert auf der Cache-Platte an dem gleichen Ort wie auf der Zielplatte. Diese Cache-Platte kann eine Hochgeschwindigkeitsplatte, wie z. B. eine Festkörperplatte (SSD), sein.
-
In Schritt 220 werden alle Partitionen der GPT auf der Zielspeicherplatte entfernt.
-
In Schritt S230 werden die ESP-Partitionen von der Zielplatte zu der Cache-Platte kopiert.
-
In Schritt S240 wird die Cache-Platte als die bootfähige Platte festgelegt.
-
In Schritt S250 wird die originale EFI-Boot-Anwendung, wie oben mit Bezug auf 1 beschrieben, auf der Cache-Platte gesichert, und wird die originale UEFI-Boot-Anwendung auf der Cache-Platte ersetzt durch die individuelle EFI-Anwendung.
-
Gemäß einem Aspekt dieser beispielhaften Ausführungsform kann ein System von der Cache-SSD (anstelle der Zielplatte) booten, die individuelle EFI-Boot-Anwendung von der ESP auf der Cache-Platte laden, die nach Einrichten des Block-I/O-Protokolls die originale EFI-Boot-Anwendung lädt, aber diesmal von der Cache-Platte selbst. Dementsprechend wird das Drehen der Zielplatte vermieden bis es einen Lesefehler auf der Cache-Platte gibt.
-
Ein ähnliches Vorgehen kann verwendet werden zum Fortsetzen nach Schlafzuständen wie einem Ruhezustand.
-
Gemäß Aspekten der beispielhaften Ausführungsform sieht diese Vorgehensweise ein Booten und eine Fortsetzung nach einer Ruhezustandsgeschwindigkeit nahezu identisch zu dem Fall vor, bei dem das gesamte Betriebssystem auf der Cache-Platte installiert ist.
-
Gemäß Aspekten der beispielhaften Ausführungsformen wird ein neues Verfahren zum Laden eines individuellen UEFI-Treibers ohne eine PCI-Vorrichtung oder System-UEFI-BIOS-Abwandlung beschrieben. Dadurch ist ein UEFI verwendendes Nur-Software-Produkt möglich, das Booten und Fortsetzen nach Ruhezustand unterstützt.
-
Gemäß Aspekten der beispielhaften Ausführungsformen kann ein UEFI-Treiber geladen werden, ohne eine PCI-Vorrichtungsabhängigkeit, und kann ein UEFI-Treiber geladen werden ohne System-BIOS-Änderungen.
-
Die oben beschriebenen Verfahrensschritte können implementiert werden durch einen Computerprozessor (z. B. eine Zentralverarbeitungseinheit oder CPU), welche auf einem computerlesbaren Aufzeichnungsmedium (z. B. eine Platte, ein Speicher, eine CD-ROM usw.) computerlesbare Codes ausführt. Der Computerprozessor kann ein Universalprozessor oder -computer, ein spezialisierter Prozessor oder Computer, oder ein Prozessor eines Speichercontrollers sein. Die computerlesbaren Codes können ein Installationsprogramm zum Laden des UEFI-Treibers in einen Speicher enthalten, und können den in den Speicher geladenen UEFI-Treiber enthalten, der ausgeführt wird durch den Computerprozessor nach Booten des Computers.
-
Obwohl einige beispielhafte Ausführungsformen gezeigt und beschrieben wurden, wird es von Fachleuten anerkannt werden, dass Änderungen bei diesen beispielhaften Ausführungsformen gemacht werden können, ohne von den Prinzipien und dem Geist des vorliegenden Konzepts abzuweichen, dessen Umfang in den Ansprüchen und ihren Äquivalenten definiert ist.
