Schön zusammengefasst, leider nicht wirklich korrekt. Das gilt so für einige ARM-Boards, aber nicht für ARM-Boards generell. Einige der ARM-SoCs werden vom Mainline-Kernel unterstützt und somit dank device tree auch die Boards, die diese nutzen. Insbesondere kann man hier den Freescale i.MX6 hervorheben (und eben NICHT den Raspi!). Bei z.B. einem Wandboard muss man mit einem puren Vanilla Kernel zwar auf 3D-Beschleunigung und WLAN/BT verzichten, aber es läuft. WLAN ist hierbei ein eigenständiger Chip, der halt nicht sonderlich gut unterstützt ist und für 3D-Beschleunigung ist ja selbst am PC durchaus ein Binärblob notwendig (siehe insb. NVidia). So verwundert es auch nicht, dass man ein solches Wandboard, trotz im Vergleich zum Raspi mickrigen Community, mit Kernel 4.3 betreiben kann (und eben nicht bei 4.1 hängt).
ARM-Prozessoren sind dabei so unterschiedlich aufgebaut wie x86-Prozessoren. Die gibt es auch mit unterschiedlichsten Instruktionserweiterungen etc. und dennoch gibt es eine gewisse Aufwärtskompatibilität. So wie i386-Code auf einem modernen Core i läuft, so läuft ein ARMv5-Binary (ala Raspi1) auf einem ARMv7 (ala Raspi2). Umgekehrt jedoch nicht. Weder läuft das ARMv7-Binary auf dem ARMv5, noch ein für den Core kompiliertes 32-Bit-Binary auf dem i386 (wirft mitunter "illegal instruction").
Ja selbst für die allgemein genormte PC-Initialisierungs-Schnittstelle BIOS (genauer: ACPI), so dass ein und der selbe Kernel auf unterschiedlichsten Maschinen booten kann und die es so direkt bei ARM nicht gibt, gibt es eine Lösung: Mit Hilfe eines "Device Tree" genannten Konstrukts kann ein und das selbe Kernel-Kompilat auf unterschiedlichsten Boards starten und die jeweils unterschiedlich konfigurierte Hardware initialisieren (z.B. GPIOs Funktionen zuweisen etc.). Bei proprietären Boards ala Raspi und Allwinner gibt es das so direkt AFAIK nicht, da hängt man dann bei einem speziellen Kompilat für ein bestimmtes Board fest.
Von Ist nur ein Pseudonym am Sa, 12. Dezember 2015 um 23:52 #
Danke für die Ergänzungen! Ich habe dadurch wieder etwas dazugelernt.
Wie oben geschrieben, das war mein bisheriges Verständnis zum Thema, ohne Anspruch auf 100%ige Korrektheit.
Bleibt zu hoffen, das mehr und mehr Boards offener werden und den von Dir beschriebenen Device Tree unterstützen. Allerdings habe ich da nicht besonders viel Hoffnung in Anbetracht der letzten Jahre im Embedded-Bereich.
Schön zusammengefasst, leider nicht wirklich korrekt. Das gilt so für einige ARM-Boards, aber nicht für ARM-Boards generell. Einige der ARM-SoCs werden vom Mainline-Kernel unterstützt und somit dank device tree auch die Boards, die diese nutzen. Insbesondere kann man hier den Freescale i.MX6 hervorheben (und eben NICHT den Raspi!). Bei z.B. einem Wandboard muss man mit einem puren Vanilla Kernel zwar auf 3D-Beschleunigung und WLAN/BT verzichten, aber es läuft. WLAN ist hierbei ein eigenständiger Chip, der halt nicht sonderlich gut unterstützt ist und für 3D-Beschleunigung ist ja selbst am PC durchaus ein Binärblob notwendig (siehe insb. NVidia). So verwundert es auch nicht, dass man ein solches Wandboard, trotz im Vergleich zum Raspi mickrigen Community, mit Kernel 4.3 betreiben kann (und eben nicht bei 4.1 hängt).
ARM-Prozessoren sind dabei so unterschiedlich aufgebaut wie x86-Prozessoren. Die gibt es auch mit unterschiedlichsten Instruktionserweiterungen etc. und dennoch gibt es eine gewisse Aufwärtskompatibilität. So wie i386-Code auf einem modernen Core i läuft, so läuft ein ARMv5-Binary (ala Raspi1) auf einem ARMv7 (ala Raspi2). Umgekehrt jedoch nicht. Weder läuft das ARMv7-Binary auf dem ARMv5, noch ein für den Core kompiliertes 32-Bit-Binary auf dem i386 (wirft mitunter "illegal instruction").
Ja selbst für die allgemein genormte PC-Initialisierungs-Schnittstelle BIOS (genauer: ACPI), so dass ein und der selbe Kernel auf unterschiedlichsten Maschinen booten kann und die es so direkt bei ARM nicht gibt, gibt es eine Lösung: Mit Hilfe eines "Device Tree" genannten Konstrukts kann ein und das selbe Kernel-Kompilat auf unterschiedlichsten Boards starten und die jeweils unterschiedlich konfigurierte Hardware initialisieren (z.B. GPIOs Funktionen zuweisen etc.). Bei proprietären Boards ala Raspi und Allwinner gibt es das so direkt AFAIK nicht, da hängt man dann bei einem speziellen Kompilat für ein bestimmtes Board fest.
RPi kennt Device Tree inzwischen zumindest zum Teil:
https://www.raspberrypi.org/documentation/configuration/device-tree.md
Danke für die Ergänzungen! Ich habe dadurch wieder etwas dazugelernt.
Wie oben geschrieben, das war mein bisheriges Verständnis zum Thema, ohne Anspruch auf 100%ige Korrektheit.
Bleibt zu hoffen, das mehr und mehr Boards offener werden und den von Dir beschriebenen Device Tree unterstützen. Allerdings habe ich da nicht besonders viel Hoffnung in Anbetracht der letzten Jahre im Embedded-Bereich.