Funktionsweise BIOS

https://de.wikipedia.org/wiki/BIOS

1

Aufgabe des BIOS ist es unter anderem, den PC zunächst funktionsfähig

2

zu machen und im Anschluss das Starten eines Betriebssystems einzuleiten.

https://de.wikipedia.org/wiki/BIOS#Aufgabe_des_BIOS

1

Ein BIOS löst zwei Probleme, die beim Kaltstart eines PCs auftreten:

2

3

Zum einen löst es durch das sogenannte „Bootstrapping“ ein

4

klassisches Henne-Ei-Problem: Software ist in der Regel auf

5

einem Datenträger gespeichert, welche beim Start zunächst in

6

den Hauptspeicher des Rechners eingelesen werden muss. Zum

7

Einlesen des Datenträgers benötigt die CPU aber wiederum Software.

8

Frühere Computer und Rechenanlagen lösten dieses Problem dadurch,

9

dass sie die CPU nach dem Einschalten des Rechners grundsätzlich

10

zunächst in den Pausemodus versetzten. Bevor der Rechner gestartet

11

werden konnte, musste manuell oder mit Hilfe spezieller Peripherie

12

eine minimale Software (der Bootloader) in den Hauptspeicher geladen

13

werden. Häufig war das Laden des Bootloaders beim Starten des Rechners

14

aber gar nicht nötig, da der in den 1960er und frühen 1970er Jahren

15

weit verbreitete Kernspeicher – im Gegensatz zum heute gebräuchlichen

16

Halbleiterspeicher – seinen Inhalt beim Ausschalten nicht verlor

17

(Persistenzspeicher) und die Programme im Hauptspeicher deshalb zumeist

18

nur neu gestartet werden mussten oder sogar fortgesetzt werden konnten.

19

Das Ladeprogramm ist bei heutigen PCs Teil des BIOS, das in einem

20

speziellen Speicherbaustein, dem EPROM oder bei neueren Modellen meist

21

in einem Flash-Speicher abgelegt ist, deren Speicherinhalt jeweils auch

22

ohne Stromversorgung erhalten bleibt. Beide sind vollständig unabhängig

23

von einer Energieversorgung und auch für die Firmware von portablen

24

Geräten geeignet. Damit entfällt heute die manuelle Eingabe eines Ladeprogramms.

25

26

Zum anderen erfordert unterschiedliche Hardware jeweils eine spezielle

27

Ansteuerungssoftware (Treibersoftware) und die zugehörige Konfiguration.

28

Früher musste ein Betriebssystem auf jede Variante jedes Rechnertyps

29

speziell zugeschnitten werden, um darauf lauffähig zu sein. Durch die

30

Auslagerung dieser speziellen Ansteuersoftware in das BIOS der jeweiligen

31

Rechner wurde es möglich, die gleiche Betriebssystemsoftware auf verschiedenen

32

Rechnern laufen zu lassen. Damit wirkt das BIOS nach neuerer Sprechweise als

33

Hardware Abstraction Layer (HAL). Allerdings benutzen fast alle modernen

34

Betriebssysteme eigene Treiber, vor allem weil die vom BIOS im Protected und

35

Long Mode nicht verfügbar sind. In einem von diesem laufen aber fast alle

36

modernen Betriebssysteme, unter anderem um einen größeren RAM verwalten zu

37

können und um Multitasking einfach zu organisieren.

Ma W. schrieb:
> Man könnte einfach das Betriebssystem und alle Programme im BIOS-EEPROM
> ablegen. Dan würde die Festplatte auch noch entfallen.

So hat man das früher zu Zeiten der Homecomputer auch gemacht, als die 
Betriebssysteme noch wenige Kilobytes groß waren.

Pascal schrieb:
> Wäre Bootstrapping dann nicht überflüssig, denn wenn das BIOS von einem
> über einen Peripherie-Baustein angesteuerten Speicher-IC geladen werden
> kann, müsste doch mit einem entsprechenden Chip auch von einer
> Festplatte das OS direkt geladen werden können...

Das Problem fängt vorher an. Denn ab Reset gibt es erst einmal kein RAM, 
in das ein ganzes Betriebssystem geladen werden kann. Der DRAM 
Controller muss dazu erst initialisiert werden.

Konrad Zuse schrieb:
> Jedesmal wenn ich die 3 Volt (CR2032) Batterie auf
> dem Motherboard wechsel,

Machst du das oft?

Rein technisch sollte es gehen. Nur sollte die dir bei der Operation 
nicht runter fallen. Sonst kann es sein, dass du nie wieder darum 
gebeten wirst.

Konrad Zuse schrieb:
> Dann erspare ich mir
> wenigstens die anschließende Einstellarbeit.

Moderne Rechner bieten inzwischen an, den Inhalt den CMOS, den die 
Batterie puffert, abzuspeichern. Bei mir gibt es dafür sogar 2 Optionen: 
ins FLASH vom BIOS, oder in den Bootsektor der Festplatte. Von da lassen 
sie sich jederzeit wieder zurückschreiben.
Gigabyte Board, hat inzwischen auch schon ca. 9 Jahre auf dem Buckel.

A. K. schrieb:
> Das Problem fängt vorher an. Denn ab Reset gibt es erst einmal kein RAM,
> in das ein ganzes

heutiges ;)

> Betriebssystem geladen werden kann.
> Der DRAM Controller muss dazu erst initialisiert werden.

Was aber auch damals schon gelöst wurde ;) Je nach Vorliebe war das 
ROM/EPROM entweder direkt (u.U. Buffer, Latches, Dekodierlogik etc. mal 
außen vorgelassen) an die CPU angebunden und hat wertvollen 
Speicherbereich belegt oder es wurde nur zum Booten eingeblendet und 
danach wieder ausgeblendet. Heute würd's reichen ein SPI/QSPI-Flash nach 
dem Reset von der CPU in den Cache laden zu lassen (falls sich der Cache 
heute noch als normaler Speicher verwenden lässt) und dann 
weiterzumachen oder wie div. Mikrocontroller gleich Excecute-In-Place 
aus dem SPI/QSPI-Flash. Die paar Leitungen und Logik für I²C/SMBus zum 
Auslesen der RAM-Parameter für die Konfiguration des Speichercontrollers 
dürften Intel, AMD und Konsorten wohl noch hinbekommen ;)

Es gibt ein paar interessante Vorträge von Coreboot, da wird das Thema 
wesentlich besser erklärt:

https://media.ccc.de/v/26c3-3661-de-coreboot_adding_support_for_a_system_near_you
https://media.ccc.de/v/25c3-2970-en-coreboot_beyond_the_final_frontier

Arc N. schrieb:
>> Betriebssystem geladen werden kann.
>> Der DRAM Controller muss dazu erst initialisiert werden.
>
> Was aber auch damals schon gelöst wurde ;) Je nach Vorliebe war das
> ROM/EPROM entweder direkt (u.U. Buffer, Latches, Dekodierlogik etc. mal
> außen vorgelassen) an die CPU angebunden und hat wertvollen
> Speicherbereich belegt oder es wurde nur zum Booten eingeblendet und
> danach wieder ausgeblendet.

Das BIOS wurde während der gesamten Laufzeit des Systems gebraucht, 
nicht nur zum Booten, weil dort z.B. so Dinge wie der Festplattentreiber 
drin waren. Was es früher gab, war "shadow RAM". Da wurde das BIOS beim 
Starten erstmal in den RAM-Speicher kopiert und dann von dort benutzt, 
weil RAM viel schneller ist als ein EPROM.

> Heute würd's reichen ein SPI/QSPI-Flash nach dem Reset von der CPU in den
> Cache laden zu lassen (falls sich der Cache heute noch als normaler
> Speicher verwenden lässt) und dann weiterzumachen oder wie div.
> Mikrocontroller gleich Excecute-In-Place aus dem SPI/QSPI-Flash.

Auch heute wird das BIOS später noch gebracht. Man denke an ACPI. Dürfte 
also nachher nie aus dem Cache fliegen, bzw. bei direkter Ausführung aus 
dem Flash über SPI dürfte es eklig langsam sein.

Rolf M. schrieb:
> Das BIOS wurde während der gesamten Laufzeit des Systems gebraucht,
> nicht nur zum Booten, weil dort z.B. so Dinge wie der Festplattentreiber
> drin waren.

Die hat aber nach dem Boot niemand mehr benutzt, weil sie ein paar sehr 
unangenehme Eigenschaften hatten:
a) langsam und CPU-fressend (keine schnellen DMA-Modi)
b) beschränkt (504 MB-Grenze, 8 GB-Grenze, ...)
c) blockierend (unbekanntes Zeitverhalten).

Ausgenommen sind davon frühe Betriebssysteme (schon WfW 3.11 hatte 
eigene Festplattentreiber) und Kompatiblitätsmodi.

> Auch heute wird das BIOS später noch gebracht. Man denke an ACPI.

Nein, bei ACPI stellt das BIOS ein paar Tabellen mit Informationen und 
Bytecode zur Verfügung, der vom Betriebssystem ausgeführt wird. Die 
kann das Betriebssystem auch selbst bereitstellen (wurde auch gemacht, 
wenn die BIOS-Tabellen fehlerhaft sind).

Das ist ein Unterschied zu UEFI, wo das Betriebssystem die Firmware 
tatsächlich anweist, Dinge zur Laufzeit zu erledigen.

Dass auch ein klassisches BIOS über SMM und andere Mechanismen auch zur 
Laufzeit die volle Kontrolle über das System hat, ist eine andere 
Baustelle, auf die das Betriebssystem aber keinen Einfluss hat. Die 
gesamte moderne x86-Architektur ist eine einzige Backdoor.

S. R. schrieb:
> Rolf M. schrieb:
>> Das BIOS wurde während der gesamten Laufzeit des Systems gebraucht,
>> nicht nur zum Booten, weil dort z.B. so Dinge wie der Festplattentreiber
>> drin waren.
>
> Die hat aber nach dem Boot niemand mehr benutzt, weil sie ein paar sehr
> unangenehme Eigenschaften hatten:

Na zumindest der Bootloader des Betriebssystems nutzt ihn, denn der muss 
erstmal irgendwas von der Platte in den Speicher laden, was einen 
eigenen Treiber mitbringen könnte.

> a) langsam und CPU-fressend (keine schnellen DMA-Modi)
> b) beschränkt (504 MB-Grenze, 8 GB-Grenze, ...)
> c) blockierend (unbekanntes Zeitverhalten).
>
> Ausgenommen sind davon frühe Betriebssysteme (schon WfW 3.11 hatte
> eigene Festplattentreiber) und Kompatiblitätsmodi.

Ja, ich dachte da auch eher an DOS. Dass Windows dann irgendwann auch 
eigene Treiber hatte, ist klar. Einen Nachteil hast du aber vergessen:

d) Muss im Real Mode laufen

>> Auch heute wird das BIOS später noch gebracht. Man denke an ACPI.
>
> Nein, bei ACPI stellt das BIOS ein paar Tabellen mit Informationen und
> Bytecode zur Verfügung, der vom Betriebssystem ausgeführt wird.

Ja, und die müssen ja auch irgendwo herkommen.

> Die kann das Betriebssystem auch selbst bereitstellen (wurde auch
> gemacht, wenn die BIOS-Tabellen fehlerhaft sind).

Das ist aber natürlich ganz und gar nicht Sinn der Sache. Immerhin soll 
das ja eigentlich dazu dienen, Hardware zu abstrahieren, damit das 
Betriebssystem sich nicht drum kümmern muss. Aber ACPI ist eh ein 
Moloch.

Rolf M. schrieb:
>> Die [BIOS-Treiber] hat aber nach dem Boot niemand mehr benutzt,
>> weil sie ein paar sehr unangenehme Eigenschaften hatten:
>
> Na zumindest der Bootloader des Betriebssystems nutzt ihn, [...]

Der gehört für mich zum Boot - wie der Name schon sagt. ;-)

> Ja, ich dachte da auch eher an DOS. Dass Windows dann irgendwann auch
> eigene Treiber hatte, ist klar. Einen Nachteil hast du aber vergessen:
>
> d) Muss im Real Mode laufen

Im Prinzip müssten sie das, aber der VM86 reicht ebenfalls aus. Das ist 
zwar etwas Aufwand, aber die Treiber sind dann auch problemlos (weil 
kein Busmaster-DMA) unter Multitasking-Betriebssystemen nutzbar.

Auf diese Weise konnte Windows 95 die BIOS-Treiber nutzen, wenn es keine 
eigene hatte (nur deswegen läuft es auch unter DOSBox).

>>> Auch heute wird das BIOS später noch gebracht. Man denke an ACPI.
>>
>> Nein, bei ACPI stellt das BIOS ein paar Tabellen mit Informationen und
>> Bytecode zur Verfügung, der vom Betriebssystem ausgeführt wird.
>
> Ja, und die müssen ja auch irgendwo herkommen.

Das BIOS kopiert diese Tabellen vor dem Boot in den Speicher (bzw. 
stellt sie im physischen Adressraum bereit). Es wird kein bisschen 
BIOS-Code benötigt, um da ranzukommen. Der BIOS-Code ist nach dem Boot 
nichtmal mehr ausführbar.

>> Die kann das Betriebssystem auch selbst bereitstellen (wurde auch
>> gemacht, wenn die BIOS-Tabellen fehlerhaft sind).
>
> Das ist aber natürlich ganz und gar nicht Sinn der Sache.

Nein, es ist aber der Beweis dafür, dass das BIOS nach dem Boot nicht 
mehr gebraucht wird.

Ja, das BIOS stellt dem Betriebssystem Informationen bereit, die es 
benutzen kann (und sollte). Vor dem Boot.
Ja, das BIOS startet den initialen Bootloader des Betriebssystems und 
stellt eine Umgebung bereit, damit sich das Betriebssystem starten kann.

Und ja, man kann diese Umgebung auch nach dem Boot nutzen. Macht aber 
niemand mehr, also ist das BIOS nach dem Boot komplett überflüssig.

Im Gegensatz zum UEFI.

Pascal schrieb:
> Allerdings: wie wird
> der Code ... überhaupt geladen? Der Prozessor führt ja noch
> keine Befehle aus...

Ein Blick in die CPU-Timing-Diagramme, insbesondere in den Aufbau des 
Maschinenzyklus schafft Klarheit: die erste Aktion der CPU, nachdem sie 
bereit ist(und am Beginn des Maschinenzyklus), ist das Holen eines 
Befehls ("command fetch" -> Speicher wird gelesen). Wie es dann 
weitergeht ist im gerade geholten Befehl kodiert und die CPU verhält 
sich entsprechend.

Pascal schrieb:
> Könnte man sich das so vorstellen?

Ja.
Es findet ständig das Wechselspiel zwischen Befehl-Holen und 
Befehl-ausführen statt. Ob jetzt ein Bios geladen wird, deren Daten in 
Byte oder Blöcken oä. organisiert sind, oder sonst irgend etwas, ist 
eine Intepretationsfrage. Der CPU ist es herzlich egal.

Pascal schrieb:
> D.h. man könnte z.B. sagen (ganz vereinfacht) der erste Befehl ist, da
> der RAM ohne Stromversorgung alle Daten 0 werden lässt,

Das ist ein Irrglaube ;) Daten im DRAM können eine Weile auch ohne Strom 
überleben, je kälter, umso länger. Bei Zimmertemperatur sind es einige 
Sekunden, dann wirds langsam bröslig. Und auf 0 fällt es auch nicht 
immer zurück. Tatsächlich ist der "Ruhe"zustand entweder 0 oder 1, 
abhängig von der Adresse.

georg schrieb:
> Da muss der erste Befehl des BIOS stehen, dafür muss die Hardware sorgen.

Soweit ich verstanden habe, war die Frage, wie sie eben das tut, wenn 
der BIOS-Flash nicht einfach am Speicherbus der CPU hängt.

Pascal schrieb:
> Das BIOS wird ja aus einem EEEPROM/Flash Chip geladen.

Pascal schrieb:
> Das Bussystem wird ja an einen Peripherie-Baustein angeschlossen, der
> wiederum an dem BIOS-EEPROM-Chip angeschlossen ist. Allerdings: wie wird
> der Code aus dem EEPROM überhaupt geladen? Der Prozessor führt ja noch
> keine Befehle aus...

Das scheint wohl nicht mehr so zu sein.

https://superuser.com/questions/695690/who-loads-the-bios-in-ram-during-computer-bootstrap

Andere Links die interessant sein könnten:

https://superuser.com/questions/336021/is-bios-read-from-the-bios-chip-or-copied-into-ram-on-startup

http://www.comptechdoc.org/hardware/pc/pcboot.html

Pascal schrieb:
> Dieser Chip hat doch eine Schnittstelle, die nicht direkt an das
> Bussystem anschließbar ist. Dazu wird vermutlich ein anderer IC
> genommen, der z.B. SPI oder i2c in ein Signal für das Bussystem
> umwandelt.

Irgendwann wirds mal dies gewesen sein:
http://ww1.microchip.com/downloads/en/DeviceDoc/25085A.pdf

Wenn du dir mal die Coreboot-Vorträge anschaust (oder zumindest die 
erste Hälfte vom ersten Vortrag), sollte sich deine Frage von selbst 
beantworten.

Nein, aktuelle x86-CPUs sind auf aktuellen x86-Mainboards von allein 
nicht mehr startfähig und benötigen Hilfe vom Chipsatz. Denn der spricht 
SPI zum Flash-Baustein und kann Zugriffe von der CPU rechtzeitig 
abfangen und dadurch in den Adressraum einblenden.