Unboxing the STM32MP157C-DK2 -- erste Eindrücke

Die STM32MP1-Prozessorfamile von ST stellt die Basis für eine Reihe günstiger SOMs dar die sich leicht für unterschiedliche Anwendungen nutzen lassen, SOMs sind schon unter 30 EUR erhältlich (z.B. Octavo, Phytec, EmCraft, Kontron) . Der Dual-Core  Cortex A7 mit 800 MHz wird dabei mit einem M4-Kern ergänzt, der neben dem Haupt-Linux z.B. für sicherheitsrelevante, zeitkritische oder energieeffiziente Aufgaben genutzt werden kann, eine heutzutage übliche Aufteilung wie etwa auch beim NXP i.MX7.

Für Multimedia-Anwendungen steht eine GPU zur Verfügung, der IP-Block von Vivante (GC3000) ist dabei ähnlich leistungsfähig wie der im i.MX6 verbaute GC2000, desgleichen sind beide nur schwer für andere Aufgaben wie OpenCL nutzbar.

Zur Evaluierung bietet ST ein Entwicklungskit mit Touchdisplay (z.B. bei RS-Online), vorkonfiguriertem Betriebssystem auf SD-Karte und eine ausführliche Dokumentation ihrer Yocto-Umgebung im Netz.

Beim Auspacken der Box fällt das USB-C Kabel auf das zur Stromversorgung dienen kann, ein 3A-Netzteil ist stark angeraten und muss extra besorgt werden -- der Bootloader beschwert sich ansonsten bitterlich.

Die Demo-Umgebung auf Wayland/Weston-Basis liefert nach ca 40 Sekunden die ersten Bilder auf dem LCD, was den ersten Eindruck doch etwas trübt. Bei näherer Betrachtung benötigt der erste Bootloader 2-3 Sekunden um die Umgebung zu verifizieren und den M4-Kern zu programmieren um danach die Kontrolle an die zweite Stufe abzugeben. Dazu wird U-Boot aus einer weiteren Partition nachgeladen und das eigentliche Linux gebootet. 

Yocto Linux und Paket-Updates

Die Build-Umgebung lässt sich leicht anhand der Anleitung von ST einrichten, nach ordentlich Kaffee hat man im deploy-Verzeichnis eine ganze Reihe von Paketen und ein fertiges Image. Wie bei allen Yocto-Umgebungen üblich wird mit einem zu sourcenden Shellscript die Umgebung eingerichtet, bei STM liegt dieses in layers/meta-st/scripts/envsetup.sh -- ein Symlink zu dieser Datei wird nicht erstellt sondern sollte manuell angelegt werden um sich die Sucherei beim nächsten Login zu ersparen.

Die Paketverwaltung basiert auf Debian-Paketen, d.h. es werden deb-Files anstatt von ipk-Files erzeugt. Dies ermöglicht das Einrichten von signierten Update-Servern. Zum Entwickeln können die erzeugten Pakete auch unsigniert auf einen Server gelegt werden, dabei wird einfach der Inhalt des tmp-glibc/deploy/deb auf einen Web-Server zu stellen und in /etc/apt/sources.list auf dem Board einzutragen:

Wichtig: Vor dem Kopieren muss der Paket-Index mit “bitbake package-index” aktualisiert werden. Nach einem “apt-get update” lassen sich dann eigene Pakete inkl. Abhängigkeiten mit “apt-get install <paket>” installieren. Einziger Nachteil: apt-get beschwert sich bei jeder Installation dass die Pakete unsigniert sind.

Für einen Produktivbetrieb empfiehlt sich daher ein signiertes Repository das mit einem Schlüssel signiert wird. Dessen öffentlicher Teil wird auf der Maschine installiert und die Pakete via reprepo  in ein signiertes Repository importiert, ein ausführliches Tutorial dazu gibt es z.B. von Thomas Krenn oder  DigitalOcean. Auf dem Board muss dann der Schlüssel importiert werden, dazu fehlte allerdings im Standard-Image das GnuGPG-Paket zur Schlüsselverwaltung. Abhilfe schafft hier ein USB-Stick mit den notwendigen .deb-Dateien, die via “dpkg -i” installiert werden müssen (gnupg, libassuan0, libgcrypt, libgnutls30, libgpg-error, libksba8, libnpth0).

Dann spricht einem Testlauf mit OpenCV nichts mehr entgegen, das ist aber eine andere Geschichte...