BIOS

Achtung dieser Artikel ist noch in Arbeit und dient vorläufig nur als Vorlage. Dieser Beitrag zu Linux oder der Abschnitt ist in Bearbeitung. Weitere Informationen findest du hier. Der Ersteller arbeitet an dem Beitrag oder Abschnitt und entsorgt den Wartungsbaustein spätestens 3 Tage nach der letzten Bearbeitung. Änderungen außer Rechtschreibkorrekturen ohne Absprache mit dem Urspungsautor sind möglichst zu vermeiden, solange dieser Baustein noch innerhalb der genannten Frist aktiviert ist.

BIOS

Das BIOS (Basic Input/Output System) ist die Firmware bei x86-basierenden Rechnern und somit ein zentraler und wichtiger Baustein auf jedem PC. Es ist in einem nichtflüchtigen Speicher auf der Hauptplatine abgelegt und wird unmittelbar nach dessen Einschalten ausgeführt. Aufgabe des BIOS ist es unter anderem, den PC zunächst funktionsfähig zu machen und im Anschluss das Starten eines Betriebssystems einzuleiten. Das Prinzip der Arbeitsweise ist seit seiner Einführung von Intel Anfang der 80er Jahre gleich geblieben, jedoch wurde es im Laufe der Zeit immer und immer wieder an Erfordernisse der Hardwareentwicklung angepasst.
Seit den 90er Jahren gab es eine Reihe von Innovationen, Bestrebungen und Entwicklungen um einen Nachfolger für das BIOS zu finden. Eine breite Markteinführung hat sich allerdings nicht zuletzt aufgrund des Widerstands der Hardware-Hersteller lange Zeit als sehr schwierig erwiesen.

Ein Blick zurück

Die Vorläufer unserer heutigen Computer hatten in den Anfängen in den 60er Jahren des vorigen Jahrhunderts ein Problem. Die Software, also der auszuführende Programmcode, musste an die Hardware angepasst werden. Betroffen davon waren alle hardwarespezifischen Teile z.B. die Ansteuerung der Eingabe- und Ausgabegeräte. Die jeweilige Software musste diese Geräte und deren genaue Adressierung innerhalb eines Computer genau kennen, um sie nutzen zu können. Sobald sich dort etwas an der Hardware verändert hat, mussten somit immer Teile der Software angepasst werden.
In den 70er Jahren dann wurde erstmals mit CP/M (Control Program for Microprocessors) eine Hardwareabstraktionsschicht eingeführt, welche eine Trennung der Hardware und der Software darstellte. Hier taucht der Name BIOS das erste mal auf, aber damals war es noch ein Teil des Betriebssystems, welcher erst mittels eines einfachen Bootloaders aus einem ROM mittels Floppy gebootet werden musste. Das BIOS beinhaltete die hardwarenahen Teile des Betriebssytems und der Rest des Betriebsystem konnte über die definierten Schnittstellen des BIOS auf die Hardware zugreifen. Änderungen an der Hardware mussten folglich nur noch im BIOS-Teil berücksichtig werden. Die Anfangs nur gedankliche Trennung dieser beiden Softwareteile wurden später auch wirklich isoliert, so das CP/M aus zwei übereinanderliegenden Schichten bestand, dem hardwarespezifischen BIOS Teil und dem darauf aufbauenden, aber vollständig hardwareunabhängigen BDOS (Basic Disk Operating System).

Dieses BIOS Konzept wurde in den frühen 80er Jahren im IBM PC aufgegriffen und weiter entwickelt und jetzt in einem separatem Festspeicher auf dem Systemboard abgelegt. Damit war eine auch Herstellerunabhängige standardisierte Schnittstelle zwischen Hardware und Betriebssystem gegeben, und ob nun von IBM gewollt oder nicht, mit dafür verantworllich, dass der IBM-PC schnell zum einem inoffiziellen Industriestandard wurde, und alles was sich nicht IBM-PC kompatibel ausgab schlichtweg auf dem PC-Markt kaum verkäuflich war. Die 100%ige Funktionalität und Leistungsfähigkeit der fest definierten Funktionen des jeweiligen BIOS über die das Betriebssystem auf die Hardware zugriffen, war mehr oder weniger ausschlaggebend ob eine Hardware IBM-kompatibel war oder nicht.

Was Anfangs revolutionär und vollkommen ausreichend für die damalige Software war, konnte der rasanten Hardwareentwicklung und Softwareentwicklung nicht lange genügen. Die aus heutiger Sicht primitiven Schnittstellen des BIOS zur Hardware konnten neuartige HW oft nur im primitivsten Modus betreiben, es kamen und gingen verschiedene System- und Erweiterungsbusse, neuartige Hardwareerweiterungskarten (zB Soundkarten) und andere Hardware (z.B. Mouse, Netzwerkkarten), an die bei der "BIOS Erfindung" überhaupt noch nicht zu denken war, die CPUs haben sich rasant entwickelt und Hauptspeicher und Massenspeicher wurde immer größer und billiger. Es war bald notwendig für die Betriebssysteme eigene Treiber für die Hardwarekomponenten zu erfinden, mit deren Hilfe das Betriebssystem nach dem Start wieder die volle Kontrolle über die Hardwarekomponenten selbst übernimmt und so erst die volle Leistung der Hardware nutzen kann.
Was aber bis heute geblieben ist, im frühen Bootprozess ist man immer noch auf diese einfachen Schnittstellen angewiesen, nur über diese vom BIOS bereitgestellten Schnittstellen können die ersten Zeichen auf den Bildschirm geschrieben werden, die ersten Tastenanschläge von der Tastatur entgegengenommen werden und nur über diese Schnittstellen können die ersten Dateien für das Betriebssystems von Platte geladen werden.

Auch sonst musste in fast 35 Jahren im BIOS viel umgebaut und erweitert werden. Die Entwicklung brachte eine ganze Reihe von BUS-Systemen hervor, das BIOS musste lernen mit USB und vielen anderen Neuerungen umzugehen, neue CPUs und Speicher brachten immer wieder neue Chipsätze und Konzepte mit auf das Systemboards, es kamen und gingen eine Menge externer Massenspeicher, die Platten von denen gebootet werden sollte wurden immer größer und die für die Adressierierung dafür vorgesehenen Zahlenbereiche im BIOS wurden mehrmals zu klein, und und und. Das heutige BIOS als solches ist im Laufe der Zeit durch immer mehr Erweitungen und Modifikationen zur Flickschusterei verkommen. Das BIOS ist heute technologisch veraltet und hat hat sich seinen Ruhestand redlich verdient.

Vielleicht werden wir uns jedoch in ein paar Jahren zurücksehnen nach diesem BIOS, das all die vielen Jahre zuverlässig seine Hauptaufgaben von uns völlig unbemerkt nach dem Einschalten erledigt hat. Eventuell werden wir die 1000 Funktionen und Einstellungen vermissen, die uns dieses simple BIOS gar nicht zur Verfügung stellen konnte.

Der BIOS-Chip

Das BIOS ist in einem nichtflüchtigen Speicher abgelegt, der sich in einem speziellem Chip auf dem Systemboard befindet. In früheren Zeiten war dies ein PROM (nur einmalig bei der Herstellung beschreibbar) EPROM (nach Löschung mittels UV-Licht wiederbeschreibbar oder EEPROM (elektrich löschbar und wiederbeschreibbar). Meist war dieser ein gut indentifizierbarer Chip auf dem Systemboard und oft auch in einem Sockel verbaut, damit er zur Neuprogrammierung entfernt werden konnte. Heute benutzt man Flash-EEPROMS in den verschiedensten Bauformen, oft unscheinbare Chips (zB. PLCC-32, PDIP-8, SOIC-8, TSOP-40) die entweder gelötet oder bei PLCC auch gesteckt sein könnten. In den heutigen Systemboardbeschreibungen sucht man oftmals vergebens nach einem Hinweis wo er sich genau befindet.

Die BIOS Software

Im BIOS-Chip befindet sich von der CPU direkt ausführbarer Binär-Code. Große Teile sind wohl auch heute noch mittels Assembler geschrieben. Dieser BIOS-Code ist eine in sich abgeschlossenes Firmware. Es ist nicht möglich diese zu ändern oder zu erweitern, ohne dass diese gesamte Firmware neu zusammengebunden und neu in das BIOS respektive den Flash-Speicherchip geschrieben (=geflasht) wird. Jedes Systemboardmodell hat sein eingenes speziell und für diese Hardware abgestimmtes BIOS/ seine eigene speziell für diese Hardware abgestimmte Firmware. Zuständig dafür ist der Systemboard- oder Rechnerhersteller. Grob vereinfacht kann man sich das so vorstellen: Der Hardwarehersteller nutzt zum Erstellen seiner BIOS-Software spezielle Entwicklungsumgebungen (IDE) von BIOS-Herstellern. Darin enthalten sind komplette binäre BIOS-Core Elemente und viele viele HW-spezifische Module in Form eines großen Baukastens. Diese Module sind schon im ausführbaren Binärcode der jeweiligen CPU. Sie müssen aber untereinander durch Adressverlinkung zu den richtigen Speicheradressen zusammen gebunden werden und eine Vielzahl von Hardwareeinstellungen darin gemacht werden. Der Hardwarehersteller wählt anhand der auf dem SystemBoard vorhanden Hardware noch das eine oder andere Modul mehr oder weniger aus, passt sich das CMOS-Setupmenu und einiges andere an und macht ansonsten hauptsächlich die hardware- und herstellerspezifischen Einstellungen innerhalb der BIOS-IDE. Anschließend werden die Einstellungen durch die IDE mit den Modulcode verheiratet und so die BIOS-Firmware automatisch aus den Modulen und Einstellungen zusammengebaut und updatefertig verpackt, womit eine zum Updaten oder Bespielen von neuen BIOS-Chips fix und fertige BIOS-Version aus der IDE herauskommt. Zwar sind die Einstellungen und zB. Tunigmöglichkeiten vom Hardwarehersteller und das BIOS an die spezielle Hardware des Systemboard angepasst, aber die Gesamtstruktur und der eigentlich auführbare Code stammen vom BIOS-Hersteller. Muss am BIOS etwas geändert werden, dann muss die Prozedur wiederholt werden und die neue Firmware auf dieser IDE wieder neu zusammengebaut werden. Somit hat der Hardwarehersteller auch nur einen begrenzten Einfluss auf die internsten Bereiche der Firmware und ist mehr oder weniger immer von der Zu- und Zusammenarbeit des BIOS-Herstellers abhängig.

Beim Einschalten oder Reset des Rechners werden hardcodierte Einstellungen auf dem Systemboard aktiv, die eine CPU zwingen den Code im BIOS zu starten und abzuarbeiten. Dieser Code übernimmt von dort an die weitere Kontrolle und führt einen kontrollierten Start des Rechners aus. Dabei werden die Hardwarekomponenten des Rechners der Reihe nach resetet, voreingestellt, überprüft und die Zusammenarbeit zwischen den einzelnen Komponenten sichergestellt, und in einen funktionierenden definierten Zustand versetzt. Es werden so die Grafikkarte resettet und in den VGA Modus versetzt, die CPUs und Speicher überprüft und zB die Busfrequenzen anhand der verwendeten CPU und Speicher aufeinander abgestimmt, es wird nach einer Tastatur gesucht und initialisiert, es werden die verschiednen Schnittstellen auf dem Board eingestellt, nach internen und zusätzlichen PCI-Kontroller gescannt und diese der Reihe nach gestartet, gegenenfalls starten diese Kontroller daran angeschlossene Devices, wie zB Festplatten. usw. Dieser Gesamtprozess wird auch als POST (Power-on self-test) bezeichnet. Ganz zum Schluss wird in der Tabelle mit den vorgesehen Bootdevices das erste Device angesprochen und versucht davon einen Bootvorgang einzuleiten. Dieser gesamte Ablauf ist in Form von Binärcode im BIOS hinterlegt. Zusätzlich kann der Startvorgang vom User durch betätigen bestimmter Tasten noch ein CMOS-Setup oder ein Bootmenü verzweigt werden. Das Setup-Menü ist für den User der markant sichtbare Teil der BIOS-Software und wird desshalb gemeinhin als "das BIOS" bezeichnet, obwohl es nur ein winziger Bestandteil der gesamten Firmware ist. Die vorgenommen Einstellungen im CMOS-Setup werden in Form von Schalterstellungen und Werten in Bits und Bytes in einem kleinem CMOS-Speicher abgelegt, der von einer kleinen BIOS- oder CMOS-Baterie gestützt im stromlosen Zustand des Rechners die Daten solange behalten kann, wie diese Baterie noch genügend Spannung liefert.

Intern nutzt die BIOS-Software zur Kommunikation mit verschiedenen Geräten (zB. Bildschirm, Festplatten, Tastatur usw.) eine Reihe von ganz simplen Schnittstellen. Diese Schnittstellen sind fest definiert und seit Anfang des PC-BIOS bis heute die gleichen geblieben. Es sind einfache Softwareinterrupts die anhand von Daten in Prozessorregistern jeweils genau definierte Funktionen an der Hardware ausführen. Insgesamt sind 20 solcher BIOS interrupt calls dafür definiert. Die Meistbenutzten sind "INT 17h" für die Ausgabe von Zeichen auf Bildschirm (ursprünglich Drucker), "INT 16h" für die Tastaturansteurung, und "INT 13h" für die Ansteuerung von Disketten, Festplatten und ähnlichen. Diese 20 Interrupts Calls sind auch nach dem Begin des Bootens das einzige was das startendete Betriebssystem zu Beginn nutzen kann, um erstmal selbst in Gang zu kommen und genügend Treiber gestartet zu starten, um die Kontrolle über die Hardware selbst zu übernehmen. Minimalistische Betriebssysteme wie zB kleine von Floppy oder USB gestartete DOS Systeme kommen heute noch wie Anfang der 80 Jahre komplett mit diesen einfachen Schnitstellen zur Hardware aus.

Der gesamte Programmablauf im BIOS läuft bei jedem Start und Restart immer in der selben Weise, und wurde nur eine einzelne manuelle Einstellung im CMOS-Setup vorgenommen, muss der gesamte Rechner neu resetet werden und die gesamte POST Prozedur von vorne durchlaufen werden, damit die Einstellung wirksam wird. Die BIOS-Software an sich besteht mehr oder weniger aus Modulen die mitsamt von Voreinstellungen und Hardwarespezifischen Einstellungen fest und starr zusammen gebunden sind, vergleichbar etwa mit feststehender Verdrahtung. Anfangs wurde die komplette BIOS-Software direkt im BIOS-Chip abgearbeitet, später könnte nach der Initialsierung ab eines bestimmten Startpunktes das BIOS 1 zu 1 in den Speicher kopiert werden und von dort weiter abgearbeitet werden, was landläufig als Shadow-RAM Technik bezeichnet wird. Heute sind größere Teile des BIOS komprimiert, das heißt sie müssen erst in den Speicher ausgepackt werden, damit sie überhaupt lauffähig sind, wodurch der früher kleine Shadow-RAM Bereich zwangsläufig vergrößert wurde. In jedem Fall sind sie aber auch dort im Speicher starr und werden unverändert ausgeführt. Im Laufe der Zeit und nicht zuletzt durch die Entwicklung immer neuer Hardware hat sich das BIOS immer weiter entwickelt und musste vielfach aufwendig angepasste werden. Es gibt eine Hand voll BIOS-Hersteller, die bekanntesten sind AMI, Award und Phoenix, aber es gibt noch einige weitere auf dem Markt, selbst größere Rechnerhersteller wie Hewlett-Packard und Fujitsu entwickeln teilweise komplett eigene BIOS-Varianten. Jeder dieser Hersteller kocht ein bisschen sein eigenes Süppchen und von einem wirklichen Standard kann beim BIOS schon lange nicht mehr die Rede sein. Jeder schreibt seine eigenen Module und hat wohl intern programmiertechnisch seine eigenen Stardards gefunden. Jeder hat seine eigene Art und Weise wie die Software vergepackt und upgedated wird, und seine eigene Vorstellung und Standards wie die Menüs im Setup aussehen und was wie im Setup einzustellen geht. Gleich ist jedoch die prinzipielle Art und Weise sowie die Gesamtfunktion, der Bootvorgang, die BIOS Interrupts, also alles was man schlechthin seit Jahr und Tag als IBM-kompatibel beschreiben würde. Geblieben ist über all die Jahre stets, egal welche x68-Hardware, egal welcher BIOS Hersteller, egal welches x86-Betriebssytem, Alles arbeitet mit Allem zusammen.

BIOS Erweiterungen

Das BIOS hat im Laufe der Zeit eine Reihe interner Erweiterungen erhalten. SMBIOS ist eine davon. Mit seiner Hilfe ist zB das Betriebssystem in der Lage Informationen über die verbaute Hardware abzurufen. (unter Linux zB mittels dmidecode)
Diese Art Erweiterungen sollen hier aber nicht weiter erläutert werden.
Das BIOS unterstützt nur die Hardware die auf dem Systemboard verbaut ist. Sind jetzt zB weitere Storagecontroller verbaut, weitere SATA- oder SAS-Controller oder Raidcontroller, dann kann das BIOS nicht auf die Platten oder RAIDs dieser Controller zugreifen, er findet sie einfach nicht, da er im BIOS die entsprechenden Module und Hardware Einstellungen dafür nicht hat. Von diesen Controllern kann letztlich also erst einmal nicht gebootet werden. Erst wenn das Betriebssystem gestartet ist und die Treiber für diese Controller geladen sind, dann können auch diese Geräte an diesen Controllern angesprochen werden. Damit jedoch auch von diesen Geräten gebootet werden kann, müssen sich auf einem solchen Controllern ein sogenanntes BOOTBIOS befinden. Dieser bietet dann in BIOS-Manier genau die gleichen BIOS Interrupt Calls für die an diesem Controller befindelichen Devices an.
Wird vom BIOS ein solcher Kontroller gestartet, dann wird dieses BOOTBIOS erkannt und das BIOS ist dann in der Lage mit Hilfe der Interrupts die Devices an diesem Controller zu erkennen, womit dann auch ein Boot von diesen Geräten möglich wird. Diese Funktion kann im BIOS entweder global oder pro PCI-Steckplatz an- oder abgeschaltet werden da das BIOS in aller Regel nur eine gewisse Anzahl solcher zusätzlichen BOOTBIOSe vertragen kann.
In früheren Zeiten waren oft auf solchen Karten ebenfalls EPROMS verbaut, oftmals auch nur die Sockel dazu, so dass der EPROM bei Bedarf dort eingebaut werden konnte(sehr häufig zu sehen bei z.B. älteren Low-Budget SCSI-Controllerkarten der 53Cxxx Serie von NCR,spätere Versionen der 53cxxx Baureihe dann von SymbiosLogic erwarteten stattdessen den ehemals im EPROM befindlichen Code als optional im Rechner-BIOS vorhanden). Heute wo man leistungsfähige Flash-EEPROMS sowieso für die Firmware der Kontroller verwendet, sind diese BOOTBIOSe Bestandteile der Firmware und zT je nach genauer Firmware-Version entweder vorhanden oder eben nicht.

Das Gleiche wie für die Storagecontroller, gilt auch für die Netzwerkkarten. Egal ob LAN, SAN oder NAS, auch solche Controller benötigen für das Booten aus dem Netz ein BOOTBIOS. Diese funktionieren etwas anders da sie zum Einleiten des Bootvorgang über diese Karte die Netzwerkkarte erst an das Netz anmelden müssen und dann eine jeweils definierte Bootsequenz starten, aber nur wenn ein solches BOOTBIOS auf den Controllern oder in deren Firmware vorhanden sind, kann ein Boot von diesen Kontrollern erfolgen. Ist ein solcher Boot-BIOS nicht in der Firmware vorhanden, oder dieser PCI-Kartenslot im BIOS dafür nicht frei gegeben, kann diese Karte erst nach dem Laden eines entsprechenden Treibers vom Betriebssystem genutzt werden. Bei Ethernet ist wohl das Bekannteste das PXE-Boot-Bios.

Der Bootvorgang mit BIOS

Während des Starts oder Reset des Rechners werden vom BIOS die Geräte registriert die von den jeweiligen Controllern für als Bootdevices vorgesehen sind. zB Floppy-Laufwerke, CD-Rom, DVD, Festplatten, angeschlossene USB-Festplatten, usw. sowie die Netzwerkkarten welche einen Boot-BIOS besitzen. Diese Geräte werden in einer Liste abgelegt und diese gegebenenfalls entsprechend der im CMOS befindlichen Bootdevice-Tabelle sortiert. Beim Bootvorgang wird das oberste Bootdevice überprüft ob es bootfähig ist. Sollte dieses erste Device nicht bootfähig sein wird mit dem nächsten Eintrag in der Bootdevice-Tabelle weitergemacht. Solange bis auf ein Bootdevice gestoßen wird das bootfähig ist. Sollte keines bootfähig sein, erscheint die Meldung "Operating System not found". Alternativ kann manuell vom einem Bootmenu einer der Einträge in dieser Tabelle gestartet werden. Ist dieses Device nicht bootfähig wird von dieser Position aus die Tabelle weiter entsprechend versucht. Als Auswahlmöglichkeit für das Bootdevice stehen also im wesentlichen 2 Möglichkeiten, entweder die Reihenfolge in der Bootdevicetabelle im CMOS-Menu ändern, oder manuell im Bootmenü von einem Device booten.

Das BIOS hat nur sehr beschränkte Möglichekeiten mit Floppy, CD/DVD, Festplatten u.Ä. umzugehen, und es gibt für diese Devices nur eine einzige Möglichkeit wie das Betriebssystem gestart werden kann. Das BIOS kann selbst nur mittels des INT 13h ganze 512 Byte große Blöcke von diesen Devices lesen, kann die Partitionstabelle zwar interpretieren, aber kennt Partitionen nicht wirklich. Auch kennt das BIOS keine Dateisysteme und somit auch keine Dateien. Der Start von einem Blockdevice erfolgt immer in dem das BIOS den ersten Block dieses Devices ließt und auswertet. In diesem erstem Block (MBR=Masterbootrecord) befindet sich die Tabelle für die 4 primären Partitionen und die ersten 444 Byte sind für einen Bootloader reserviert. Dieser Bootloader ist typischer Weise mit Assembler programmiert, nicht nur wegen der sehr geringen Große von maximal 444 Byte Code, sondern auch da sich diese Art der Programmierung für die einfachen BIOS-Interrupt-Call Aufrufe, mit denen er über das BIOS mit der Hardware reden kann, am besten eignet, denn Assembler ist nichts anderes als eine mnemonische (=durch Ersatzzeichen verständlichere)Darstellung von direkter (rein binärer) Maschinensprache,der einzigen Sprache die der Hauptprozessor des Rechners direkt verarbeiten kann.
Das Bios sucht in diesen 444 Byte nach einem Hinweis dass es sich um einen ausführbaren binären Code handelt. Wenn ja wird dieser in den Speicher geladen und gestartet. Das Bios beendet damit seine bis dorthin sequentiell ablaufende Arbeit und reagiert nur noch auf die BIOS-Interrupt-Calls. Ist in den ersten 444 Byte des MBR kein offensichlicher Binärcode vorhanden, untersucht das BIOS noch die Partitionstabelle und sucht dort eine mit dem Bootflag gekennzeichnete Partition. Wird eine solche gefunden, dann wird die Blockadresse des ersten Blockes dieser Partition errechnet und dieser Block gelesen und genauso untersucht wie der MBR. Auch hier würde ein maximal 444 Byte großer Bereich der sich als ausführbarer Binärcode erkannt wird in den Speicher geladen und gestartet.

Stellt sich ein solcher Bootloader als fehlerhaft heraus, weil zB das Betriebssystem das dieser laden soll gelöscht worden ist, dann bleibt der Rechner an dieser Stelle hängen. Das BIOS hat seine Arbeit mit dem Start dieses Bootloaders eingestellt und reagiert nur noch auf die Interrupts, es kann also nicht das nächste Device in der Bootdevice Tabelle suchen und den Bootvorgang von dort aus starten. Der Rechner und damit das BIOS muss resettet werden um von einem anderem Device booten zu können. Es gibt also pro Device immer nur einen Bootloader der gestartet werden würde. Ist ein Bootcode im MBR dann wird dieser gestartet, ist im MBR für den BIOS nichts brauchbares affindbar, dann wird der Bootcode der Partition mit dem aktiven Bootflag gestartet. Es werden vom BIOS immer nur diese 444 Byte in den Speicher geladen und gestartet.

Für ein Betriebssytem und den Bootloader bedeutet dies, in diesen 444 Byte muss alles einprogrammiert sein, was für das Auffinden, Laden und Starten des Betriebssystemkernes benötigt wird, zB. die blockgenaue Position auf dem Device, die genaue Länge der Binärdaten und die genaue Startadresse dieses Betriebssystemkernes. Oder aber es muss die genannten Informationen von einem anderem Stück Binärcode haben, der dann auch größer als nur die 444Byte sein kann, der dannn in den Speicher geladen wird und seinerseits die Informationen hat um den Betriebssystemkern zu finden zu laden und zu starten. Es könnte auf diesem Wege also der Bootloader aus dem MBR einen anderen Bootloader laden und starten, und erst dieser Bootloader dann den Betriebssystemkern. Für alle Zugriffe zur Hardware stehen hierbei aber immer nur die BIOS-Interrupt-Calls zur Verfügung.

Es gibt verschiedene Möglichkeiten und Funtionsweisen wie Bootloader arbeiten. Die einfachsten laden einfach eine ihnen bekannte Anzahl von Byte in den Arbeitsspeicher und zwar von einer ihnen bekannten Blockadresse auf der Platte, und starten dann die Ausführung diesen Codes im Speicher ab einer ihnen bekannten Adresse.

Andere Bootloader laden zuerst weitere oder andere Codebereiche in den Speicher und starten diese. In diesen Binärcode könnten dann z.B. Code für das Erkennen und Lesen von Dateisystemen und Dateien enthalten sein. Damit kann dann der Betriebssystemkern mittels seines Namens im Dateisystem gefunden werden. Oder sie laden anstatt des Betriebssytemkerns zuerst ein Hilfssystem, dass seinerseits dann erstmal Konfigurationen und Dateien aus dem Dateisystem lesen kann und mit dessen Hilfe es dann möglich ist, unterschiedliche Betriebssysteme bzw. Einstellungen z.B. aus einem Menu heraus zu starten.

Beim Netzwerkboot startet das BIOS das BOOTBIOS auf der Netzwerkkarte. Dieses BOOTBIOS muss die Netzwerkkarte dann initialisieren und versuchen diese an das Netzwerk anzumelden. Ist ihm das gelungen kann es anfragen ob es im Netzwerk einen Server gibt der für das Booten für dieser HW-Adresse einen Dienst bereitstellt. Wenn ja dann kann es von dort eine Art Bootloader, ein "Network Bootstrap Program" herunter laden und in den Hauptspeicher laden und dort starten. Dieses ubernimmt dann das Booten des Rechners aus dem Netzwerk. Dieser Mechanismus wird z.B. vom MosNis genutzt mit Hilfe der im Netzwerkbootabschnitt des Bootmanager-Wikibooks beschriebenen Bootloader. Ist eine Anmeldung am Netzwerk nicht möglich oder wird kein zuständiger Bootserver erkannt, kann das BOOTBIOS wieder zurück an das BIOS übergeben und dieses versuchen vom nächsten Device in der Bootliste zu booten.

BIOS Links

BIOS Kompendium

---