Firmware-Entwicklung für serienreife Geräte

Auf Anwendungsprozessoren wie NXP i.MX, TI Sitara, AMD Zynq oder NVIDIA Jetson bauen wir die komplette Embedded-Linux-Plattform: Board Support Package (BSP), U-Boot, Kernel-Konfiguration, Device Tree und Root-Dateisystem. Wir nutzen das Yocto Project mit eigenen Layern für das Produkt, sodass sich jedes Image auch Jahre nach dem Release auf jedem Rechner aus den Quellen neu bauen lässt.

Yocto-Beratung beginnt oft mit einem bestehenden Build, den nur eine Person versteht. Wir teilen ihn in saubere BSP-, Distributions- und Anwendungs-Layer auf, fixieren alle Versionen, bringen den Build in die CI und dokumentieren, wie man ein Rezept oder eine neue Board-Variante hinzufügt.

• Yocto-BSP-Entwicklung, eigene Meta-Layer und Rezepte für Ihre Hardware
• Portierung von Kernel und U-Boot, Device Tree und Optimierung der Bootzeit
• Schreibgeschützte Root-Dateisysteme und A/B-Updates mit RAUC, SWUpdate oder Mender
• Langfristige Wartung: LTS-Kernel-Updates und Schwachstellen-Monitoring des Images

Für den Cyber Resilience Act ist Yocto ein guter Ausgangspunkt: Bei jedem Build kann es eine SPDX-SBOM des gesamten Images erzeugen und die Pakete auf bekannte Schwachstellen (CVEs) prüfen. Wir binden beides in den Release-Prozess ein, sodass die technische Dokumentation und die im Supportzeitraum erwarteten Sicherheitsupdates aus derselben Pipeline kommen.

Für Mikrocontroller wählen wir zwischen Bare-Metal, FreeRTOS, Zephyr und Eclipse ThreadX nach Echtzeitanforderungen, Speicher, Energiebudget und dem Kommunikationsstack, den das Produkt braucht. Zephyr bringt Device Tree, viele Treiber sowie Bluetooth-LE-, Thread- und Matter-Stacks mit; FreeRTOS bleibt die schlankere Wahl für kleine MCUs und bestehende Codebasen.

Zephyr-Entwicklung umfasst Board-Ports für eigene Hardware, Out-of-Tree-Treiber, West-Manifeste mit fixierten Modulversionen und MCUboot als Bootloader. Bei FreeRTOS planen wir Task-Modell, Prioritäten und Speicherbudget von Anfang an und messen das Timing auf der Zielhardware, nicht nur im Simulator.

• Zephyr-Board-Support, Device-Tree-Overlays und Out-of-Tree-Treiber
• RTOS-BSP- und Treiberentwicklung für STM32, Nordic nRF, NXP, Renesas und Espressif
• Low-Power-Design: Schlafmodi, Tickless Idle und Strommessungen auf echter Hardware
• Migration von Bare-Metal oder einem älteren RTOS auf Zephyr oder FreeRTOS

Signierte, vom Bootloader geprüfte Images, Rollback-Schutz und eine Liste aller Module mit ihren Versionen helfen, die Anforderungen des Cyber Resilience Act an Integrität, sichere Updates und die SBOM zu erfüllen - auch bei kleinen Geräten. Wir bauen sie von Anfang an in die Firmware ein, nicht erst kurz vor dem Release. Siehe die CRA-Checkliste.

Wenn ein Sensor, FPGA, Display oder Funkmodul keinen Treiber für Ihren Kernel hat, schreiben wir ihn: Plattform- und Character-Treiber, I2C, SPI, UART, USB, PCIe und Netzwerktreiber, mit Device-Tree-Bindings und IIO-, Input-, DRM- oder V4L2-Schnittstellen, wo ein Kernel-Subsystem passt. Anwendungen nutzen dann Standardwerkzeuge statt einer eigenen Schnittstelle.

Treiberentwicklung für Embedded-Systeme heißt auch, Treiber langfristig lauffähig zu halten: Wir portieren sie zwischen Kernel-Versionen, bereiten Patches für den Mainline-Kernel vor, wenn es sinnvoll ist, und testen sie auf dem Zielboard in unserem Labor. Auf Mikrocontrollern schreiben wir Treiber auf Basis der Hersteller-HAL oder direkt auf Registerebene.

• Linux-Kernel-Treiber für eigene und Standard-Peripherie
• Device Tree, Pin Control und Power Management (Runtime PM, Suspend und Resume)
• Treiberportierung bei Kernel- und BSP-Upgrades
• Bare-Metal- und RTOS-Treiber für Mikrocontroller-Peripherie

Kernel-Treiber laufen mit vollen Rechten, ein Treiberfehler ist also ein Sicherheitsproblem. Code-Review, statische Analyse und zeitnahe Kernel-Updates gehören zur Schwachstellenbehandlung, die der Cyber Resilience Act von Herstellern von Produkten mit digitalen Elementen verlangt.