Showcase: Continuous Testing

In den Linux-Kernel wandern jedes Jahr etwa 70.000 Patche, viele davon sind Bugfixes. Das Gleiche gilt für die meisten anderen Open-Source-Projekte, die Teil eines modernen Linux-Systems sind. Um von der Arbeit in der Community profitieren zu können, bleibt als sinnvolle Strategie, ständig auf dem neusten Softwarestand aufzusetzen und das System aktuell zu halten. Natürlich können bei dieser Menge an Änderungen auch neue Fehler hinzukommen oder Inkompatibilitäten entstehen.

Wie können wir Ihnen helfen?

Durch den Einsatz von Continuous Testing (CT) auf echter Hardware sind wir in der Lage, auftretende Probleme früh zu erkennen und zu beheben. Unsere Entwicklungsprojekte bestehen im Wesentlichen aus zwei Phasen:

Initiale Produktentwicklung

Viele Projekte beginnen mit einer initialen Entwicklungsphase: In dieser unterstützen wir Sie bei der Inbetriebnahme Ihrer Hardware, sowie dem Aufbau eines Board Support Packages (BSP), das genau auf Ihre Hardware zugeschnitten ist. In dieser Phase entwickeln wir zum Beispiel fehlende Treiber, ergänzen Softwarekomponenten um fehlende Funktionen oder optimieren die Bootzeit Ihres Geräts. In dieser Phase werden Softwarekomponenten in der Regel ständig auf die neusten Versionen aktualisiert. Gleichzeitig bieten wir Ihnen aber auch an für Ihre Hardware und Ihr BSP Tests zu entwickeln. Diese überprüfen entwicklungsbegleitend die Kernfunktionen des Systems. Diese Phase endet in der Regel mit dem Release Ihres Produkts.

Langfristige Wartung

Darüber hinaus bieten wir Ihnen eine dauerhafte Wartung Ihres BSPs an: Wir aktualisieren regelmäßig (z.B. mehrmals pro Jahr) Ihr System und stellen mit den Tests sicher, dass die Funktionen weiterhin gegeben sind.

Durch die anschließende Wartung entstehen Ihnen wesentliche Vorteile: Sollte es durch eine Softwarekomponente zu einem Fehler Ihres Produkts kommen, oder eine Sicherheitslücke auftauchen, steht Ihnen ständig ein aktuelles System zur Verfügung. Hierdurch sind Ihnen kurze Release-Zyklen möglich. Gleichzeitig sind die Änderungen von Update zu Update geringer, sodass die tatsächlichen Aufwände für die Pflege geringer ausfallen.

Sprechen Sie uns hierzu gern an: Wir erstellen mit Ihnen ein auf Ihre Anforderungen zugeschnittenes Entwicklungs- und Wartungskonzept für Ihre Betriebssystemkomponenten.

Beispiel aus dem Alltag

Im folgenden Beispiel setzt ein Kunde für sein Produkt auf Verified Boot. Dabei wird durch eine Kette von kryptographischen Operationen sichergestellt, dass nur ein vom Hersteller signiertes Betriebssystem auf einem Gerät ausgeführt werden kann. Dabei überprüft die jeweils aktive Komponente (z.B. der Bootloader), ob die nächste zu ladende Komponente (z.B. der Linux Kernel) eine gültige Signatur besitzt. Nur wenn dies der Fall ist, wird die jeweilige nächste Komponente auch ausgeführt.

Mehr Informationen zu Verified Boot

Unser Kollege Marc Kleine-Budde hat auf der ELC Europe 2016 mit "Verified Boot: From ROM to Userspace" einen Vortrag zum Thema gehalten. (Youtube, Slides)

Die Verified-Boot-Kette, von der Konfiguration des ROM-Codes des Prozessors, über den Bootloader, den Linux Kernel, bis hin zum Userspace werden bei diesem Kunden durch uns ins BSP integriert und gewartet.

Testfall

Die beschriebene Verifikation in dieser Kette wird durch eine Reihe von Tests sichergestellt. Dazu gehören u.a. die Verifikation des FIT Images, welches Linux-Kernel und Device-Tree enthält, als auch der Test des dm-verity geschützten Dateisystems. Hierzu wird das FIT Image subtil verändert und anschließend versucht das System zu booten. Ein weiterer Test verändert die Datei des init-Prozesses im dm-verity geschützten Dateisystem. Der Test erwartet, dass Lesen und Ausführen dieser Datei fehlschlägt und somit Verified-Boot korrekt funktioniert.

Während dieses Tests werden als Seiteneffekt verschiedene Funktionen des Bootloaders barebox getestet: Es werden Images zwsichen Partitionen kopiert, Dateisystem eingehangen/verändert und das Auslösen des Watchdogs getestet.

Fehlerfall

Während eines Wartungs-Updates des BSP wurde nun der Bootloader aktualisiert und der zuvor besprochene Testfall ist fehlgeschlagen. Die gute Nachricht: Die Verified-Boot-Funktionen haben weiterhin funktioniert: Das manipulierte System wurde nicht gebootet.

Aber: Der Test hat zwei Fehler in barebox aufgedeckt: Der eine Fehler trat beim Kopieren auf POSIX device-files auf (Fix von Sascha Hauer). Der andere Fehler betrifft den Watchdog (Fix von Ahmad Fatoum), der das System nach dem provozierten Fehler in der Verified-Boot-Kette hätte zurücksetzen sollen.

Beide Fehler wurden durch den Test aufgedeckt und die Fixes ins BSP integriert, bevor der neue Softwarestand zum Kunden ausgeliefert wurde.

Zurück zur Messeseite

Weiterführende Links

Showcase: Remote Working

Zur Projektarbeit mit unseren Kunden gehört die Arbeit mit Prototypen-Hardware. Da wir grundsätzlich parallel für mehrere Kunden an vielen verschieden Projekten arbeiten, bedeutet das eine Flut von Prototypen auf den Schreibtischen unserer Entwickler. Spätestens wenn im Team an einem Prototypen gearbeitet werden soll oder längere Zeit nicht aktiv an einem Projekt gearbeitet wird, muss die Hardware regelmäßig umgezogen und am neuen Arbeitsplatz verkabelt werden. Erschwerend kommt hinzu, dass die Entfernung zwischen unseren Entwickler-Schreibtischen durch die aktuelle Homeoffice-Situation, nicht wie gewohnt in Metern, sondern in Kilometern gemessen wird.


Showcase: Embedded off-the-shelf

Ein Firmware-Upgrade ist fällig. Eine neu implementierte Funktion muss ausgerollt, eine Sicherheitslücke gepatcht oder neue Hardware-Unterstützung hinzugefügt werden. Die Software ist zwar leistungsfähig, aber komplex. Pengutronix' Strategie, mit dieser Komplexität umzugehen, ist die Arbeit an einem versionskontrollierten Board Support Package (BSP) mit kontinuierlichen Updates und Tests auf dem neuesten Mainline-Linux-Kernel.


Showcase: Fail-Safe (OTA) Field Updating

Enrico Jörns | | didyouknow, rauc

Eingebettete Systeme und IoT-Geräte robust und sicher im Feld updaten zu können ist heute eine Kernanforderung jedes Produkts. Das Update-Framework RAUC ist die Basis für eine moderne und zukunftsfähige Lösung. In diesem Showcase zeigen wir die Grundprinzipien eines ausfallsicheren Update-Systems und wie Sie dieses mit Unterstützung von Pengutronix für Ihre Plattform realisieren können.


Showcase: Grafik auf i.MX8MP

Die Inbetriebnahme der Grafikausgabepipeline auf dem i.MX8M Plus (kurz i.MX8MP) ist ein aktuelles Beispiel dafür, wie Open Source und Upstream-Treiber für GPUs und Displayeinheiten Aufwand und Risiko im Projekt reduzieren können.


Showcase: Preempt RT und Time Sensitive Networking

Heutzutage verfügen selbst einfache und günstige Mikrocontroller über ausreichend Rechenleistung, um zeitkritische Aufgaben im industriellen Umfeld zu bearbeiten. Sind jedoch die Aktoren und Sensoren in einer größeren Anlage verteilt und sollen mittels Ethernet vernetzt werden, ist der tatsächliche Verarbeitungszeitpunkt eines Ereignisses nicht ohne weiteres vorhersehbar. Linux mit Preempt RT und ein Netzwerk mit Time Sensitive Networking (TSN) Funktionalitäten kann hier Abhilfe schaffen.


Pengutronix at FOSDEM 2021

"FOSDEM is a free event for software developers to meet, share ideas and collaborate. Every year, thousands of developers of free and open source software from all over the world gather at the event in Brussels. In 2021, they will gather online." -- FOSDEM


Pengutronix auf dem Live Embedded Event

Conference, Event, Testing

Jetzt, wo sich durch die COVID-19-Pandemie alle an die Digitalisierung und Online-Konferenzen gewöhnt haben, war es noch nie so einfach, eine Konferenz zu organisieren und alle Experten und Interessierten aus einem Bereich für wenige Stunden des intensiven Ideenaustauschs zusammenzuholen.


A Logo for labgrid

Enrico Jörns | | labgrid

It took us a while to find a good logo for one of our latest (but already quite-a-few-years-out) software projects, called labgrid. In case you have not heard of it yet, feel free to read our short blog post from 2017 or visit labgrid's GitHub page.


Pengutronix at FrOSCon 2018

This year, a team from Pengutronix attended FrOSCon in St. Augustin for the first time. We took the opportunity to shake hands, talk about our latest developments and meet hackers interested in working with embedded Linux.


USB-SD-Mux: Automated SD-Card Juggler

Once the bootloader on your embedded device is up and running the development of kernel and userland in PTXdist-based BSPs is usually based on booting from network. Thus there is no need for the developer to write the boot media with a new image.