OP-TEE

Im ersten Vortragsslot um 09:00 Uhr hatte ich eigentlich vor, den Vortrag "OP-TEE - Using Trust Zone to Protect Our Own Secrets" meines Kollegen Marc Kleine-Budde anzuhören, aber der Vortrag war so restlos überlaufen, dass kein Platz mehr zu bekommen war. Somit startete der Tag mit einer ausführlicheren Kaffeepause... Offenbar waren noch mehr Teilnehmer enttäuscht, den Vortrag verpasst zu haben, so dass es am Mittwoch einen weiteren Zeitslot geben wird.

Linux Powered Arctic Buoys

Im zweiten Vortrag berichtete Satish Chetty über "Linux Powered Autonomous Arctic Buoys".

Der Referent betreibt einen Satz dieser von ihm selbstgebauten Sensorträger in Alaska und berichtete über die Erfahrungen, die man so macht, wenn man eine Embedded Linux / ARM basierte Plattform bei Temperaturen von bis zu -40 °C betreibt. Die Geräte werden genutzt, um die Vorgänge beim Abschmelzen des Eises im Sommer zu untersuchen.

Eines der wichtigsten Themen war, mit dem Mess-System so viel Strom wie möglich zu sparen; so wird immer jeweils ein Mess-Zyklus gefahren, dann wird das Device ausgeschaltet und von einem Microcontroller Stunden später für den Beginn des nächsten Zyklusses wieder aufgeweckt.

Als Batterien haben sich überraschenderweise normale Handy-Akkupacks als vorteilhaft erwiesen, da diese auch von ungeschultem Personal leicht in der Forschungsstation aufgeladen und selbst unter widrigen Bedingungen hinreichend gut getauscht werden können. Andere Probleme jedoch, wie Kabelbiss durch Polarfüchse oder Eisbären, die sich auf den Sensorträger setzen, sind weiterhin ungelöst.

AGL

Der nächste Vortrag von Walt Miner gab einen Einblick in das Automotive Grade Linux Projekt der Linux-Foundation. Der Vortrag war allerdings sehr high-level gehalten und ging nicht auf technische Details ein, so dass als Message vor allem hängengeblieben ist, dass der Referent die in der Automotive-Industrie mit Linux befassten Entwickler zur Zusammenarbeit aufruft.

r4d

Im letzten Slot vor der Mittagspause gaben Anna-Maria Gleixner und Manuel Traut einen Einblick in ihre Erfahrungen, Jenkins und libvirt zu nutzen, um ihr Testlabor für das Testen der Preempt-RT Kernel zu nutzen. Viele der Anforderungen, die im Vortrag angesprochen wurden, sind sehr ähnlich zu denen, die uns bei unseren eigenen Aktivitäten zu labgrid geleitet haben.

Leider scheinen wir uns auch im Bereich Testautomatisierung wieder in einer Phase zu befinden, wo viele Protagonisten gleichzeitig versuchen, sehr ähnliche Lösungen zu finden und ihre eigenen Projekte starten.

Farming BoF

Dieser Eindruck verfestigte sich auch in der BoF Session "Farming Together" von Andrew Murray nach der Mittagspause: Viele der Anwesenden im Raum betreiben Testfarmen, aber kaum jemand benutzt die gleiche Technik. Im oberen Bereich des Stacks scheinen sich Jenkins und LAVA durchgesetzt zu haben (was sich mit unseren eigenen Erfahrungen deckt - Pengutronix nutzt ebenfalls Jenkins für das automatische Bauen und LAVA als Infrastruktur für unser kernelci.org Testlabor).

Tim Bird regte an, dass die Teilnehmer eine Mailingliste und eine Wiki-Seite einrichten; letzere wurde noch in der BoF Session auf elinux.org angelegt; dort werden weiterhin Kontaktdaten von Interessenten gesammelt.

Kernel Process

Die "Bash the Kernel Maintainers" BoF von Laurent Pinchart griff das altbekannte Thema auf, dass es manchmal schwierig sein kann, Kernel-Maintainer dazu zu bekommen, gewisse Patche zu akzeptieren. Ein Problem ist, dass man manchmal selbst für kleine Patche einfach keine Rückmeldung bekommt und dies erst Monate später mitbekommt, wenn der Patch eben nicht aufgenommen wurde ("Black Hole Problem"). Vor allem kleinere Consulter stehen vor dem Problem, dass sie während eines Projekts Patche einschicken, später dann aber längst mit einem anderen Thema befasst sind, wenn das Feedback eintrifft, und manchmal nicht mal mehr Zugriff auf die Hardware haben. Hans Verkuil machte den Vorschlag, dass man solche Infos gern auf den Mailinglisten ansprechen soll, damit die Maintainer Bescheid wissen.

Fazit: "politely pinging" und immer wieder den Kontakt Suchen sind die Schlüssel dazu, dass diese Probleme gelöst werden können.

labgrid

Ein weiteres Highlight für das Pengutronix-Team war der Vortrag "Automation beyond Testing and Embedded System Validation" von Jan Lübbe. Der Hintergrund der Testaktivitäten ist, dass Pengutronix für Kundenprojekte ständig eine größere Menge Open Source Komponenten integriert, die sich ständig ändern. Da das Updaten und Ausrollen von Updates nicht ohne intensives Testen funktioniert, ist es Zeit für mehr Automatisierung in diesem Bereich. Dabei war wichtig, dass die gleiche Fernsteuertechnik sowohl für automatische Tests wie auch für das interaktive Arbeiten an den Boards (die als Prototypen oft nur in wenigen Stückzahlen existieren) genutzt werden kann.

Weitere Features, die mit existierenden Frameworks nicht abgedeckt werden konnten, sind das Testen von Updates (inkl. Booten der Devices während des Tests) oder das gleichzeitige Fernsteuern mehrerer Geräte (Video-Streaming Box + Empfänger). Jan gab einen kurzen Überblick über die zur Zeit verfügbaren Testframeworks und erklärte, warum diese leider nicht die Anforderungen erfüllen, die sich in unseren Projekten zeigen.

labgrid bietet eine Python-basierte Infrastruktur, in der Fernsteuer-Geräte wie Powerschalter und USB-Seriell-Wandler mittels Treibern abstrahiert werden. Ein wichtiges Feature sind die sogenannten "strategies": Mit diesen kann man ein System anweisen, in einen bestimmten State zu gehen (z.B. auf die Linux-Konsole); wenn nötig, wird das System dabei hinter den Kulissen auch mittels der Fernsteuertechnik gebootet oder mit Software versehen. Die eigentlichen Tests werden in pytest geschrieben, der Output wird als JUnit XML erzeugt und kann z.B. von Jenkins direkt angezeigt werden.

Für ein Lab, das verteilt an mehreren Rechnern angeschlossen ist, übernimmt der labgrid Concentrator die Koordination der verfügbaren Ressourcen.

Neben dem eigentlichen Testen kann labgrid auch bei der Produktion von Embedded Systemen helfen und am Bandende die komplette Firmware auf das Device schreiben und das Ergebnis testen.

Zum Schluss des Vortrags zeigte eine Demo, wie man mit labgrid das Updaten eines Systems mittels RAUC mit einem simulierten System im QEmu testen kann.