Personnalisation de la caméra (mise en service des capteurs CSI / MIPI / GMSL)

Présentation

Les puces Tegra264 (Thor) et Tegra234 (Orin) exposent un seul contrôleur tegra-capture-vi géré par NVCSI et un ensemble fixe de ports CSI. La mise en service de la caméra se déroule comme suit :

1. Sélection du capteur — choisi parmi l’ensemble des références.dtsi fournies par NVIDIA dans l’arborescence pour la plateforme active.
2. Vérification de la prise en charge du support et du module — effectuée par rapport au Guide de développement des caméras, au Guide d'adaptation §Caméra, au schéma du support, au TRM du module et au plan de brochage du support.
3. Câblage — dérivé du fichier *.dtsi de la branche principale« tegra-camera- » lorsqu’il existe (le DTSI EST la source de référence en matière de câblage) ; capturé par capteur auprès de l’utilisateur lorsque le capteur est personnalisé.
4. Superposition du noyau-DT — expansion en C++ du DTSI intégré à l’arborescence, extraction de son corpsfragment@N, ajout à la superposition composite personnalisée .dts pour la cible active (selon ../../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 configuration du support.

Approche agentique, non pilotée par des tables — la liste des capteurs est construite à l’exécution par recherche globale des fichiers dtbos par capteur dans l’arborescence. Pas de dictionnaire _THOR_CAMERAS, pas de questions.json, pas de moteur de rendu Python dans le chemin d’accès aux questions.

Pas de modification d’ODMDATA — les caméras ne consomment pas de voies UPHY (CSI est un pool PHY distinct). La compétence n’émet qu’une superposition de DT du noyau ; la ligne ODMDATA dans la configuration du support n’est pas modifiée par cette compétence.

La sortie correspond à un seul commit:

• Le bloc « Camera fragment@N » (plus le nom de l’en-tête Jetson sur la racine du composite s’il n’y figure pas déjà) est ajouté à la superposition personnalisée composite .dts selon ../../references/bsp-customization-kernel-dtb.md → validé dans le dépôt bsp_sources/hardware. /jetson-build-source compile le composite en .dtbo et gère son Makefile ainsi que son enregistrement dans flash-conf.

Quand l'invoquer

• L’utilisateur indique « activer la caméra », « configurer le CSI », « connecter un capteur Hawk / Owl / IMX », « caméra MIPI », « caméra GMSL », ou demande de lancer tegra-capture-vi / NVCSI sur une carte porteuse personnalisée.
• Le flash démarre mais v4l2-ctl --list-devices n’affiche aucun canaltegra-capture-vi, OU l’énumération des capteurs sur une nouvelle carte fille doit être confirmée.
• Un capteur était précédemment activé et l’utilisateur souhaite en ajouter un autre (mise en service multi-capteurs).

Prérequis :

• Profil actif avec les blocs reference_devkit : + custom_carrier :.
• /Linux_for_Tegra/.git existe (/jetson-init-source).
• /jetson-derive-carrier a été exécuté — la branche « flash-conf » du carrier se trouve dans le tracker overlay.
• Le répertoire /bsp_sources/hardware/nvidia//nv-public/overlay/ existe et contient les fichiers .dtsi par capteur intégrés à l’arborescence (provenant de l’extrait d’archive de la branche A de /jetson-init-source).
• /bsp_sources/kernel/kernel-noble/include/dt-bindings/ contient les en-têtes de macros dont C++ a besoin (il peut être nécessaire d’ exécutersource_sync.sh si la branche B a été utilisée — voir l’étape 5a.i ci-dessous).
• Documents de référence enregistrés ou fournis à la demande : Guide de développement de la caméra (dans le miroir bsp_developer_guide ou sur un chemin distinct), Guide d’adaptation §Caméra, schéma du support, TRM du SoC, Guide de conception du module.
• dtc, cpp, fdtoverlay dans PATH.

Procédure

La procédure détaillée étape par étape (étapes 1 à 7, avec tous les tableaux, blocs de code et portes logiques) se trouve dansle fichier references/procedure.md. Résumé :

1. Étape 1 — Déterminer la cible active et ouvrir les documents de référence.
2. Étape 2 — Répertorier les capteurs pris en charge en parcourant les dtbos de caméra par plateforme dans l’arborescence ; les classer en DPHY-direct / GMSL / personnalisés. Ne jamais inventer de capteurs.
3. Étape 3 / 3a — Vérifier la prise en charge du support et du module par rapport au DTSI, au Guide de développement de la caméra, au Guide d’adaptation §Caméra, au TRM du SoC, au Guide de conception du module, au schéma et à la carte des broches du support. Générer le tableau de câblage EN PREMIER, puis déclencher la porte « confirmer ou personnaliser ».
4. Étape 4 (parcours personnalisé uniquement) — Questions de câblage par capteur regroupées et remplies automatiquement à partir de la carte des broches du support.
5. Étape 5 — Ajoutez exactement UN fragment /* custom-bsp: camera: */ au fichier .dts de superposition personnalisée composite (voir ../../references/bsp-customization-kernel-dtb.md). Le chemin « clone » effectue l’expansion C++ du DTSI intégré à l’arborescence ; le chemin « custom » intègre les réponses de l’étape 4 et les tables de mode directement sur place. Définissez de manière idempotente jetson-header-name sur la racine composite. Vérifiez avec dtc + fdtoverlay (porte de pré-compilation à fragment unique ; porte de post-compilation garantissant l’unicité de l’arborescence profonde). Validez via la porte de prévisualisation du message de validation du workflow.
6. Étape 6 — Vérifier les SFIO des broches CAM auxiliaires (cam_i2c_*,_clk des périphériques externes, GPIO reset/PWDN/PWR_EN) via pin_verifier.py; signaler les divergences de routage à /jetson-customize-pinmux.
7. Étape 7 — Effectuez une écriture atomique du fichier JSON d’état d’exécution (sidecar) à l’adresse /target-platform/.jetson-customize-camera.json et affichez le titre, puis lancez la chaîne des étapes suivantes en aval via des invites séquentielles « AskUserQuestion » conformément au fichier references/procedure.md Étape 7. La chaîne constitue une étape documentée du workflow, et non une question de clarification — le mode automatique ne la dispense PAS. Ne remplacez jamais les invites par une ligne imprimée « Étape suivante : … ».

Pièges

• Piège des fragments doubles. Contribuez exactement à UN SEULfragment@N marqué par la caméra au composite. Un deuxième fragment portant des informations de statut déclenche une fusion profonde dtc → des sous-arborescences sœurs en double (par ex. deux tca9546@70) → la première correspondance en exécution rejette l’arborescence profonde fournie par dtsi → la caméra ne procède pas à l’énumération de manière silencieuse. Appliquez le contrôle d’accès uniquement sur le marqueur de cette compétence (Étape 5c).
• La racine du composite compatible est gérée globalement, et non par cette compétence. Ne pas étendre à partir des DTBO par capteur présentes dans l’arborescence compatibles (contrôlées par le SKU du kit de développement). Corriger la racine du composite si nécessaire.
• jetson-header-name provenant de n’importe quel DTBO par capteur présent dans l’arborescence. Corrigé, indépendant de l’opérateur ; lire une fois, coller dans la racine des métadonnées.
• N’ajoutez PAS non plus le fichier DTBO par capteur présent dans l’arborescence à OVERLAY_DTB_FILE. L’enregistrement à la fois de votre superposition rendue ET du fichier DTBO Tegraprésent dans l’arborescence -p3971-camera--overlay.dtbo génère une liaison de sous-périphérique fantôme qui bloque l’énumération de la caméra.
• La superposition « stub » est un piège connu. Valider tegra-capture-vi { status="okay"; num-channels=; } sans corps de type ports / sensor / nvcsi rend la caméra inutilisable (échec de l’initialisation de tous les canaux). Intégrez le corps COMPLET du capteur via cpp + dtc.
• Les tables de mode du capteur doivent être intégrées, jamais rédigées à la main. mode, sensor_modes, pixel_phase — copiez mot pour mot à partir du DTSI le plus proche dans l’arborescence.
• camera_common_regulator_get (null) ERR : -EINVAL = chaînes avdd-reg / iovdd-reg / dvdd-reg manquantes — intégrez l’intégralité du corps du capteur ; les rails toujours actifs se rabattent sur un régulateur factice.
• Les références externes &label doivent exister dans le fichier __symbols__ du DTB de base. Utilisez target-path = « /tegra-capture-vi » lorsque le label est absent ; sinon,fdtoverlay renvoie un code de sortie non nul avec FDT_ERR_NOTFOUND.
• Échecde compilation dans dt-bindings/gpio/gpio.h : fichier introuvable = l’arborescence source L4T n’est pas préparée. Relancez /jetson-init-source ( le script source_sync.sh de la branche B récupère les en-têtes). Ne simulez jamais l’ expansion de la macro.
• Pas de modification d’ODMDATA, pas de modification de la configuration flash. La caméra ne consomme pas de voies UPHY. La valeur ODMDATA="..." de la configuration du support reste inchangée. OVERLAY_DTB_FILE+= relève de l’étape 5.0a de /jetson-build-source — cette procédure ne modifie jamais la configuration flash du porteur.
• Ne modifiez pas le BSP en amont disponible à l'adresse . Toutes les modifications sont enregistrées dans /Linux_for_Tegra/ (suivi des overlays) et /bsp_sources/ ( fichiers .dts des overlays) selon le modèle de commit « version d'origine + personnalisation ».

Références

• references/procedure.md — procédure complète étape par étape des étapes 1 à 7 (extraite de ce fichier SKILL.md).
• references/csi-dt-bindings.md — notes de référence sur les liaisons DT CSI / nvcsi / vi.
• references/overlay-template.md — conseils sur la structure de superposition « metadata-root + clone-body ».
• references/camera-overlay-templates/ — modèles .dts.tmpl de départ : dphy-direct.dts.tmpl, gmsl-serdes.dts.tmpl.
• ../../scripts/pin_verifier.py — Vérificateur de broches HSIO partagé (étape 6).
• ../../references/platform_template.yaml — documents : bloc utilisé à l'étape 1.
• ../../context/bsp-customization-workflow.md — protocole d’édition des superpositions.
• ../jetson-customize-pinmux/SKILL.md — compétence sœur automatiquement invoquée par l’étape 6 pour corriger les incohérences entre les broches HSIO et SFIO (CAM I²C, MCLK, GPIO de réinitialisation).
• ../jetson-derive-carrier/SKILL.md — doit s’exécuter en premier ; génère la superposition de base du support (le fichier*-dynamic.dtbo) sur laquelle cette compétence empile ensuite ses composantes.
• ../jetson-init-source/SKILL.md — génère le tracker de superposition + le dépôt bsp_sources (contenant l’ arborescence DTSI par capteurdans hardware/nvidia/) que cette compétence lit et dans lequel elle effectue des commits.