Raspberry-Pi-Klon SolidRun HummingBoard aus Israel (Seite 2)

# mount -t debugfs none /sys/kernel/debug
# cat /sys/kernel/debug/gpio
[...]
GPIOs 64-95, gpio-2:
 gpio-67  (pin22               ) in  hi
 gpio-68  (PCIE RESET          ) out hi
 gpio-69  (gpio-ir-recv        ) in  hi
 gpio-70  (pin15               ) in  hi
[...]
# echo 67 > /sys/class/gpio/export
# echo out > /sys/class/gpio/gpio67/direction
# cat /sys/kernel/debug/gpio
[...]
GPIOs 64-95, gpio-2:
 gpio-67  (pin22               ) out lo
 gpio-68  (PCIE RESET          ) out hi
 gpio-69  (gpio-ir-recv        ) in  hi
 gpio-70  (pin15               ) in  hi
[...]
# val=1
# while : ; do
>   echo $val > /sys/class/gpio/gpio67/value
>   echo $val
>   sleep 1
>   val=$((1-$val))
> done
1
0
1
0
[...]

Der zweite Test gilt der Inbetriebnahme des Serial Peripheral Interface (SPI, [5]). Für den Raspberry Pi gibt es dazu viele Beschreibungen [6]. Das verwendete Programm spidev_test.c kommt zusammen mit dem Kernel-Quellcode und implementiert einen Loopback-Test, bei dem MOSI- und MISO-Pins am GPIO-Header verbunden werden (Listing 3). Das funktioniert aber nur, wenn spidev_test.c zu dem auf dem Raspberry Pi laufenden Kernel passt.

Zur SPI-Kommunikation mit dem HummingBoard existiert nur wenig Dokumentation. Im Test luden wir das Kernel-Modul spi_imx, das aber weder das gewünschte Gerät in /dev erstellte noch Einträge in Logfiles hinterließ. Erst der Einsatz eines alternativen Debian-Images [7] für das HummingBoard von Igor Pecovnik ließ die SPI-Geräte erscheinen, wenn auch unter etwas anderem Namen. Daraufhin klappte der Loopback-Test auch auf dem HummingBoard (Listing 4).

$ gcc spidev_test.c -o spidev_test
$ ./spidev_test -s 100000 -D /dev/spidev0.0
spi mode: 0
bits per word: 8
max speed: 100000 Hz (100 KHz)
FF FF FF FF FF FF
40 00 00 00 00 95
FF FF FF FF FF FF
FF FF FF FF FF FF
FF FF FF FF FF FF
DE AD BE EF BA AD
F0 0D

# gcc spidev_test.c -o spidev_test
# ./spidev_test -D /dev/spidev1.0
spi mode: 0
bits per word: 8
max speed: 500000 Hz (500 KHz)
FF FF FF FF FF FF
40 00 00 00 00 95
FF FF FF FF FF FF
FF FF FF FF FF FF
FF FF FF FF FF FF
DE AD BE EF BA AD
F0 0D

Das Kameramodul lässt sich auf dem Raspberry Pi problemlos integrieren und unter Raspbian in Betrieb nehmen. Dazu konfigurieren Sie es zunächst mit raspi-config und können nach einem Reboot sofort mit raspistill -o image.jpg Fotos aufnehmen. Für das HummingBoard fand sich trotz intensiver Suche im Netz keine Anleitung, wie man die Kamera in Betrieb nimmt. Allerdings scheinen andere Kameratypen zu funktionieren, was der Autor aber mangels verfügbarer Hardware nicht überprüfen konnte.

Der Software-Stack

Der ARMv7-Befehlssatz erlaubt es, auf dem HummingBoard direkt Debian-Armhf-Pakete zu installieren. Im Test kamen neben einem Vanilla-Debian das SolidRun-Image sowie das beim SPI-Test erwähnte Image von Igor Pecovnik zum Einsatz (siehe Tabelle “Debian-Images für das HummingBoard”).

Als kritischste Punkte der Software-Images kristallisierten sich der Kernel und der Grafik-Stack heraus. Freescale unterstützt für den Vivante-GC2000-Grafikkern der HummingBoards die Kernel 3.0.x und 3.10.x. Der Grafiktreiber besteht aus einem quelloffenen Teil im Kernel und einem binären Teil im Userspace. Zudem fließt viel Arbeit in eine Kernel-3.14.x-Variante, die derzeit im Image von Igor Pecovnik zum Einsatz kommt. Debian selbst arbeitet mit dem Upstream-Kernel 3.16.

Für Anwendungen, die sehr gute Hardware-Unterstützung benötigen, insbesondere auch Grafik-Support, stellt momentan das Image von Igor Pecovnik die beste Wahl dar. Für Anwendungen, die keine spezielle Hardware-Unterstützung brauchen, aber auf aktuellstem Sicherheitsstandard sein oder größtmögliche Flexibilität bei Software-Paketen bieten sollen, greifen Sie am besten zu Vanilla-Debian mit seiner guten Upgrade-Infrastruktur. Debian stellt jedoch bislang keinen Installer für das HummingBoard zur Verfügung, sodass Sie das Bootstrapping auf einem x86-Rechner mit Debian selbst vornehmen müssen.

Fazit

Zwar fassen sich die meisten Schnittstellen des HummingBoard ganz ähnlich an wie ihre Pendants auf dem RasPi, doch gibt es oft Unterschiede im Detail. Zudem mangelt es an entsprechender Dokumentation, was dazu führt, dass sich der Umgang mit dem SolidRun-SBC deutlich zeitaufwendiger gestaltet als jener mit dem Original. Daher sollten Sie neue Komponenten erst einmal am RasPi in Betrieb nehmen und die resultierenden Erkenntnisse dann für den Einsatz am HummingBoard übertragen.

Für den Erfolg der HummingBoard-Familie dürfte es entscheidend sein, ob es SolidRun gelingt, eine ausreichend große Community um die Hardware-Platform zu scharen. Erste Anzeichen dafür gibt es: So empfiehlt beispielsweise OpenELEC die CuBox-i als Hardware-Plattform für seine Mediacenter-Distribution [8]. Zudem tummeln sich im IRC-Kanal #cubox auf Irc.freenode.org zahlreiche Benutzer. SolidRun bietet hier meist schnelle Hilfe und betreibt zudem ein eigenes Forum [9].