Was machen BIOS / UEFI alles, wieso ist coreboot wesentlich schneller?

[Stannis]

Hi. Der Thread besteht aus reinem Interesse, nicht wegen eines Problems.

Ich hatte mich gefragt, ob ihr mir ein paar Takte über BIOS und Konsorten erklären könntet. Ich kenne mich zwar besser aus als der Durchschnittsbürger, viel mehr aber auch nicht...
Und zwar habe Ich mir in letzter Zeit einiges über coreboot durchgelesen, ein opensource Projekt, dass BIOS und UEFI ersetzen möchte.

Ich weiß grob, weshalb ein BIOS überhaupt nötig ist: Um ein OS zu starten, ist Software nötig (Treiber etc.), die aber noch nicht verfügbar sind. Daher wird Software direkt als Maschinencode aus einem Flashchip in die CPU gefüttert, die Hardware initalisiert und ein Bootloader gestartet.

1. Was macht das BIOS sonst noch so; früher hat es ja auch noch als Schnittstelle zur Hardware fungiert, aber heute nutzen doch alle Betriebssysteme eigene Treiber, um Geräte anzusprechen, oder?
2. Laufen BIOS und UEFI nur beim Systemstart oder sind sie auch permanent im Hintergrund aktiv?
3. Dieses Schaubild auf der Wikipedia suggeriert letzteres. Wozu ist es nötig, dass UEFI weiterhin unter dem Betriebssystem sitzt?
4. Nach dem Booten steuert das OS die gesamte Hardware? Zumindest beim Systemstart müsste ja das BIOS die Lüfter usw. steuern. Auf meinem ASUS Board kann Ich allerdings auch Perfomance-Modi setzen, was ja darauf hindeutet, dass die Firmware während des gesamten Betriebes der Maschine Steuerfunktionen übernimmt?

Und, falls sich jemand mit coreboot auskennen sollte:

• Wie kommt es, dass es angeblich so viele Schritte, die die traditionelle Firmware tun muss, überspringen kann?
• Coreboot übergibt nach dem Initalisieren an eine Payload, die das System weiter hochfährt. Kann man über letztere dann die ganzen Einstellungen vornehmen, die man beim normalen PC im BIOS macht? Virtualisierung ein und ausschalten, Taktfrequenz ändern etc.

 

[D1rty]

Punkt 1-4 werden dir doch alle im Wikipedia Artikel beantwortet. Hast du auch den englischen gelesen?

 

[cvzone]

angeblich so viele Schritte, die die traditionelle Firmware tun muss, überspringen kann?

Sowas geht alles zur Lasten der Kompatibilität. UEFI arbeitet ohne CSM auch sehr viel schneller, aber dann funktionieren halt etlichen Sachen nicht mehr.

Das Bios/UEFI läuft immer und bildet die direkte Schnittstelle zur Hardware (bzw. verbindet es die jeweilige Firmware untereinandner). Ein unmittelbarer Zugriff auf die Hardware findet durch den Treiber nur begrenzt statt.

 

[Stannis]

@D1rty: Ich habe Wikipedia weitgehend abgegrast, stoße aber eben immer mal wieder auf scheinbar widersprüchliche Informationen - wie z.B., dass früher auf Geräte wie Tastatur etc. übers bios zugegriffen wurde, wohingegen heute eigene Treiber genutzt würden.

 

[D1rty]

wie z.B., dass früher auf Geräte wie Tastatur etc. übers bios zugegriffen wurde, wohingegen heute eigene Treiber genutzt würden.

Das nennt sich technologischer Fortschritt. Genau wie vom Pferd, zum Motor, der dann z.B. turboaufgeladen ist.

 

[Stannis]

Das nennt sich technologischer Fortschritt. Genau wie vom Pferd, zum Motor, der dann z.B. turboaufgeladen ist.

Schon klar, aber was passiert denn mit der heutigen Methode z.B. bei einer USB-Webcam. Das Betriebssystem spricht über einen Treiber das bios an und dieses dann die Kamera? Man könnte meinen, dass das bios dann ebenfalls einen treiber für dieses spezielle Gerät benötigte.

 

[cvzone]

Nein, das Bios stellt nur die Verbindung über die Controller bereit. Die Geräte sprechend schon untereinander über den Treiber. Es gibt mehrere Ebenen der Gerätekommunikation.

 

[Stannis]

Und könnte das OS diese Funktion prinzipiell komplett übernehmen? Darauf scheint coreboot ja abzuzielen, wenn Ich es richtig verstehe.

 

[xxMuahdibxx]

Wenn man bedenkt das ab Windows Vista das direkte Ansprechen von Soundhardware durch Treiber ( Soundblaster EAX speziell ) unterbunden wurde ... sollte man nochmal überlegen was wirklich direkt mit Hardware kommunizieren darf.

 

[mensch183]

Wenn man bedenkt das ab Windows Vista das direkte Ansprechen von Soundhardware durch Treiber ( Soundblaster EAX speziell ) unterbunden wurde ... sollte man nochmal überlegen was wirklich direkt mit Hardware kommunizieren darf.

Schmarrn. Bei "neueren" Windowsvarianten fehlten lediglich die alten APIs im OS, über die früher z.B. EAX verwendet wurde. Am potentiellen Zugriff auf die (PCI-)Hardware hat sich nichts verändert. Als Ersatz fürs weggefallene API im OS muss der Hardwarehersteller eben selbst was bauen (im Normallfall eine Bibliothek, ggf. sind noch Anpassungen im Gerätetreiber nötig), was die "verlorenen" Fähigkeiten anbietet.

 

[xxMuahdibxx]

Ok stimmt Direct Sound hat keinen Zugriff auf die Hardware erlaubt ... und man muss es per Wrapper in OpenAL umwandeln das es wieder zugriff hat.