Rückblick auf 2022

PWM Subsystem

Die Maintanance im PWM-Subsystem des Kernels war in 2022 geprägt von Aufräumarbeiten und Vereinheitlichungen. Prominent sticht dabei heraus, dass das PWM-Framework nur noch die seit 2016 implementierte atomic updates-Abstraktion für Hardware-Treiber unterstützt, mit dessen Hilfe Konfigurationsänderungen mit einem einzigen API-Call getätigt werden können. Damit können (mit der passenden Implementierung des Hardware Treibers und der passenden Hardware) ungewollte Spannungsausschläge beim Umkonfigurieren des PWM verhindert werden. 2022 wurde endlich mal die Altlast alle Treiber auf dieses Modell zu konvertieren angepackt und mit der Änderung pwm: Drop support for legacy drivers abgeschlossen.

Eine Umstellung, die noch nicht komplett vollzogen ist, ist, dass Nutzer der PWM-API auch die oben beschriebene atomic API verwenden. Das ist eines der nächsten Ziele.

Barebox

Auch Barebox wird fleißig weiter entwickelt und so gibt es einige neu unterstütze Boards:

• Quartz64 board
• BananaPi R2 Pro
• Radxa Rock3 board
• 96Boards Meerkat96
• Enclustra AA1
• Raspberry Pi4 im 32bit- und 64bit-Modus
• PHYTEC phyCORE stm32mp1
• InnoComm WB15 i.MX8MM
• TQ mba8mpxl
• TQMa6UL
• MYIR MYD-AM335X

Features und Verbesserungen:

Mit verbesserten TrustZone-Support können einige neuere SoCs einzelne Blöcke ihrer Hardware entweder der Normal World oder der Secure World zuweisen. Während in der Normal World beispielsweise der Bootloader und Linux laufen, kann dann der Zugriff auf grundlegende Infrastruktur wie Clocks, Resets und Regulatoren dann nur noch aus der Secure World erfolgen. Da Treiber in der Normal World dennoch mit Teilen dieser Hardwarekomponenten kommuniziere müssen, wurde von ARM SCMI (System Control and Management Interface) als standardisiertes Interface eingeführt. Auch die Treiber in Barebox müssen daher mit der Secure World, z.B. der ARM Trusted Firmware, über die entsprechenden Secure Monitor Calls kommunizieren können, dafür wurde entsprechender Support in Barebox hinzugefügt.

Durch den DSA (Distributed Switch Architecture) Support in Barebox ist es nun möglich, einen Switch an das xMII-Interface eines SoCs anzuschließen und dadurch mehrere Netzwerkports an einem Gerät auch schon im Bootloader zu unterstützen, beispielsweise für Netboot. Die einzelnen Switchports werden dabei als separate virtuelle Netzwerkinterfaces dargestellt und können separate Netzwerkkonfigurationen gesetzt bekommen.

Um die vorhandene Netzwerkbandbreite für TFTP Downloads optimal ausnutzen zu können, unterstützt TFTP in Barebox nun auch die Windowsize-Option aus RFC7440. Durch sorgfältiges Tuning der Parameter kann dadurch bei TFTP Downloads ein Speedup um den Faktor 4-30 erreicht werden.

Da Python2 bereits seit einiger Zeit abgekündigt wurde, setzten die Tools in Barebox nun komplett auf Python3.

DistroKit

Benutzer unseres Beispiel-BSPs DistroKit durften sich 2022 über 90 Patche freuen. Neben Updates auf die Greatest-und-Latest Releases verschiedener Komponenten unterstützt DistroKit jetzt zwei weitere Boards: Den Raspberry Pi 4 und das Radxa Rock 3-A.

Auch an bereits existerenden Boards hat sich was getan: Für die STM32MP1-Boards wird jetzt das neue FIP-Boot-Format unterstützt und alle ARMv7-A-kompatiblen Raspberry Pi Boards werden nun mit dem selben Image unterstützt, egal ob Raspberry Pi 2, 3 oder 4.

Labgrid

In der Embedded-Board-Control-Library labgrid haben wir dieses Jahr Resource- und Driver-Support für einige neue Anwendungsfälle gemergt, u.a. für

• Geräte im DFU-Modus,
• Netzwerkgeräte im Android-Fastboot-State und
• Proxy-Support für mehr Power-Backends.

Neben einer Vielzahl von Bugfixes und anderen Features wurde labgrids Dokumentation überarbeitet und einige Code-Beispiele werden seither per CI getestet. Unter der Haube haben wir auf pyproject.toml umgestellt. Ein CI-Job für Releases soll uns in Zukunft häufigere Releases erleichtern.

Als Nächstes wird die Authentifizierung zwischen Coordinator, Exporter und Client umgestellt werden (die bisherige Authentifizierung wird noch eine Zeit lang unterstützt bleiben). Das ebnet uns den Weg zur Aufteilung von Abhängigkeiten vom Coordinator (aktuell Crossbar) und labgrid selbst. Das Ziel ist, ungepinnte Abhängigkeiten zu ermöglichen. Versionskonflikte von Abhängigkeiten sollen damit zur Ausnahme werden.

PTXdist

Neben der üblichen Pflege der ganzen Pakete, die bei einem Embedded-Linux Buildsystem wie PTXdist unabdingbar ist, gab es dieses Jahr vor allem Verbesserungen bei der User-Experience.

Mit den neuen Befehlen fast-bsp-report und full-bsp-report lassen sich yaml-Dateien erstellen, die jede Menge Informationen zum BSP beinhalten. Details zu den Paketen wie Version, Lizenz und Patche, aber auch die verwendete Toolchain und was für Images erzeugt werden. Daraus kann dann mit weiterem Tooling z.B. ein Lizenz-Report erzeugt werden. Und es gibt auch schon ein kleines Tool was daraus die notwendigen Informationen holt, um mit VisualStudioCode Applikationen für das BSP entwickeln zu können.

Für viele Pakete erzeugt PTXdist jetzt eine compile_commands.json Datei. Die kann von Language Servern wie clangd verwendet werden um zum Beispiel die richtigen Header zu finden. Das macht das Editieren von Code mit Editoren und IDEs, die einen Language Server verwenden, deutlich komfortabler. Voraussetzung dafür ist, dass das Buildsystem des Pakets Support dafür bietet. Aktuell sind dies alle CMake- und Meson-basierten Pakete, der Linux Kernel und Barebox.

Optional kann PTXdist jetzt zu allen Binaries eine sogenannte MiniDebugInfo Section hinzufügen. Das ist eine extrem reduzierte Form der Debugsymbole, die gerade dafür reicht, Funktionsnamen aufzulösen. Damit können dann Applikationen wie systemd-coredump zur Laufzeit Backtraces erstellen und loggen, auch wenn die normalen Debugsymbole fehlen. Sehr praktisch um im Feld bei Fehlern mehr Informationen im Log abzulegen ohne grössere Datenmengen in Form Coredumps zu archivieren.

RAUC

Für das von Pengutronix verwaltete Update-Framework RAUC war das vergangene Jahr geprägt von einer Reihe interessanter Entwicklungen im Bereich OTA-Updates.

Besonders stolz sind unsere Maintainer, die das Projekt mit viel Herzblut voran treiben, dass es RAUC in der Zwischenzeit auch ohne das Zutun von Pengutronix in viele populäre Produkte geschafft hat, wie etwa die Spielekonsole 'Steam Deck' von Valve oder als Teil von Linux4ICE in die Anzeigen der ICEs.

In 478 Patchen, verteilt auf 3 Releases, wurden, basierend auf dem 2020 eingeführten neuen 'verity' Bundle-Format, drei grundlegende Features implementiert:

So unterstützt RAUC erstmals ohne externe Tools das Streamen von Update-Bundles über HTTP(S). Damit gehört die Notwendigkeit eines Zwischenspeichers für Update-Artefakte auf dem Zielsystem der Vergangenheit an. Da auch heutzutage Übertragungsbandbreiten immer noch oft limitiert, teuer oder instabil sind, haben wir mit dem Konzept der 'adaptiven Updates' den Grundstein für verschiedene Methoden zur delta-artigen Übertragung gelegt. Das beste daran: dank der Möglichkeit von RAUC, wahlfreien Zugriff auf das Bundle zu haben, geschieht dies weitgehend transparent. Mit 'block-hash-index' wurde eine erste Methode zum Chunken und differentiellen Updates Block-Device-Images geschaffen.

Da Updates auch sensible Daten oder Applikationen enthalten können und sowohl die Transportwege als auch die Ablageorte für OTA Updates nicht immer vollständig abgeschottet werden können, gab es schon des Öfteren den Wunsch, in RAUC Update-Bundles auch verschlüsselt übertragen zu können. Diese Jahr wurde auch dieser Punkt im Rahmen eines Projektes umgesetzt. Mit crypt-Bundles können Updates nun vollständig und für eine Große Anzahl individueller Empfänger-Systeme verschlüsselt werden, während es weiter möglich bleibt sie für Streaming und "Adaptive Updates" zu nutzen.

candleLight

Wir sind ja ein bisschen überrascht von dem Erfolg, den das Video "CAN Protocol Reverse Engineering with Wireshark" von Leonard auf Youtube hat und freuen uns, dass uns aus der Community Anfragen zu Varianten und Verbesserungen rund um den dort verwendeten Open Hardware USB-zu-CAN-Adapters candleLight erreichen.

Für eine bessere Handhabung hat Chris Fiege daher zum Beispiel ein 3D-Druck Gehäuse entworfen.

LXA TAC

Wer uns dieses Jahr auf einer Messe oder Konferenz getroffen hat, konnte vielleicht schon einen Blick auf das LXA TAC, den Linux Automation GmbH Test Automation Controller, erhaschen. Aber auch bei zukünftigen Messen wird es dazu noch ausreichend Gelegenheit geben. Wer mehr als nur einen Blick erhaschen möchte, wird sich allerdings noch etwas gedulden müssen, denn durch die schon seit 2020 bestehenden Probleme in der Bauteilbeschaffung wird sich die Serienproduktion noch etwas verschieben.

Die Wartezeit bis zur Produktion gibt uns Gelegenheit die Softwareseite mit Feinschliff und Politur zu versehen. Zukünftige KäuferInnen können sich also auf einiges freuen:

• Saubere Labgrid-Integration der verschiedenen Features.
• Ein offenes und einfach anpassbares Yocto-Layer als Basis für eigene Betriebssystem-Images, inklusive Anleitungen um z.B. eigene Konfigurationsdateien direkt im Image auszuliefern. (Offizielle vorgebaute Images wird es aber natürlich auch geben)
• Einen System-Management-Deamon, der das Gerät per Webinterface und API steuerbar macht.

USB-Mux

Lange war es Mux-Mäuschen still um unsere USB-Muxe, aber wie heißt es so schön? "Was lange wärt, wird endlich gut!" Im Dezember 2022 haben wir die ersten Geräte aus der Fertigung erhalten und konnten sie an Kunden weitergeben.

Mit den USB-Muxen erweitern wir unsere Möglichkeiten in der Testautomatisierung auf USB-Schnittstellen. Detailliertere Informationen gibt es in dem Datenblatt

Die Fertigung weiterer Geräte folgt, sodass wir den USB-Mux im nächsten Jahr im breiteren Einsatz sehen.

USB-T1L - Adapter

Der neue 10Base-T1L Ethernet-Standard erlaubt Übertragungsraten von 10MBit/s über ein einzelnes Aderpaar. Wer sich jetzt in die 1980er und die Zeit der Vampirklemmen zurückerinnert fühlt, sei beruhigt: 10Base-T1L bringt einige Verbesserungen gegenüber der Technologie von damals. 10Base-T1L erlaubt Punkt-zu-Punkt Ethernet-Verbindungen von Geräten über Distanzen von bis zu 1.5km-2km bei niedrigem Leistungsbedarf.

10Base-T1L ist auf bestem Wege sich als Industrial-Ethernet-Standard für lange Distanzen zu etablieren.

Der USB-T1L-Adapter ist ein Werkzeug für Embedded-EntwicklerInnen, die 10Base-T1l basierte Produkte sowohl zeitnah, als auch möglichst nahe am tatsächlichen Produkt entwickeln wollen. Dazu ist der USB-T1L als firmwareloses Gerät designed; Der Linux-Kernel des angeschlossenen Geräts übernimmt selbst die Ansteuerung und Konfiguration des auf dem Gerät verbauten 10Base-T1L Phy.

Eine Besonderheit des USB-T1L ist, dass es unser erstes in-house produziertes Gerät für den externen Verkauf darstellt. Der USB-T1L ist das Gerät mit dem wir unsere neue Pick&Place-Maschine eingeweiht haben. Diese Anschaffung ermöglicht uns zukünftig schneller Prototypen zu fertigen und unsere Entwicklungszyklen zu beschleunigen. Fingers crossed, dass bald auch die Bauteilverfügbarkeit besser wird.