GMSL2-Kameras in Betrieb nehmen

Inbetriebnahme

Diese Anleitung gehört zum BE-IIS-GMSL2-2CAM-HAT. Wähle den Abschnitt für deinen Aufbau:

• HAT mit passendem SER und Imager: Die Komponenten passen bereits zusammen. Du richtest den Pi ein und bringst das erste Bild zur Anzeige.
• Neuen Imager am BE-IIS-SER anschließen: Der Serializer bleibt. Sensoransteuerung und Videokonfiguration werden angepasst.
• Andere GMSL2-Kamera anschließen: Die Kamera hat einen eigenen Serializer und benötigt eine passende Integration.

Jeder Abschnitt folgt denselben drei Schritten:

1. Hardware anschließen.
2. I²C-Pfad aufbauen.
3. MIPI-Pfad aufbauen.

Zwei Pfade, zwei Aufgaben

Der I²C-Pfad dient der Steuerung: Der Pi erreicht den Deserializer auf dem HAT, über dessen GMSL-Rückkanal den entfernten Serializer und schließlich den Sensor. Darüber werden unter anderem Sensor-ID, Belichtung und Betriebsmodus angesprochen. Ein erreichbarer Serializer bedeutet noch nicht, dass auch der Sensor erreichbar ist.

Der Videopfad transportiert Bilder: Der Imager liefert MIPI CSI-2 an den Serializer. Dieser überträgt die Daten über GMSL2 zum HAT. Der Deserializer gibt wieder MIPI CSI-2 an den Raspberry Pi aus. Der Sensortreiber startet den Sensor beim Öffnen der Kamera.

Ein Eintrag in rpicam-hello --list-cameras bestätigt die Kameraerkennung. Erst empfangene Bilder bestätigen den vollständigen Videopfad.

Fall 1: BE-IIS-HAT mit passendem SER und Imager

Das konkrete Beispiel verwendet Raspberry Pi 5, BE-IIS-GMSL2-2CAM Rev. B, BE-IIS-SER mit MAX96717 und IMX708. Der SER und der passende Imager sind bereits miteinander verbunden. Zunächst nehmen wir eine Kamera an Link A in Betrieb.

Die Befehle entsprechen dem unten verlinkten Installer-Stand. Das Profil imx708-revb ist dort als verified markiert; die README fordert jedoch ausdrücklich einen erneuten Hardwaretest der auf JSON umgestellten Initialisierung vor dem Produktionseinsatz. Diese Anleitung ist kein neuer Hardware-Testbericht. Für andere Boardrevisionen und Sensoren ist ein passendes, geprüftes Profil erforderlich.

1) Hardware anschließen

1. Raspberry Pi und Kameraversorgung ausschalten.
2. HAT montieren und den zu Link A gehörenden CSI-Ausgang mit CSI1 des Pi 5 verbinden. Orientierung der FFC-Kontakte und Verriegelung nach Boardbeschriftung prüfen.
3. Den bereits bestückten SER über das passende Koaxkabel an Link A anschließen.
4. Versorgung einschließlich Power over Coax entsprechend Boardrevision und Kamerakopf einrichten. Spannung und Leistungsbedarf müssen zu beiden Seiten passen.
5. Einschalten und Raspberry Pi OS starten.

Für das duale Referenzsystem wird zusätzlich Link B mit einem zweiten passenden Kamerakopf und dessen CSI-Ausgang mit CSI0 des Pi verbunden. Die Zuordnung gilt für die hier beschriebene Referenzkonfiguration.

2) I²C-Pfad aufbauen

Linux-I²C-Schnittstelle aktivieren

Zuerst muss Linux den I²C-Controller bereitstellen. Öffne auf aktuellem Raspberry Pi OS:

sudo nano /boot/firmware/config.txt

Auf älteren Images liegt dieselbe Datei unter /boot/config.txt. Verwende die tatsächlich vorhandene Datei. Setze die folgenden Einträge im wirksamen [all]-Abschnitt; passe bereits vorhandene Einträge an:

[all]
dtparam=i2c_arm=on
dtparam=i2c_csi_dsi=on
camera_auto_detect=0

i2c_arm aktiviert die ARM-I²C-Schnittstelle am GPIO-Header. Für den hier verwendeten Kamerabus ist zusätzlich i2c_csi_dsi erforderlich. camera_auto_detect=0 verhindert, dass die automatische Kameraerkennung mit unseren manuell geladenen Overlays kollidiert.

Starte nach einer Änderung neu:

sudo reboot

Installiere anschließend die Werkzeuge und lade den Userspace-Zugang:

sudo apt-get update
sudo apt-get install -y i2c-tools
sudo modprobe i2c-dev
i2cdetect -l
ls -l /dev/i2c-11

i2cdetect -l zeigt die vorhandenen Adapter, ohne Geräte zu scannen. Die folgenden Beispiele gelten für Bus 11 der Pi-5-Referenzkonfiguration. Fehlt dieser Adapter, zuerst Bootkonfiguration und CSI-Verbindung prüfen. Ein vorhandener Bus 1 ersetzt ihn nicht.

Deserializer auf dem HAT erreichen

Prüfe gezielt die erwartete DES-Adresse und lies anschließend dessen Identifikationsregister:

sudo i2cdetect -y 11 0x28 0x28
sudo i2ctransfer -y 11 w2@0x28 0x00 0x0d r1

28 im Scan bedeutet, dass ein Gerät antwortet; -- bedeutet keine Antwort. UU bedeutet, dass ein Kernel-Treiber die Adresse belegt. In diesem Fall zuerst die Treiberbelegung klären, statt den Zugriff mit -f zu erzwingen. Auch ein Scan sendet Buszugriffe; prüfe hier nur die bekannten Adressen und führe ihn vor dem Laden der Kamera-Overlays aus.

Beim Registerzugriff schreibt w2@0x28 die zwei Adressbytes 0x00 0x0d und r1 liest danach ein Byte zurück. Das setzt den Registerzeiger auf 0x000D; es schreibt keinen neuen Konfigurationswert.

Prüfpunkt: Bus 11 existiert und der DES antwortet auf einen gezielten Registerzugriff. Erst danach wird der entfernte I²C-Pfad zum SER aufgebaut.

Treiber und Initialisierungswerkzeuge installieren

Installiere auf dem Pi die Software:

git clone https://github.com/be-iis/be-iis-cam-installer.git
cd be-iis-cam-installer
PROFILE=imx708-revb
./install.sh "$PROFILE"

Bei einem bestehenden Checkout auf main genügt vor der Installation git pull --ff-only origin main, sofern keine ungelösten lokalen Änderungen vorliegen.

Der Installer richtet Abhängigkeiten, Treiber und Device-Tree-Overlays ein. Falls er die Bootkonfiguration ändern muss, startet er den Pi neu. Gehe danach wieder ins Repository, setze PROFILE=imx708-revb und führe ./install.sh "$PROFILE" erneut aus. Die Installation allein aktiviert noch keinen GMSL- oder Videopfad.

Prüfpunkt: Die Installation endet erfolgreich. Der Installer findet den Kamera-I²C-Bus /dev/i2c-11. In dieser Referenzkonfiguration wird nicht pauschal I²C-Bus 1 verwendet.

Entfernten I²C-Pfad initialisieren

Beende laufende Kameraanwendungen. Führe im Installer-Verzeichnis aus:

PROFILE=imx708-revb
make unoverlay
make init-a PROFILE="$PROFILE"

unoverlay entfernt dynamisch geladene BE-IIS-Kamera-Overlays. Statisch in der Bootkonfiguration eingetragene Overlays entfernt es nicht; diese dürfen nicht mit der manuellen Einrichtung kollidieren.

init-a wählt Link A, stellt die Verbindung zum Serializer her, gleicht die GMSL-Datenrate ab und führt die profilabhängige Versorgung und Freigabe des Sensors aus. Danach richtet es die I²C-Adressübersetzung ein und prüft Sensor-ID und Fokuszugriff. Noch wird kein Videopfad aufgebaut.

Die Tabelle verwendet 7-Bit-I²C-Adressen. Zwei identische Sensoren können lokal dieselbe Adresse besitzen, während der Pi sie über unterschiedliche Aliasse erreicht. Werte in Adressübersetzungsregistern können anders kodiert sein; übernimm dafür die Implementierung des passenden Profils.

Prüfpunkt: Der Befehl endet ohne Fehler und meldet den verifizierten IMX708 unter 0x52. Ein GMSL-Link-Lock oder ein I²C-Scan allein genügt nicht. Bei falscher Sensor-ID zuerst Versorgung, Takt, Reset und Adressübersetzung prüfen.

Serializer und Sensor mit i2ctransfer prüfen

Die folgenden Befehle laufen nach erfolgreichem make init-a und vor dem Laden des Kamera-Overlays. Link A ist jetzt ausgewählt, der Sensor ist versorgt und seine Aliasse sind eingerichtet.

# Serializer auf dem ausgewählten Link
sudo i2cdetect -y 11 0x40 0x40
sudo i2ctransfer -y 11 w2@0x40 0x00 0x0d r2

# IMX708 über seinen Host-Alias
sudo i2cdetect -y 11 0x52 0x52
sudo i2ctransfer -y 11 w2@0x52 0x00 0x16 r2

Das aktuelle Profil erwartet beim SER 0xbf 0x06 und beim IMX708 0x07 0x08. Der zweite Zugriff liest zwei Bytes ab Sensorregister 0x0016. Vor Link-Initialisierung und Sensorfreigabe sind diese Antworten noch nicht zu erwarten.

Wie wird ein Register geschrieben? Beim MAX96717 folgen auf zwei Registeradressbytes die Nutzdaten. Die folgenden zwei Befehle zeigen die im Profil verwendete Sensor-Adressübersetzung für Link A. Sie setzen die bereits durch init-a eingerichtete Zuordnung erneut:

# Host-Alias 0x52, im SER-Register als 0x52 << 1 = 0xa4 kodiert
sudo i2ctransfer -y 11 w3@0x40 0x00 0x42 0xa4

# Reale Sensoradresse 0x1a, kodiert als 0x1a << 1 = 0x34
sudo i2ctransfer -y 11 w3@0x40 0x00 0x43 0x34

# Zuordnung durch Lesen der Sensor-ID prüfen
sudo i2ctransfer -y 11 w2@0x52 0x00 0x16 r2

w3 bedeutet drei gesendete Bytes: Registeradresse High, Registeradresse Low und ein Datenbyte. Diese Schreibzugriffe gelten ausschließlich für den MAX96717 und den hier ausgewählten Link A. Sie ersetzen weder Linkaufbau noch Versorgung, Reset und Takt des Sensors.

Bei zwei angeschlossenen Serializern mit derselben Adresse muss vor direkten SER-Zugriffen eindeutig der gewünschte Link ausgewählt sein. Die Beispiele deshalb nicht nach einer Dual-Link-Initialisierung ungeändert ausführen.

3) MIPI-Pfad aufbauen

Lade für die einzelne IMX708-Kamera nur das bereits installierte Link-A-Overlay und konfiguriere den Videopfad:

sudo dtoverlay imx708-gmsl-link-a
make pipeline-a PROFILE="$PROFILE"
rpicam-hello --list-cameras

Das Overlay beschreibt Sensor, I²C-Alias, Taktversorgung und Verbindung zum CSI-Eingang für Linux. pipeline-a konfiguriert den CSI-Eingang des Serializers sowie Videoausgang und Routing des Deserializers. Beide müssen zum Sensorbetrieb passen.

Wähle den tatsächlich angezeigten Kameraindex. Bei einer einzelnen erkannten Kamera ist dies üblicherweise 0:

CAMERA=0
rpicam-hello --camera "$CAMERA" --timeout 0

Beende die Vorschau mit Strg+C. Ohne lokale Bildschirmausgabe kannst du anschließend eine Aufnahme speichern:

rpicam-still --camera "$CAMERA" --nopreview --timeout 1000 --output test.jpg

Prüfpunkt: Die Kamera wird erkannt und liefert ein korrektes Bild. Das dokumentierte IMX708-Referenzsystem verwendet unter anderem 2304 × 1296, RAW10, zwei CSI-2-Lanes und 900 Mbit/s je Lane. Diese CSI-Datenrate ist nicht die GMSL-Linkrate.

Erweiterung: zwei passende Kameras

Sind beide Kameraköpfe und beide CSI-Verbindungen angeschlossen, verwende anstelle des einzelnen Link-A-Ablaufs:

PROFILE=imx708-revb
make unoverlay

# I²C-Pfade beider Kameras
make init-a-b PROFILE="$PROFILE"

# Linux-Kameraanbindung und MIPI-Videopfade
make overlays-a-b PROFILE="$PROFILE"
make pipeline-a-b PROFILE="$PROFILE"
rpicam-hello --list-cameras

Teste anschließend jede Kamera einzeln; beende die erste Vorschau vor dem nächsten Aufruf:

rpicam-hello --camera 0 --timeout 0
rpicam-hello --camera 1 --timeout 0

In der dokumentierten Dual-Konfiguration ist Link A → Alias 0x52 → CSI1 → Kamera 1 und Link B → Alias 0x53 → CSI0 → Kamera 0. Prüfe die Indizes trotzdem anhand der aktuellen Kameraliste.

Nach einem Neustart oder Hardware-Reset können die manuellen Einstellungen verloren sein. Wiederhole dann I²C-Initialisierung, Overlay-Laden und Pipeline-Einrichtung. Der Installer richtet keinen automatischen Kamera-Initialisierungsdienst ein.

Fall 2: Neuer Imager am BE-IIS-SER

Hier bleiben HAT und Serializer erhalten. Der neue Imager kann andere Versorgungsspannungen, eine andere Reset-Sequenz, einen anderen Takt oder ein anderes CSI-2-Format benötigen. Ein mechanisch passender Stecker bestätigt noch keine elektrische Kompatibilität.

1) Hardware anschließen

1. Pi und Kameraversorgung ausschalten.
2. Pinbelegung und elektrische Anforderungen des neuen Moduls mit dem SER abgleichen: Versorgung, I²C-Pegel, MCLK, Reset, Enable sowie CSI-Lanes und deren Reihenfolge.
3. Sensormodul mit passendem Kabel beziehungsweise Adapter am SER anschließen. Für den ersten Test nur einen Kameralink verwenden.
4. Den benötigten Sensormodus festlegen: Auflösung, Bildrate, RAW-/YUV-Format, Bitbreite, Lane-Anzahl und Linkfrequenz.

Halte Sensor-Datenblatt, Modulschaltplan und die Dokumentation des Linux-Treibers bereit.

Prüfpunkt: Das Modul lässt sich mit den richtigen Spannungen, Takten und Steuersignalen betreiben.

2) I²C-Pfad aufbauen

Der Weg bis zum BE-IIS-Serializer bleibt grundsätzlich derselbe. Danach muss die Initialisierung zum neuen Sensor passen:

1. GMSL-Link und Serializer-Zugriff herstellen.
2. Versorgung, MCLK, Enable und Reset in der vom Sensor geforderten Reihenfolge setzen.
3. Die reale Sensoradresse auf einen eindeutigen Host-Alias abbilden.
4. Das dokumentierte Identifikationsregister lesen und mit der erwarteten Sensor-ID vergleichen.
5. Falls vorhanden, Fokuscontroller und weitere benötigte I²C-Geräte separat berücksichtigen.

Im Installer gehören die kamerabezogenen Angaben in ein eigenes JSON-Profil, die Linux-Anbindung in passende DTS-Overlays:

Grenze des aktuellen Installers: Der Runner erwartet noch zwei Linkdefinitionen und gemeinsame Sensordaten. Er verwendet beim Sensor-ID-Zugriff eine 16-Bit-Registeradresse und prüft nach der Sensor-ID zwingend einen Fokuscontroller. Ein Fixed-Focus-Modul ohne diesen Controller oder ein Sensor mit anderem Registerprotokoll benötigt deshalb auch Änderungen am Runner und seiner Validierung. Zwei unterschiedliche Imager an A und B lassen sich nicht allein durch Austauschen des Sensornamens konfigurieren.

Ein Profil kopieren und lediglich status auf verified setzen ist keine Validierung. Neue Hardware muss zunächst kontrolliert integriert und tatsächlich getestet werden. Der aktuelle Runner nimmt nur entsprechend markierte Profile an.

Prüfpunkt: Die richtige Sensor-ID wird reproduzierbar über den Host-Alias gelesen – auch nach einem vollständigen Aus- und Einschalten.

3) MIPI-Pfad aufbauen

Passe alle Teile an denselben Sensormodus an:

Für die Videoeinstellungen enthält das Profil unter anderem serializer_csi, deserializer_a, deserializer_b, route_a und route_ab. Diese Registerfolgen müssen zur tatsächlichen Kombination passen.

Der vorhandene IMX708-Treiber und das IMX708-Overlay ersetzen keinen Treiber für einen anderen Sensor. Auch die Unterstützung im verwendeten libcamera-/rpicam-System und gegebenenfalls passende Bildverarbeitungsparameter müssen vorhanden sein.

Sobald Profil, Runner-Unterstützung, Treiber und Overlays fertiggestellt und geprüft sind, folgt die Inbetriebnahme wieder der Reihenfolge aus Fall 1 – mit dem neuen Profil und dessen Overlaynamen. Verwende das IMX708-Profil nicht versuchsweise für den neuen Sensor.

Prüfpunkt: Kameraerkennung, erste Aufnahme und wiederholter Streamstart funktionieren im vorgesehenen Modus. Prüfe Bildformat, Farben, Auflösung und Stabilität. Die vorhandenen make png-/make video-Helfer enthalten IMX708-Auflösungswerte und müssen für andere Sensoren überprüft werden.

Fall 3: Eine andere GMSL2-Kamera am HAT

Hier bringt die Kamera ihren eigenen Serializer und möglicherweise einen ISP oder Mikrocontroller mit. Damit ändern sich unter Umständen sowohl der Steuerpfad als auch das Videoformat.

1) Hardware anschließen

Beschaffe vor dem Anschluss die Integrationsunterlagen der Kamera:

• Serializer-Typ und unterstützte GMSL-Version, Linkrate und Übertragungsmodus.
• Koax-/Steckverbinderausführung und zulässige Kabellänge.
• Versorgung: PoC-Unterstützung, erforderliche Spannung und Leistungsaufnahme.
• I²C-Adressen, Startsequenz, Reset-/Enable-Verhalten und erforderliche Referenztakte.
• Videoausgabe: RAW oder YUV, Auflösung, Bildrate, CSI-Lanes sowie Stream-/Virtual-Channel-Zuordnung.

Schalte die Versorgung aus und verbinde zunächst eine Kamera mit Link A. Richte PoC nur dann ein, wenn HAT und Kamera hinsichtlich Spannung und Versorgungskonzept zusammenpassen.

Prüfpunkt: Die Kamera ist elektrisch kompatibel und ihr Serializer kann mit dem MAX96716A des HATs zusammenarbeiten. Die Bezeichnung „GMSL2“ allein belegt noch keine vollständige Kompatibilität.

2) I²C-Pfad aufbauen

1. Den Deserializer passend zur Kamera für Linkrate und Übertragungsmodus konfigurieren.
2. GMSL-Link-Lock prüfen und den Rückkanal zum Serializer herstellen.
3. Serializer-ID beziehungsweise den vom Hersteller vorgesehenen Identifikationszugriff prüfen.
4. Die herstellerspezifische Kamera-Startsequenz ausführen.
5. Sensor, ISP oder Kamera-Mikrocontroller über dokumentierte Adressen erreichen und erforderliche Aliasse einrichten.

Manche Kameras geben den direkten Sensorzugriff frei; andere werden über einen ISP oder Mikrocontroller gesteuert. In letzterem Fall ist dessen Protokoll maßgeblich. Ein IMX708-ID-Read ist dann kein geeigneter Funktionstest.

Der aktuelle BE-IIS-Runner enthält MAX96717-spezifische ID-, Datenraten- und Aliaszugriffe. Ein anderer Serializer kann deshalb Anpassungen im Code erfordern. Seine Register dürfen nicht ungeprüft mit der MAX96717-Sequenz beschrieben werden.

Prüfpunkt: Das dokumentierte Steuerinterface der Kamera antwortet zuverlässig und lässt sich gezielt konfigurieren.

3) MIPI-Pfad aufbauen

Übernimm den vom Hersteller vorgesehenen Videomodus in die gesamte Kette:

1. Kamera beziehungsweise ISP auf den gewünschten Ausgabemodus einstellen.
2. Serializer-Stream und Deserializer-Pipe einander zuordnen.
3. CSI-Datentyp, gegebenenfalls Virtual Channels, Lane-Anzahl und Ausgangsdatenrate am DES konfigurieren.
4. Den passenden CSI-Eingang im Device Tree anbinden und die nötige Linux-/libcamera-Unterstützung bereitstellen.
5. Stream starten und tatsächlichen Bildempfang prüfen.

Eine Kamera mit internem ISP kann beispielsweise YUV statt RAW liefern. Dafür passen weder ein RAW-Sensortreiber noch dessen Formatannahmen automatisch. Ob rpicam oder eine andere V4L2-Anwendung verwendet wird, hängt von der implementierten Treiber- und Pipeline-Unterstützung ab.

Prüfpunkt: Das Bild kommt im erwarteten Format ohne Timeouts oder erkennbare Übertragungsfehler an. Prüfe anschließend wiederholte Starts und vollständige Neustarts, bevor du einen zweiten Kameralink hinzufügst.

Fehler anhand des letzten erfolgreichen Schritts eingrenzen

Quellen und weiterführende Anleitungen

Die konkreten Befehle und Grenzen wurden mit dem Installer-Stand 56733d5 abgeglichen. Der Installationsbefehl oben lädt den jeweils aktuellen Stand; prüfe dessen README bei späteren Änderungen.

• Installer und Installationshinweise
• Profil und Registerfolgen der Referenzkonfiguration
• Profil-Runner und aktuelle Annahmen
• Dokumentierte Dual-Kamera-Inbetriebnahme
• HAT-Dokumentation und Vorschau-Beispiele
• Kamerasystem im Überblick

Werkzeugreferenz: i2cdetect und i2ctransfer.