Zum Hauptinhalt Zur Navigation Zur Suche

Loongson LS2K0300 im Test: Dieser SBC brachte uns an den Rand der Verzweiflung

Wem Raspberry Pis viel zu nutzerfreundlich sind, der findet im Loongson LS2K0300 eine Herausforderung. Benchmarks hinterlassen ein gemischtes Bild.
/ Johannes Hiltscher
Kommentare Auf Google folgen (öffnet im neuen Fenster)
Der Banana Pi BPI 2K0300 sieht zwar aus wie ein Raspberry Pi, ist aber alles andere als benutzerfreundlich. (Bild: Johannes Hiltscher/Golem.de)
Der Banana Pi BPI 2K0300 sieht zwar aus wie ein Raspberry Pi, ist aber alles andere als benutzerfreundlich. Bild: Johannes Hiltscher/Golem.de
Inhalt
  1. Loongson LS2K0300 im Test: Dieser SBC brachte uns an den Rand der Verzweiflung
  2. Auf Fehlersuche im Kernel
  3. Leistung passt zu Herstellerangaben
  4. Der Raspberry Pi 3B protzt mit Speicherbandbreite
  5. SBC mit Loongson LS2K0300: Fazit, Preis und Verfügbarkeit

Computer von heute sind viel zu einfach, die Jugend lernt da ja gar nichts mehr – möglicherweise haben sich das Longsoons Entwickler gedacht. Und mit dem LS2K0300(öffnet im neuen Fenster) haben sie eine echte Herausforderung geschaffen. Zwar müssen für das System-on-a-Chip (SoC), das auf einer Reihe von Single Board Computern (SBC) verkauft wird, keine Lochkarten gestanzt werden. Und auch ohne Assembler-Kenntnisse lässt es sich zum Laufen bringen. Einige Ausdauer und Erfahrung im Umgang mit Embedded Systems braucht es aber dennoch.

Aufgefallen war uns der LS2K0300, weil er unter anderem im Raspberry-Pi-Formfaktor angeboten wird. Diesen Banana Pi BPI 2K0300(öffnet im neuen Fenster) haben wir bestellt, darauf ist das SoC zusammen mit 512 MByte RAM verbaut. Wir haben uns für die Luxusvariante mit eMMC- und Wi-Fi-Modul entschieden – in der Hoffnung, dass es einfach funktioniert.

Nachdem wir bereits Loongsons Desktop-CPU 3A6000 getestet haben (g+), interessierte uns das SoC: Zwar ist nur ein Kern verbaut, der auch nur mit 1 GHz taktet, er soll aber auf dem Leistungsniveau eines Cortex-A55 von ARM liegen. Der Kern implementiert Loongsons 64-Bit-Befehlssatz, theoretisch läuft das gleiche Programm also sowohl auf dem SoC als auch auf der Desktop-CPU.

Der kompakteren LA264-Architektur des SoC-Kerns fehlen allerdings die Vektorerweiterungen. Sie decodiert zudem nur zwei Befehle pro Takt, es scheint sich aber um eine Out-of-Order-Architektur (g+) zu handeln – ein Loongson-Datenblatt erwähnt eine "dynamische Pipeline". Gedacht ist das SoC eigentlich für industrielle Anwendungen, weshalb etwa zwei CAN- und vier PWM-Controller sowie ein Analog-Digital-Wandler (ADC) integriert sind. Auch eine Echtzeituhr findet sich im Chip.

Bootet, ist aber unbenutzbar

Die erste Herausforderung ist, herauszufinden, über welche Pins die serielle Konsole ausgegeben wird. Denn einen Displayanschluss hat der SBC nicht – sieht man einmal vom 40-poligen LCD-Anschluss ab, für den wir aber keines der unterstützten Displays auftreiben konnten.

Die Information findet sich zum Glück auf der Homepage des Herstellers. Entgegen unserer Erwartung versteckt sich der entsprechende UART neben den Pins des ADC. Auf die Freude darüber, dass der Linux-Kernel problemlos startet, folgte schnell die Ernüchterung. Denn eine Shell bekamen wir nicht, und damit begann eine monatelange Fehlersuche, bevor wir endlich Benchmarks laufen lassen konnten.

Unsere erste Vermutung war, dass möglicherweise schlicht die entsprechende Software fehlt. Überprüfen ließ sich das leider nicht, da wir auf das eMMC-Modul nicht zugreifen konnten. Schnell stießen wir aber auf ein Loongson-Repository, in der sich eine Buildroot-Umgebung für den LS2K0300 findet(öffnet im neuen Fenster). Damit haben wir glücklicherweise bereits Erfahrung (g+), also erstellten wir ein eigenes Betriebssystemabbild und starteten es von einer SD-Karte.

Beim ersten Versuch sehen wir ein höchst seltsames Verhalten: Den Quellcode einiger Anwendungen versuchte Buildroot von einer statischen, privaten IP-Adresse zu laden. Die Idee dahinter erhellt auch ein ausführliches chinesisches Handbuch nicht, auf das wir stoßen. Ebenso unklar bleibt, wo wir den entsprechenden Quellcode herbekommen könnten. Andere Programme sollten im Buildroot-Verzeichnis liegen, fehlten aber. Wir warfen die problematischen Pakete einfach raus – wichtig scheint keines davon zu sein. Das neue Image brachte uns leider keinen Schritt weiter.

Damit begann eine Odyssee durch Device Trees, chinesische Datenblätter und Quellcode des Linux-Kernels sowie des Bootloaders u-boot. Denn wirklich sicher ist zu diesem Zeitpunkt nur: Der Bootloader kann offensichtlich von eMMC und SD-Karte lesen, um den Linux-Kernel in den RAM zu laden. Ob es der Kernel auch kann, ist unklar. Möglicherweise steckt auch ein Fehler in einem Treiber, vielleicht gibt der Device Tree falsche Adressen oder Pins an. Unser Plan: Wir wollen das Wurzeldateisystem als CPIO-Archiv ebenfalls in den RAM laden.

Dafür müssen wir zunächst den Linux-Kernel neu kompilieren.


Relevante Themen