DH electronics GmbH
Change to English
scroll Scroll Down down

Linux als Betriebssystem

Neben der Hardwareentwicklung gehört auch die Softwareentwicklung zu unseren Kernkompetenzen

Seit mehr als 30 Jahren befassen wir uns mit der Entwicklung von individuellen Embedded Systemen. Über die Zeit haben wir uns dabei auf Linux als Embedded Betriebssystem spezialisiert und unterstützen heute mit unserem BSP ein Linux System auf Basis von Yocto und Debian. Wir sind von der Open Source Bewegung überzeugt und stellen unseren Code der Linux Kernel Community zur Verfügung

Mainline Kernel vs. Vendor Kernel

Bei der Entscheidung zwischen dem Mainline Kernel und dem Vendor Kernel kommen mehrere Faktoren ins Spiel:

  • Sicherheit und CRA (Cyber Resilience Act)
  • Aktualität und Versionsflexibilität
  • Qualitätskontrolle und Workarounds
  • Binäre Blobs und Abhängigkeiten
  • Probleme werden im Mainline Kernel auf generische Weise gelöst

Zusammenfassend lässt sich sagen, dass die Wahl eines Vendor Kernels mit Nachteilen in Bezug auf Sicherheit, Aktualität, Flexibilität, Qualitätskontrolle, Binärblöcke und CI/CD Kompatibilität verbunden ist. All diese Nachteile können jedoch durch die Verwendung des Mainline Kernels überwunden werden.

Yocto Layer Aufbau

Grundsätzlich nutzt man bei Yocto verschiedene Layer, die zusammen das Buildsystem ergeben und über diese ein Linux Image gebaut werden kann. Diese Layer beinhalten Rezepte, aus denen die einzelnen Softwarepakete gebaut werden und Konfigurationen, bei denen die Eigenschaften des resultierenden Systems konfiguriert werden.

Alle Yocto Layer sind gleichzeitig Git-Repositories, bei denen jede Yocto Version, die der Layer unterstützt, ein eigener Branch ist.
Dabei haben die Layer jeweils einen unterschiedlichen Zweck.

Folgende Layer werden üblicherweise bei einem Build für ein DHSOM Modul benutzt:

Yocto Basis Layer (poky, https://git.yoctoproject.org/poky/)
Der Layer "poky" beinhaltet den Kern des Buildsystems (Bitbake) und Rezepte für die wichtigsten Pakete und Libraries, die oft für das Basissystem benötigt werden.
Der Layer wird von der Open Source Community unter dem Schirm der Yocto Foundation verwaltet.

OpenEmbedded Layer (meta-openembedded, https://git.openembedded.org/meta-openembedded/)
"meta-openembedded" beinhaltet eine Vielzahl von Rezepten für populäre Pakete und Libraries.
Der Layer wird von der Open Source Community verwaltet.

Mainline Layer (meta-mainline-common, https://source.denx.de/denx/meta-mainline-common)
Der Layer beinhaltet regelmäßig aktualisierte Rezepte für die verschiedenen LTS-Versionen vom Linux-Kernel, U-Boot und Mesa (Allgemeiner Grafiktreiber). Das sind jeweils die Mainline-Versionen ohne irgendwelche Patches.
Der Layer wird von der Firma DENX verwaltet.

DH BSP Layer (meta-dhsom-imx-bsp (für i.MX6, i.MX8), https://github.com/dh-electronics/meta-dhsom-imx-bsp, meta-dhsom-stm32-bsp (für STM32MP), https://github.com/dh-electronics/meta-dhsom-stm32-bsp)
Dieser Layer beinhalten die Anpassungen damit grundsätzlich Images für DHSOM Module gebaut werden können. Darunter zählen unter anderem Patches für Kernel und U-Boot (aus dem Mainline-Layer) und die Buildkonfigurationen für die verschiedenen Module.
Diese Layer werden von DH verwaltet.

DH Extras Layer (meta-dhsom-extras, https://github.com/dh-electronics/meta-dhsom-extras)
Dieser Layer beinhaltet primär ein modulares Demo-Image (dh-image-demo). Mit diesem Demoimage können verschiedene Aspekte der DHSOM Module getestet werden.
Zusätzlich sind noch für ein paar Pakete sinnvolle Anpassungen vorhanden.
Dieser Layer wird von DH verwaltet.

Diverse Layer für verschiedene Frameworks oder Softwarepakete (optional)
Wenn benötigt gibt es für verschiedene Frameworks oder Softwarepakte noch spezielle Layer, die man in den Build einbinden kann. Beispiele hierfür sind:

  • Qt (meta-qt5, meta-qt6)
  • Flutter (meta-flutter)
  • Webkit Webbrowser (meta-webkit)

Der Kundenlayer ist spezifisch für den jeweiligen Kunden bzw. für das jeweilige Kundenprojekt. Der Layer beinhaltet in der Regel folgendes:

  • Angepasster Kernel und Bootloader
  • Rezepte für Kundenspezifische Pakete
  • Rezeptanpassungen für Pakete aus anderen Layern
  • Kundenspezifische Konfiguration des Images

Der Layer ist dabei nicht öffentlich, sondern im nichtöffentlichen DH GitLab oder beim Kunden selbst gehostet.

Wenn an einem Kundenprojekt gearbeitet wird, dann wird jeweils nur der Kundenlayer verändert.

Um einen Build zu "fixieren", damit dieser in der Zukunft mit gleichem Ergebnis wiederholt werden kann, muss man den Build mit den gleichen Ständen (= Commits) der jeweiligen Yocto Layer durchführen, mit dem auch der ursprüngliche Build durchgeführt wurde. Dazu kann das KAS-Tool helfen.

Will man bei einem Projekt die neuesten Sicherheitsupdates bekommen, reicht es, jeweils die aktuellen Stände der verschiedenen übergeordneten Layer zu pullen. Damit werden die aktualisierten Rezepte verwendet. Wenn man im Kundenlayer ein Rezept aus einem anderen Layer erweitert, dann kann es sein, dass hier durch das Update etwas angepasst werden muss.

Nähere Infos zu unserem Wartungsvertrag

Mainline-Support (Upstream-Support)

Jedes neue DH System On Module (SOM) wird zu Mainline Linux und U-Boot upgestreamt. Eine Mainline-Version eines System On Modules kann es nicht direkt geben, da nur ein fertiges Produkt upgestreamt werden kann. Daher werden die System On Modules immer auf Basis des jeweiligen Evaluation Boards upgestreamt.
 

Hier ein Überblick über unsere SOMs und die Evaluierungsboards:

+

Das Yocto basierte BSP verwendet außerdem die Mainline-Version und nicht eine Vendor-Version des SoC-Herstellers. Dies macht es viel einfacher, das BSP zu pflegen und auf dem neuesten Stand zu halten.

Die Wartung des BSP basiert auf der Kombination zum Evaluation Board und ist kostenlos.

Bei kundenspezifischen Projekten wird immer das Referenzdesign als Basis für die Erstellung eines angepassten BSP für das jeweilige Produkt verwendet. Die Yocto Struktur ist zudem so ausgelegt, dass das Basis BSP unverändert weiterverwendet werden kann. Dies hat für das Projekt den Vorteil, dass ein aktualisiertes Basis BSP leichter übernommen werden kann.

KAS Tool

KAS (https://github.com/siemens/kas) ist ein Python Tool, das den Workflow bei dem Bau von Linux Images mit Yocto/OpenEmbedded unterstüzt, indem es eine große Auswahl an möglichen Konfigurationen bietet.

KAS vereinfacht so nicht nur die Konfiguration bei Yocto Systemen, sondern ermöglicht auch diese einfach im zusätzlichen Software Support zu erweitern. Das hält unsere Softwaresysteme aktuell und damit auch sicher.

KAS deckt die folgenden Bereiche ab:

  • Herunterladen der verschiedenen für den Build benötigten Layer
  • Initialisierung der Buildumgebung und Konfiguration für den Build (z.B. Zielhardware)
  • Starten des Builds

Dabei arbeitet KAS mit Konfigurationsfiles, in denen die verschiedenen zu verwendenden Layer und Konfigurationsoptionen definiert sind. Dabei können auch Selektionsoptionen definiert werden.

Diese Selektionsoptionen können über eine konsolenbasierte GUI (wie bei der Konfiguration des Linux-Kernels) ausgewählt werden.

Im DH-Repository zum Bau von Yocto-Images mit KAS (https://github.com/dh-electronics/kas-dhsom) z.B. kann über diese GUI ausgewählt werden, für welches DHSOM-Modul das Image gebaut werden soll (z.B. i.MX6, i.MX8MP oder STM32MP15) und gesteuert werden, welche Bestandteile in das Demo-Image integriert werden sollen (z.B. Qt, verschiedene Webbrowser, Flutter). Dies ist der große Vorteil von KAS: Sind die KAS Konfigurationsfiles für ein Projekt einmal erstellt, ist es auch für jemanden ohne Kenntnisse des Yocto/OpenEmbedded Buildprozesses relativ einfach, ein Yocto Image mit KAS zu bauen.

Auch Projekte, bei denen es verschiedene Hardware Varianten gibt, die jeweils eigene Builds benötigen, lassen sich mit KAS sehr gut abbilden, da man in den Konfigurationsfiles von KAS eine Auswahlmöglichkeit einbauen kann. Wenn du beispielsweise ein Build-Image auf deinem Gerät releast, kann die KAS-Konfiguration um eine Option erweitert werden, bei der die Yocto/OpenEmbedded Layer auf den jeweiligen Stand des releasten Images fixiert werden. Damit sind reproduzierbare Builds möglich.

+