News UEFI im Jahr 2011 erstmal vor dem BIOS?

SheepShaver schrieb:
Na du Schlauberger. Dann zeig mir mal, wie du mit einem BIOS direkt von einer GPT bootest.

Mmhh villeicht meinte er auch auch dass man das BIOS auf die GPT Anpassen sollte, und sich vom MBR trennen. Naja hauptsache Blöd daherreden, Gell? ;)

Weiß jemand welche einschränkungen es gibt weshalb sowas nicht ins BIOS implementiert ist?


MFG
 
Ich glaube nicht, dass das auch nur annähernd schon 2011 gelingen wird.
 
Eröffnet (U)EFI nicht ganz neue Sabotagemöglichkeiten für Viren? Das ist doch sicher mit dem Internet verbunden, oder?
 
Volker schrieb:
Gute Einwand! Problem ist aber die mangelnde Dokumentation dazu. Kein Mensch weiß doch, was dahinter steckt, ob klassisches BIOS oder bereits EFI.

Das war mir auch nicht bewusst hab das heute zufällig in der ct gelesen:

ct schrieb:
Dass das BIOS-Setup eine grafische Oberfläche aufweist, sagt nichts über UEFI aus. Allerdings wird der Firmware-Code vieler PC-Mainboards bereits nach den UEFI-Vorgaben geschrieben. Weil aber erst wenige Betriebssysteme auf einem reinen UEFI-System starten könnten, enthält die Firmware meistens ein sogenanntes Compatibility Support Module (CSM), welches BIOS-Kompatibilität herstellt. Aus Sicht des Betriebssystems unterscheidet sich UEFI-Firmware mit CSM nicht von einem BIOS.
Falls es eine UEFI-Boot-Option im BIOS-Setup gibt, dient sie dazu, das Laden des CSM zu unterbinden. Nach unseren Erfahrungen mit einigen der wenigen bisher lieferbaren UEFI-tauglichen Systemen lädt die Firmware meistens aber trotzdem das CSM, falls es von einem Massenspeicher sonst nicht booten kann – beispielsweise mangels EFI System Partition (ESP) oder EFI-Bootloader.
Wegen der CSM-„Ladeautomatik“ muss man im Betriebssystem nachschauen, ob es im UEFI-Modus läuft. Unter Windows erkennt man das unter anderem in der Datenträgerverwaltung, weil das Laufwerk mit der Systempartition dann stets GPT-verwaltet ist, also keinen Master Boot Record (MBR) nutzt. Auch die Boot Configuration Data (BCD) entlarven eine UEFI-Installation: Ruft man auf einer mit Administratorrechten gestarteten Kommandozeile (cmd.exe) das Programm bcdedit auf, meldet es bei UEFI-Systemen den Bootmanager bootmgfw.efi auf der ESP unter \EFI\Microsoft\Boot sowie den Bootloader winload.efi im Verzeichnis \Windows\system32. Zeigt bcdedit stattdessen winload.exe an, läuft das System im BIOS-Modus.

Also selbst wenn man ein UEFI Board hat bekommt man davon erstmal gar nichts mit solange man nicht solche tests anstellt...

Schade dass man lieber mit blau eloxierten Kühlkörpern wirbt als mit der verwendeten Technik/Software.

nille02 schrieb:
Laut Wikipedia sind alle Versionen ab Windows Vista SP1 EFI Tauglich. Nur die älteren Windows Versionen benötigen die BIOS Emulation.

Aber nur die x64 Versionen offenbar:

ct schrieb:
Bisher lassen sich also anscheinend ausschließlich die x64-Versionen von Windows Vista, Windows 7 und Windows Server 2008 im UEFI-Modus installieren.

Quelle:
http://www.heise.de/ct/hotline/FAQ-Unified-Extensible-Firmware-Interface-1082020.html
 
Zuletzt bearbeitet:
Da gab es sogar einen ganzen Artikel inklusive Installationsversuche etc.
Ich weiß nur nicht mehr genau welches Heft. Müsste so 2008 gewesen sein. Win 7 gab es auch noch nicht.
Ich versuch's mal noch zu finden.
 
Blutschlumpf schrieb:
Hier ist das Problem, warum sollen Hersteller die offenbar nicht in der Lage sind ein BIOS vernünftig zu implementieren, bei UEFI (blöder Name, klingt nach UEFA) weniger schlampig arbeiten....
Ganz einfach: Weil Programmierung in einer Hochsprache wie C wesentlich "leichter" von der Hand geht, als Denkakrobatik in Assembler, mit wenigen C-Modulen und völlig unstandardisiertem Flickwerk, weil eben gerade das BIOS überhaupt kein Standard ist - wenn du einen ATAPI-Treiber für BIOS schreibst, darfst du den fürs nächste Mainboardmodell komplett neu schreiben, nichts ist portabel - in der (U)EFI-Welt ist das, genau wie seit über 15 Jahren in der OpenFirmware-Welt (bspw. PowerMacs, SPARC-Server usw.) kein Problem - den Standard-Atapi- oder AHCI-treiber kannst du einfach für viele unterschiedliche Boardtypen nutzen - weniger Arbeit am Schreiben des Codes, mehr Zeit für Fehlersuche/-behebung. Deswegen ist (laut c't) auf den meisten Board auch bereits EFI vorhanden - nur wird dem Anwender meistens der EFI-Modus verboten, sodass allein der BIOS Compatibility Mode zur Verfügung steht. (welcher c't Artikel as war, müsste ich vielleicht noch raussuchen, mache ich später vielleicht - gibts im Online-Kiosk der c't)

@ "EFI hält sich an keinen Standard, deswegen haben Linux ua. Probleme damit"

Das ist ja nun totaler Quatsch - UEFI ist wesentlich stärker standardisiert als BIOS, dass viele Linuxdistros noch Pribleme damit haben, liegt allein am Mangel an freiwilligen Testern mit entsprechenden UEFI-Rechnern. Wenn in ganz Deutschland gerademal 10 Menschen Linux im EFI-Modus booten wollen, kann man als Distributor schlecht die Codestabilität gewährleisten.

Allerdings kann ich Entwarnung geben: Zumindest Kubuntu 10.04 bootet völlig problemfrei im EFI-Modus von GPT, man muss es allerdings aus der im BIOS-Modus gestarteten LiveCD auf einen GPT-Datenträger installieren, nicht vom Direktinstaller, weil die ISOs selbst nur BIOS-Boot unterstützen. Bei mir startet Kubuntu 10.04 jedenfalls völlig problemfrei von seinem GPT-Datenträger auf einem mit EFI laufenden MSI P45 Platinum.

@ "unrealistische Zeitvorstellung seitens UEFI Consortium"

Nö gar nicht - MSI hatte doch, nachdem die UEFI-Ambitionen von MSI zwischenzeitlich offiziell beerdigt waren, im Sommer verlauten lassen, dass Ende diesen Jahres MSI-Boards auf den Markt kommen sollen, die standardmäßig und empfohlener Maßen im EFI-Modus laufen sollen - ich find die Zeitvorstellung, dass innerhalb eines Jahres dann der Umstieg der Braanche erfolgt, durchaus sehr realistisch. Macht wenig Sinn den Kunden danach noch lange damit zu verwirren, dass manche Boards EFI und manche BIOS sind.
 
Zuletzt bearbeitet:
lässt sich OSX bzw die illegalen Derivate dann leichter auf einem PC installieren? ^^

Ich würd da ja mega drauf abgehen :-)
 
MountWalker schrieb:
@ "unrealistische Zeitvorstellung seitens UEFI Consortium"

Nichts leichter als das -> die Hersteller sollen einfach alle neuen MB für Sandy Bridge damit ausrüsten. Ähnlich neuen RAM-Standards dauert es dann nicht lange bis alle drauf abfahren.
 
MountWalker schrieb:
wenn du einen ATAPI-Treiber für BIOS schreibst, darfst du den fürs nächste Mainboardmodell komplett neu schreiben, nichts ist portabel
Grober Unfug. Das Interface zur Hardware bleibt dabei identisch und damit auch der Treiber. Lediglich wenn du den "Treiber" plötzlich ins BIOS eines anderen Herstellers integrieren mußt, handelst du dir ggf. ein paar kleine Unterschiede beim Linken deines Treibers zum reslichen Code des BIOS ein.

Glaubst du wirklich, die Mainboardhersteller oder BIOS-Hersteller (Ami, ...) im PC-Bereich schreiben für jede neue Generation von Mainboards das BIOS komplett neu? Tun sie nicht. Die klicken sich nur die nötigen Komponenten neu zusammen, fügen ein bischen Bit Fddeling für einige Einstellungen hinzu, für die es nix vorgefertiges vom BIOS-Vendor (Ami, Award, ...) gibt und sind fertig. Ein PC-BIOS ist intern kein Hexenwerk, lediglich meistens closed source und kaum dokumentiert.

MountWalker schrieb:
- in der (U)EFI-Welt ist das, genau wie seit über 15 Jahren in der OpenFirmware-Welt (bspw. PowerMacs, SPARC-Server usw.) kein Problem - den Standard-Atapi- oder AHCI-treiber kannst du einfach für viele unterschiedliche Boardtypen nutzen
Die schleppen für gleiche Hardware genauso den gleichen Treiber (mit kleinen Updates) über Jahre mit wie man es im PC-Bereich tut. Als Vorteil von OpenFirmware & Co - was die Treiber angeht - bleibt, dass man die Firmware für eine Hardwarekomponente auf mehren Plattformen verwenden kann, also meinetwegen Sparc und PowerPC, weil die Firmware statt in Maschinenkode in einer high level Sprache daherkommt. So wahnsinnig wichtig ist das nicht, denn nur für die paar zum Booten des OS nötigen Gerätschaften brauch man solche Firmware. SCSI-Adapter in Form von Steckkarten als typisches fürs Booten nötige Ding bekam man z.B. oft alternativ mit Openfirmware. Das sah dann so aus:
* Controller Model XYZ für BIOS: 2000 Euro
* Controller Model XYZ für OF: 3000 Euro

... wahrscheinlich weil OF
MountWalker schrieb:
- weniger Arbeit am Schreiben des Codes, mehr Zeit für Fehlersuche/-behebung.
verursachte. :D
 
Zuletzt bearbeitet:
mensch183 schrieb:
Grober Unfug. ...
Moment:
c't 11/09 Maskierte Ablösung - Extensible Firmware Interface ersetzt BIOS schrieb:
Die BIOS-Zulieferer binden auch Code-
Module ein, die sie von Chipsatz- oder CPUHerstellern
erhalten. AMD etwa pflegt AGESA
(AMD Generic Encapsulated Software Architecture)
zur Initialisierung und Konfiguration
der AMD64-Prozessoren. Genau an solchen
Stellen bringt (U)EFI Verbesserungen: Code-
Module müssen nun nicht mehr für jede
BIOS-Version separat geschrieben und getestet
werden
, sondern sie lassen sich als EFIQuellcode
in EFI-Firmware integrieren und
dann in einem Rutsch in EFI Byte Code übersetzen.
Ähnliches gilt auch für Treiber für
Chipsatz-Funktionen sowie Netzwerk- oder
Storage-Controller.

Den ganzen Artikel gibts im c't Kiosk
 
Zuletzt bearbeitet:
Zurück
Oben