Bei diesem Artikel handelt es sich um einen Meinungsbeitrag!
Mit dem Aufkommen der ersten Smartphones zog eine neue CPU-Architektur immer mehr Aufmerksamkeit auf sich. So neu war sie eigentlich gar nicht: Bereits im Jahr 1983 wurde die ARM Architektur entwickelt. Aber durch den Einsatz in weniger leistungsfähigen Embedded-Geräten und nicht-smarten Handys war sie für die grosse Masse weitestgehend unsichtbar.
Die Vorteile lagen auf der Hand: Die SoCs vereinen die wichtigsten Chips eines Computers in nur einem Bauteil, sind günstiger und verbrauchen deutlich weniger Strom. Mit Leistungen im MHz Bereich und wenigen hundert Megabyte Arbeitsspeicher waren sie für Intel und AMD in Computern keine ernstzunehmende Konkurrenz. Das hat sich geändert, ARM bringt mittlerweile vergleichbare Leistungen bei geringerem Stromverbrauch und kommt sogar in grossen Servern zum Einsatz.
Doch der Siegeszug von ARM fordert auch seine Opfer. Dazu zählt in jedem Fall die freie Software. Natürlich wird in jedem Android Handy der Linux Kernel eingesetzt, aber dieser wurde um unfreie Treiber erweitert, was im Übrigen die GPL Lizenz des Linux Kernels verletzt, aber angesichts der wenigen Klagen scheint das die Hersteller kaum zu interessieren.
Es haben sich Projekte entwickelt, die mit viel Geduld, Manpower und Aufwand versuchen, freie Custom ROMs für ein paar bestimmte Handymodelle zu entwickeln. Jedes neue Modell ist wieder eine riesige Herausforderung, die Arbeit beginnt von neuem. Natürlich könnte man auch den Herstellern die Schuld geben, die hier ganz klar Lizenzen verletzen und somit die Nutzung von freier Software erschweren. Ich denke aber, das eigentliche Problem liegt schon im Design der Architektur.
Selbst wenn alle Herstellertreiber Open-Source wären, müsste man für jedes einzelne Gerät ein eigenes Image des Custom ROMs liefern, oder die Device Trees für jedes einzelne Gerät in einem riesigen Image zusammenfassen. Das Problem liegt bei fehlender Hardwareerkennung und fehlenden Standardtreibern. Schon alleine die Tatsache, dass in jeder neuen Linux Kernel Version 70000 Codezeilen für ARM Bauteile hinzugefügt werden müssen, während es bei x86 nur etwa 5000 sind, zeigt, dass hier etwas gewaltig schiefläuft.
Ein ARM Gerät weiss einfach nicht, welche Bauteile es besitzt, an welchen Anschlüssen sie sich befinden und wie sie angesprochen werden müssen. Beim normalen Computer weiss es das BIOS. Das System startet in jedem Fall, man bekommt zumindest VESA Grafik und die PS/2 Tastatur funktioniert. Wenn passende Treiber für die Hardware vorhanden sind, werden diese automatisch erkannt und verwendet und wenn nicht, hat man mit den Standardtreibern ein Gerät, das zumindest eingeschränkt nutzbar ist.
Dieses eingeschränkte System bringt natürlich auch eine solide Basis mit, um fehlende Treiber zu ermitteln und zu versuchen, welche zu entwickeln. Bei ARM ist das nicht der Fall. Wenn ich nicht bereits das passende Image für exakt meine Hardware habe, wird das System gar nicht starten. Ich tappe im Dunkeln und wenn ich nicht gerade zufällig einen Hersteller erwischt habe, der sich doch an die GPL hält und seinen Kernel Fork veröffentlicht, besteht wenig Hoffnung, mein System zum Laufen zu bringen.
Es gibt natürlich auch Ausnahmen. Zum Beispiel den Raspberry Pi, auf den mittlerweile fast jedes freie System portiert wurde. Der richtet sich aber auch speziell an Entwickler und Bastler, weniger an den Endverbraucher. Und selbst der funktioniert nicht ohne proprietäre Binärblobs, die den Bootvorgang starten. Oder den Apple M1, der so viel Aufmerksamkeit auf sich zog, dass man durch Reverse Engineering innerhalb kürzester Zeit fast jeden Treiber als freie Software nachgebaut hat.
Aber auf einem Billighandy des Herstellers A543B44K Modell B442K53 kann ich nicht einfach eine beliebige Linux Distribution mit einem standardisierten ISO installieren. Und das ist ein Problem. Es schränkt die freie Auswahl des Betriebssystems massiv ein. Und es liegt eben nicht nur an den Herstellern. Dass diese eine Mitschuld tragen, steht ausser Frage. Aber der Aufbau von ARM selbst ist ein wichtiger Faktor für diese Einschränkungen.
Besorgniserregend finde ich das vor allem deshalb, weil die ARM Architektur immer mehr zu einem ernstzunehmenden Konkurrenten für Intel und AMD wird, auch auf dem Desktopmarkt. Das hat Apple erst vor wenigen Monaten mit seinem M1 Chip eindrucksvoll gezeigt. Dieser kann problemlos mit High End CPUs von Intel und AMD mithalten und braucht dabei noch viel weniger Strom.
Beim grossen Aufschrei rund um Meltdown bei Intel und Spectre, was auch AMD betraf, wünschte ich mir noch, ARM würde sich auch im Desktopmarkt durchsetzen. Es schien die bessere Wahl zu sein, denn es braucht keine Management Engine, die selbst ein kleines Betriebssystem in der CPU mitbringt. Dass es effizienter ist, also mehr Leistung mit weniger Stromverbrauch bringt, war ebenfalls verlockend. Und natürlich die Preise, ARM SoCs sind einfach günstiger.
Viele wünschten sich das. Etwas, was damals noch unrealistisch erschien. Nun scheint es immer realistischer zu werden und ich möchte diesen Wunsch gerne rückgängig machen. Ich habe damals übersehen, wie schwierig es für die freien Betriebssysteme werden würde. Ich dachte wohl eher an gut funktionierende Beispiele wie den Raspberry Pi, aber am Ende wird sich die Betriebssystemauswahl auf den meisten ARM Computern wohl eher so verhalten, wie auf billigen Android Handys.
Wenn ich mich recht erinnere, hat der Einsatz von ARM in Laptops mit den Chromebooks begonnen. Google gibt sich grösste Mühe, die Installation von anderen Systemen auch auf Intel Chromebooks zu erschweren - sehr erfolgreich, wie ich leider zugeben muss. Aber es wurden schnell Hacks gefunden, um eben doch von einem externen Datenträger booten zu können und alles ab da ist kein grosser Unterschied mehr zu einem Laptop mit vorinstalliertem Windows.
Bei ARM ist die Sache komplizierter. Hier muss zunächst einmal ein spezielles Image für genau dieses eine Chromebook existieren, um es starten zu können. Und das funktioniert dann wirklich nur genau auf diesem einen Modell und keinem anderen. Ich habe hier mal ein Projekt herausgesucht, mit dem man Linux auf ARM Chromebooks eben doch installieren kann. Wie man sieht, werden hier nur wenige bestimmte Geräte unterstützt und das Ganze ist eine eigene Linux Distribution, es ermöglicht nicht die Nutzung jeder beliebigen Distribution.
Doch die grosse Mehrheit aller Computer kommt ja mit Windows und das ist noch immer auf x86 CPUs beschränkt, oder? Nein, auch Microsoft findet mittlerweile Gefallen an ARM. Es besitzt sogar eine Kompatibilitätsschicht, um ganz normale x86 Programme ausführen zu können. Bei der Nutzung von Linux oder anderen freien Betriebssystemen ist das aber leider nicht hilfreich. Man kann darauf hoffen, dass die Gamer-Szene den Durchbruch von ARM auf dem Desktop noch eine Zeit lang verzögert, denn nativ läuft es einfach schneller, als mit einer Kompatibilitätsschicht. Wenn mehr Software und Spiele auch direkt für Windows auf ARM kommen, stehen uns aber schwierige Zeiten bevor.
Heute gibt es noch jede Menge Computer mit x86 CPU und wenn man freie Software nutzen will, kauft man einfach so einen. Ich sehe da aber Probleme. Erstens entwickelt sich ARM deutlich schneller weiter, als x86. Ich denke, in einigen Jahren könnte x86 irrelevant und selten sein, wenn sich diese Entwicklung nicht umkehrt. Klingt unrealistisch? Nun, das dachte man früher über PowerPC bestimmt auch und jetzt schaut mal, wo es heute steht.
Und zweitens, was ist, wenn ich bereits einen ARM Computer habe, weil ich Windows gut fand und erst später angefangen habe, mich für freie Software zu interessieren? Ein Wechsel wird jetzt schwieriger. Entweder muss ich genau dieses eine Image finden, das auf meinem speziellen ARM Computer funktioniert oder ich muss mir neue Hardware kaufen, um eine beliebige Linux Distribution installieren zu können. Das setzt die Hemmschwelle enorm hoch.
Eins ist klar: Ich werde bei x86 CPUs bleiben, solange es so etwas noch zu kaufen gibt. Auch wenn sie unfrei sind, sind sie eine deutlich bessere Plattform für freie Software, als die ebenfalls unfreie ARM Architektur. Zumindest so lange, bis dem wirklich freien RISC-V der grosse Durchbruch gelingt und es mit der Leistung moderner Intel und AMD Chips mithalten kann.
Warum schreibe ich genau jetzt über dieses Thema, werden sich bestimmt einige fragen. Nun, einen top aktuellen Anlass gibt es nicht. Mir ist dieser Gedanke vor ein paar Tagen ganz spontan gekommen, vielleicht, weil ich mich zurzeit vermehrt mit mehr und weniger freien CPU Architekturen beschäftige. Vielleicht habe ich mich auch wieder einmal über mein dämliches Android Handy aufgeregt, auf dem ich gerne Linux installieren würde. Ich weiss es nicht mehr, aber ich hielt es für wichtig genug, um diesen Artikel zu verfassen.
Quellen:
- Bild: https://commons.wikimedia.org/wiki/File:Arm_logo_2017.svg
- https://de.wikipedia.org/wiki/Arm-Architektur
- https://www.areamobile.de/Galaxy-Tab-Tablet-273552/News/Viel-nehmen-wenig-geben-Viele-Tablet-Hersteller-verstossen-gegen-Lizenzrecht-1305845/
- https://www.zdnet.com/article/one-linux-for-all-arm-systems/
- https://de.wikipedia.org/wiki/BIOS#Funktionen
Danke, wirklich guter Beitrag. Ich werde ebenfalls ARM so gut wie möglich meiden und freue mich sehr auf RISC-V.
Servus
Aus meiner Sicht nein. Das Problem ist nicht ARM. Es sind die vielen Hersteller, die keine Sourcs von Devicetreibern zur Verfügung stellen. Ich sprech hier über Linux. Und gute Beispielen sind nicht nur der RASPI sondern zB auch die ganzen Beagles. Dieses Problem ist großteils auf mobile devices focusiert.
lg Sepp
Ich habe mich vor 15 Jahren riesig gefreut als mein ATNGW100 Board endlich ankam, war aber schnell von compiler-Orgien und root-on-sd-card genervt.
Die Euphorie und der Gedanke "da läuft Linux drauf", wenn ich seit dem ein Android oder anderes embedded Gerät in der Hand hatte blieb aber noch lange.
Produkt XY irgendwo eingesammelt, schnell im Netz gesucht, man findet UART pinout und ein buildroot fork, ab ins "Lager". So liegen hier mittlerweile zwei Fleischerkisten von mit solchen Teilen, vom Handy über SAT Receiver bis zu einem ungeöffneten Banana Pi M1 Router oder so ähnlich.
Der Gedanke eines "BIOS-artigen" Standards für embedded Geräte kam mir noch nie. Nach deinem Artikel wird mir aber langsam klar, das Fehlen eines solchen und das fehlen von fertigen ISOs wie beim PC nimmt mir immer wieder den Spass daran.
Ich will [ssh, zsh, einen compiler, mc, nano, man] und dann auf dem Teil für das Teil die jeweilige Anwendung basteln und Spass daran haben. Ewiges Compilieren, Ausprobieren, zu viel Lesen und gar am Schluss noch ein eigenes Init-System und rootfs-Overlay-Hack-Dingens bauen macht einfach keinen Spass. Der I²C Adapter über die FritzBox LEDs und die LED-Streifen Steuerung im Hausflur bauen und programmieren hingegen schon. Leider fehlt einem dann schon die Luft, wenn man das leere Makefile fürs neue Projekt endlich angelegt hat und drüber nachdenkt, wie man nun anfängt.
Den PowerPC finde ich nen schlechten Vergleich. Der kam nach x86, wie ARM. Und war auch nie wirklich Dominant.
https://georgi.family/notice/AEES28DlDmAm2s4jHk <- ist eine Diskussion zum Artikel mit einem langen Beitrag von Patrick Georgi
Danke für dein Beitrag, das war mir nicht bewusst und ändert meine Sicht darauf ebenfalls.
Ich weiß nicht. Historisch betrachtet ist das bei x86 nur anders, weil diese Platform unter anderem als IBM PC begann, der eben ein proprietäres, spezielles BIOS hatte. Durch IBM’s Dominanz an einem lukrativen Markt wollten andere Hersteller (z.B. Compaq) ebenfalls mitmischen, und haben quasi dieses BIOS reverse-engineered. (Chips etc. waren bei Intel zu kaufen, aber eben das BIOS nicht), wodurch dann der Markt der IBM-kompatiblen entstand. MS DOS, Windows, … der Rest ist Geschichte. Weiterentwickelt wurde dann auch gemeinsam, weswegen wir heute UEFI haben. ARM hingegen hat eine kompliziertere Entstehungsgeschichte – mit viel embedded-Lösungen, die quasi „ein Wald von Einzelfällen" waren und bei denen man lange auch nicht von Software sprach, sondern jegliche Software Firmware nannte. Darunter leidet die Platform bis heute – es gibt ARM-Boards mit OpenFirmware (OLPC), mit UEFI (Windows-Tablets, mehr oder weniger zugenagelt), mit CoreBoot (ChromeBooks), bei denen man teilweise (definitiv bei OpenFirmware) nicht mit Device Trees rumhampeln muss.
Der andere Faktor, und da stimme ich dir zu, ist die Treiberentwicklung bzw. Linux-Portierung. Hier rotzen sehr viele ARM-SoC-Hersteller nur irgendwas hin womit dann irgendwie Android läuft und eilen dann weiter zum nächsten Produkt (auch wegen eines relativ harten Wettbewerbsumfelds) – und auch da dann IP von verschiedensten Partnern verbaut ist, bleibt die Mainline-Arbeit bei der Community hängen und dauert je nach Chip lange, und manche SoC-Komponenten (z.B. VPUs) funktionieren erst nach Jahren oder nie mit freien Treibern.
Bei Intel und AMD hingegen kümmert man sich mehr um Linux-Treiber, vor allem wegen des Server-Markts – und auch weil man es sich „leisten kann“, da der Wettbewerbsdruck in einem Prozessormarkt mit drei Marktteilnehmern (VIA (bzw. Rechtsnachfolger/chinesische Partner mischt ja auch noch hin und wieder mit, aber da VIA es sich nicht leisten kann, ist der Linux-Support da auch oft eher mies) eben die Margen bietet, die die ARM-Lizenznehmer nicht haben.
Bei RISC-V befürchte ich ähnliches Chaos, da hier potenziell noch weniger standardisiert ist – aber wer weiß, vielleicht geschieht ja ein Wunder.
Also, TLDR: Das Problem ist nicht ARM, die x86-Welt ist durch glückliche Zufälle eben besser vereinheitlicht und hat dadurch, dass der Wettbewerb geringer ist und die Wettbewerber in Linux-Treiber zu investieren können, einen besseren Linux-Support.