Überreife Himbeere
Wie es mit dem Raspberry Pi weitergeht
Pünktlich zum vierten Geburtstag hat die Raspberry Pi Foundation den bisher schnellsten Raspberry Pi herausgebracht. Der ist zwar 64-bittig und hat WLAN sowie Bluetooth an Bord, ansonsten hat sich aber wenig geändert. Warum eigentlich?
Vom neuen Raspberry Pi 3 hatten sich viele Anwender mehr RAM, endlich Gigabit-Ethernet oder wenigstens USB-3.0- oder SATA-Ports erhofft. Doch neben dem offensichtlichen Kostenfaktor gibt es weitere Gründe, die dem entgegenstehen. Er soll nicht nur kompatibel zu den bisherigen Versionen sein, auch die Systemarchitektur selbst ist recht speziell.
Architekturschau
Das wird bei einem Blick auf das System on a Chip (SoC) klar. Anders als man erwarten würde, handelt es sich bei den Broadcom-SoCs des Raspberry Pi (BCM2835 bis BCM2837) um Multimediaprozessoren mit angeflanschten ARM-CPUs und etwas Peripherie. Den Kern des SoC bildet der VideoCore IV, der an erster Stelle die Vector Processing Unit (VPU) enthält. Die VPU verfügt neben einer Vektoreinheit über zwei Skalareinheiten und spricht einen RISC-artigen Befehlssatz. Zur VPU gesellt sich ein 3D-Komplex für die Grafikschnittstelle OpenGL ES, eine Verarbeitungseinheit für Kameradaten (Image Sensor Pipeline, ISP) sowie Hardware-Unterstützung für Medienformate wie H.264 und JPEG (jeweils De- und Encoder) oder VC-1 und MPEG-1/-2/-4 (jeweils nur Decode). Formate, die nicht direkt in Hardware unterstützt werden (wie Theora, VP6 und VP8), können zumindest bis 720p von der VPU in Software dekodiert werden.
Zentrale VideoCore
Der VideoCore enthält wesentliche Systembestandteile wie den Speicher-Controller oder den L2-Cache (128 KByte, 4-fach assoziativ). Letzterer dient hierbei fast ausschließlich den Einheiten des VideoCore und wird bei CPU-Zugriffen in der Regel umgangen. Die ARM-CPUs wirken wie „danebengestellt“ – ein Eindruck, der sich durch den Ablauf des Bootprozesses bestätigt: Beim Systemstart sind weder RAM noch der ARM-Komplex initialisiert. Stattdessen arbeitet die VPU einen ersten Bootloader aus einem ROM ab, welches fest in das SoC „gebrannt“ ist.
Danach wird ein zweiter Bootloader von SD-Karte (bootcode.bin) in den L2-Cache geladen und gestartet. Er initialisiert den Arbeitsspeicher und lädt die VideoCore-Firmware, die einen dritten (!) Bootloader enthält (start.elf). Dieser teilt wiederum den Arbeitsspeicher zwischen VideoCore und ARM-Komplex auf und startet die ARM-Kerne, die dann das eigentliche Betriebssystem ausführen. So schrullig dieser Bootprozess aussieht – zur Entwicklungszeit des BCM2835-SoC gab es im ARM-Bereich keinen standardisierten Bootablauf oder gar eine normierte Systemarchitektur. Erst mit den Server-Ambitionen der ARMv8-Architektur entwickeln sich solche Standards.
Auch nach dem Bootprozess hat der VideoCore einiges zu tun: Dort läuft ein eigenes Betriebssystem (VideoCore OS, VCOS), das parallel zur ARM-Welt läuft. Hier befindet sich unter anderem ein OpenGL-ES-Treiber für den 3D-Teil des VideoCore inklusive dazugehörigem Shader-Compiler. Die Kommunikation zwischen VideoCore und ARM-Welt wird über eine „Mailbox“ realisiert, über die beispielsweise Befehle für den 3D-Treiber abgesetzt werden können. Ein auf den ARM-Kernen laufendes Linux benötigt also keinen vollständigen 3D-Treiber, um beschleunigte Grafik auszugeben, sondern lediglich eine Fassade, um Aufrufe an OpenGL ES über die Mailbox an den VideoCore weiterzureichen. So werden auch andere Funktionen, wie etwa die Video-Decoder, angesprochen.
Von den Eigenheiten des Broadcom-SoC bemerkt der Endanwender nichts. Die enge Verbindung mit der VideoCore-Architektur hat jedoch unmittelbare Auswirkungen auf die weitere Produktentwicklung des Raspberry Pi: Man kann den VideoCore zwar wie im Falle des Raspberry Pi 3 etwas höher takten, doch ohne Hilfe von Broadcom wird es keine Raspis mit größerem Hauptspeicher geben, weil der VideoCore IV nur 1 GByte ansteuern kann.
Broadcom im Wandel
In neue VideoCores sollte man jedoch keine allzu großen Hoffnungen setzen, denn Broadcom hat das VideoCore-Team aufgelöst. Das hängt mit der Entscheidung zusammen, sich ebenso wie etwa Texas Instruments oder Nvidia aus dem Smartphone-Markt zurückzuziehen, weshalb kein Bedarf für eine eigene Grafiktechnologie mehr besteht. Hinzu kommt, dass die SoC-Entwicklung umso teurer wird, je fortgeschrittener der verwendete Fertigungsprozess ist.
Da wundert es nicht, dass auch der neue BCM2837 noch in einem betagten 40-nm-Prozess hergestellt wird: Es mangelt nicht nur an einem Team, das einen Shrink der VideoCore-Architektur auf 28 nm betreuen könnte – auch sind mit dem Rückzug aus dem Massenmarkt die zu erwartenden Stückzahlen nicht groß genug, um die Kosten wieder einzuspielen.
Im Vergleich dazu ließen sich das Update auf den ARM Cortex-A53 des Raspberry Pi 3 vergleichsweise einfach und günstig realisieren. Als Lizenznehmer der ARM-Architektur stehen Broadcom Blaupausen für moderne ARM-Kerne zur Verfügung.
Beziehungsspiele
Dass die Auffrischung für den Raspberry Pi 3 überhaupt erfolgte, dürfte an der sehr innigen Beziehung zwischen Broadcom und der Raspberry Pi Foundation liegen. Der Gründer der Raspberry Pi Foundation, Eben Upton, hatte zuvor bei Broadcom an der VideoCore-Architektur mitgearbeitet. Die Entscheidung, beim Raspberry Pi auf Broadcom-Technologie zu setzen, lag also auf der Hand.
Da der BCM2836 und der BCM2837 (im Unterschied zum ursprünglichen BCM2835) bisher nur auf Raspis gesichtet wurden, kann man durchaus von Maßanfertigungen sprechen. Upton zufolge brauchte es jedoch einige Überzeugungsarbeit, damit Broadcom sie fertigte [1]. Grundlegend neue SoCs lassen sich alleine mit den Absatzzahlen des Raspberry Pi nicht finanzieren, zumal die Raspberry Pi Foundation noch nicht mal der größte Abnehmer der bisherigen Technologie ist.
Nachbars Garten
Der Raspberry Pi behauptet sich gegenüber anderen kostengünstigen ARM-Computern vor allem durch seine gute Software-Unterstützung und die verfügbare Zusatz-Hardware. Die Stabilität der Plattform ist für viele Nutzer (gerade auch im angepeilten Bildungsbereich) der entscheidende Grund, einen Raspi einzusetzen. Entsprechend ist die Raspberry Pi Foundation sehr darauf bedacht, die Kompatibilität zu bestehender Soft- und Hardware zu erhalten.
Weiterhin hat die Raspberry Pi Foundation erklärt, eine zunehmende Öffnung der Plattform anzustreben. Dies bezieht sich insbesondere auf den Code, der auf dem VideoCore läuft. Hierbei handelt es sich um Broadcom-Software, zu der kein Quelltext vorliegt (hier wird gerne von „Blobs“, also undurchsichtigen Binärdaten, geredet). Dass sich Betriebssysteme auf dem Raspberry Pi auf Funktionen stützen müssen, die von proprietärer Software bereitgestellt werden, wird insbesondere im Linux-Umfeld mit Argwohn betrachtet.
Offene Treiber?
Als Reaktion hat Broadcom die Dokumentation zur Programmierung der Peripheriegeräte und der 3D-Einheit im VideoCore freigegeben. Broadcom finanziert auch die Entwicklung eines quelloffenen 3D-Treibers, der in das Mesa-Framework für Grafiktreiber integriert wurde und auch Kompatibilität zu OpenGL für Desktops herstellt, während der geschlossene Broadcom-Treiber nur das mobile OpenGL ES unterstützt. Der offene Treiber wird auf den ARM-Kernen ausgeführt und greift direkt auf die 3D-Pipeline des VideoCore zu, womit die Abhängigkeit von der VideoCore-Software bereits stark reduziert wird.
Ein Wechsel auf eine SoC-Architektur, die nicht auf VideoCore-Technologie aufbaut, wäre ein Rückschritt: Die Platzhirsche der lizenzierbaren Grafiktechnologien für ARM-SoCs sind Mali von ARM sowie PowerVR von Imagination Technologies. Treiber gibt es hier nur in binärer Form; Quellcode bekommt man von den Herstellern nicht. Im Unterschied zu den VideoCore-Blobs, die auf einem eigenständigen Co-System laufen, arbeiten diese auf den ARM-Kernen selbst und müssen deshalb an das jeweilige Betriebssystem angepasst werden. Wenn Linux eingesetzt werden soll, so ist man bei schlechter Treiberpflege durch den Hersteller deshalb schnell von der Linux-Entwicklung abgehängt. Darunter leiden einige der durchaus interessanten Raspi-Alternativen, sodass man sich in der Regel mit älteren Linux-Versionen oder rudimentären Android-Ports zufrieden geben muss, sofern man die Grafik-Hardware ausreizt.
Es ist bisher nicht abzusehen, ob ARM oder Imagination künftig einen offeneren Ansatz anstreben. Eher das Gegenteil scheint der Fall zu sein: Nach Aussagen von Luc Verhaegen, der die Entwicklung des freien „lima“-Treibers für Mali-Einheiten gestartet hat, hat ARM sich nach Kräften bemüht, diese Entwicklung zu unterminieren [2].
Weitere Stolpersteine beim Wechsel der SoC-Architektur lauern dort, wo Software die Spezialeinheiten des bisherigen SoC nutzt. Auf der Image Sensor Pipeline (ISP) können beispielsweise Operationen wie Weißabgleich, Rauschentfernung und Skalierung „nebenher“ auf Kameradaten durchgeführt werden. Software, die dies nutzt, müsste angepasst oder ausgetauscht werden. Auch greifen einige Anwendungen direkt über die Speicheradressen auf die GPIO-Ports zu. Deren Lage im Speicher und die Interpretation der Datenwerte würde sich mit hoher Wahrscheinlichkeit ändern, sodass einige Software direkt inkompatibel würde.
Blick nach vorne
Unterm Strich würde eine neue SoC-Architektur zwangsweise zu einer Fragmentierung der Software-Landschaft auf dem Raspberry Pi führen. Das hat die Raspberry Pi Foundation bisher vermieden und auch für die neueren Raspis keine separaten Ausgaben des offiziellen Betriebssystems Raspbian bereitgestellt, die von erweiterten Befehlssätzen der neueren ARM-Kerne profitieren. Stattdessen läuft Raspbian auch in der neuesten Version auf jedem beliebigen Raspi gleichermaßen, was sicherlich Anwender freut, die mehrere Gerätegenerationen nutzen.
Um den Raspberry Pi auch für die nächsten Jahre attraktiv zu halten, wird sich die Foundation voraussichtlich noch stärker als zuvor im Software-Bereich engagieren. Hierzu gehört, alle zum Betrieb notwendigen Treiber im Hauptzweig des Linux-Kernels unterzubringen und sich so weit wie möglich von den VideoCore-Blobs unabhängig zu machen. Durch den neuen offenen 3D-Treiber erweitert sich die Auswahl an 3D-Software; selbst weitreichende Desktop-Beschleunigung rückt in greifbare Nähe.
Auch neue Hardware wird es geben: Neuauflagen des Model A und des Compute Module auf Basis des BCM2837 sind angekündigt. Bevor die Raspberry Pi Foundation mit einem gänzlich neuen SoC in die nächste Runde geht, dürfte der BCM2837 also noch für einige Zeit aktuell bleiben. (vza@ct.de)