Kamera anpassen (Inbetriebnahme von CSI-/MIPI-/GMSL-Sensoren)

Übersicht

Tegra264 (Thor) und Tegra234 (Orin) stellen einen einzigen „tegra-capture-vi“-Controller bereit, der über NVCSI und einen festen Satz von CSI-Ports angesteuert wird. Die Inbetriebnahme der Kamera erfolgt wie folgt:

1. Sensorauswahl – ausgewählt aus dem Satz von NVIDIA im Tree ausgelieferter .dtsi-Referenzen für die aktive Plattform.
2. Überprüfung der Trägerplatinen- und Modulunterstützung – abgeglichen mit dem „Camera Development Guide“, dem „Adaptation Guide“ (§Camera), dem Schaltplan der Trägerplatine, dem Modul-TRM und der Pinbelegung der Trägerplatine.
3. Verdrahtung – abgeleitet aus den im Tree vorhandenen „tegra-camera- “-*.dtsi-Dateien, sofern vorhanden (die DTSI ist die maßgebliche Quelle für die Verdrahtung); bei kundenspezifischen Sensoren vom Benutzer pro Sensor erfasst.
4. Kernel-DT-Overlay – cpp-expand des DTSI im Baum, Extrahieren seines „fragment@N “-Körpers, Anhängen an das zusammengesetzte benutzerdefinierte Overlay .dts für das aktive Ziel (gemäß ../../references/bsp-customization-kernel-dtb.md), Überprüfung des Composites mit fdtoverlay. /jetson-build-source kompiliert das Composite und ist verantwortlich für die Registrierung in der Carrier-Konfiguration unter OVERLAY_DTB_FILE+=.

Agentengesteuert, nicht tabellengesteuert – die Sensorliste wird zur Laufzeit durch das Einlesen der sensorspezifischen dtbos im Baum erstellt. Kein _THOR_CAMERAS-Dict, keine questions.json, kein Python-Renderer im Fragepfad.

Keine Bearbeitung von ODMDATA – Kameras belegen keine UPHY-Lanes (CSI ist ein separater PHY-Pool). Der Skill gibt nur ein Kernel-DT-Overlay aus; die ODMDATA-Zeile in der Carrier-Konfiguration bleibt von diesem Skill unberührt.

Die Ausgabe besteht aus einem Commit:

• Kamera -Fragment@N -Block (zuzüglich „jetson-header-name“ am Composite-Stamm, falls noch nicht vorhanden) angehängt an das benutzerdefinierte Composite-Overlay .dts gemäß ../../references/bsp-customization-kernel-dtb.md → in das Repository „bsp_sources/hardware“ committet. /jetson-build-source kompiliert das Composite zu .dtbo und ist für dessen Makefile sowie die Flash-Conf-Registrierung zuständig.

Wann aufrufen

• Der Benutzer gibt die Befehle „Kamera aktivieren“, „CSI konfigurieren“, „Hawk-/ Owl-/IMX-Sensor anschließen“, „MIPI-Kamera“ oder „GMSL-Kamera“ ein oder fordert an, „tegra-capture-vi“ bzw. „NVCSI“ auf einem benutzerdefinierten Trägermodul zu starten.
• Der Flash-Start erfolgt, aber `v4l2-ctl --list-devices ` zeigt keine `tegra-capture-vi `-Kanäle an, ODER die Sensorauflistung auf einer neuen Tochterkarte muss bestätigt werden.
• Ein Sensor war zuvor aktiviert und der Benutzer möchte einen weiteren hinzufügen (Inbetriebnahme mehrerer Sensoren).

Voraussetzungen:

• Aktives Profil mit den Blöcken „reference_devkit:“ und „custom_carrier: “.
• /Linux_for_Tegra/.git existiert (/jetson-init-source).
• /jetson-derive-carrier wurde ausgeführt – der Carrier-Flash-Conf-Fork befindet sich im Overlay-Tracker.
• /bsp_sources/hardware/nvidia//nv-public/overlay/ ist vorhanden und enthält die im Baum enthaltenen .dtsi-Dateien pro Sensor (die aus dem Archivauszug von Branch A von /jetson-init-source stammen).
• /bsp_sources/kernel/kernel-noble/include/dt-bindings/ enthält die von C++ benötigten Makro-Header (source_sync.sh muss möglicherweise ausgeführt werden, wenn Branch B verwendet wurde – siehe Schritt 5a.i unten).
• Als „Source of Truth“ registrierte oder an der Eingabeaufforderung angegebene Dokumente: Kamera-Entwicklungsleitfaden (im „bsp_developer_guide“-Mirror oder in einem separaten Pfad), Anpassungsleitfaden §Kamera, Trägerplatinen-Schaltplan, SoC-TRM, Modul-Design-Leitfaden.
• dtc, cpp, fdtoverlay im PATH.

Vorgehensweise

Eine detaillierte Schritt-für-Schritt-Anleitung (Schritte 1–7, mit allen Tabellen, Code- Blöcken und Gatter) finden Sie in references/procedure.md. Zusammenfassung:

1. Schritt 1 – Aktives Ziel festlegen + „Source of Truth“-Dokumente öffnen.
2. Schritt 2 – Auflistung der unterstützten Sensoren durch Glob-Suche in den plattformspezifischen Kamera-DTBOs im Baum; Klassifizierung als DPHY-direkt / GMSL / benutzerdefiniert. Niemals Sensoren erfinden.
3. Schritt 3 / 3a – Überprüfen Sie die Träger- und Modulunterstützung anhand von DTSI, dem Kamera-Entwicklungsleitfaden, dem Anpassungsleitfaden §Kamera, dem SoC-TRM, dem Modul-Design-Leitfaden, dem Schaltplan und der Pinbelegung des Trägers. Erstellen Sie ZUERST die Verdrahtungstabelle und lösen Sie dann das „Bestätigen oder Anpassen“-Gate aus.
4. Schritt 4 (nur bei benutzerdefiniertem Pfad) – Batchweise sensorbezogene Verdrahtungsfragen, die automatisch aus der Pinbelegung des Trägers ausgefüllt werden.
5. Schritt 5 — Fügen Sie genau EIN /* custom-bsp: camera: */ Fragment an die zusammengesetzte benutzerdefinierte Overlay-Datei .dts an (siehe ../../references/bsp-customization-kernel-dtb.md). Der Klonpfad führt eine CPP-Expansion der DTSI im Baum durch; der benutzerdefinierte Pfad fügt die Antworten aus Schritt 4 sowie die Modustabellen an Ort und Stelle ein. Setzen Sie jetson-header-name idempotent am zusammengesetzten Stamm. Überprüfen Sie dies mit dtc + fdtoverlay (Gate zur Vorabkompilierung einzelner Fragmente; Gate zur Überprüfung der Eindeutigkeit des tiefen Baums nach der Kompilierung). Führen Sie den Commit über das Commit-Message-Vorschau-Gate des Workflows durch.
6. Schritt 6 – Überprüfen Sie die zusätzlichen CAM-Pin-SFIOs (cam_i2c_*, extperiph_clk, Reset/PWDN/PWR_EN-GPIOs) über pin_verifier.py; leiten Sie Unstimmigkeiten an /jetson-customize-pinmux weiter.
7. Schritt 7 – Führen Sie ein atomares Schreiben des JSON-Sidecars für den Laufstatus unter /target-platform/.jetson-customize-camera.json durch, geben Sie die Überschrift aus und steuern Sie anschließend die nachgelagerte Kette für den nächsten Schritt über sequenzielle „AskUserQuestion“-Aufforderungen gemäß references/procedure.md Schritt 7. Die Kette ist ein dokumentiertes Workflow-Tor, keine klärende Frage – der Automatikmodus stellt hier keine Ausnahme dar. Ersetzen Sie die Aufforderungen niemals durch eine gedruckte Zeile „Nächster Schritt: …“.

Fallstricke

• Falle durch doppelte Fragmente. Füge genau EIN mit einer Kamera gekennzeichnetes Fragment@N zur Zusammensetzung bei. Ein zweites, das Status- Überschreibungen enthält, löst eine dtc-Deep-Merge-Vorgang aus → doppelte Geschwister-Unterbäume (z. B. zwei tca9546@70) → Die Laufzeit-Erste-Übereinstimmung verwirft den von dtsi bereitgestellten Deep-Tree → Die Kamera führt stillschweigend keine Aufzählung durch. Das Gate darf nur auf den Marker dieser Funktion angewendet werden (Schritt 5c).
• Die Kompatibilität der Composite-Root wird global verwaltet, nicht von diesem Skill. Keine Erweiterung aus den sensorbezogenen DTBO-Strukturen innerhalb des Baums (devkit-SKU-abhängig). Korrigiere die Composite-Root bei Bedarf.
• „jetson-header-name“ aus allen sensorspezifischen DTBOs im Baum. Behoben, trägerunabhängig; einmal lesen, in die Metadaten-Root einfügen.
• Füge die im Baum enthaltenen, sensorspezifischen DTBOs NICHT zusätzlich an „OVERLAY_DTB_FILE“ an. Die Registrierung sowohl deines gerenderten Overlays ALS AUCH der im Baum enthaltenen Tegra-Datei „-p3971-camera--overlay.dtbo“ erzeugt eine Phantom-Subdev-Bindung, die die Kamera-Enumeration lahmlegt.
• Stub-Overlay ist eine bekannte Fallstrick. Das Committen von tegra-capture-vi { status="okay"; num-channels=; } ohne Ports-/Sensor-/nvcsi-Body blockiert die Kamera (Initialisierung aller Kanäle fehlgeschlagen). Fügen Sie den VOLLSTÄNDIGEN Sensor-Body über C++ + DTC ein.
• Sensormodustabellen müssen eingefügt werden, niemals manuell erstellt. mode, sensor_modes, pixel_phase — wortwörtlich aus dem nächstgelegenen DTSI im Baum kopieren.
• camera_common_regulator_get (null) ERR: -EINVAL = fehlende avdd-reg / iovdd-reg / dvdd-reg-Zeichenfolgen – füge den VOLLSTÄNDIGEN Sensor-Body ein; bei ständig aktiven Schienen auf Dummy-Regler zurückgreifen.
• Externe &label-Referenzen müssen in den __symbols__ der Basis-DTB vorhanden sein. Verwende target-path = „/tegra-capture-vi“, wenn das Label fehlt; ansonsten beendetfdtoverlay den Vorgang mit einem von Null verschiedenen Wert und FDT_ERR_NOTFOUND.
• C++-Fehler in dt-bindings/gpio/gpio.h: Keine solche Datei = L4T-Quellbaum ist nicht in den Staging-Bereich übernommen. /jetson-init-source erneut ausführen (die Datei source_sync.sh des Zweigs B ruft die Header ab). Die Makroexpansion niemals künstlich erzeugen.
• Keine Bearbeitung von ODMDATA, keine Bearbeitung der Flash-Konfiguration. Die Kamera beansprucht keine UPHY-Lanes. Der Eintrag ODMDATA="..." in der Carrier-Konfiguration bleibt unverändert. OVERLAY_DTB_FILE+= gehört zu /jetson-build-source Schritt 5.0a – diese Funktion greift niemals auf die Flash-Konfiguration des Trägers zu.
• Rühren Sie das Upstream-BSP unter nicht an. Alle Änderungen landen unter /Linux_for_Tegra/ (Overlay- Tracker) und /bsp_sources/ (Overlay -.dts) gemäß dem Commit-Muster „unverändert + Anpassung“.

Referenzen

• references/procedure.md — vollständige Schritt-für-Schritt-Anleitung für die Schritte 1–7 (aus diesem SKILL.md extrahiert).
• references/csi-dt-bindings.md — Referenzhinweise zu CSI-, nvcsi- und vi-DT-Bindungen.
• references/overlay-template.md — Anleitung zur Overlay-Form „Metadata-Root + Clone-Body“.
• references/camera-overlay-templates/ — Starter-Vorlagen im Format .dts.tmpl: dphy-direct.dts.tmpl, gmsl-serdes.dts.tmpl.
• ../../scripts/pin_verifier.py — Gemeinsamer HSIO-Pin-Verifizierer (Schritt 6).
• ../../references/platform_template.yaml — Dokumente: Block, der in Schritt 1 verwendet wird.
• ../../context/bsp-customization-workflow.md — Protokoll zur Bearbeitung von Overlays.
• ../jetson-customize-pinmux/SKILL.md — gleichrangiges Skill, das von Schritt 6 automatisch aufgerufen wird, um HSIO-Pin-SFIO- Nichtübereinstimmungen zu beheben (CAM I²C, MCLK, Reset-GPIOs).
• ../jetson-derive-carrier/SKILL.md — muss zuerst ausgeführt werden; erzeugt das Carrier-Basis-Overlay (die *-dynamic.dtbo), auf das die Composite-Stacks dieses Skills anschließend aufsetzen.
• ../jetson-init-source/SKILL.md — Erzeugt den Overlay-Tracker sowie das Repo „bsp_sources“ (mit dem DTSI-Baum„hardware/nvidia/ “ pro Sensor), das dieser Skill liest und in das er Commits vornimmt.