Pengutronix: Rückblick auf 2023 - Teil I
Wieder ist ein spannendes aber auch herausforderndes Jahr vorüber, wir sind ein Jahr näher am Y2038-Problem, OpenSSL 1.1.1 ist endgültig Geschichte, Kernel v4.14 von 2017 wird in vier Wochen endlich abgekündigt, kommende LTS-Kernel nur noch 2 Jahre unterstützt. Die Relevanz von Linux, nicht nur im Embedded-Segment, steigt ungemein, gleichzeitig steht die (Open Source) Software-Welt in Europa vor notwendigen aber auch herausfordernden Umbrüchen, die in Form des Cyber Resilience Acts ihre Schatten voraus werfen.
Eine gute Gelegenheit in diesem Trubel kurz inne zu halten, sich zu besinnen und zurück zu schauen auf das vergangene Jahr 2023 und was es uns als Pengutronix so beschert hat.
Wir starten den ersten Teil unseres Jahres-Rückblicks mit einer Übersicht über unsere wesentlichen Beiträge zu Open Source-Projekte, allen voran natürlich dem Linux-Kernel in den weiterhin der Großteil an Entwicklungsstunden der verschiedenen Projekte fließt. Aber auch die von Pengutronix-Entwicklern federführend maintainten Projekte wie Barebox, RAUC oder labgrid haben mitunter wegweisende Neuerungen oder Erweiterungen erhalten, auf die wir kurz eingehen möchten.
In den zwei folgenden Teilen dieser Reihe werden wir dann unter anderem auf unsere Aktivitäten im Bereich Grafik und Multimedia und die Entwicklungen unserer Hardware-Firma Linux Automation GmbH zurück blicken.
Beiträge zum Linux-Kernel
Im Kernel haben in 2023 17 Entwickler aus unserem Team gut 2500 Änderungen an über 4000 Dateien eingebracht, die thematisch sehr weit gefächert sind. Zwischen Mini-Korrekturen für Rechtschreibfehler und großen, subsystemübergreifenden Aufräumaktionen finden sich Fehlerkorrekturen, Cleanups und Vereinfachungen, sowie Treiber für zuvor nicht unterstützte Hardwarekomponenten und Ergänzungen in Device-Trees für neue sowie auch bereits unterstützte Hardware.
Beispielsweise wurde von Oleksij Rempel der DSA-Treiber für die häufig genutzten Microchip "KSZ"-Switche um Unterstützung für Wake on LAN (WoL) und Access Control Lists erweitert.
Unser Kollege Uwe Kleine-König hat zum Ende des Jahres die Maintenance für das PWM-Subsystem vom langjährigen Maintainer Thierry Reding übernommen und wird nach dem kommenden 6.7er Release dafür verantwortlich sein.
Barebox Bootloader
Auch 2023 ging der monatliche barebox-Release-Zyklus weiter und 1677 Änderungen von 53 Autoren und Autorinnen, darunter 19 Pengutronix-Entwicklern, fanden damit den Weg auf verschiedenste Geräte. Einige Highlights:
- Unterstützung neuer SoCs: Rockchip RK3588, NXP i.MX93 und TI AM62x
- Neue und überarbeitete Treiber, u.a. DSA-Treiber für weitere Microchip und Realtek Ethernet-Switches, höherer Geschwindigkeitsmodus für eMMCs und initiale Unterstützung von USB Type-C
- Echter Multiplatform support: barebox kann nun, wie schon der Linux kernel, im selben Build verschiedene Prozessorfamilien unterstützen, z.B. i.MX8M, AM62x und RK3568 zur selben Zeit
- Secure-Boot Verbesserungen: Für den i.MX8M, ist verified boot (HAB) nun auch einfach durch das normale Kconfig konfigurierbar. Mit JSON Web-Tokens gibt es jetzt auch einen eingebauten Weg, signierte Unlock-Tokens im barebox auszuwerten, sodass Entwickler trotz Secure-Boot mit einem signierten Token einzelne Geräte temporär freischalten können.
- Stackprotector support: Stack Korruptionen können nun detektiert und gemeldet werden
Die wahrscheinlichen Highlights des v2024.01.0 Releases sind auch schon bekannt: Der vorhandene Support für den STM32MP13 wurde erweitert und bidirektionale Kommunikation mit OP-TEE ist nun möglich, z.B. zum Schalten von Clocks, die ausschließlich aus der TrustZone kontrollierbar sind.
RAUC
Für RAUC, dem Open-Source-Embedded-Linux-Updater, haben wir dieses Jahr drei Feature-Releases veröffentlicht:
v1.9 im März hat eine neue InspectBundle-D-Bus-API hinzugefügt, mit der detaillierte Informationen zu einem Bundle abgefragt werden können. Dabei werden sowohl lokalen Bundle-Dateien als auch URLs auf einem HTTPS-Server unterstützt.
v1.10 im Juni brachte einerseits feingranularere Fortschritts-Meldungen während der Installation und andererseits die Möglichkeit, den "Handlern" zusätzliche System-Informationen mitzugeben.
v1.11 im Dezember ermöglichte es schließlich, dem HTTPS-Update-Server zusätzliche Header zu übermitteln (z.B. Geräte-Seriennummer, -Typ, -Variante). Außerdem kann RAUC konfigurierbare Event-Logs erzeugen können, mit denen z.B. alle Software-Installationen auf einem Gerät langfristig nachvollziehbar sind.
Neben den neuen Features haben wir die CI durch die Nutzung von Sanitizern verbessert und RAUC in OSS-Fuzz integriert. Nachdem wir im v1.9er Release meson als neues Buildsystem hinzugefügt haben, wurde autotools mit dem aktuellen v1.11 Release entfernt. Last, but not least, wurde die Dokumentation weiter verbessert. Vielen Dank an alle, die etwas zu RAUC beigetragen haben!
Labgrid
Die sichtbarste Änderung im Hardware-Control-Framework labgrid dieses Jahr ist sicherlich das neue Logging. Damit sind die verschachtelten Schritte, die z.B. eine Testsuite durchführen muss, um ein Board zu provisionieren, viel besser nachvollziehbar. Nicht nur die Ausgabe wurde verbessert, auch die Eingabe per labgrid-client geht dank Bash-Completion jetzt noch leichter von der Hand. Dazu gehört auch die Angabe von Ressourcen-Namen, denn die unterstützen jetzt alle relevanten Subcommands. So können Places mit mehreren Ressourcen des selben Typs einfach per labgrid-client benutzt werden. Neben der üblichen Mischung aus kleineren Features und Fixes, wächst die Liste der Driver und Ressourcen stetig.
labgrid-intern haben wir auf ein neues, datumsbasiertes Versionsschema umgestellt. Das passt besser zur kontinuierlichen Entwicklung des Projekts als die bisherige semantische Versionierung. Ebenfalls intern, aber hoffentlich spürbar: wir haben Coordinator und Client/Bibliothek/Pytest-Plugin/Exporter bei der Installation getrennt. Das bringt einfacheres Abhängigkeitsmanagement mit sich. Durch die unkompliziertere Installation kann labgrid noch besser z.B. als Bibliothek benutzt werden.
OpenEmbedded & Yocto
Nachdem wir unseren Ansatz für einheitliche Nutzung von Signaturschlüsseln auf Hardware-Token auf dem OE Workshop direkt nach der FOSDEM vorgestellt haben, wurde der dafür nötige Code im meta-openembeded layer aufgenommen.
In oe-core haben wir, neben Version-Bumps, Typo-Fixes und Dokumentationsanpassungen zum Upstream-Status-Feld von Patchen, auch erste kleinere Aufräumarbeiten am Testcode rund um oe-selftest upstream gebracht. Diese sind Teil unserer Bemühungen, der Community auch barebox als Bootloader in oe-core bereit zu stellen.
Insgesamt haben wir dieses Jahr 22 Patche in meta-oe eingebracht. In oe-core waren es mit knapp 42 zwar doppelt so viele, jedoch leider noch weniger als dass es unserem eigenen Anspruch an Contributions gerecht wird. Dieser Punkt kommt auf jeden Fall auf die Liste der guten Vorsätze für 2024.
PTXdist
Der Compiler-Wrapper in PTXdist ist dieses Jahr ein ganzes Stückchen strenger geworden und filtert nun alle Zugriffe auf Pfade außerhalb des BSP-Build-Verzeichnisses. Dadurch wird das Build-System weiter unabhängig von dem Host-System, auf dem es läuft, was zu erhöhter Reproduzierbarkeit von Build-Artefakten führt.
In den Makros zum Bauen von Python-Paketen gibt es nun Unterstützung für Projekte, die pyproject.toml statt setup.py benutzen, was sich in letzter Zeit zum neuen Standard für Python-Paketierung entwickelt hat. Der Support für Rust-Software mit Cargo als Buildsystem wurde weiterhin ausgebaut. Für eingebettete Geräte, die sich üblicherweise mehr als 10 Jahre im Feld befinden, ist Y2K38-Kompatibilität zur Verarbeitung von Zeitstempeln jenseits von 2038 wichtig. In Verbindung mit der OSELAS.Toolchain 2023.07.0 bietet die glibc-Version 2.37 hierfür nun Unterstützung an.
Wie auch in den letzten Jahren drehte sich aber der Großteil der Änderungen in PTXdist um die Aktualisierung von Software-Versionen und der Paketierung von neuer Software.
DistroKit
In drei neuen Releases wurden dieses Jahr viele aktualisierte Software-Versionen, Bugfixes, und auch einige neue Features in unsere PTXdist-Referenz-Distribution DistroKit eingebracht.
Ein großer Teil der Patches drehte sich um die Integration unseres Update-Frameworkes RAUC auf den Boards der v7a- und v8a-Plattformen, sowie die darauf aufbauende Mechanik, um zur Laufzeit eine Datenpartition anzulegen, die unabhängig von den Systempartitionen beschrieben werden kann. Kleinere Ergänzungen machen es nun außerdem möglich, ein System über Androids Fastboot-Protokoll statt von einer SD-Karte zu booten, oder ein einzelnes Barebox-Rezept für alle Boards der v8a-Platform zu verwenden. Als neu unterstützte Plattform ist das Microchip SAMA5D3 EDS-Board hinzugekommen.
umpf - Universal Magic Patch Functionator
Starke Tools sind das Rückgrat produktiver Entwicklungsarbeit, weil sie lästige Fleißarbeit und Flüchtigkeitsfehler vermeiden. So sieht es auch mit unserer Patch-Verwaltung für Kunden-BSPs aus. Dort wo Git beim Jonglieren vieler lange bestehenden Feature-Branches an seine Grenzen stößt, setzt unser seit Jahren intern genutztes Tool umpf an; es dient zur Verwaltung und zum Zusammenfügen von Git-basierten Themen-Branches, besonders in komplexen und lange gepflegten Projekten wie unseren Kunden-Kernel-Repositories.
Dieses Jahr haben wir uns im Sinne unserer Open-Source und Mainline-First-Strategie dazu entschieden, dieses Tool als Open-Source-Software zu veröffentlichen und somit nicht nur versierten Kunden, sondern vor allem auch der interessierten Community die Möglichkeit zu geben, ebenfalls davon zu profitieren.
In unserem Blog-Post umpf - Git on a New Level geben wir einen tieferen Einblick in die Funktionsweise und Nutzung von umpf.