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.


labgrid geht auf Live-Tour!

labgrid erlaubt es uns, Embedded-Linux-Geräte aus der Ferne zu steuern und Integrationstests von Embedded-Linux auf echter Hardware zu implementieren. Pengutronix und andere Firmen setzen daher schon einige Zeit erfolgreich auf labgrid als Mittelpunkt ihrer Embedded-Software-Entwicklungsinfrastruktur.


Linux Automation Test Automation Controller: Ein all-in-one labgrid Exporter

Unsere Tochter Linux Automation GmbH stellt mit dem LXA TAC (Linux Automation Test Automation Controller) einen all-in-one labgrid exporter vor. Das LXA TAC bietet die üblichen Schnittstellen, um ein oder mehrere Embedded Geräte (DUTs, Devices under Test) mit labgrid interaktiv oder automatisiert steuern zu können.


Yes we CAN... add new features

Have you ever experienced an otherwise fine product that is missing just the one feature you need for your application?


DSA in Barebox

The v2022.05.0 Release of barebox introduced initial support for the Distributed Switch Architecture (DSA) Framework. DSA is originally a subsystem from the Linux Kernel, which exposes the individual ports of a network switch IC as virtual network interfaces.


Pengutronix at Embedded World 2022

Welcome to our booth at the Embedded World 2022 in Nürnberg!


First Steps using the candleLight

So you went and got yourself one of our fancy rocket-penguin branded CandleLight dongles or, being the die hard hacker you are, went and soldered one up in your toaster oven labeled "not food safe". What's next then? How do you use this thing? Let's answer these question by grabbing a Raspberry Pi and exploring some of the possibilities.


labgrid Tutorials

This week, we started our series of YouTube labgrid tutorials. In the next few weeks we will publish more video tutorials showing you labgrid's features and giving you handy tips and tricks.


Lab-Automatisierung mit LXA IOBus

Etwas über dreieinhalb Jahre sind seit unserer letzten Produktankündigung vergangen, seitdem haben wir viele Normen gelesen, Dinge über Webshops und den Alltag der Elektronikfertigung gelernt und still und heimlich an neuen Produkten getüftelt. Heute möchte ich das LXA IOBus-System vorstellen, bestehend aus einem CAN-basierten Kommunikationsprotokoll, einem zugehörigen Gateway-Server und einer neuen Klasse an Linux Automation GmbH Produkten. Zwei dieser neuen Produkte sind der Ethernet-Mux und das 4DO-3DI-3AI Input/Output-Board.