Hardware und Architekturen - ein Flickenteppich ohne Standards?

[McMoneysack91]

Liebe Freunde,

Als Linux-User habe ich gelernt, dass Linux im Grunde nur der Kernel ist, während der Rest des Betriebssystems ein Haufen zusammengewürfelter Software ist. Somit gibt es nicht DAS Linux-OS sondern unendlich viele. Die Diskussion, ob Linux nun eine Community ist, oder ein gesplitteter Haufen kleiner Lager, die ihr eigenes Süppchen kochen, habe ich bereits in einem separaten Thread diskutiert.

Doch diese Betrachtungsweise lässt mich Ähnliches bei Hardware vermuten oder gar fürchten. Wir alle kennen die "Giganten" der Architekturen x86 und amd64. Intel und AMD sind da die Vorreiter. So gut wie jedes OS funktioniert auf diesen Architekturen in seiner Gänze.

Beim Thema ARM wurde ich ein wenig ernüchtert. Anscheinend gibt es nicht DAS ARM. Raspberry Pi ist scheinbar eine andere ARM Architektur als andere ARM SBCs. Fasziniert von den vielen SBCs las ich gespannt von den sogenannten "Raspberry Pi Killer" wie z.B. BananaPi M2. Die Specs waren definitiv beeindruckender, als die des Raspberries. Doch etliche Reviews sagten, dass der Software Support miserabel sei. Etliche Funktionen seien noch nicht einmal einsatzbereit oder unterstützt etc.

Da fragte ich mich...hä? Es ist ein ARM SBC. Kann ich da nicht einfach ARM-Debian draufpacken und alles läuft rund? Warum läuft RaspberryPi-OS auf einem RaspberryPi fantastisch, auf einem anderen ARM SBC jedoch katastrophal?

Insbesondere bei SBCs habe ich derzeit das Gefühl, dass jeder Hersteller, der seine Hardware herausbringt, auch unbedingt seine Software herausbringen muss, bzw der Endnutzer muss hoffen, dass der Hersteller dies tut. Denn sonst hat man ein SBC mit tollen Specs, welches jedoch zu nichts zu gebrauchen ist. Bei den SBCs habe ich momentan den Eindruck, dass es eher eine Glückssache ist, ob ein aus dem Boden sprießender neuer "RaspberryPi Killer" wirklich was taugt, und wenn er anfänglich was taugt, dann dass seine Herstellerfirma nicht morgen pleite geht und verschwindet und man quasi nur noch Plastikmüll vor sich hat.

Okay, ich habe einen Gedankenansatz, warum diese Giganten wie x86 von allen OS so unterstützt werden. Weil z.B. Intel oder AMD jede Menge Mühe gemacht haben, dass ihre Firmware, Treiber etc den ganzen OS-Entwicklern für die Implementierung in die Kernels gegeben wurden. Oder?

Ich schätze auch die Raspberry Foundation hat die entsprechende Manpower, um in Zusammenarbeit mit Linux auf Basis von Debian ein OS aufzusetzen, das sämtliche Bauteile und Elemente des RPi voll zur Geltung bringt. Andere SBC Hersteller (noname oder homemade Projekte) haben diese Ressourcen (Zeit, Geld, KnowHow) nicht und versuchen selbst eine gewisse Basis für ihre Hardware zu schaffen, welche dann eben so lückenhaft ist.

Kann man das in etwa so sehen?

 

[ghecko]

Mal abgesehen von den verschiedenen ARM Architekturen (Versionen) sind die meisten dieser SOCs ziemlich speziell. Speziell im Sinne von: Es sind keine PCs. So Dinge die der Kernel bei einem standardisierten PC an gewohnter Stelle vorfindet, existieren bei ARM nicht oder werden über einen anderen Bus/Adresse exponiert.
Was für Steine dem Kernel da manchmal im Weg liegen veranschaulich das Video ganz gut:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

Und da jeder Hersteller mit seinem SOC machen kann was er will, herrscht da Wildwuchs. Dazu kommen die ganzen proprietären Lösungen für Grafik etc, die ihren Weg in den SOC finden. Jeder Hersteller hat Angst dass ein anderer ihm was weg klaut, also sind Dinge wie Treiber closed source und werden vom Hersteller in angepasste Kernel gebacken, damit ja kein anderer nachvollziehen kann wie was funktioniert.

Somit muss der Kernel für solche SOCs stark angepasst werden, damit er funktioniert. Viele weniger bekannte Boards bedienen sich zb. einem Android-Kernel, den der Hersteller für den SOC veröffentlicht hat und bauen den in eine Distribution, weil sie sonst kein performantes System haben was auf ihrem SBC läuft.

Ich denke aber wenn die Verbreitung von ARM steigt, wird sich das abseits von den SOCs auf dem Desktop standardisieren. Dann sollte sich das eher wie x86 verhalten. Embedded ist halt eine andere Welt. Und SBC gehören dazu.

 

[Chesterfield]

In den Grundzügen verstehe ich was du meinst, aber es ist meiner Meinung nach nur aus einer Sicht betrachtet.
Diese „Flickenteppiche“ die du meinst sind vllt genau das was man braucht. Individualisierte Bedürfnissorientierte Software. Nur so kann neues und vielfältiges auch in Sachen soft und Hardware entstehen. Letzen Endes muss man sagen , dass genau das auch den Fortschritt herbeiführt indem man immer besser werden will und maßgeschneiderte soft/Hardware liefert.
Kleines Beispiel, viele nutzen den RasPi für ne Heizungssteuerung. Jedoch ist das zwar ähnlich anders dennoch anders als die Leute die damit ein Smarthome betreiben . Jeder hat individuelle Bedürfnisse , aber der Grundbaustein ist immer gleich … in dem Fall das steuern von irgendwas …
Daher verstehe ich deinen Beitrag auch nicht so ganz ob du es eher kritisch meinst oder uns nur ein Einblick deiner Gedanken geben willst.
Architekturen , wie der Name sagt überdauern nur eine Zeitspanne … es kommt eines Tages was neues und besseres und in der Regel lernt man immer dazu und wird besser und oder effizienter

 

[Karre]

Deine Baustelle heißt Treiber, nicht OS

 

[McMoneysack91]

@Chesterfield ich weiß selbst nicht ganz, ob ich das kritisch sehen soll oder nicht aber meine Gedanken wollte ich sowieso kund tun

Da ich ein Laie bin, drücke ich mich mal aus wie ein Laie:

Angenommen ich verwende einen ganz normalen x86 PC mit Intel CPU. Auf dem PC läuft Windows. Ich weiß jetzt schon, dass wenn Microsoft von heute auf morgen verschwindet und Windows hinüber ist, dann wechsel ich einfach zu Linux. Und wenn das futsch ist dann wechsel ich eben zu FreeBSD. X86 ist eine gewaltig verbreitete Architektur und ich weiß, dass zig Leute zig OS dafür schreiben. Und die Hersteller der ganzen Komponenten wie Grafikkarten etc stellen mit Treibern sicher, dass die Hardware auch dadrin funktioniert. Peace of mind also.

Wenn ich mir aber etwas so spezielles wie ein Banana Pi Zero M2 anschaue. Nettes Board und hoffentlich nettes Team dahinter. Aber sollte dieses Team von heute auf morgen verschwinden, dann ist mein BananaPi Zero M2 fürn Eimer. Ein Insel/randprojekt von einer Insel/Randgruppe mit Insel/Randunterstützung.

OOOOODER aber ich sehe den Elefanten im Raum nicht. Ich erinnere mich an eine Folge von Explaining Computers mit Christopher Barnatt wo er RISC-OS präsentierte. Ich meine, er präsentierte es sogar auf einem Raspberry Pi, wenn ich mich nicht täusche. ARM Cpus folgen doch der RISC Mentalität, während x86 CISC folgt, oder? Ist es dann vielleicht so, dass z.B. sowas wie RISC-OS für ALLE ARM PCs und Boards verwendbar ist, nur vielleicht an manchen Ecken und Kanten nicht SOOO flüssig wie das "proprietäre" OS des Entwicklers selbst? Quasi nVIDIA-Style. Raspberry Pi OS ist für den Raspberry Pi optimiert, aber andere ARM OS laufen drauf auch. Sprich wenn die Raspberry Foundation morgen das Licht ausmacht, dann gibt es nach wie vor etliche OS-Kandidaten, die auf meinem Pi Einkehr finden könnten?

Kann man das in etwa so pauschal und laienhaft stehen lassen?

 

[DorMoordor]

Du darfst aber auch nicht vergessen, dass alle x86 Boards ein Bios haben. Da werden alle Informationen über die Peripherie und wie die angesprochen wird abgelegt. Das gibt es bei Arm nicht und muss dem OS anderweitig übergeben werden. Unter Linux wurde dafür der Device Tree Blob eingeführt, damit das OS weiß welche Treiber geladen werden müssen.
Und ein weiterer Unterschied ist, jeder Hanswurst kann Arm lizenzieren und ne CPU herstellen. Da gibt es keine explizite Vorgaben, was die Cpu können muss. Bei amd64 hast du derzeit noch die ganzen Abwärtskompatibilitäten, damit auch möglichst viel darauf läuft.
Also das eine ist dafür gemacht möglichst viele normale Einsatzzwecke abzudecken und das hat sich die Nische der stromsparenden spezial Anwendungen gesucht. Das ändert sich zwar gerade, aber
in der Vergangenheit war Arm keine wirkliche Alternative zu amd64. Deswegen erstmal ne Nische um groß zu werden und wir können gerne in fünf Jahren nochmal drüber reden, aber ich denke dann wird es für Desktop Arm ähnlich aussehen, wie bei amd64. Bei Embedded wirds eher so bleiben. Das soll halt so stromsparend wie möglich sein und damit auch so wenig wie möglich extra Zeug (BIOS/UEFI, CPU Instruktionen...)

 

[McMoneysack91]

Ich verstehe so langsam den Hintergrund. Jetzt muss ich aber x86 an dieser Stelle in Puncto Stromsparsamkeit verteidigen. Ich habe einige MiniPCs mit Intel Atom x5-z8350 Quad Core CPUs. Im idle verbrauchen sie selbst mit sowas abstrus schwerem wie Win10 um die 2W. Das ist im Grunde der Verbrauch eines Raspberry Pi 4B. Wenn ich den x86 Mini PC mit was schön leichtem wie Debian XFCE/OpenBox füttere, dann schläft das Teil ja nahezu. Auch habe ich ein HP Tablet, welches einen x86 Prozessor hat. In dem Sinne ist x86 sehr wohl in der Lage absolut minimalistisch und stromsparend daherzukommen.

Sicher, ein Raspberry Pi Zero W verbraucht nur etwa 0,7W idle, aber da reden wir auch von 1GHz single core CPU mit 512MB RAM. Ich denke ein x86 PC mit diesen specs würde ähnlichen Verbrauch erzielen.

=======

Zurück zum Thema:

verstehe ich also richtig, dass in erster Linie die Treiber das "treibende" Problem sind? Verzeih den Wortwitz. Wenn ein Hersteller eine Hardware produziert (z.B. Broadcom baut eine WLAN Karte) dann muss der Hersteller auch Treiber zur Verfügung stellen, die dann die ganzen Betriebssysteme in ihren Kernel aufnehmen? Kann man das so sehen? Sprich daher auch die Probleme mit nVIDIA bei Free OpenSource OS wie Linux, weil nVIDIA ihre Treiber proprietär hält?

Heißt das im Umkehrschluss, dass wenn die Raspberry Foundation jetzt ALLE Treiber für ALLE Komponenten ihrer Boards offenlegt, dann können alle OS wie z.B: Linux, FreeBSD, RISC-OS diese Treiber in ihre Kernels implementieren und selbst wenn Raspberry Froundation morgen abdankt, dann ist ja ihr Erbe eben diese freigelegten Treiber und obwohl keine neuen Pis produziert werden, so sind die alten nicht Plastikschrott, sondern können von allen OSs weiter unterstützt und betrieben werden?

DAS wäre z.B. ein Hoffnungsschimmer. Dann wäre die Tendenz, sich nicht an Nischenprojekte zu orientieren, sondern an die "großen" wie etwa die Raspberry Foundation, weil diese ja das Interesse der OS auf sich ziehen und mit größerer Wahrscheinlichkeit aufgenommen werden, als ultra Randerscheinungen.

Sehe ich das soooo ungefähr richtig?

 

[DorMoordor]

Ich habe einige MiniPCs mit Intel Atom x5-z8350 Quad Core CPUs. Im idle verbrauchen sie selbst mit sowas abstrus schwerem wie Win10 um die 2W. Das ist im Grunde der Verbrauch eines Raspberry Pi 4B.

Du hast schon Recht. Im Grunde nehmen sich die Architekturen nicht viel. Bei amd64 hat sich halt für den Desktop ein riesiger Speckgürtel angesammelt, der den IDLE Verbrauch ansteigen lässt.

Wenn ein Hersteller eine Hardware produziert (z.B. Broadcom baut eine WLAN Karte) dann muss der Hersteller auch Treiber zur Verfügung stellen, die dann die ganzen Betriebssysteme in ihren Kernel aufnehmen?

Nicht unbedingt. Die "Treiber" für CPUs kommen in den Kernel. Treiber für Peripherie (WLAN-Karten zähle ich jetzt dazu) müssen nicht unbedingt in den Kernel, die können auch extra geliefert werden.

Bei Open Source Treibern kann halt jeder den Treiber an den neuesten Kernel anpassen. Damit ist es egal, ob die Firma noch existiert oder nicht, so lange jemand die Treiber braucht und die Zeit und den Elan hat wird der Treiber aktuell gehalten. Selbst wenn er nicht im Kernel ist.
Bei proprietären Treibern muss das halt die jeweilige Firma machen. Und weil das Zeit kostet und somit Geld, gibt es halt nur Treiber für die nächsten X (oft 3-10) Jahre. Sieht man sehr gut an den ganzen Android Smartphones, die keine Android Updates mehr bekommen. Zum einen liegt das an den Smartphone Herstellern und zum anderen an den Treibern der verbauten Module, die oft nur Treiberupdates von 3 bis 5 Jahren bekommen.

Dann wäre die Tendenz, sich nicht an Nischenprojekte zu orientieren, sondern an die "großen" wie etwa die Raspberry Foundation, weil diese ja das Interesse der OS auf sich ziehen und mit größerer Wahrscheinlichkeit aufgenommen werden, als ultra Randerscheinungen.

Naja die "Bausteine" sind sehr oft auch bei den "Kleinen" die gleichen. Es liegt nicht direkt am Treiber sondern (bei ARM SBCs) was an welchem internen GPIO der CPU hängt. Das hat sich mit den Device Tree Blobs verbessert, aber vorher musste dem OS halt ganz genau gesagt werden GPIO123 der CPU ist GPIO4 des GPIO-Headers. Das steht jetzt alles im Device Tree Blob. Und der ist bei den meisten ARM SBCs öffentlich.
Aber wenn der Hersteller pleite geht, ist die Wahrscheinlichkeit, dass ein OS für eine bekanntere Plattform aktuell gehalten wird, größer als bei Nischenprodukten (es sei denn du hast Ambitionen dir dein Linux selber zu kompilieren und zu warten).