Personnaliser la caméra (capteur CSI / MIPI / GMSL bring-up)

Vue d'ensemble

Tegra264 (Thor) et Tegra234 (Orin) exposent un contrôleur tegra-capture-vi unique fronté par NVCSI et un ensemble fixe de ports CSI. Le bring-up de la caméra est :

Sélection du capteur — choisi dans l'ensemble des références DTSI .dtsi livrées en-tree par NVIDIA pour la plateforme active.
Vérification du support du carrier + module — validée contre le Camera Development Guide, Adaptation Guide §Camera, schéma du carrier, Module TRM, et pinmap du carrier.
Câblage — dérivé des fichiers tegra<soc>-camera-<sensor>*.dtsi en-tree quand ils existent (le DTSI EST la source de vérité du câblage) ; capturé par capteur auprès de l'utilisateur quand le capteur est personnalisé.
Overlay kernel-DT — cpp-expand le DTSI en-tree, extraire son corps fragment@N, ajouter au overlay custom composite .dts pour la cible active (par ../../references/bsp-customization-kernel-dtb.md), vérifier le composite avec fdtoverlay. /jetson-build-source compile le composite et gère l'enregistrement OVERLAY_DTB_FILE+= de la conf du carrier.

Agent-driven, non table-driven — la liste des capteurs est construite à l'exécution en globbant les dtbos en-tree par capteur. Pas de dict _THOR_CAMERAS, pas de questions.json, pas de rendu Python dans le chemin des questions.

Aucune édition ODMDATA — les caméras ne consomment pas de lanes UPHY (CSI est un pool PHY séparé). Le skill n'émet qu'un overlay kernel-DT ; la ligne ODMDATA dans la conf du carrier n'est pas modifiée par ce skill.

La sortie est un seul commit :

Bloc fragment@N de la caméra (plus jetson-header-name sur la racine composite si absent) ajouté au overlay custom composite .dts par ../../references/bsp-customization-kernel-dtb.md → commité dans le repo hardware bsp_sources/. /jetson-build-source compile le composite en .dtbo et gère son Makefile + enregistrement flash-conf.

Quand invoquer

L'utilisateur dit « activer la caméra », « configurer CSI », « câbler un Hawk / Owl / capteur IMX », « caméra MIPI », « caméra GMSL », ou demande à activer tegra-capture-vi / NVCSI sur un carrier personnalisé.
Le flash démarre mais v4l2-ctl --list-devices n'affiche aucun canal tegra-capture-vi, OU l'énumération des capteurs sur une carte fille neuve doit être confirmée.
Un capteur était précédemment activé et l'utilisateur veut en ajouter un autre (bring-up multi-capteur).

Conditions préalables :

Profil actif avec blocs reference_devkit: + custom_carrier:.
<source.root_path>/Linux_for_Tegra/.git existe (/jetson-init-source).
/jetson-derive-carrier a été exécuté — le fork flash-conf du carrier est dans le tracker overlay.
<source.root_path>/bsp_sources/hardware/nvidia/<chip-dir>/nv-public/overlay/ existe et contient les fichiers .dtsi par capteur en-tree (sourcés par l'extraction d'archive Branch A de /jetson-init-source).
<source.root_path>/bsp_sources/kernel/kernel-noble/include/dt-bindings/ contient les en-têtes de macros que cpp nécessite (source_sync.sh peut devoir être exécuté si Branch B a été utilisé — voir Étape 5a.i ci-dessous).
Documents source-of-truth enregistrés ou fournis à l'invite : Camera Development Guide (dans le miroir bsp_developer_guide ou chemin séparé), Adaptation Guide §Camera, schéma du carrier, SoC TRM, Module Design Guide.
dtc, cpp, fdtoverlay dans PATH.

Procédure

La procédure détaillée pas à pas (Étapes 1–7, avec tous les tableaux, blocs de code et portes) se trouve dans references/procedure.md. Résumé :

Étape 1 — Résoudre la cible active + ouvrir les documents source-of-truth.
Étape 2 — Énumérer les capteurs supportés en globbant les dtbos caméra en-tree par plateforme ; classifier en DPHY-direct / GMSL / personnalisé. Ne jamais inventer de capteurs.
Étape 3 / 3a — Recouper le support du carrier + module contre le DTSI, Camera Development Guide, Adaptation Guide §Camera, SoC TRM, Module Design Guide, schéma, et pinmap du carrier. Rendre d'abord le tableau de câblage, puis émettre la porte de confirmation ou personnalisation.
Étape 4 (chemin personnalisé uniquement) — Questions de câblage par capteur en lot, pré-remplies depuis le pinmap du carrier.
Étape 5 — Ajouter exactement UN fragment /* custom-bsp: camera:<sensor> */ au overlay custom composite .dts (voir ../../references/bsp-customization-kernel-dtb.md). Le chemin clone cpp-expand le DTSI en-tree ; le chemin personnalisé épisse les réponses Étape-4 + tableaux de mode sur place. Définir idempotently jetson-header-name sur la racine composite. Vérifier avec dtc + fdtoverlay (porte pré-compilation fragment unique ; porte post-compilation uniqueness deep-tree). Committer via la porte d'aperçu du message de commit du workflow.
Étape 6 — Vérifier les broches CAM auxiliaires SFIOs (cam_i2c_*, extperiph<m>_clk, GPIOs reset/PWDN/PWR_EN) via pin_verifier.py ; router les décalages vers /jetson-customize-pinmux.
Étape 7 — Atomic-write le JSON sidecar run-state à <workspace>/target-platform/<profile-stem>.jetson-customize-camera.json et émettre le titre, puis piloter la chaîne next-step en aval via des invites AskUserQuestion séquentielles par references/procedure.md Étape 7. La chaîne est une porte de workflow documentée, pas une question clarifiante — le mode auto ne l'exempte PAS. Ne jamais substituer une ligne « Étape suivante : … » imprimée aux invites.

Pièges

Piège à double fragment. Contribuer exactement UN fragment@N tagué caméra au composite. Un second portant status override déclenche dtc deep-merge → subtrees frères dupliqués (ex. deux tca9546@70) → le premier match à l'exécution abandonne le deep tree fourni par dtsi → la caméra n'énumère silencieusement pas. Porte uniquement sur le marqueur de ce skill (Étape 5c).
La compatible racine du composite est propriété globale, pas de ce skill. Ne pas élargir depuis celle d'un dtbo en-tree par capteur (gated par SKU-devkit). Corriger la racine composite si nécessaire.
jetson-header-name depuis tout dtbo en-tree par capteur. Fixé, carrier-agnostique ; lire une fois, coller sur la racine des métadonnées.
NE PAS aussi ajouter le dtbo en-tree par capteur à OVERLAY_DTB_FILE. Enregistrer à la fois votre overlay rendu ET le tegra<soc>-p3971-camera-<sensor>-overlay.dtbo en-tree produit une liaison subdev fantôme qui brique l'énumération de caméra.
L'overlay stub est un piège connu. Committer tegra-capture-vi { status="okay"; num-channels=<N>; } sans corps ports / sensor / nvcsi brique la caméra (all channel init failed). Épisser le corps capteur COMPLET via cpp + dtc.
Les tableaux de mode capteur doivent être épissés, jamais écrits à la main. mode<N>, sensor_modes, pixel_phase — copier verbatim depuis le DTSI en-tree le plus proche.
camera_common_regulator_get (null) ERR: -EINVAL = chaînes manquantes avdd-reg / iovdd-reg / dvdd-reg — épisser le corps capteur COMPLET ; les rails toujours-on se rabattent sur regulator dummy.
Les références &label externes doivent exister dans __symbols__ du DTB de base. Utiliser target-path = "/tegra-capture-vi" quand le label est absent ; fdtoverlay sort non-zéro avec FDT_ERR_NOTFOUND sinon.
Échec cpp sur dt-bindings/gpio/gpio.h: No such file = l'arbre source L4T n'est pas mis en place. Ré-exécuter /jetson-init-source (le source_sync.sh de Branch B récupère les en-têtes). Ne jamais fabriquer l'expansion de macros.
Aucune édition ODMDATA, aucune édition flash-conf. La caméra ne consomme pas de lanes UPHY. La ODMDATA="..." de la conf du carrier n'est pas modifiée. OVERLAY_DTB_FILE+= est propriété de /jetson-build-source Étape 5.0a — ce skill ne touche jamais la conf flash du carrier.
Ne pas toucher au BSP en amont à <bsp_image.root_path>. Tous les édits atterrissent dans <source.root_path>/Linux_for_Tegra/ (tracker overlay) et <source.root_path>/bsp_sources/ (overlay .dts) sous le motif pristine + customization commit.

Références

references/procedure.md — procédure complète pas à pas Étapes 1–7 (extraite de ce SKILL.md).
references/csi-dt-bindings.md — notes de référence DT binding CSI / nvcsi / vi.
references/overlay-template.md — guidance sur la forme overlay metadata-root + clone-body.
references/camera-overlay-templates/ — templates de démarrage .dts.tmpl : dphy-direct.dts.tmpl, gmsl-serdes.dts.tmpl.
../../scripts/pin_verifier.py — vérificateur HSIO pin partagé (Étape 6).
../../references/platform_template.yaml — bloc documents: consommé par Étape 1.
../../context/bsp-customization-workflow.md — protocole édition overlay.
../jetson-customize-pinmux/SKILL.md — skill frère auto-invoqué par Étape 6 pour corriger les décalages HSIO pin SFIO (CAM I²C, MCLK, GPIOs reset).
../jetson-derive-carrier/SKILL.md — doit être exécuté en premier ; produit le carrier base overlay (*-dynamic.dtbo) que le composite de ce skill empile après.
../jetson-init-source/SKILL.md — produit le tracker overlay + repo bsp_sources (avec l'arbre DTSI per-sensor hardware/nvidia/<chip-dir>/ ) que ce skill lit et commite.