Booten - Booting

Ein Flussdiagramm eines Computerstarts

In der Computertechnik ist Booten der Vorgang des Startens eines Computers . Sie kann durch Hardware wie einen Tastendruck oder durch einen Softwarebefehl ausgelöst werden . Nach dem Einschalten hat die Zentraleinheit (CPU) eines Computers keine Software in ihrem Hauptspeicher , sodass einige Prozesse Software in den Speicher laden müssen, bevor sie ausgeführt werden kann. Dies kann durch Hardware oder Firmware in der CPU oder durch einen separaten Prozessor im Computersystem erfolgen.

Das Neustarten eines Computers wird auch als Neustart bezeichnet , was "hart" sein kann, z. Auf einigen Systemen kann ein Softboot optional den RAM auf Null löschen . Sowohl das Hard- als auch das Softbooten können durch Hardware wie beispielsweise einen Tastendruck oder durch einen Softwarebefehl eingeleitet werden. Das Booten ist abgeschlossen, wenn das operative Laufzeitsystem , typischerweise das Betriebssystem und einige Anwendungen, erreicht ist.

Der Prozess der Rückkehr eines Computers aus dem Ruhezustand (Suspendierung) beinhaltet kein Booten; die Wiederherstellung aus dem Ruhezustand funktioniert jedoch. Zumindest erfordern einige eingebettete Systeme keine merkliche Boot-Sequenz, um zu funktionieren, und können beim Einschalten einfach Betriebsprogramme ausführen, die im ROM gespeichert sind. Alle Computersysteme sind Zustandsmaschinen , und ein Neustart kann das einzige Verfahren sein, um aus einem unbeabsichtigten, gesperrten Zustand in einen bestimmten Null-Zustand zurückzukehren.

Zusätzlich zum Laden eines Betriebssystems oder eines eigenständigen Dienstprogramms kann der Bootvorgang auch ein Speicherauszugsprogramm laden, um Probleme in einem Betriebssystem zu diagnostizieren.

Boot ist die Abkürzung für Bootstrap oder Bootstrap Load und leitet sich von der Phrase ab , sich an seinen Bootstraps hochzuziehen . Die Verwendung macht auf die Anforderung aufmerksam, dass, wenn die meiste Software durch andere Software, die bereits auf dem Computer läuft, auf einen Computer geladen wird, ein Mechanismus vorhanden sein muss, um die anfängliche Software auf den Computer zu laden. Frühe Computer verwendeten eine Vielzahl von Ad-hoc-Methoden, um ein kleines Programm in den Speicher zu bekommen, um dieses Problem zu lösen. Die Erfindung von Festwertspeichern (ROM) verschiedener Typen löste dieses Paradox, indem sie es ermöglichte, Computer mit einem Startprogramm auszuliefern, das nicht gelöscht werden konnte. Die Zunahme der ROM-Kapazität hat die Implementierung immer ausgefeilterer Startverfahren ermöglicht.

Geschichte

Schalter und Kabel zur Programmierung von ENIAC (1946)

Es gibt viele verschiedene Methoden, um ein kurzes Startprogramm in einen Computer zu laden. Diese Methoden reichen von einfachen physischen Eingaben bis hin zu Wechselmedien, die komplexere Programme enthalten können.

Beispiele für vorintegrierte ROM-Schaltungen

Frühe Computer

Frühe Computer in den 1940er und 1950er Jahren waren einzigartige Ingenieurleistungen, deren Programmierung Wochen dauern konnte, und das Laden von Programmen war eines von vielen Problemen, die gelöst werden mussten. Ein früher Computer, ENIAC , hatte kein Programm im Speicher, sondern wurde für jedes Problem durch eine Konfiguration von Verbindungskabeln eingerichtet. Bootstrapping galt nicht für ENIAC, dessen Hardwarekonfiguration bereit war, Probleme zu lösen, sobald die Stromversorgung eingeschaltet wurde.

Das EDSAC- System, der zweite zu bauende speicherprogrammierbare Computer, verwendete Schrittschalter , um ein festes Programm in den Speicher zu übertragen, wenn der Startknopf gedrückt wurde. Das auf diesem Gerät gespeicherte Programm, das David Wheeler Ende 1948 fertigstellte, lud weitere Anweisungen von Lochstreifen und führte sie dann aus.

Erste kommerzielle Computer

Die ersten programmierbaren Computer für den kommerziellen Verkauf, wie der UNIVAC I und der IBM 701, enthielten Funktionen, die ihre Bedienung vereinfachten. Sie enthielten normalerweise Anweisungen, die eine vollständige Eingabe- oder Ausgabeoperation durchführten. Die gleiche Hardwarelogik könnte verwendet werden, um den Inhalt einer Lochkarte (die typischsten) oder anderer Eingabemedien, wie einer Magnettrommel oder eines Magnetbandes , die ein Bootstrap-Programm enthielten, durch Drücken einer einzigen Taste zu laden . Dieses Bootkonzept wurde für IBM- Computer der 1950er und frühen 1960er Jahre mit verschiedenen Namen bezeichnet , aber IBM verwendete den Begriff "Initial Program Load" mit der IBM 7030 Stretch und verwendete ihn später für ihre Mainframe-Linien, beginnend mit dem System/360 in 1964.

Erstes Programm laden Lochkarte für die IBM 1130 (1965)

Der Computer IBM 701 (1952–1956) hatte einen "Laden"-Knopf, der das Lesen des ersten 36-Bit- Wortes in den Hauptspeicher von einer Lochkarte in einem Kartenleser , einem Magnetband in einem Bandlaufwerk oder einer Magnettrommeleinheit initiierte , je nach Stellung des Lastwahlschalters. Das linke 18-Bit-Halbwort wurde dann als Anweisung ausgeführt, die normalerweise zusätzliche Wörter in den Speicher einliest. Das geladene Boot-Programm wurde dann ausgeführt, das wiederum ohne weitere Hilfe des menschlichen Bedieners ein größeres Programm von diesem Medium in den Speicher lud. Der Begriff „Stiefel“ wird in diesem Sinne mindestens seit 1958 verwendet.

IBM System/3-Konsole aus den 1970er Jahren. Programmlade-Wahlschalter ist unten links; Der Programmladeschalter befindet sich unten rechts.

Andere IBM-Computer dieser Ära hatten ähnliche Funktionen. Zum Beispiel verwendete das IBM 1401- System (ca. 1958) einen Kartenleser, um ein Programm von einer Lochkarte zu laden. Die in der Lochkarte gespeicherten 80 Zeichen wurden in die Speicherplätze 001 bis 080 eingelesen, dann verzweigte der Computer zum Speicherplatz 001, um seinen ersten gespeicherten Befehl zu lesen. Diese Anweisung war immer die gleiche: Verschieben Sie die Informationen dieser ersten 80 Speicherplätze in einen Sammelbereich, wo die Informationen der Lochkarten 2, 3, 4 usw. zu dem gespeicherten Programm zusammengefügt werden konnten. Sobald diese Informationen in den Montagebereich verschoben wurden, verzweigte die Maschine zu einer Anweisung in Platz 080 (Karte lesen) und die nächste Karte würde gelesen und ihre Informationen verarbeitet.

Ein anderes Beispiel war die IBM 650 (1953), eine Dezimalmaschine, die auf ihrem Bedienfeld eine Gruppe von zehn 10-Positionen-Schaltern hatte, die als Merkerwort (Adresse 8000) adressierbar waren und als Anweisung ausgeführt werden konnten. Somit würde das Einstellen der Schalter auf 7004000400 und das Drücken der entsprechenden Taste die erste Karte im Kartenleser in den Speicher lesen (Operationscode 70), beginnend bei Adresse 400 und dann zu 400 springen, um mit der Ausführung des Programms auf dieser Karte zu beginnen.

Die Konkurrenten von IBM boten auch das Laden von Programmen mit einer einzigen Taste an.

  • Der CDC 6600 (ca. 1964) hatte ein Totstart- Panel mit 144 Kippschaltern; der Totstartschalter hat 12 Wörter von den Kippschaltern in den Speicher des Peripherieprozessors ( PP ) 0 eingegeben und die Ladesequenz eingeleitet. PP 0 hat den notwendigen Code in seinen eigenen Speicher geladen und dann die anderen PPs initialisiert.
  • Das GE 645 (ca. 1965) hatte einen "SYSTEM BOOTLOAD"-Knopf, der beim Drücken einen der I/O-Controller veranlasste, ein 64-Wort-Programm aus einem Dioden - Lesespeicher in den Speicher zu laden und einen Interrupt abzugeben, um zu verursachen dieses Programm zu starten.
  • Das erste Modell des PDP-10 hatte einen "READ IN"-Knopf, der beim Drücken den Prozessor zurücksetzte und einen I/O-Vorgang an einem durch Schalter auf dem Bedienfeld spezifizierten Gerät startete, wobei ein 36-Bit-Wort eingelesen wurde Zieladresse und Zählung für nachfolgende Wortlesevorgänge; Wenn das Lesen abgeschlossen war, begann der Prozessor mit der Ausführung des eingelesenen Codes, indem er zum letzten eingelesenen Wort sprang.

Eine bemerkenswerte Variante davon findet sich beim Burroughs B1700, wo es weder ein Bootstrap-ROM noch einen fest verdrahteten IPL-Betrieb gibt. Stattdessen liest das System, nachdem es zurückgesetzt wurde, Opcodes und führt sie sequentiell von einem Bandlaufwerk aus, das an der Frontplatte angebracht ist; Dadurch wird ein Bootloader im RAM eingerichtet, der dann ausgeführt wird. Da dies jedoch nur wenige Annahmen über das System voraussetzt, kann es genauso gut zum Laden von Diagnosebändern (Maintenance Test Routine) verwendet werden, die selbst bei einem groben CPU-Ausfall einen verständlichen Code auf der Frontplatte anzeigen .

IBM System/360 und Nachfolger

Im IBM System/360 und seinen Nachfolgern, einschließlich der aktuellen z/Architecture- Maschinen, wird der Boot-Prozess als Initial Program Load (IPL) bezeichnet.

IBM hat diesen Begriff für den 7030 (Stretch) geprägt , ihn für das Design des System/360 wiederbelebt und verwendet ihn auch heute noch in diesen Umgebungen. Bei den System/360-Prozessoren wird ein IPL vom Computerbediener initiiert, indem die drei hexadezimale Geräteadresse (CUU; C=E/A-Kanaladresse, UU=Steuereinheit und Geräteadresse) ausgewählt wird, gefolgt von Drücken der Taste LOAD . Bei den High-End- System/360- Modellen, den meisten System/370 und einigen späteren Systemen werden die Funktionen der Schalter und der LOAD-Taste durch auswählbare Bereiche auf dem Bildschirm einer Grafikkonsole simuliert, oft ein IBM 2250- ähnliches Gerät oder ein IBM 3270 -ähnliches Gerät. Beim System/370 Modell 158 beispielsweise führt die Tastaturfolge 0-7-X (Null, Sieben und X, in dieser Reihenfolge) zu einem IPL von der Geräteadresse, die in den Eingabebereich eingegeben wurde. Die Amdahl 470V/6 und verwandte CPUs unterstützten vier hexadezimale Ziffern auf den CPUs, auf denen die optionale zweite Kanaleinheit installiert war, also insgesamt 32 Kanäle. Später würde IBM auch mehr als 16 Kanäle unterstützen.

Die IPL-Funktion im System/360 und seinen Nachfolgern und seinen kompatiblen Geräten wie dem von Amdahl liest 24 Bytes von einem vom Bediener spezifizierten Gerät in den Hauptspeicher, beginnend bei der realen Adresse Null. Die zweite und dritte Gruppe von acht Bytes werden als Channel Command Words (CCWs) behandelt, um das Laden des Startup-Programms fortzusetzen (der erste CCW wird immer von der CPU simuliert und besteht aus einem Read IPL-Befehl, 02h , mit Befehlsverkettung und Unterdrückung falscher Länge Anzeige wird durchgesetzt). Wenn die E/A-Kanalbefehle abgeschlossen sind, wird die erste Gruppe von acht Bytes dann in das Programmstatuswort (PSW) des Prozessors geladen und das Startprogramm beginnt mit der Ausführung an der von diesem PSW bezeichneten Stelle. Das IPL-Gerät ist normalerweise ein Diskettenlaufwerk, daher die besondere Bedeutung des 02h- Read-Type-Befehls, aber genau das gleiche Verfahren wird auch zum IPL von anderen Eingabegeräten wie Bandlaufwerken oder sogar Kartenlesern verwendet geräteunabhängig, was beispielsweise die Installation eines Betriebssystems auf einem fabrikneuen Computer von einem Magnetband der Erstverteilung des Betriebssystems ermöglicht. Für Plattencontroller, die 02h verursacht Befehl auch das ausgewählte Gerät zu Zylinder suchen 0000h , Kopf 0000h , einen Zylinder und Kopf Suchbefehl zu simulieren, 07h , und für die Aufzeichnung suchen 01h , eine Suche ID Equal Befehl, Simulation 31h ; Suchvorgänge und Suchvorgänge werden von Band- und Kartencontrollern nicht simuliert, da ein 02h- Befehl für diese Geräteklassen einfach ein sequentieller Lesebefehl ist, kein Read IPL-Befehl.

Die Diskette, das Band- oder Kartendeck muss ein spezielles Programm enthalten, um das eigentliche Betriebssystem oder das eigenständige Dienstprogramm in den Hauptspeicher zu laden, und zu diesem speziellen Zweck wird "IPL-Text" vom eigenständigen DASDI (Direct Access Storage Device) auf der Platte platziert Initialisierungsprogramm oder ein gleichwertiges Programm, das unter einem Betriebssystem läuft, zB ICKDSF, aber IPL-fähige Bänder und Kartendecks werden normalerweise mit diesem bereits vorhandenen "IPL-Text" vertrieben.

Minicomputer

Vorderseite des PDP-8/E mit den Schaltern zum Laden des Bootstrap-Programms

Minicomputer , beginnend mit den Digital Equipment Corporation (DEC) PDP-5 und PDP-8 (1965) vereinfachten das Design, indem sie die CPU zur Unterstützung von Eingabe- und Ausgabeoperationen verwendeten. Dies sparte Kosten, machte das Booten jedoch komplizierter als das Drücken einer einzigen Taste. Minicomputer hatten normalerweise eine Möglichkeit, in kurzen Programmen umzuschalten , indem sie eine Reihe von Schaltern auf der Vorderseite manipulierten. Da die frühen Minicomputer einen Magnetkernspeicher verwendeten , der seine Informationen beim Ausschalten nicht verlor, blieben diese Bootstrap-Loader an Ort und Stelle, wenn sie nicht gelöscht wurden. Das Löschen geschah manchmal versehentlich, wenn ein Programmfehler eine Schleife verursachte, die den gesamten Speicher überschrieb.

Andere Minicomputer mit solch einfacher Form des Bootens sind die HP 2100- Serie von Hewlett-Packard (Mitte der 1960er Jahre), das Original von Data General Nova (1969) und DECs PDP-11 (1970).

DEC fügte später einen optionalen Diodenmatrix -Lesespeicher für den PDP-11 hinzu, der ein Bootstrap-Programm von bis zu 32 Wörtern (64 Bytes) speicherte. Es bestand aus einer gedruckten Schaltungskarte, der M792, die in den Unibus eingesteckt wurde und ein 32 mal 16 Array von Halbleiterdioden enthielt . Mit allen 512 Dioden enthielt der Speicher alle "Eins"-Bits; die Karte wurde programmiert, indem jede Diode abgeschaltet wurde, deren Bit "Null" sein sollte. DEC verkaufte auch Versionen der Karte, die BM792-Yx-Serie, die für viele Standard-Eingabegeräte vorprogrammiert waren, indem einfach die nicht benötigten Dioden weggelassen wurden.

Dem älteren Ansatz folgend, weist der frühere PDP-1 einen Hardwarelader auf, so dass eine Bedienungsperson nur den "Laden"-Schalter drücken muss, um den Papierstreifenleser anzuweisen , ein Programm direkt in den Kernspeicher zu laden. Die Data General Supernova verwendete Frontplattenschalter, um den Computer zu veranlassen, automatisch Anweisungen von einem durch die Datenschalter der Frontplatte angegebenen Gerät in den Speicher zu laden und dann zum geladenen Code zu springen; die Nova 800 und 1200 hatten einen Schalter, der ein Programm aus einem speziellen Nur-Lese-Speicher in den Hauptspeicher lud und dorthin sprang.

Beispiele für frühe Minicomputer-Bootloader

In einem Minicomputer mit einem Papierbandleser würde das erste Programm, das im Bootprozess ausgeführt wird, der Bootloader, entweder den Bootloader der zweiten Stufe (oft als Binary Loader bezeichnet ) in den Kernspeicher einlesen, der Papierbänder mit Prüfsumme lesen konnte, oder das Betriebssystem von einem externen Speichermedium. Pseudocode für den Bootloader kann so einfach sein wie die folgenden acht Anweisungen:

  1. Setzen Sie das P-Register auf 9
  2. Überprüfen Sie, ob der Papierstreifenleser bereit ist
  3. Wenn nicht bereit, springen Sie zu 2
  4. Lesen Sie ein Byte vom Papierbandleser zum Akkumulator
  5. Akkumulator auf Adresse im P-Register speichern
  6. Bei Bandende zu 9 . springen
  7. Erhöhen Sie das P-Register
  8. Springe zu 2

Ein verwandtes Beispiel basiert auf einem Lader für einen Minicomputer der Nicolet Instrument Corporation aus den 1970er Jahren, der die Papierstreifenlese-Stanzeinheit auf einem Teletype Model 33 ASR Fernschreiber verwendet . Die Bytes seines Laders der zweiten Stufe werden in umgekehrter Reihenfolge vom Papierband gelesen.

  1. Setzen Sie das P-Register auf 106
  2. Überprüfen Sie, ob der Papierstreifenleser bereit ist
  3. Wenn nicht bereit, springen Sie zu 2
  4. Lesen Sie ein Byte vom Papierbandleser zum Akkumulator
  5. Akkumulator auf Adresse im P-Register speichern
  6. Dekrementiere das P-Register
  7. Springe zu 2

Die Länge des Laders der zweiten Stufe ist derart, dass das letzte Byte die Stelle 7 überschreibt. Nachdem der Befehl an der Stelle 6 ausgeführt wurde, startet die Stelle 7 die Ausführung des Laders der zweiten Stufe. Der Lader der zweiten Stufe wartet dann darauf, dass das viel längere Band, das das Betriebssystem enthält, in den Bandleser eingelegt wird. Der Unterschied zwischen dem Bootloader und dem Second Stage Loader besteht darin, dass ein Prüfcode hinzugefügt wird, um Lesefehler auf Papierbändern abzufangen, ein häufiges Auftreten bei relativ kostengünstiger "Teilzeit"-Hardware, wie dem Teletype Model 33 ASR. (Friden Flexowriters waren weitaus zuverlässiger, aber auch vergleichsweise teuer.)

Booten der ersten Mikrocomputer

Die frühesten Mikrocomputer, wie der Altair 8800 (erstmals 1975 veröffentlicht) und eine noch frühere, ähnliche Maschine (basierend auf der Intel 8008 CPU) hatten keine Bootstrapping-Hardware als solche. Beim Start sah die CPU Speicher, der ausführbaren Code enthielt, der nur binäre Nullen enthielt – der Speicher wurde beim Hochfahren durch Zurücksetzen gelöscht. Die Frontplatten dieser Maschinen trugen Kippschalter zur Eingabe von Adressen und Daten, einen Schalter pro Bit des Computerspeicherworts und des Adressbusses. Einfache Erweiterungen der Hardware ermöglichten es, jeweils eine Speicherstelle von diesen Schaltern zu laden, um Bootstrap-Code zu speichern. Währenddessen wurde die CPU daran gehindert, Speicherinhalt auszuführen. Nach dem korrekten Laden wurde die CPU aktiviert, um den Bootstrapping-Code auszuführen. Dieser Prozess war mühsam und musste fehlerfrei sein.

Ära des Nur-Lese-Speichers der integrierten Schaltung

Ein Intel 2708 EPROM "Chip" auf einer Platine.

Der Boot-Prozess für Minicomputer und Mikrocomputer wurde durch die Einführung des integrierten Festwertspeichers (ROM) mit seinen vielen Varianten, darunter maskenprogrammierte ROMs , programmierbare ROMs (PROM), löschbare programmierbare ROMs (EPROM) und Flash-Speicher, revolutioniert . Diese ermöglichten es, Firmware- Boot-Programme als Teil des Computers zu integrieren. Die Einführung eines (externen) ROM wurde in einem italienischen Telefonvermittlungshersteller namens "Gruppi Speciali" 1975 von Alberto Ciaramella , einem Forscher am CSELT , patentiert . Gruppi Speciali war ab 1975 eine vollständig Ein-Knopf-Maschine, die von einem ROM-Speicher aus Halbleitern, nicht aus Ferritkernen, in das Betriebssystem bootete. Obwohl das ROM-Gerät aufgrund des Maschinendesigns nicht nativ in den Computer von Gruppi Speciali eingebettet war, erlaubte es auch das Ein-Knopf-ROM-Booten in Maschinen, die nicht dafür ausgelegt waren (daher war dieses "Bootstrap-Gerät" architekturunabhängig ), zB die PDP-11. Die Speicherung des Zustands der Maschine nach dem Ausschalten war ebenfalls vorhanden, was ein weiteres wichtiges Merkmal im Telefonumschaltwettbewerb war.

Normalerweise führt jeder Mikroprozessor nach einem Reset- oder Einschaltzustand einen Startvorgang durch, der normalerweise die Form "Ausführung des gefundenen Codes beginnend an einer bestimmten Adresse" oder "Suchen nach einem Multibyte-Code bei eine bestimmte Adresse eingeben und zum angegebenen Ort springen, um mit der Ausführung zu beginnen". Ein unter Verwendung dieses Mikroprozessors aufgebautes System weist das permanente ROM auf, das diese speziellen Stellen einnimmt, so dass das System immer ohne Bedienerunterstützung zu arbeiten beginnt. Intel x86- Prozessoren beginnen beispielsweise immer mit der Ausführung der Anweisungen beginnend bei F000:FFF0, während für den MOS 6502- Prozessor die Initialisierung mit dem Lesen einer Zwei-Byte-Vektoradresse bei $FFFD (MS-Byte) und $FFFC (LS-Byte) beginnt und zu diesem Ort springen, um den Bootstrap-Code auszuführen.

Der erste Computer von Apple Inc. , der 1976 eingeführte Apple 1 , verfügte über PROM-Chips, die die Notwendigkeit einer Frontplatte für den Startvorgang (wie beim Altair 8800) in einem kommerziellen Computer überflüssig machten. Laut Apples Anzeige "Keine Schalter mehr, keine Lichter ... die Firmware in PROMS ermöglicht es Ihnen, Programme (alle in Hex) über die Tastatur einzugeben, anzuzeigen und zu debuggen."

Aufgrund der damaligen Kosten für Nur-Lese-Speicher bootete die Apple II-Serie ihre Festplatten-Betriebssysteme mit einer Reihe von sehr kleinen inkrementellen Schritten, von denen jeder die Kontrolle an die nächste Phase des allmählich komplexer werdenden Boot-Prozesses übergab. (Siehe Apple DOS: Bootloader ). Da das Festplattenbetriebssystem so wenig auf ROM angewiesen war, war die Hardware auch äußerst flexibel und unterstützte eine Vielzahl von benutzerdefinierten Kopierschutzmechanismen . (Siehe Software-Cracking: Verlauf .)

Einige Betriebssysteme, vor allem Macintosh- Systeme vor 1995 von Apple , sind so eng mit ihrer Hardware verwoben, dass es unmöglich ist, ein anderes Betriebssystem als das Standard-Betriebssystem nativ zu booten. Dies ist das entgegengesetzte Extrem des oben erwähnten Szenarios mit Schaltern; es ist sehr unflexibel, aber relativ fehler- und narrensicher, solange die gesamte Hardware normal funktioniert. Eine übliche Lösung in solchen Situationen besteht darin, einen Bootloader zu entwerfen, der als Programm des Standardbetriebssystems funktioniert, das das System entführt und das alternative Betriebssystem lädt. Diese Technik wurde von Apple für seine A/UX Unix-Implementierung verwendet und von verschiedenen Freeware-Betriebssystemen und BeOS Personal Edition 5 kopiert .

Einige Maschinen, wie der Atari ST- Mikrocomputer , waren "instant-on", wobei das Betriebssystem von einem ROM ausgeführt wurde . Das Abrufen des Betriebssystems aus dem sekundären oder tertiären Speicher wurde daher als eine der charakteristischen Operationen für das Bootstrapping eliminiert. Damit Systemanpassungen, Zubehör und andere Support-Software automatisch geladen werden können, wurde das Diskettenlaufwerk des Atari während des Bootvorgangs auf zusätzliche Komponenten ausgelesen. Es gab eine Zeitüberschreitungsverzögerung, die Zeit bot, um eine Diskette manuell einzulegen, während das System nach den zusätzlichen Komponenten suchte. Dies könnte durch das Einlegen einer leeren Diskette vermieden werden. Die Atari ST-Hardware wurde auch so konzipiert, dass der Cartridge-Slot eine native Programmausführung für Spielezwecke als Überbleibsel von Ataris Legacy-Herstellung elektronischer Spiele ermöglicht. durch Einsetzen der Spectre GCR- Cartridge mit dem Macintosh-System-ROM in den Spielschlitz und Einschalten des Atari konnte es das Macintosh-Betriebssystem "nativ booten" und nicht Ataris eigenes TOS .

Der IBM Personal Computer enthielt eine ROM-basierte Firmware namens BIOS ; Eine der Funktionen dieser Firmware bestand darin, beim Einschalten des Computers einen Einschalt-Selbsttest durchzuführen und dann die Software von einem Startgerät zu lesen und auszuführen. Mit dem BIOS auf dem IBM Personal Computer kompatible Firmware wird in IBM PC-kompatiblen Computern verwendet. Das UEFI wurde von Intel ursprünglich für Itanium- basierte Maschinen entwickelt und später auch als Alternative zum BIOS in x86- basierten Maschinen verwendet, darunter Apple Macs mit Intel-Prozessoren .

Unix-Workstations hatten ursprünglich herstellerspezifische ROM-basierte Firmware. Sun Microsystems entwickelte später OpenBoot , später bekannt als Open Firmware, das einen Forth- Interpreter enthielt , wobei ein Großteil der Firmware in Forth geschrieben wurde. Es wurde von der IEEE als IEEE-Standard 1275-1994 standardisiert; Firmware, die diesen Standard implementiert, wurde in PowerPC- basierten Macs und einigen anderen PowerPC-basierten Computern sowie in Suns eigenen SPARC- basierten Computern verwendet. Die Advanced RISC Computing- Spezifikation definierte einen weiteren Firmware-Standard, der auf einigen MIPS- basierten und Alpha- basierten Maschinen und den SGI Visual Workstation x86-basierten Workstations implementiert wurde .

Moderne Bootloader

Wenn ein Computer ausgeschaltet wird, bleibt seine Software – einschließlich Betriebssysteme, Anwendungscode und Daten‍ – im nichtflüchtigen Speicher gespeichert . Wenn der Computer eingeschaltet ist, verfügt er normalerweise nicht über ein Betriebssystem oder seinen Loader im Arbeitsspeicher (RAM). Der Computer führt zuerst ein relativ kleines Programm aus, das im Nur-Lese-Speicher (ROM und später EEPROM , NOR-Flash ) gespeichert ist, zusammen mit einigen benötigten Daten, um den RAM zu initialisieren (insbesondere auf x86-Systemen), um auf das nichtflüchtige Gerät zuzugreifen (normalerweise Blockgerät , zB NAND-Flash) oder Geräte, von denen die Betriebssystemprogramme und Daten in den Arbeitsspeicher geladen werden können.

Das kleine Programm, das diese Sequenz startet, wird als Bootstrap-Loader , Bootstrap oder Boot-Loader bezeichnet . Häufig werden mehrstufige Bootloader verwendet, bei denen mehrere Programme mit steigender Komplexität in einem Kettenladeprozess nacheinander geladen werden .

Einige frühere Computersysteme können beim Empfang eines Boot-Signals von einem menschlichen Bediener oder einem Peripheriegerät eine sehr kleine Anzahl fester Anweisungen an einer bestimmten Stelle in den Speicher laden, mindestens eine CPU initialisieren und dann die CPU auf die Anweisungen verweisen und ihre Ausführung beginnen. Diese Anweisungen starten typischerweise eine Eingabeoperation von einem Peripheriegerät (das durch den Bediener durch Schalter wählbar sein kann). Andere Systeme können Hardwarebefehle direkt an Peripheriegeräte oder E/A-Controller senden, die bewirken, dass eine extrem einfache Eingabeoperation (wie "Sektor Null des Systemgeräts in den Speicher beginnend bei Position 1000 einlesen") ausgeführt wird, wodurch effektiv eine kleine . geladen wird Anzahl von Bootloader-Anweisungen in den Speicher; ein Beendigungssignal vom E/A-Gerät kann dann verwendet werden, um die Ausführung der Befehle durch die CPU zu starten.

Kleinere Computer verwenden oft weniger flexible, aber mehr automatische Bootloader-Mechanismen, um sicherzustellen, dass der Computer schnell und mit einer vorgegebenen Softwarekonfiguration startet. In vielen Desktop - Computern, zum Beispiel, beginnt der Bootstrap - Prozess mit der CPU Ausführung von Software in ROM enthalten (zum Beispiel das BIOS eines IBM PC ) an eine vordefinierte Adresse (einige CPUs, einschließlich der Intel x86 - Serie sind so konzipiert , um diese Software auszuführen nach Reset ohne fremde Hilfe). Diese Software enthält rudimentäre Funktionen, um nach Geräten zu suchen, die am Booten teilnehmen können, und um ein kleines Programm aus einem speziellen Abschnitt (meistens dem Bootsektor ) des vielversprechendsten Geräts zu laden , normalerweise beginnend an einem festen Einstiegspunkt wie dem Start des Sektor.

Bootloader können besonderen Einschränkungen unterliegen, insbesondere in Bezug auf die Größe; auf IBM-PCs und kompatiblen Geräten muss der Boot-Code beispielsweise in den Master Boot Record (MBR) und den Partition Boot Record (PBR) passen , die wiederum auf einen einzelnen Sektor beschränkt sind; auf dem IBM System/360 ist die Größe durch das IPL-Medium begrenzt, zB Kartengröße , Spurgröße.

Auf Systemen mit diesen Einschränkungen ist das erste in den RAM geladene Programm möglicherweise nicht groß genug, um das Betriebssystem zu laden, und muss stattdessen ein anderes, größeres Programm laden. Das erste in den RAM geladene Programm wird als Bootloader der ersten Stufe bezeichnet, und das Programm, das es lädt, wird als Bootloader der zweiten Stufe bezeichnet.

Bootloader der ersten Stufe

Beispiele für Bootloader der ersten Stufe (ROM-Stufe oder Hardware-Initialisierungsstufe) sind BIOS , UEFI , coreboot , Libreboot und Das U-Boot . Auf dem IBM-PC wurde der Bootloader im Master Boot Record (MBR) und im Partition Boot Record (PBR) so codiert, dass er mindestens 32 KB (später auf 64 KB reduziert) Systemspeicher benötigt und nur Anweisungen verwendet, die vom Original unterstützt werden 8088 / 8086- Prozessoren.

Bootloader der zweiten Stufe

Bootloader der zweiten Stufe wie GNU GRUB , rEFInd , BOOTMGR , Syslinux , NTLDR oder iBoot sind selbst keine Betriebssysteme, können aber ein Betriebssystem richtig laden und die Ausführung darauf übertragen; das Betriebssystem initialisiert sich anschließend selbst und lädt möglicherweise zusätzliche Gerätetreiber . Der Bootloader der zweiten Stufe benötigt keine Treiber für seinen eigenen Betrieb, sondern kann stattdessen generische Speicherzugriffsmethoden verwenden, die von der Systemfirmware wie BIOS, UEFI oder Open Firmware bereitgestellt werden , jedoch normalerweise mit eingeschränkter Hardwarefunktionalität und geringerer Leistung.

Viele Bootloader (wie GNU GRUB, rEFInd, BOOTMGR von Windows, Syslinux und NTLDR von Windows NT/2000/XP) können so konfiguriert werden, dass sie dem Benutzer mehrere Auswahlmöglichkeiten beim Booten bieten. Diese Auswahlmöglichkeiten können verschiedene Betriebssysteme (für Dual- oder Multi-Boot von verschiedenen Partitionen oder Laufwerken), verschiedene Versionen desselben Betriebssystems (falls eine neue Version unerwartete Probleme hat), verschiedene Ladeoptionen des Betriebssystems (z Rescue oder abgesicherter Modus ) und einige eigenständige Programme, die ohne Betriebssystem funktionieren können, wie Speichertester (zB memtest86+ ), eine Basis-Shell (wie in GNU GRUB) oder sogar Spiele (siehe Liste der PC-Booter-Spiele ). Einige Bootloader können auch andere Bootloader laden; GRUB lädt beispielsweise BOOTMGR, anstatt Windows direkt zu laden. Normalerweise wird eine Standardauswahl mit einer Zeitverzögerung vorausgewählt, während der ein Benutzer eine Taste drücken kann, um die Auswahl zu ändern; Nach dieser Verzögerung wird die Standardauswahl automatisch ausgeführt, sodass ein normaler Bootvorgang ohne Interaktion erfolgen kann.

Der Bootvorgang kann als abgeschlossen betrachtet werden, wenn der Computer bereit ist, mit dem Benutzer zu interagieren, oder das Betriebssystem in der Lage ist, Systemprogramme oder Anwendungsprogramme auszuführen.

Viele eingebettete Systeme müssen sofort booten. Eine Minute zu warten, bis ein digitales Fernsehen oder ein GPS-Navigationsgerät gestartet wird, ist im Allgemeinen nicht akzeptabel. Daher verfügen solche Geräte über Softwaresysteme im ROM oder Flash-Speicher, so dass das Gerät sofort mit dem Betrieb beginnen kann; Es ist nur wenig oder kein Laden erforderlich, da das Laden im Voraus berechnet und auf dem ROM gespeichert werden kann, wenn das Gerät hergestellt wird.

Große und komplexe Systeme können Bootprozeduren haben, die in mehreren Phasen ablaufen, bis schließlich das Betriebssystem und andere Programme geladen und zur Ausführung bereit sind. Da Betriebssysteme so konzipiert sind, dass sie niemals starten oder stoppen, kann ein Bootloader das Betriebssystem laden, sich selbst als reinen Prozess innerhalb dieses Systems konfigurieren und dann die Kontrolle unwiderruflich an das Betriebssystem übertragen. Der Bootloader wird dann wie jeder andere Prozess normal beendet.

Netzwerk-Booten

Die meisten Computer können auch über ein Computernetzwerk booten . In diesem Szenario wird das Betriebssystem auf der Festplatte eines Servers gespeichert und bestimmte Teile davon werden mit einem einfachen Protokoll wie dem Trivial File Transfer Protocol (TFTP) an den Client übertragen . Nach der Übertragung dieser Teile übernimmt das Betriebssystem die Steuerung des Bootvorgangs.

Wie beim Bootloader der zweiten Stufe beginnt der Netzwerkstart mit generischen Netzwerkzugriffsmethoden, die vom Boot-ROM der Netzwerkschnittstelle bereitgestellt werden, das normalerweise ein Preboot Execution Environment (PXE)-Image enthält. Es sind keine Treiber erforderlich, aber die Systemfunktionalität ist eingeschränkt, bis der Betriebssystemkernel und die Treiber übertragen und gestartet wurden. Als Ergebnis ist es nach Abschluss des ROM-basierten Bootens durchaus möglich, über das Netzwerk in ein Betriebssystem zu booten, das selbst nicht die Fähigkeit besitzt, die Netzwerkschnittstelle zu verwenden.

Personalcomputer (PC)

Boot-Geräte

Windows To Go bootfähiges Flash-Laufwerk, ein Live-USB- Beispiel

Das Bootgerät ist das Gerät, von dem das Betriebssystem geladen wird. Die UEFI- oder BIOS- Firmware eines modernen PCs unterstützt das Booten von verschiedenen Geräten, typischerweise einem lokalen Solid-State-Laufwerk oder einer Festplatte über den GPT oder Master Boot Record (MBR) auf einem solchen Laufwerk oder einer solchen Festplatte, einem optischen Laufwerk (mit El Torito ), ein USB- Massenspeichergerät ( FTL- basiertes Flash-Laufwerk, SD-Karten- oder Multimedia-Kartensteckplatz , USB-Festplattenlaufwerk, optisches USB-Laufwerk usw.) oder eine Netzwerkkarte (mit PXE ). Ältere, weniger verbreitete BIOS-bootfähige Geräte umfassen Diskettenlaufwerke , Zip-Laufwerke und LS-120- Laufwerke.

Normalerweise ermöglicht die Firmware (UEFI oder BIOS) dem Benutzer, eine Bootreihenfolge zu konfigurieren . Wenn die Bootreihenfolge auf "erstens das DVD-Laufwerk; zweitens das Festplattenlaufwerk" eingestellt ist, wird die Firmware versuchen, vom DVD-Laufwerk zu booten, und wenn dies fehlschlägt (z. B. weil sich keine DVD im Laufwerk befindet), Es wird versuchen, von der lokalen Festplatte zu booten.

Auf einem PC, auf dem Windows auf der Festplatte installiert ist, könnte der Benutzer beispielsweise die Bootreihenfolge auf die oben angegebene einstellen und dann eine Linux- Live-CD einlegen , um Linux auszuprobieren, ohne ein Betriebssystem auf der Festplatte installieren zu müssen Fahrt. Dies ist ein Beispiel für Dual-Booting , bei dem der Benutzer auswählt, welches Betriebssystem gestartet werden soll, nachdem der Computer seinen Power-on-Self-Test (POST) durchgeführt hat. In diesem Beispiel des dualen Bootens wählt der Benutzer aus, indem er die DVD in den Computer einlegt oder herausnimmt, aber es ist üblicher, das zu bootende Betriebssystem auszuwählen, indem er aus einem Boot-Manager- Menü auf dem ausgewählten Gerät auswählt, indem er die Computertastatur verwendet, um Wählen Sie aus einem BIOS- oder UEFI- Boot-Menü oder beidem aus; das Boot-Menü wird normalerweise durch Drücken der Tasten F8oder F12während des POST aufgerufen; Das BIOS-Setup wird normalerweise durch Drücken der Tasten F2oder DELwährend des POST aufgerufen.

Es stehen mehrere Geräte zur Verfügung, die es dem Benutzer ermöglichen, schnell in eine Linux-Variante für verschiedene einfache Aufgaben wie den Internetzugang zu booten ; Beispiele sind Splashtop und Latitude ON .

Startvorgang

Ein Hex - Dump von FreeBSD ‚s boot0 MBR
Auszeichnung Software- BIOS von 2000 beim Booten

Beim Starten, einem IBM-kompatiblen Personal Computers x86 CPU führt in Real - Mode , der Befehl an sich Reset - Vektor (der physikalische Speicheradresse FFFF0h auf 16-Bit - x86 - Prozessoren und FFFFFFF0h auf 32-Bit- und 64-Bit x86 - Prozessoren), in der Regel zeigt auf den Einstiegspunkt der Firmware ( UEFI oder BIOS ) im ROM. Dieser Speicherort enthält typischerweise einen Sprungbefehl, der die Ausführung an den Ort des Firmware- Startprogramms ( UEFI oder BIOS ) überträgt . Dieses Programm führt einen Einschalt-Selbsttest (POST) durch, um erforderliche Geräte wie den Hauptspeicher ( DRAM ), den PCI-Bus und die PCI-Geräte (einschließlich der Ausführung von eingebetteten Options-ROMs ) zu überprüfen und zu initialisieren . Einer der aufwendigsten Schritte ist das Einrichten von DRAM über SPD , was durch die Tatsache, dass der Speicher zu diesem Zeitpunkt sehr begrenzt ist, noch komplizierter wird.

Nach der Initialisierung der erforderlichen Hardware durchläuft die Firmware ( UEFI oder BIOS ) eine vorkonfigurierte Liste nichtflüchtiger Speichergeräte ("Boot-Gerätesequenz"), bis sie ein bootfähiges Gerät findet. Eine bootfähiges MBR Vorrichtung ist definiert als eine , die aus gelesen werden kann, und wo die letzten beiden Bytes des ersten Sektors , die enthalten little-endian Wort AA55h als Bytesequenz gefunden 55h , AAh auf Festplatte (auch bekannt als die MBR - Boot - Signatur ) , oder wo anderweitig festgestellt wird, dass der Code innerhalb des Sektors auf x86-PCs ausführbar ist.

Sobald das BIOS ein bootfähiges Gerät gefunden hat, lädt es den Bootsektor auf die lineare Adresse 7C00h (normalerweise segment : offset 0000h : 7C00h , aber einige BIOSes verwenden fälschlicherweise 07C0h : 0000h ) und überträgt die Ausführung an den Bootcode. Bei einer Festplatte wird dies als Master Boot Record (MBR) bezeichnet. Der herkömmliche MBR-Code überprüft die Partitionstabelle des MBR auf eine Partition, die als bootfähig gesetzt ist (diejenige mit aktivem Flag gesetzt). Wenn eine aktive Partition gefunden wird, lädt der MBR-Code den Bootsektorcode von dieser Partition, bekannt als Volume Boot Record (VBR), und führt ihn aus. Der MBR-Bootcode ist oft betriebssystemspezifisch.

Der Bootsektorcode ist der Bootloader der ersten Stufe. Es befindet sich auf Festplatten und Wechseldatenträgern und muss in die ersten 446 Byte des Master Boot Record passen , um Platz für die standardmäßige 64-Byte- Partitionstabelle mit vier Partitionseinträgen und der 2-Byte- Boot-Signatur zu lassen , die die Das BIOS erfordert einen richtigen Bootloader – oder noch weniger, wenn zusätzliche Funktionen wie mehr als vier Partitionseinträge (bis zu 16 mit jeweils 16 Byte), eine Festplattensignatur (6 Byte), ein Festplattenzeitstempel (6 Byte), ein Advanced Active In manchen Umgebungen müssen auch Partitionen (18 Byte) oder spezielle Multi-Bootloader unterstützt werden. Bei Disketten- und Superfloppy- Volume-Boot-Records werden für den Extended BIOS Parameter Block auf FAT12- und FAT16- Volumes seit DOS 4.0 bis zu 59 Byte belegt , während der mit DOS 7.1 eingeführte FAT32- EBPB sogar 87 Byte benötigt, so dass nur 423 Byte für den Bootloader übrig bleiben wenn eine Sektorgröße von 512 Byte angenommen wird. Microsoft-Bootsektoren legten daher traditionell gewisse Einschränkungen für den Boot-Vorgang fest, zum Beispiel musste die Boot-Datei an einer festen Position im Root-Verzeichnis des Dateisystems liegen und als aufeinanderfolgende Sektoren gespeichert werden, Bedingungen wurden durch den SYSBefehl und geringfügig in späteren Versionen von DOS entspannt. Der Bootloader war dann in der Lage, die ersten drei Sektoren der Datei in den Speicher zu laden, der zufällig einen weiteren eingebetteten Bootloader enthielt, der den Rest der Datei in den Speicher laden konnte. Als Microsoft LBA- und FAT32-Unterstützung hinzufügte , wechselten sie aus Größengründen sogar zu einem Bootloader, der über zwei physische Sektoren reicht und 386-Anweisungen verwendet. Gleichzeitig gelang es anderen Herstellern, viel mehr Funktionalität in einen einzigen Boot-Sektor zu packen, ohne die ursprünglichen Beschränkungen auf nur minimalen verfügbaren Speicher (32 KB) und Prozessorunterstützung (8088/8086) zu lockern. DR-DOS-Bootsektoren sind beispielsweise in der Lage, die Bootdatei im Dateisystem FAT12, FAT16 und FAT32 zu finden und als Ganzes über CHS oder LBA in den Speicher zu laden , auch wenn die Datei nicht an einem festen Ort gespeichert ist und in aufeinanderfolgenden Sektoren.

Der VBR ist oft betriebssystemspezifisch; seine Hauptfunktion besteht jedoch darin, die Bootloader-Datei des Betriebssystems (wie bootmgroder ntldr), die der Bootloader der zweiten Stufe ist, von einer aktiven Partition zu laden und auszuführen . Dann lädt der Bootloader den Betriebssystemkernel vom Speichergerät.

Wenn keine aktive Partition vorhanden ist oder der Bootsektor der aktiven Partition ungültig ist, lädt der MBR möglicherweise einen sekundären Bootloader, der eine Partition auswählt (oft über Benutzereingaben) und ihren Bootsektor lädt, der normalerweise den entsprechenden Betriebssystemkernel lädt. In einigen Fällen versucht der MBR möglicherweise auch, sekundäre Bootloader zu laden, bevor er versucht, die aktive Partition zu booten. Wenn alles andere fehlschlägt, sollte es einen INT 18h BIOS-Interrupt-Aufruf ausgeben (gefolgt von einem INT 19h nur für den Fall, dass INT 18h zurückkehren würde), um die Kontrolle an das BIOS zurückzugeben, das dann versuchen würde, von anderen Geräten zu booten, versuchen Sie a Remote-Boot über das Netzwerk.

Die meisten modernen Systeme (neuere Apple Macs und neuere PCs ) verwenden UEFI .

Im Gegensatz zum BIOS verlässt sich UEFI (nicht Legacy-Boot über CSM) nicht auf Bootsektoren, das UEFI-System lädt den Bootloader ( EFI-Anwendungsdatei auf dem USB-Laufwerk oder in der EFI-Systempartition ) direkt und der Betriebssystemkernel wird vom Bootloader geladen .

Andere Arten von Bootsequenzen

Ein entsperrter Bootloader eines Android- Geräts, der zusätzliche verfügbare Optionen anzeigt

Einige moderne CPUs und Mikrocontroller (z. B. TI OMAP ) oder manchmal sogar DSPs haben möglicherweise ein Boot-ROM mit direkt in ihr Silizium integriertem Boot-Code, sodass ein solcher Prozessor selbst eine ziemlich ausgeklügelte Boot-Sequenz ausführen und Boot-Programme aus verschiedenen Quellen laden könnte wie NAND-Flash, SD- oder MMC-Karte und so weiter. Es ist schwierig, die gesamte erforderliche Logik für die Handhabung solcher Geräte fest zu verdrahten, daher wird in solchen Szenarien stattdessen ein integriertes Boot-ROM verwendet. Die Boot-ROM-Nutzung ermöglicht flexiblere Boot-Sequenzen, als dies mit festverdrahteter Logik möglich wäre. Beispielsweise könnte das Boot-ROM versuchen, von mehreren Bootquellen aus zu booten. Außerdem ist ein Boot-ROM oft in der Lage, über serielle Schnittstellen wie UART , SPI , USB usw. einen Bootloader oder ein Diagnoseprogramm zu laden . Diese Funktion wird oft für Systemwiederherstellungszwecke verwendet, wenn aus irgendeinem Grund die übliche Boot-Software im nichtflüchtigen Speicher gelöscht wurde, und sie kann auch für die anfängliche Programmierung des nichtflüchtigen Speichers verwendet werden, wenn sauberer nichtflüchtiger Speicher installiert ist und daher keine Software noch im System vorhanden.

Einige eingebettete Systemdesigns können auch einen zwischengeschalteten Bootsequenzschritt in Form von zusätzlichem Code umfassen, der vom integrierten Boot-ROM in den System- RAM geladen wird . Zusätzlicher Code, der auf diese Weise geladen wird, dient normalerweise dazu, Plattformbeschränkungen wie kleine Mengen an RAM zu überwinden, sodass ein dedizierter primärer Bootloader wie Das U-Boot als nächster Schritt in der Bootsequenz des Systems geladen werden kann. Der zusätzliche Code- und Bootsequenzschritt werden normalerweise als sekundärer Programmlader (SPL) bezeichnet.

Es ist auch möglich, die Kontrolle über ein System zu übernehmen, indem eine Hardware-Debug-Schnittstelle wie JTAG verwendet wird . Eine solche Schnittstelle kann verwendet werden, um das Boot-Loader-Programm in einen bootfähigen nichtflüchtigen Speicher (zB Flash) zu schreiben, indem der Prozessorkern angewiesen wird, die notwendigen Aktionen zum Programmieren des nichtflüchtigen Speichers durchzuführen. Alternativ kann die Debug-Schnittstelle verwendet werden, um einen Diagnose- oder Boot-Code in den RAM hochzuladen und dann den Prozessorkern zu starten und ihn anzuweisen, den hochgeladenen Code auszuführen. Dies ermöglicht beispielsweise die Wiederherstellung von eingebetteten Systemen, bei denen keine Software auf einem unterstützten Bootgerät verbleibt und bei denen der Prozessor kein integriertes Boot-ROM hat. JTAG ist eine standardmäßige und beliebte Schnittstelle; viele CPUs, Mikrocontroller und andere Geräte werden mit JTAG-Schnittstellen hergestellt (Stand 2009).

Einige Mikrocontroller bieten spezielle Hardware-Schnittstellen, die nicht verwendet werden können, um eine beliebige Kontrolle über ein System zu übernehmen oder Code direkt auszuführen, sondern sie ermöglichen das Einfügen von Boot-Code in einen bootfähigen nichtflüchtigen Speicher (wie Flash-Speicher) über einfache Protokolle. In der Herstellungsphase werden solche Schnittstellen dann verwendet, um Bootcode (und möglicherweise anderen Code) in den nichtflüchtigen Speicher einzuschleusen. Nach dem Zurücksetzen des Systems beginnt der Mikrocontroller mit der Ausführung von Code, der in seinen nichtflüchtigen Speicher programmiert wurde, genau wie normale Prozessoren ROMs zum Booten verwenden. Vor allem wird diese Technik von Atmel AVR- Mikrocontrollern und auch von anderen verwendet. In vielen Fällen werden solche Schnittstellen durch festverdrahtete Logik implementiert. In anderen Fällen könnten solche Schnittstellen durch Software erzeugt werden, die im integrierten On-Chip-Boot-ROM von GPIO- Pins ausgeführt wird.

Die meisten digitalen Signalprozessoren verfügen über einen Boot im seriellen Modus und einen Boot im parallelen Modus, z. B. die Host-Port-Schnittstelle (HPI-Boot).

Bei DSPs ist oft ein zweiter Mikroprozessor oder Mikrocontroller im Systemdesign vorhanden, der für das Gesamtsystemverhalten, die Interrupt-Behandlung, den Umgang mit externen Ereignissen, die Benutzeroberfläche usw. verantwortlich ist, während der DSP nur für Signalverarbeitungsaufgaben zuständig ist . In solchen Systemen könnte der DSP von einem anderen Prozessor gebootet werden, der manchmal als Host-Prozessor bezeichnet wird (der einem Host-Port einen Namen gibt). Ein solcher Prozessor wird manchmal auch als Master bezeichnet , da er normalerweise zuerst von seinen eigenen Speichern bootet und dann das Gesamtsystemverhalten steuert, einschließlich des Bootens des DSP, und dann das Verhalten des DSP weiter steuert. Dem DSP fehlen oft seine eigenen Boot-Speicher und er verlässt sich darauf, dass der Host-Prozessor stattdessen den erforderlichen Code liefert. Die bemerkenswertesten Systeme mit einem solchen Design sind Mobiltelefone, Modems, Audio- und Videoplayer usw., bei denen ein DSP und eine CPU/ein Mikrocontroller nebeneinander existieren.

Viele FPGA- Chips laden ihre Konfiguration beim Einschalten von einem externen seriellen EEPROM ("Konfigurations-ROM").

Siehe auch

Anmerkungen

Verweise