Hardware-Entwicklung für Linux-Systeme

Linux kann die Entwicklung eines Embedded-Systems deutlich beschleunigen. Das gilt aber nur, wenn die Hardware zum Linux-Modell passt. Gute Treiber, ein sauberer Device Tree und eine gut durchdachte Schaltung gehören deshalb zusammen.

Dieser Artikel richtet sich an Entwickler, die eigene Linux-Hardware planen. Der Schwerpunkt liegt auf ARM- und SBC-basierten Systemen. Viele Punkte gelten ebenso für andere Plattformen.

Warum Linux?

Linux bringt eine große Menge bewährter Infrastruktur mit:

• Netzwerk und Routing,
• Dateisysteme,
• Benutzer- und Rechteverwaltung,
• Logging und Diagnose,
• Grafik und Kamera,
• Update-Mechanismen,
• Security-Funktionen,
• viele stabile Userspace-APIs.

Auch die Werkzeuge sind bereits vorhanden. Ein Ethernet-Interface lässt sich mit ip, ping, ethtool, tcpdump und iperf3 prüfen. Für I²C gibt es i2cdetect und i2ctransfer. Kameras nutzen die V4L2- und Media-Controller-Werkzeuge.

Das spart Entwicklungszeit. Vor allem reduziert es die Menge eigener Software, die über Jahre gepflegt werden muss.

Hardware entscheidet über den Linux-Aufwand

Die Vorteile von Linux entstehen nicht automatisch. Sie werden durch die Hardwareentscheidung entweder unterstützt oder blockiert.

Ein gutes Design nutzt vorhandene Kernel-Subsysteme. Ein schlechtes Design erzeugt Sonderwege:

• private Kernel-Patches,
• eigene Treiber,
• alte Hersteller-BSPs,
• manuelle Konfiguration nach jedem Update,
• schwer reproduzierbare Fehler.

Die zentrale Regel lautet:

Hardware sollte so angebunden werden, wie es der vorhandene Linux-Treiber und sein Device-Tree-Binding vorsehen.

Nicht jede elektrisch mögliche Verschaltung ist auch eine gute Linux-Lösung.

Zielplattform und BSP

Nicht nur ein einzelner Treiber muss passen. Die gesamte Plattform muss passen.

Vor dem Schaltplan sollten diese Punkte feststehen:

• Ziel-SoC,
• Linux-Distribution,
• Kernelversion,
• Hersteller-BSP oder Mainline-Kernel,
• erwartete Produktlebensdauer.

Ein Mainline-Treiber ist eine gute Grundlage. Er reicht jedoch nicht immer aus. Der Zielkernel muss ihn auch enthalten und aktivieren. Zusätzlich können Kernel-Konfigurationsoptionen oder SoC-spezifische Voraussetzungen nötig sein.

Ein praktisches Beispiel ist ein Ethernet-MAC-PHY. Der Treiber kann vorhanden sein, aber eine benötigte Kerneloption fehlt im gewählten Image. Dann funktioniert die Hardware trotz passendem Baustein nicht wie geplant.

Prüffragen:

• Wird der Zielkernel auf dem SoC aktiv gepflegt?
• Gibt es ein aktuelles Eval-Board?
• Funktionieren die benötigten Schnittstellen im Zielkernel?
• Ist die gewünschte Kernelkonfiguration verfügbar?
• Welche Einschränkungen hat das Hersteller-BSP?
• Lässt sich später auf einen neuen LTS-Kernel wechseln?

Gute Quelle: Linux Kernel Documentation – Driver Implementer’s API Guide

Bauteilauswahl: Mainline zuerst

Die Bauteilauswahl ist die wichtigste Entscheidung im Projekt. Sie bestimmt den späteren Wartungsaufwand stärker als viele Details im Layout.

Ein Treiber im offiziellen Linux-Kernel ist der Goldstandard. Er wird bei neuen Kernelversionen mitgebaut und von einer großen Nutzerbasis verwendet. Das vereinfacht Updates und reduziert langfristig das Risiko.

Auch die zugehörigen Device-Tree-Bindings sollten upstream vorhanden sein. Ein Treiber ohne dokumentiertes Binding ist keine vollständige Lösung.

Mainline-Support richtig prüfen

Die Aussage „Linux supported“ ist zu ungenau. Sie kann bedeuten:

• ein alter Herstellerpatch,
• ein GitHub-Repository ohne Wartungszusage,
• ein Binary-Kernelmodul,
• ein Treiber in einem Hersteller-BSP,
• ein Treiber im offiziellen Linux-Kernel.

Diese Fälle sind nicht gleichwertig.

Prüfen Sie daher:

• die Linux-Kernel-Dokumentation,
• den Linux-Quellcode,
• das Treiberverzeichnis,
• die Device-Tree-Bindings,
• aktuelle LTS-Kernel,
• die öffentliche Patch- und Diskussionhistorie.

Nach einem Mainline-Treiber kommt lange nichts. Ein lokaler Patch kann heute funktionieren. Bei einem Security-Update oder dem nächsten LTS-Kernel muss er aber oft angepasst werden.

Wer einen nicht-mainline Treiber einsetzt, sollte ihn selbst langfristig beherrschen. Dazu gehören Quellcode, Build-System, Tests, Kernelwissen und eine klare Verantwortung im Unternehmen.

Bauteile ohne Treiber

Ein Bauteil ohne speziellen Linux-Treiber ist nicht immer ein Ausschlusskriterium. Einfache Registerschnittstellen über I²C, SPI oder GPIO lassen sich manchmal bewusst im Userspace betreiben.

Das passt zum Beispiel für:

• eine kleine Steuerfunktion,
• einen einfachen ADC,
• einen FPGA mit klarer Registerschnittstelle,
• einen Prototypen oder Bring-up-Aufbau.

Dann müssen aber API, Fehlerverhalten und langfristige Wartung ebenfalls geplant werden. i2c-dev oder spidev sind Werkzeuge. Sie ersetzen nicht automatisch ein gutes Treibermodell.

Firmware, Verfügbarkeit und Lebenszyklus

Viele Komponenten benötigen Firmware. Das betrifft etwa WLAN, Kameras, Ethernet-Switches, FPGAs und Beschleuniger.

Prüfen Sie früh:

• Ist die Firmware verfügbar und redistributable?
• Wie wird sie aktualisiert?
• Welche Firmwareversion passt zu welchem Treiber?
• Gibt es eine Longevity-Zusage?
• Gibt es Errata und ein aktuelles Eval-Board?

Ein technisch gut unterstützter, aber abgekündigter Baustein ist keine gute Basis für ein neues Produkt.

Device Tree: Hardware als Datenmodell

Der Device Tree beschreibt die Hardware für den Kernel. Er enthält unter anderem Busse, Adressen, Interrupts, Reset-Leitungen, Regulatoren, Clocks, GPIOs und Pin-Multiplexing.

Er ist damit der Vertrag zwischen Schaltplan und Linux.

Ein guter Ablauf ist:

1. Treiber auswählen.
2. Device-Tree-Binding lesen.
3. Schaltung danach auslegen.
4. Overlay parallel erstellen.
5. Mit dem Zielkernel testen.

Wenn sich eine Hardware nicht sauber im Device Tree beschreiben lässt, ist das ein ernstes Warnsignal. Es kann auf ein ungeeignetes Treibermodell oder eine unnötige Sonderlösung hinweisen.

Gute Quelle: Linux and the Devicetree

Bauteilanbindung

Ein Treiber beschreibt mehr als das Kommunikationsprotokoll. Häufig legt er auch fest:

• zulässige Clock-Frequenzen,
• Interrupt-Polarität,
• Reset-Verhalten,
• GPIO-Funktionen,
• Versorgung,
• Datenformate,
• unterstützte Betriebsmodi.

Ein Hardwarefeature ist nur dann wertvoll, wenn es vom Treiber konfiguriert werden kann.

Beispiele:

• Ein IC akzeptiert mehrere Clocks. Der Treiber unterstützt nur eine davon.
• Ein Pin ist laut Datenblatt flexibel. Der Treiber nutzt ihn nur als Reset.
• Ein Kamera-Deserializer kann Lane-Swap. Das Binding beschreibt diese Option jedoch nicht.

Der Treiber gehört deshalb zur Bauteilspezifikation.

Pinmux und Boot-Straps

Ein SoC-Pin ist selten nur ein GPIO. Er kann auch SPI, I²C, UART, PWM, Clock, Debug oder Boot-Strap sein.

Prüfen Sie für jeden verwendeten Pin:

• alternative Funktionen,
• interne Pull-ups und Pull-downs,
• Zustand nach Reset,
• Zustand während des Bootens,
• Nutzung durch Boot-ROM oder Firmware,
• Verfügbarkeit für Linux.

Ein falscher Pull-Widerstand kann den Bootvorgang verhindern. Ein Pin kann beim Start kurzzeitig einen unerwünschten Pegel ausgeben. Das betrifft besonders Reset-, Enable- und Lastschalter-Signale.

Pinmux und Pinctrl sollten deshalb früh mit dem Zielkernel getestet werden.

Clocks

Clock-Signale brauchen dieselbe Sorgfalt wie schnelle Datenleitungen.

Prüfen Sie:

• Frequenz und Toleranz,
• Jitter,
• Richtung: Eingang oder Ausgang,
• Start-up-Verhalten,
• Enable-Signal,
• Spannungspegel,
• Verteilung auf mehrere Empfänger.

Shared Clocks sind möglich. Alle beteiligten Bauteile müssen damit umgehen können. Besonders kritisch sind Ethernet, PCIe, USB, MIPI-CSI, MIPI-DSI und Audio.

Interrupts und Reset

Linux kann viele GPIOs als Interrupt verwenden. Trotzdem muss der Interrupt zum Treiber und zur Hardware passen.

Prüfen Sie:

• Edge oder Level,
• Active High oder Active Low,
• Pull-up oder Pull-down,
• Zustand während Reset und Boot,
• Interruptfähigkeit des SoC-Pins.

Geteilte Interrupts sollten die Ausnahme sein. Sie sind nur sinnvoll, wenn Hardware und Treiber sie ausdrücklich unterstützen.

Auch Reset-Leitungen sollten nicht unnötig geteilt werden. Ein Treiber kann einen Reset jederzeit verlangen. Ein globaler Reset kann dann andere, eigentlich unabhängige Geräte zurücksetzen.

Planen Sie daher möglichst:

• getrennte Reset-Leitungen,
• klare Reset-Polarität,
• definierte Mindestdauer,
• einen sicheren Zustand bei Power-up,
• ein definiertes Verhalten nach Watchdog-Reset.

Unterscheiden Sie Power-Reset, Hardware-Reset und Software-Reset. Diese Mechanismen haben oft unterschiedliche Folgen.

Versorgung und Power Sequencing

Die Stromversorgung ist Teil der Linux-Integration. Viele Treiber und Bindings modellieren Regulatoren, Enable-Signale und Abhängigkeiten.

Prüfen Sie:

• benötigte Spannungen,
• Einschaltreihenfolge,
• Spannungsrampen,
• Power-Good,
• Enable-Signale,
• Einschaltstrom,
• Brown-out-Verhalten,
• Abschaltreihenfolge.

Ein gemeinsames Power-Enable kann dieselben Probleme verursachen wie ein gemeinsamer Reset. Wenn ein Treiber eine Versorgung abschaltet, darf er keine unabhängige Peripherie stören.

Nach Neustart, Brown-out und Spannungsunterbrechung muss die Hardware wieder definiert starten.

Gute Quelle: Linux Regulator Framework

I²C

I²C ist einfach, aber nicht automatisch robust.

Die Adresse 0x00 ist für den General Call reserviert. Sie darf nicht als normale Target-Adresse verwendet werden.

Vor dem Schaltplan prüfen:

• Gibt es doppelte Adressen?
• Gibt es Adresspins oder Adressregister?
• Welche Pull-ups sind erforderlich?
• Wie groß sind Buskapazität und Leitungslänge?
• Gibt es mehrere Spannungsdomänen?
• Kann ein einzelnes Gerät zurückgesetzt oder abgeschaltet werden?

Back-Powering muss verhindert werden. Ein ausgeschaltetes Bauteil darf den Bus nicht über I/O-Schutzdioden mitversorgen.

Auch Fehlerfälle gehören ins Konzept:

• Was passiert bei dauerhaft Low auf SDA?
• Was passiert bei dauerhaft Low auf SCL?
• Ist Bus-Recovery möglich?
• Kann ein fehlerhaftes Gerät isoliert werden?

Praxisbeispiel: gleiche Sensoradresse

Zwei gleiche Kameras haben oft dieselbe feste Sensoradresse. In einem Dual-GMSL2-System können beide IMX708-Sensoren nativ 0x1a verwenden.

Damit Linux beide Sensoren getrennt ansprechen kann, erhält jeder Link einen eigenen I²C-Alias. Im BE-IIS-GMSL2-Aufbau sind das zum Beispiel 0x52 und 0x53.

Das zeigt: Die Adressplanung ist Teil der Systemarchitektur. Sie ist nicht nur ein Detail des Schaltplans.

Quellen: Linux I²C/SMBus, BE-IIS GMSL2 Camera Installer

SPI

SPI braucht eine klare Ressourcenplanung.

Prüfen Sie:

• Anzahl der Chip-Select-Leitungen,
• aktive Polarität,
• maximale Frequenz,
• Timing,
• DMA-Unterstützung,
• Interrupt-Leitung,
• Datenrate und CPU-Last.

GPIOs können als Chip Select dienen. Diese Leitungen müssen jedoch im Device Tree beschrieben werden. Ein zusätzlicher CS ist damit kein beliebiger freier GPIO, sondern Teil der verbindlichen SPI-Topologie.

Praxisbeispiel: dritter Chip Select

Viele SBCs stellen zwei SPI-Chip-Selects bereit. Für ein drittes Gerät kann ein GPIO-basierter CS verwendet werden.

Im HAT++-Konzept wird SPI0 dafür bewusst auf drei CS-Leitungen erweitert. Die Belegung ist vorab definiert. Dadurch lassen sich mehrere Interface-HATs kombinieren, ohne dass Chip-Selects zufällig kollidieren.

Bei hohen Datenraten ist SPI keine kostenlose Alternative zu Ethernet oder PCIe. Durchsatz, Interrupt-Last und CPU-Last müssen gemessen werden.

Quellen: Linux SPI subsystem, BE-IIS Installer

GPIOs und schnelle Interfaces

Prüfen Sie vor jeder GPIO-Nutzung, ob der Pin wirklich frei ist. Viele Pins sind bereits für Boot-Straps, Debug, SD-Karte, eMMC, Ethernet, USB, Display, Kamera oder den PMIC vorgesehen.

Bei SoCs mit mehreren Prozessordomänen kommen weitere Fragen dazu:

• Gehört der GPIO zum Application Core?
• Wird er durch einen Real-Time-Core verwendet?
• Kontrolliert Firmware diesen Pin?
• Kann Linux ihn wirklich verwenden?

Bei PCIe, USB 3, Ethernet und MIPI gilt zusätzlich: Treiber lösen keine Signalprobleme.

Prüfen Sie früh:

• Lagenaufbau,
• Impedanz,
• Differenzpaare,
• Längenausgleich,
• Stubs,
• Terminierung,
• Referenzflächen,
• ESD-Schutz,
• Stromversorgung.

Ein Interface kann im Labor funktionieren und im Feld trotzdem ausfallen. Ursachen sind häufig Return-Path-Probleme, schlechte Versorgung oder ungeeignete Schutzbauteile.

Quellen: GPIO descriptor interface, Linux PCI documentation

Echtzeit

Linux ist nicht automatisch echtzeitfähig. Auch PREEMPT_RT hat Grenzen.

Linux passt sehr gut für:

• Netzwerk,
• Konfiguration,
• Logging,
• Visualisierung,
• Datenspeicherung,
• Diagnose,
• Updates.

Für harte zeitkritische Aufgaben ist häufig ein MCU, FPGA oder dedizierter Controller besser geeignet.

Das betrifft zum Beispiel:

• exakte Pulsfolgen,
• schnelle Regelungen,
• sehr niedrige Latenzgrenzen,
• bitgenaue Protokolle,
• zeitkritische Bus-Ansteuerung.

LIN ist ein typisches Beispiel. Der zeitkritische Teil gehört oft in einen Kommunikationscontroller oder einen kleinen Embedded-MCU. Linux übernimmt dann die übergeordnete Logik.

Gute Quelle: Linux real-time documentation

Feldbusse und Ethernet

Linux unterstützt CAN sehr gut. SocketCAN integriert CAN als Netzwerkschnittstelle in den Linux-Netzwerkstack.

CAN bleibt sinnvoll für:

• Maschinen,
• Fahrzeuge,
• Bestandsanlagen,
• robuste Feldbuskommunikation.

Ein Linux-System sollte Ethernet trotzdem früh mitdenken. Ethernet bietet IP, Routing, bekannte Diagnosewerkzeuge und Remote-Zugriff.

Single Pair Ethernet

Single Pair Ethernet ist für industrielle Systeme interessant. MAC-PHYs mit SPI-Schnittstelle ermöglichen Ethernet auch auf kleinen Linux-Systemen.

Das passt gut für Steuer- und Diagnosedaten. Für hohe Datenraten ist ein nativer Ethernet-MAC mit PHY meist besser.

Das Ziel ist immer eine normale Linux-Netzwerkschnittstelle. Dann arbeiten Anwendung und Diagnose mit Standardwerkzeugen.

Im BE-IIS-HPP-T1L-Praxistest wird eine SPI-angebundenes 10BASE-T1L-Interface mit ping und iperf3 wie ein gewöhnliches Linux-Netzwerkinterface geprüft. Der Test zeigt zugleich, wie sich Hardware, Device Tree, Treiber und Testskripte zu einer nutzbaren Schnittstelle verbinden.

Stabile Namen für Anwendungen

Kernel-Gerätenamen sind nicht immer stabil. Die Reihenfolge von Netzwerkschnittstellen, UARTs oder USB-Geräten kann sich ändern.

Anwendungen sollten deshalb nicht auf zufälligen Namen beruhen.

Geeignete Methoden sind:

• udev-Regeln,
• symbolische Links,
• eindeutige Device-Tree-Knoten,
• dokumentierte Instanznamen,
• feste MAC-Adressen.

Ein Name wie beiis-t1l0 ist für Testskripte und systemd-Dienste robuster als die Annahme, dass „eth1“ immer dieselbe Hardware meint.

Quellen: udev documentation, BE-IIS udev rules

Kameras

Kameras sind ein eigenes Teilprojekt. Die Auswahl beginnt beim Linux-Treiber.

Prüfen Sie:

• Mainline- oder Plattformtreiber,
• unterstützte Sensormodi,
• Auflösung und Bildrate,
• Bayer-Format,
• HDR,
• Autofokus,
• Embedded Data,
• Firmware,
• ISP-Pipeline.

Ein MIPI-Kamerasystem besteht oft aus Sensor, Serializer, Deserializer, CSI-Receiver, I²C-Tunneling, Clock, Reset, Versorgung, Device Tree und Media Pipeline.

Alle Teile müssen zusammenpassen.

Lane- oder Pin-Swap sollte nur genutzt werden, wenn Treiber und Binding diese Funktion ausdrücklich beschreiben. Eine Fähigkeit der Hardware allein reicht nicht.

Ein strukturiertes Bring-up spart viel Zeit:

1. Versorgung und Reset prüfen.
2. I²C-Steuerpfad prüfen.
3. Aliasse prüfen.
4. Overlay laden.
5. Sensor erkennen.
6. CSI-Pipeline konfigurieren.
7. Bildstream starten.

Damit lässt sich ein Fehler schnell dem Steuerpfad, dem Device Tree oder der Video-Pipeline zuordnen.

Quellen: Linux media subsystem, V4L2 documentation, BE-IIS GMSL2 Camera Installer

Displays

Displays benötigen eine ähnlich frühe Prüfung.

Prüfen Sie:

• Interface: HDMI, LVDS, MIPI-DSI, eDP oder RGB,
• Auflösung,
• Bildrate,
• Timing und Pixelfrequenz,
• Backlight-Ansteuerung,
• Touch-Controller,
• EDID,
• Panel-Initialisierung.

MIPI-DSI ist nicht nur eine elektrische Schnittstelle. Panel, SoC, Bridge-IC und Treiber müssen als Gesamtsystem passen.

Hardware-Monitoring und Thermal

Professionelle Systeme sollten ihre Versorgung und Temperatur überwachen.

Typische Messwerte sind:

• Core-Spannungen,
• Versorgungsschienen,
• Strom,
• Temperaturen,
• Lüfterdrehzahl,
• Alarmgrenzen.

Das hilft beim Bring-up und im Feld. Fehler werden früher sichtbar:

• unterversorgter Core,
• instabile externe Versorgung,
• ausgefallener Lüfter,
• thermische Überlast.

Auch der Monitoring-IC braucht einen passenden Treiber. Messbereich, Skalierung und Sensorposition müssen zur realen Hardware passen.

Quelle: Linux hwmon subsystem

Boot, Debug und Recovery

Debug-Zugänge sollten immer vorgesehen werden.

Mindestens sinnvoll sind:

• UART-Konsole,
• JTAG oder SWD für MCU und FPGA,
• Testpunkte für Versorgung,
• Testpunkte für Reset,
• Testpunkte für wichtige Busse.

Die UART-Konsole ist oft der wichtigste Zugang. Wenn Netzwerk, Grafik oder Anwendung nicht funktionieren, bleibt sie häufig als einziger Diagnoseweg.

Übernehmen Sie möglichst die bewährte UART-Beschaltung des Eval-Boards. Gerade bei frühen Mustern sind unnötige Experimente mit Pegeln, Pull-ups oder Pinmux teuer.

JTAG oder SWD hilft bei erster Programmierung, Bootloader-Problemen, MCU-Debugging, FPGA-Programmierung und Recovery. Auch ohne geplante Kernelentwicklung ist dieser Zugang sehr wertvoll.

Flashen und Bootloader

Die Frage lautet nicht nur: Wie läuft Linux? Sie lautet auch: Wie kommt Linux auf das Gerät?

Flashen ist oft mehrstufig:

1. Bootloader über JTAG oder ein Hersteller-Tool programmieren.
2. Verbindung über UART, USB oder Ethernet herstellen.
3. Bootloader konfigurieren.
4. Linux-Image übertragen.
5. Root-Dateisystem und Anwendung aktualisieren.

Hardware, die bereits beim Booten benötigt wird, braucht oft Unterstützung im Boot-ROM, in der Firmware oder im Bootloader.

Das betrifft zum Beispiel:

• Boot-Flash,
• eMMC,
• SD-Karte,
• DDR,
• PMIC,
• Ethernet für Recovery oder Netzwerk-Boot.

Ein Linux-Treiber hilft an dieser Stelle noch nicht. Der Kernel läuft zu diesem Zeitpunkt noch nicht.

Quelle: U-Boot Documentation

Update-Konzept

Ein Produkt enthält oft mehr als Linux. Updates können Bootloader, Kernel, Root-Dateisystem, Anwendung, MCU-Firmware, FPGA-Bitstream oder Gerätefirmware betreffen.

Planen Sie deshalb:

• Versionsabhängigkeiten,
• Update-Reihenfolge,
• Unterbrechung während eines Updates,
• Fehlererkennung,
• Fallback,
• A/B-Update,
• Signaturprüfung,
• Berechtigungen.

Ein Update ohne Recovery-Konzept ist kein robustes Updatekonzept.

Security

Security beginnt bei der Hardware.

Fragen Sie früh:

• Welche Schlüssel werden benötigt?
• Wo werden sie gespeichert?
• Wer programmiert sie?
• Können sie ausgelesen oder ersetzt werden?
• Wie werden Debug-Ports abgesichert?

Mögliche Maßnahmen sind:

• Secure Boot,
• signierte Updates,
• TPM,
• Secure Element,
• geschützte Schlüsselablage,
• gesperrte Debug-Ports,
• sichere Produktionsprogrammierung.

Nicht jedes Produkt braucht alle Maßnahmen. Die Architekturentscheidung muss aber früh fallen.

Produktions- und Systemtest

Testbarkeit beginnt im Schaltplan.

Prüfen Sie:

• Können wichtige Spannungen gemessen werden?
• Sind Reset-Leitungen erreichbar?
• Lassen sich GPIOs und Busse prüfen?
• Gibt es einen Production-Testmodus?
• Kann die Hardware-Revision ausgelesen werden?

In der Produktion müssen oft weitere Daten programmiert werden:

• Seriennummer,
• MAC-Adresse,
• Zertifikate,
• Schlüssel,
• Kalibrierdaten,
• Hardware-Revision.

Diese Daten brauchen einen dokumentierten und abgesicherten Prozess.

Dokumentation auf der Leiterplatte

Frühe Hardware wechselt oft den Arbeitsplatz. Gute Beschriftung spart dann viel Zeit.

Sinnvoll sind:

• klare Steckverbinderbezeichnungen,
• Spannungsangaben,
• Testpunktnamen,
• sichtbare Hardware-Revision,
• Reset- und Boot-Taster,
• UART- und JTAG-Pins,
• QR-Code zur Dokumentation.

Ein deutlich beschrifteter Taster RESET-SOC hilft beim Bring-up oft mehr als die Referenzbezeichnung S4.

Bring-up-Linux und Werkzeuge

Ein schlankes Bring-up-Image ist sehr wertvoll. Es sollte Login, Terminal, SSH, Kernel-Logs und Diagnosewerkzeuge enthalten.

Wichtige Werkzeuge:

Aufgabe	Werkzeuge	Dokumentation
Kernel-Logs	dmesg -w, journalctl -kf	dmesg, journalctl
Netzwerk	ip, ping, ethtool, tcpdump, iperf3	ip, ethtool, tcpdump, iperf3
I²C	i2cdetect, i2ctransfer	i2c-tools
GPIO	gpioinfo, gpioget, gpioset	libgpiod tools
Kamera	v4l2-ctl, media-ctl	v4l2-ctl, media-ctl
Performance	htop, stress-ng, perf	perf

Testskripte sollten bereits beim Bring-up entstehen. Später helfen sie bei Regressionstests, Fertigung und Support.

Fazit

Ein Linux-System entsteht nicht erst durch das Flashen eines Images.

Gute Linux-Hardware folgt einem gemeinsamen Modell aus:

• Plattform,
• Kernel,
• Treiber,
• Device Tree,
• elektrischer Anbindung,
• Standard-Linux-Schnittstellen.

Die beste Hardwarelösung ist nicht immer die flexibelste Schaltung. Sie ist die Lösung, die langfristig mit einem gepflegten Linux-System zuverlässig funktioniert.

Sonderlösungen sind nicht grundsätzlich falsch. Sie müssen aber bewusst entwickelt, getestet, dokumentiert und über die gesamte Produktlebensdauer gewartet werden.

Weiterführende Quellen

Linux und Kernel

• Linux Kernel Documentation
• Device Tree Usage Model
• Device Tree Specification
• Driver Implementer’s API Guide
• SocketCAN
• Linux Media Documentation
• U-Boot Documentation

BE-IIS-Praxisbeispiele

• BE-IIS Installer
• BE-IIS GMSL2 Camera Installer
• BE-IIS HAT++ Produkte
• 10BASE-T1L-Test über 100 m