UEFI 2.0 und Driver ?
- Ersteller lockdoc
- Erstellt am
olhe
UNIX lover
http://de.wikipedia.org/wiki/Extensible_Firmware_Interface
Dort steht doch alles, inkl. weiteren Quellen.
Dort steht doch alles, inkl. weiteren Quellen.
lockdoc
Well-Known Member
Ja das hatte ich mir schon durchgelesen und auch dass hier gefunden
Also wenn ich das richtig deute und sich das durchsetzt, dann wird es also bald vorbei sein mit den ganzen Treiberproblemen?
Also das waer nur zu schoen, dann brauch man sich bei den ganzen OS'es nicht mehr mit Treibern rumschlagen.
Ich sehe dass dan schon praktisch vor mir. In einer Zeit wo es FreeBSD10 gibt werde ich mir das einfach auf irgendeinem Rechner installieren und er erkennt meine Graka, Wlan, etc, da das Bios ja alles liefert. Das wuerde ja die Konkurrenz auf dem OS Markt deutlich anheben. *muhahaha*
Hoffe mal ick freu mich nicht zu frueh.
Also wenn ich das richtig deute und sich das durchsetzt, dann wird es also bald vorbei sein mit den ganzen Treiberproblemen?
Also das waer nur zu schoen, dann brauch man sich bei den ganzen OS'es nicht mehr mit Treibern rumschlagen.
Ich sehe dass dan schon praktisch vor mir. In einer Zeit wo es FreeBSD10 gibt werde ich mir das einfach auf irgendeinem Rechner installieren und er erkennt meine Graka, Wlan, etc, da das Bios ja alles liefert. Das wuerde ja die Konkurrenz auf dem OS Markt deutlich anheben. *muhahaha*
Hoffe mal ick freu mich nicht zu frueh.
Vincent Vega
phisch
Zwar ist es technisch möglich, (U)EFI Treiber auch zur Laufzeit des Betriebssystems zu verwenden. Allerdings ist es i.A. aus Gründen der Performance wenig sinnvoll. Als ich das letzte Mal nachgeschaut hatte, konnten UEFI Treiber z.B. keine Interrupts registrieren. Insofern werden sich die universellen Treiber wohl erstmal auf die Firmware beschränken und evtl. als Fallback, d.h. wenn kein nativer Treiber vorhanden ist, vom Betriebssystem verwendet werden.
Wenn Windows 8 wirklich UEFI benötigt dann bedeutet das wohl eher, dass dem BIOS endlich der Todesstoß gegeben wird. Schließlich muss jeder Boardhersteller dann eine UEFI-kompatible Firmware bereit stellen. Anders ausgedrückt: Consumer-Boards werden dann wohl ohne BIOS, aber mit UEFI Firmware ausgeliefert.
Wenn Windows 8 wirklich UEFI benötigt dann bedeutet das wohl eher, dass dem BIOS endlich der Todesstoß gegeben wird. Schließlich muss jeder Boardhersteller dann eine UEFI-kompatible Firmware bereit stellen. Anders ausgedrückt: Consumer-Boards werden dann wohl ohne BIOS, aber mit UEFI Firmware ausgeliefert.
UEFI hat ein paar Vorteile, aber macht eigentlich nur alles komplizierter, bringt potentielle Angriffsvektoren, hilft den DRM-Leuten und ist IMO mindestens genau so schlimm, wie das TCPA-Zeug.
UEFI ist ja vor allem mal ein Standard. Den kann man entweder so implementieren, dass darunter ein BIOS läuft (ich hoffe, dass das standardmäßig der Fall bleiben wird) oder, dass man damit quasi das BIOS ersetzt. In diesem Fall gibt man damit einiges an Kontrolle her. Irgendwer, ich bin mir nicht sicher, ob es Linus Torvalds oder irgendein Coreboot-Entwickler war hat das ganze mal ziemlich auf dem Punkt gebracht.
Jedenfalls tun die Unterstützer alle so, als würde es die Dinge einfacher machen, obwohl das nicht der Fall ist und eigentlich nur weitere Hürden bringt. Es ist einfach eine (schlechte) Lösung für Probleme, die es nicht gibt.
UEFI ist ja vor allem mal ein Standard. Den kann man entweder so implementieren, dass darunter ein BIOS läuft (ich hoffe, dass das standardmäßig der Fall bleiben wird) oder, dass man damit quasi das BIOS ersetzt. In diesem Fall gibt man damit einiges an Kontrolle her. Irgendwer, ich bin mir nicht sicher, ob es Linus Torvalds oder irgendein Coreboot-Entwickler war hat das ganze mal ziemlich auf dem Punkt gebracht.
Jedenfalls tun die Unterstützer alle so, als würde es die Dinge einfacher machen, obwohl das nicht der Fall ist und eigentlich nur weitere Hürden bringt. Es ist einfach eine (schlechte) Lösung für Probleme, die es nicht gibt.
Zuletzt bearbeitet:
Vincent Vega
phisch
Ok, ich beiß an...
Eigentlich ist es für den Benutzer annähernd egal, ob der Rechner nun eine UEFI-kompatible Firmware hat oder ein klassisches BIOS. UEFI bietet aber die Infrastruktur für Features die man von einer modernen Firmware erwartet. So z.B. einen sauberen Update-Pfad, rudimentäres Platform Management auch während das Betriebssystem läuft oder auch nur die Unterstützung von mehreren Konsole-Geräten gleichzeitig. Wer war nicht schon mal in der Situation, dass an einem ansonsten bildschirmlosen System das BIOS nicht über die serielle Schnittstelle bedien- und aktualisierbar war sondern man dazu extra eine Grafikkarte und Bildschirm ranstöpseln musste?
Unter den Features von UEFI sind natürlich auch solche, denen man erstmal kritisch gegenüber steht: Es stimmt, dass UEFI tatsächlich die Infrastruktur für DRM bereit stellt. Allerdings lässt sich das genauso in einem klassischen BIOS abbilden.
Auch stimmt es wohl, dass mit der Zahl von Features auch die Komplexität und damit auch das Risiko von Fehlern steigt. Andernseits: Bis auf SeaBIOS kenn ich keine BIOS Implementierung im Source Code, habe mir aber sagen lassen, dass die meisten kommerziellen BIOS Implementierungen in Assembler programmiert seien. Stimmt das, dann ist es naiv zu glauben, dass es einfacher und weniger fehleranfällig ist, neue Features einem "gereiften" BIOS, d.h. uraltem (Real Mode) x86 Assembler Code, hinzuzufügen.
Da sind wir übrigens schon bei einem der wirklich großen Vorteile von UEFI gegenüber einem BIOS: UEFI ist nicht auf x86 Systeme beschränkt, sondern es gibt mittlerweile schon Implementierungen bzw. Portierungen auf ARM und MIPS. Hinzu kommt, dass hinter UEFI eine moderne Softwarearchitektur steht.
Diese Architektur wird niemand in Assembler nachprogrammieren wollen. Ich denke generell, dass niemand UEFI nachprogrammieren wird, sondern eher auf Intels freie (ja, wirklich) Referenzimplementierung TianoCore aufbauen wird. Daher ist ein "UEFI auf BIOS-Basis" in meinen Augen eher unwahrscheinlich.
Zum Schluss ein persönliches Wort, weshalb ich diesen Beitrag überhaupt geschrieben hab: Meiner Meinung nach basiert die Angst der Open Source Gemeinde gegenüber UEFI hauptsächlich auf unvollständigen Wissensbrocken. Um die Vorteile von UEFI zu erkennen, muss man sich meiner Meinung nach mal einige Zeit genommen haben um sich einzuarbeiten. Ein Wikipedia Artikel alleine reicht hier leider nicht aus.
Eigentlich ist es für den Benutzer annähernd egal, ob der Rechner nun eine UEFI-kompatible Firmware hat oder ein klassisches BIOS. UEFI bietet aber die Infrastruktur für Features die man von einer modernen Firmware erwartet. So z.B. einen sauberen Update-Pfad, rudimentäres Platform Management auch während das Betriebssystem läuft oder auch nur die Unterstützung von mehreren Konsole-Geräten gleichzeitig. Wer war nicht schon mal in der Situation, dass an einem ansonsten bildschirmlosen System das BIOS nicht über die serielle Schnittstelle bedien- und aktualisierbar war sondern man dazu extra eine Grafikkarte und Bildschirm ranstöpseln musste?
Unter den Features von UEFI sind natürlich auch solche, denen man erstmal kritisch gegenüber steht: Es stimmt, dass UEFI tatsächlich die Infrastruktur für DRM bereit stellt. Allerdings lässt sich das genauso in einem klassischen BIOS abbilden.
Auch stimmt es wohl, dass mit der Zahl von Features auch die Komplexität und damit auch das Risiko von Fehlern steigt. Andernseits: Bis auf SeaBIOS kenn ich keine BIOS Implementierung im Source Code, habe mir aber sagen lassen, dass die meisten kommerziellen BIOS Implementierungen in Assembler programmiert seien. Stimmt das, dann ist es naiv zu glauben, dass es einfacher und weniger fehleranfällig ist, neue Features einem "gereiften" BIOS, d.h. uraltem (Real Mode) x86 Assembler Code, hinzuzufügen.
Da sind wir übrigens schon bei einem der wirklich großen Vorteile von UEFI gegenüber einem BIOS: UEFI ist nicht auf x86 Systeme beschränkt, sondern es gibt mittlerweile schon Implementierungen bzw. Portierungen auf ARM und MIPS. Hinzu kommt, dass hinter UEFI eine moderne Softwarearchitektur steht.
Diese Architektur wird niemand in Assembler nachprogrammieren wollen. Ich denke generell, dass niemand UEFI nachprogrammieren wird, sondern eher auf Intels freie (ja, wirklich) Referenzimplementierung TianoCore aufbauen wird. Daher ist ein "UEFI auf BIOS-Basis" in meinen Augen eher unwahrscheinlich.
Zum Schluss ein persönliches Wort, weshalb ich diesen Beitrag überhaupt geschrieben hab: Meiner Meinung nach basiert die Angst der Open Source Gemeinde gegenüber UEFI hauptsächlich auf unvollständigen Wissensbrocken. Um die Vorteile von UEFI zu erkennen, muss man sich meiner Meinung nach mal einige Zeit genommen haben um sich einzuarbeiten. Ein Wikipedia Artikel alleine reicht hier leider nicht aus.
Im Übrigen war die von Heise verbreitete Nachricht Windows 8 würde nur auf UEFI booten eine klassiche Ente. Wahrscheinlich basierte sie auf einem Missverständnis. Die UEFI-Beschränkung gibt es für einige spezielle Versionen von Windows 8 - zum Beispiel die x86-Tablet-Variante - für das normale Wald und Wiesen Windows gilt aber weiterhin das, was schon seit Vista aktuell ist:
- Bis 2TB-Platte als Bootlaufwerk startet es per ganz klassischem BIOS mit MBR und so,
- ab 2TB braucht man UEFI
- Bis 2TB-Platte als Bootlaufwerk startet es per ganz klassischem BIOS mit MBR und so,
- ab 2TB braucht man UEFI
Aus gegebenen Anlass bitte ich darum mir die Totenschändung zu verzeihen.
http://www.zdnet.com/blog/open-sour...-systems-from-windows-8-arm-pcs-devices/10132
http://www.zdnet.com/blog/open-sour...-systems-from-windows-8-arm-pcs-devices/10132
Erwähnenswert ist noch das SecureBoot "Feature" von UEFI, welches so ausschaut, dass der zu bootende Kernel mit einem Schlüssel signiert ist, welcher von der Firmware vorm Booten geprüft wird. Erstmal kein Problem, da im Prinzip jeder OS-Erzeuger den Kernel signieren könnte - also xBSD oder Linux oder HasteNichGesehen. Praktisch hiesse das z.B. dass Microsoft Windows mit einem Key signiert und die Boards eben den Public-Key dazu parat halten. Was aber, wenn ein Hersteller sich dazu entscheidet ausschliesslich den Windows-Key mitzuliefern (und sind wir mal ehrlich....)? Das ist zum glück erstmal kein Problem, denn Microsoft schreibt vor, dass SecureBoot optional zu sein hat (würden sich ja sonst selbst ins Bein schießen mit den ganzen Legacy-Windows Nutzern). Auf ARM dagegen wirds interessant. Da schreiben sie nämlich explizit vor, dass SecureBoot verwendet werden muss und nicht deaktivierbar zu sein hat.
Selbst wenn es nun aber ein signiertes FreeBSD oder ein signiertes Linux geben sollte würde das immer noch bedeuten, dass nur der Generic Kernel (oder Vendor-Kernel bei Linux) signiert ist und man mit einem selbstgebackenen Kernel Probleme bekommt. Von GPL Problematiken im Linux Lager ganz zu schweigen.
Siehe:http://blogs.computerworlduk.com/op...linux-booting-on-arm-based-hardware/index.htm
Selbst wenn es nun aber ein signiertes FreeBSD oder ein signiertes Linux geben sollte würde das immer noch bedeuten, dass nur der Generic Kernel (oder Vendor-Kernel bei Linux) signiert ist und man mit einem selbstgebackenen Kernel Probleme bekommt. Von GPL Problematiken im Linux Lager ganz zu schweigen.
Siehe:http://blogs.computerworlduk.com/op...linux-booting-on-arm-based-hardware/index.htm
christian83
Well-Known Member
Die Sache ist nun mal so das Microsoft Angst hat in Zukunft den Anschluss zu verlieren. Egal was man bis jetzt versucht hatte, abseits des Desktops hat Microsoft keinen wirklichen Erfolg. Mal abgesehen vom Konsolenmarkt. Windows Mobile konnte sich nicht wirklich durchsetzen. Windows Phone 7 nuckelt auch ganz weit unten bei den Marktanteilen. Nun soll Windows 8 das Ruder umreißen und dabei kann man kein Android auf Microsoft arm Hardware brauchen...
Aber ich bin mir schon relativ sicher das der Versuch auf mobilen Geräten einzu zu halten auch diesesmal scheitern wird. Android und IOS sind einfach zu weit verbreitet und Windows 8 ist genau wie Phone 7 für die Hersteller unaktraktiv weil es zu viele Vorschriften gibt. Außerdem gibt es keinen wirklichen Vorteil gegenüber bestehenden Systemen. Einzig die Möglichkeit Desktop Anwendungen auf einem Mobilen Gerät zu nutzen könnte ein interessantes Feature sein. Aber werden die Softwareentwickler wirklich anfangen diese "Metro Scripte" zu erstellen und ist die ARM Plattform auch leistungsfähig genug damit umzugehen?
Ich will jetzt Windows 8 nicht schlechtreden, aber vor jeder neuen Version wurde das System hochgepriesen und hat meist wenig der gemachten Versprechen gehalten. Außerdem war jede zweite Windows Version ein flopp
Grüße
Aber ich bin mir schon relativ sicher das der Versuch auf mobilen Geräten einzu zu halten auch diesesmal scheitern wird. Android und IOS sind einfach zu weit verbreitet und Windows 8 ist genau wie Phone 7 für die Hersteller unaktraktiv weil es zu viele Vorschriften gibt. Außerdem gibt es keinen wirklichen Vorteil gegenüber bestehenden Systemen. Einzig die Möglichkeit Desktop Anwendungen auf einem Mobilen Gerät zu nutzen könnte ein interessantes Feature sein. Aber werden die Softwareentwickler wirklich anfangen diese "Metro Scripte" zu erstellen und ist die ARM Plattform auch leistungsfähig genug damit umzugehen?
Ich will jetzt Windows 8 nicht schlechtreden, aber vor jeder neuen Version wurde das System hochgepriesen und hat meist wenig der gemachten Versprechen gehalten. Außerdem war jede zweite Windows Version ein flopp
Grüße