Board Farms for Everyone: Making Hardware Debugging Easier and Sharing Boards Across the Globe!

Ein wichtiger Aspekt von Open Source ist die Zusammenarbeit in der Community - oft auch zwischen direkten Wettbewerbern im gleichen Marktsegment. Somit war in diesem Jahr bemerkenswert, dass der Vortrag über Testautomatisierung mit labgrid nicht von Pengutronix, sondern von Christopher Obbard (Collabora) gehalten wurde.

Zu Beginn stellte Chris fest, dass es oft vorkommt, dass die Entwickler zunächst mal "etwas auf einem Board ausprobieren" müssen, wobei das Board sich in einem Labor an einem anderen Standort befinden kann. Somit ist es für die Collabora Entwickler (wie für uns auch) ein Usecase, ein Board an einem entfernten Standort neu zu flashen. Das lokale Lab in Chris' Homeoffice besteht aus ca. 10 Boards, die auch mal schnell umkonfiguriert werden müssen; es kommt dabei auf einen geringen Stromverbrauch sowie einen leisen Betrieb (WAF!) an. Sein Lab nutzt als Controller einen Raspberry Pi 4 mit USB-Seriell-Wandlern für die Konsolen. Dabei traten ähnliche Probleme mit der Robustheit von USB auf, wie wir sie aus unseren Labs auch kennen. Weiterhin gibt es einen Netzwerkswitch. Die Software-Installation auf dem Raspi erfolgte mittels Ansible.

In Sachen Software war sein erster Versuch LAVA, jedoch fand Chris schnell heraus, dass LAVA vor allem für automatische Testläufe und nicht für interaktive Benutzung designt wurde. Der Pflegeaufwand für ein LAVA Lab stellte sich als hoch heraus, und insbesondere die Turnaround-Zeiten zur Ausführung eines einzelnen Jobs sind sehr hoch. Somit war LAVA für ein Home Lab mit interaktiver Benutzung und einem Fokus auf Entwicklung nicht gut geeignet.

Im interaktiven Betrieb ist die Kontrolle über die Stromversorgung zum Ein- und Ausschalten der Boards ebenso wichtig wie das Flashen und Starten neuer Software. Dies waren auch die Anforderungen, die uns bei Pengutronix beim Design von Labgrid als pythonbasiertes Testautomatisierungsframework wichtig waren. Bei Labgrid kümmert sich der Controller um den Zustand des Systems und die Kommunikation zu den verschiedenen Exportern, an die wiederum die Test-Devices angeschlossen sind. Dabei abstrahiert Labgrid Stromversorgungs-Schnittstellen und serielle Interfaces. Für Chris stellte es sich als ein Vorteil heraus, dass man mit Labgrid sehr einfach Lab-Hardware beschreiben kann. Dadurch, dass es möglich ist, einen Laborplatz zu locken, ist auch ein Mischbetrieb zwischen einem Continuous Integration System und interaktivem Betrieb möglich. Zum Schalten von 230 V Geräten nutzt er Sonoff WiFi Steckdosen, die über MQTT angesteuert werden. Die automatischen Tests werden von GitLab CI gesteuert.

Alles in allem scheint Chris mit seinem Lab sehr zufrieden zu sein; als derzeitige Schwäche wurde identifiziert, dass es nicht möglich ist, Files auf den Exporter hochzuladen. Alles in allem war gut zu sehen, dass auch andere Nutzer mit unseren Open Source Projekten zufrieden sind.

Using OpenEmbedded Inside Containers? How and Why?

In meinen zweiten Vortrag des Tages berichtete Drew Mosley (Toradex) über seine Erfahrungen mit OpenEmbedded in Containern. Seiner Erfahrung nach sind Container ein handlicher Mechanismus zum Packagen von Software und zum Ausliefern auf Embedded Systeme, ohne dass es Abhängigkeiten zum Entwicklungshost gibt. Container nutzen Kapselungs-Features des Kernels, wobei es auf dem Zielsystem innerhalb des Containers nur Userspace und keinen eigenständigen Kernel gibt. Nach Drews Erfahrung machen es Container Registries wie Docker Hub sehr einfach, beliebige Software ohne größere Schmerzen zu installieren.

Allerdings bleibt als Hauptfrage bestehen, wie die Container erstellt werden; dabei ist das Problem, dass man ggf. Containern anderer Leute hinreichend vertrauen muss. Zudem beinhalten die üblichen Standard-Container eine Menge Software, die in einer konkreten Anwendung ggf. gar nicht benötigt wird. Deshalb ist OpenEmbedded nach seiner Erfahrung ein gutes Werkzeug, um sehr kleine und maßgeschneiderte Container zu erstellen.

Leveraging Next Generation Cellular Networks for Drone Telemetry and Payload Communication

Leider musste der "How Automotive Grade Linux UCB Transitioned to Make Use of Flutter"-Vortrag abgesagt werden. Der nächste Talk von Ngonidzashe Mombeshora konnte aufgrund von Visa-Problemen leider auch nicht vor Ort, sondern nur im Stream gehalten werden.

Ngonidzashe stellte vor, dass der Vorteil von Mobiltelefon-Netzwerken zur Steuerung von Drohnen darin besteht, dass diese nahezu überall auf der Welt bereits ausgerollt sind. Allerdings ist es zur Steuerung von Drohnen in Echtzeit nötig, eine sehr geringe Latenz in der Kommunikation zu erreichen. Zu deren Optimierung hat er an der Uni ein SDR basiertes 4G Mobiltelefonienetzwerk aufgebaut - mit einem Raspberry Pi mit SDR Hat und einer Reihe von Docker-Containern mit der nötigen Software. In einem zweiten Schritt wurde ein 5G Testbed aufgesetzt. Damit ließen sich 90/30 MBit/s Down-/Uplink Raten mit 5 ms Latenz erreichen. Allerdings stellte sich auch heraus, dass sich in regulären kommerziellen Netzwerken leider nur schlechtere Latenzen realisieren lassen. Immerhin konnte er in seinem Testnetz einen realen Testflug mit MavLink als Telemetrieprotokoll durchführen.

Alles in allem ein beeindruckendes Ergebnis, wobei das Setup insbesondere von akademischem Interesse ist.

Automating and Managing an IoT Fleet Using Git

In meinem letzten Vortrag des zweiten Tages berichtete Matthias Lüscher (Schindler AG) von seinen Aktivitäten, eine IoT Flotte mittels git zu managen. Sein Open Source Projekt edi hat sich zur Aufgabe gemacht, so viele Schritte wie möglich zum Bauen, Verwalten und Ausrollen von Embedded Linux Systemen zu automatisieren. Er nutzt Debian für die Pakete, erstellt damit Mender Update Images und rollt sie zunächst in ein Testfeld aus, in dem das Resultat mittels Testinfra getestet wird. Funktioniert alles wie gewünscht, erhält er ein qualifiziertes Image für das Target Device.

Um einen "golden image"-Ansatz zu vermeiden, nutzte Matthias debootstrap, startet das resultierende Image im QEMU und baut dort die nötigen Änderungen und fehlenden Konfigurationen mittels Ansible ein. Testinfra hat sich für ihn als ein praktikabler Ansatz für Tests in pytest herausgestellt; dabei könnnen die Tests auf einer Entwicklungsmaschine laufen und gegen ein Embedded System testen.

Als Demo zeigte Matthias einen edi-Workflow mittels oben skizzierter Toolchain, der einen Raspberry Pi in eine GitHub Action Runner verwandelt. Der resultierende Action Runner registriert sich selbst bei GitHub. In einem weiteren Beispiel entstand ein Kiosk Terminal, dem man mittels 6 Zeilen Ansible Code die anzuzeigende URL konfigurieren konnte.

Der Ansatz funktioniert nicht nur mit einzelnen Devices, sondern auch mit ganzen Geräteflotten. Die Testflotte, die Matthias zu Hause betreibt, besteht aus unterschiedlichen Devices, vom Raspberry Pi 2 bis hin zu aktuellen MX8M Evalkits. Die Flotte wird auf verschiedene git-Branches abgebildet: Alle Entwicklung findet auf einer Development-Branch statt; auf einer Main-Branch werden komplettere Features gesammelt, die dann in eine Canary-Branch auf eine realistische, aber in erreichbarer Nähe befindliche Feldgeräteflotte ausgerollt wird. Wenn es dort keine Ausfälle gibt, wird in das echte Produktionsumfeld ausgerollt. Dabei schauen die Clients jeweils über Mender, ob es neue Daten für sie gibt.

Es bietet sich an, die Geräte im Feld via Monitoring zu überwachen; dann bekommt man auch mit, wenn z.B. Geräte gerade offline sind, wenn es neue Updates oder Konfiguration für sie gibt. Sehr große Flotten sollten die Informationen vermutlich besser nicht aus einem Git Repository via Ansible ziehen, sondern auf eine Datenbank ausweichen. Zumindest für kleine Flotten funktioniert aber der Workflow mit git und Ansible hinreichend gut.

In Summe hat sich die verwendete Toolbox als sehr mächtig herausgestellt. Für den Fall, dass die einzelnen Tools nicht zu den eigenen Bedürfnissen passen, kann man sie auch einzeln gegen vergleichbare andere tauschen, z.B. indem man Yocto statt Debian verwendet.

Booth Crawl

Traditionell gibt es in jedem Jahr den Booth Crawl, auf dem diverse Projekte ihre Embedded Linux Demos vorstellen. Leider gab es in diesem Jahr nur 6 Demos von drei Gruppen, unter anderem von Pengutronix. Hoffen wir, dass es im nächsten Jahr wieder mehr Demos gibt - die Demos sind immer ein Highlight.

Das Pengutronix Team zeigte das Labgrid Test Automation Framework, einen Prototypen des LXA Test Automation Controllers (TAC), das RAUC Update Framework sowie unsere aktuellen Mainlining-Aktivitäten für die Unterstützung der Grafik auf Rockchip-SoCs. Wie in jedem Jahr gab es eine Vielzahl interessanter Gespräche mit einem interessanten Publikum.