Hi, die Frage ist sicher sehr simpel zu beantworten, jedoch bleibe ich da gerade beim Verstehen des Bootvorgans eines PCs hängen. Ich gehe hier mal von einem PC aus, der auf jeden Fall noch ein BIOS nutzt. Das BIOS wird ja aus einem EEEPROM/Flash Chip geladen. 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. Könnte man dann nicht auch das Betriebssystem inkl. Bootloader direkt starten ohne BIOS und ohne Bootloader? 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... Somit gäbe es kein Henne-Ei-Problem Oder liegt das daran, dass die Festplatte eine Formatierung besitzt? Sonst könnte man doch Festplatten ohne Formatierung für das OS verwenden und einfach einen weiteren Speicher mit Formatierung für das Speichern von Programmen,... verwenden Oder eben mit Partitionen das tun. Danke für jede Hilfe Pascal
> Könnte man dann nicht auch das Betriebssystem inkl. Bootloader direkt > starten ohne BIOS und ohne Bootloader? Natürlich. Machts aber nicht unbedingt einfacher.
Pascal schrieb: > Könnte man dann nicht auch das Betriebssystem inkl. Bootloader direkt > starten ohne BIOS und ohne Bootloader? Klar kann man, machen alte System ohne BIOS auch. Nur wie bekommst du das System auf den Rechner? Vor allem mit den richtigen Treibern? Ohne einen anderen Rechner zu haben.
Man könnte einfach das Betriebssystem und alle Programme im BIOS-EEPROM ablegen. Dan würde die Festplatte auch noch entfallen.
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.
Rolf M. schrieb: > So hat man das früher zu Zeiten der Homecomputer auch gemacht, als die > Betriebssysteme noch wenige Kilobytes groß waren. Und, vor allem, kein alternatives Betriebssystem überhaupt in Frage kam. Georg
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.
:
Bearbeitet durch User
Kurze Zwischenfrage: Jedesmal wenn ich die 3 Volt (CR2032) Batterie auf dem Motherboard wechsel, muss ich die Uhrzeit und noch andere Einstellungen wieder neu einstellen. Kann ich das vermeiden, in dem ich den Rechner beim Batteriewechsel einfach eingeschaltet lasse, oder hat das gravierende Nachteile?
Konrad Zuse schrieb: > Jedesmal wenn ich die 3 Volt (CR2032) Batterie auf > dem Motherboard wechsel, Machst du das oft?
A. K. schrieb: > Machst du das oft? Ja, leider auch für andere Leute, da weiß ich nie was die für Einstellungen vorher hatten. Das ist dann immer lästig.
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.
A. K. schrieb: > Nur sollte die dir bei der Operation > nicht runter fallen. Sonst kann es sein, dass du nie wieder darum > gebeten wirst. Aha. Das mit dem runterfallen auf die darunter liegende Platine, am besten noch auf die Lötseite, habe ich mir fast gedacht. Aber gut, wenn ich eine ruhige Hand habe, dürfte es gehen. Dann erspare ich mir wenigstens die anschließende Einstellarbeit. vielen Dank
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.
Konrad Zuse schrieb: > Kann ich das vermeiden, in dem ich den Rechner beim Batteriewechsel > einfach eingeschaltet lasse, oder hat das gravierende Nachteile? Wie Radio Eriwan sagt, im Prinzip ja. Nur wechselt man die Batterie in der Regel, wenn die Einstellungen bereits verloren sind... Georg
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
:
Bearbeitet durch User
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.
Noch eine ganz grundlegende Frage: zum Laden des BIOS in den RAM bevor es ausgeführt wird: 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... Die Antwort ist sicher einfach (vielleicht lädt die Hardware der CPU softwareunabhängig durch entsprechende interne Hardware inklusive einem Counter automatisch die ersten 512 Bytes des EEPROM-Chips in den RAM (oder kann ein BIOS größer als 512 Bytes sein und Daten im restlichen Speicherplatz des EEPROM lagern?) und lässt daraufhin den Prozessor nacheinander die Befehle laden? Und kann das BIOS aus mehreren Stufen bestehen?) Danke im Voraus Pascal
Wäre nett wenn ihr auf alle 4 Fragen antworten würdet. Selbst Ja/Nein bzw. bei Nein wie dann würde locker ausreichen.
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.
Das schafft tatsächlich eine beeindruckende Klarheit. 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, 0x0000000000000..., der als bspw. "Lade den ersten Block aus dem BIOS-EEPROM in den RAM" decodiert wird Könnte man sich das so vorstellen?
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.
Pascal schrieb: > Wäre nett wenn ihr auf alle 4 Fragen antworten würdet Nach 3 Minuten schon die Geduld verloren? Wir spuren dir wohl nicht genug? Pascal schrieb: > Könnte man sich das so vorstellen? Quatsch. Jede CPU, nicht nur im PC, lädt nach einem Reset als erstes einen Befehl von einer bestimmten Adresse, häufig von der Adresse 0. Da muss der erste Befehl des BIOS stehen, dafür muss die Hardware sorgen. Georg
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.
Rolf M. schrieb: > 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. Genau das war meine Frage. Wie wird dann der erste Befehl in den RAM und dann ins Befehlsregister geladen?
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: > Wie wird dann der erste Befehl in den RAM und dann ins Befehlsregister > geladen? Wer sagt denn, dass er das wird? Der erste Befehl wird aus dem ROM ausgeführt, am einfachsten wäre es doch den Wikipedia-Artikel dazu zu lesen: https://en.wikipedia.org/wiki/BIOS Im weiteren Verlauf kann das BIOS natürlich alles mögliche tun, auch z.B. seinen eigenen Inhalt ins RAM laden und dort weitermachen. Rein theoretisch und wenn man es umständlich mag, kann man natürlich spezielle Hardware oder einen zusätzlichen kleinen Prozessor damit beauftragen, den Code zu kopieren und dann den Hauptprozessor zu starten. Es besteht nur kein Grund dafür. Georg
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.