Personalizar la cámara (puesta en marcha del sensor CSI / MIPI / GMSL)

Descripción general

Tegra264 (Thor) y Tegra234 (Orin) exponen un único controlador tegra-capture-vi con NVCSI como interfaz y un conjunto fijo de puertos CSI. La puesta en marcha de la cámara consiste en:

1. Selección del sensor: se elige del conjunto de referencias.dtsi que NVIDIA incluye en el árbol de fuentes para la plataforma activa.
2. Comprobación de compatibilidad de la placa base y el módulo: se verifica con respecto a la Guía de desarrollo de cámaras, la Guía de adaptación (apartado «Cámara»), el esquema de la placa base, el TRM del módulo y el mapa de pines de la placa base.
3. Cableado: derivado del archivo *.dtsi de «tegra-camera- » incluido en el árbol del proyecto, cuando exista (el DTSI ES la fuente de referencia definitiva para el cableado); capturado por el usuario para cada sensor cuando el sensor es personalizado.
4. Superposición del kernel-DT: expandir con cpp el DTSI del árbol de código, extraer su cuerpofragment@N y añadirlo al archivo de superposición personalizado compuesto .dts para el objetivo activo (según ../../references/bsp-customization-kernel-dtb.md), verificar la superposición compuesta con fdtoverlay. /jetson-build-source compila la superposición compuesta y se encarga del registro OVERLAY_DTB_FILE+= en la configuración del operador.

Basado en agentes, no en tablas: la lista de sensores se genera en tiempo de ejecución mediante la inclusión global de los dtbos por sensor del árbol del sistema. Sin diccionario _THOR_CAMERAS, sin questions.json, sin renderizador de Python en la ruta de la pregunta.

Sin edición de ODMDATA: las cámaras no consumen carriles UPHY (CSI es un grupo PHY independiente). La skill solo emite una superposición del DT del kernel; la línea ODMDATA de la configuración del carrier no se ve afectada por esta skill.

El resultado es una única confirmación:

• El fragmento de cámara @N bloque (más el nombre del encabezado de Jetson en la raíz del compuesto si aún no está presente) se añade a la superposición personalizada compuesta .dts según ../../references/bsp-customization-kernel-dtb.md → confirmado en el repositorio de hardware bsp_sources/. /jetson-build-source compila el compuesto a .dtbo y se encarga de su Makefile y del registro en flash-conf.

Cuándo invocarlo

• El usuario dice «activar la cámara», «configurar CSI», «conectar un sensor Hawk / Owl / IMX», «cámara MIPI», «cámara GMSL», o solicita activar tegra-capture-vi / NVCSI en una tarjeta portadora personalizada.
• La memoria flash arranca, pero v4l2-ctl --list-devices no muestra ningún canalde tegra-capture-vi, O BIEN es necesario confirmar la enumeración de sensores en una tarjeta secundaria nueva.
• Anteriormente se había habilitado un sensor y el usuario desea añadir otro (puesta en marcha multisensor).

Requisitos previos:

• Perfil activo con reference_devkit: + custom_carrier: blocks.
• Existe/Linux_for_Tegra/.git (/jetson-init-source).
• Se ha ejecutado/jetson-derive-carrier: la bifurcación de la configuración flash del carrier se encuentra en el rastreador de superposiciones.
• Existe/bsp_sources/hardware/nvidia//nv-public/overlay/ y contiene los archivos .dtsi por sensor integrados en el árbol (procedentes de la extracción del archivo de la rama A de /jetson-init-source).
• /bsp_sources/kernel/kernel-noble/include/dt-bindings/ contiene los encabezados de macros que necesita C++ (puede que sea necesario ejecutarsource_sync.sh si se ha utilizado la rama B; véase el paso 5a.i más abajo).
• Documentación de referencia registrada o facilitada en el momento solicitado: Guía de desarrollo de la cámara (en el espejo de bsp_developer_guide o en una ruta independiente), Guía de adaptación §Cámara, esquema del soporte, TRM del SoC, Guía de diseño del módulo.
• dtc, cpp y fdtoverlay en PATH.

Procedimiento

El procedimiento detallado paso a paso (pasos 1–7, con todas las tablas, bloques de código y puertas) se encuentra en references/procedure.md. Resumen:

1. Paso 1 — Identificar el objetivo activo y abrir la documentación de referencia.
2. Paso 2 — Enumerar los sensores compatibles mediante la búsqueda global en el árbol de los dtbos de cámara por plataforma; clasificarlos como DPHY directo / GMSL / personalizados. Nunca inventar sensores.
3. Paso 3 / 3a — Comparar la compatibilidad del operador y del módulo con el DTSI, la Guía de desarrollo de cámaras, la Guía de adaptación §Cámara, el TRM del SoC, la Guía de diseño de módulos, el esquema y el mapa de pines del operador. Generar la tabla de cableado PRIMERO y, a continuación, activar la puerta de «confirmar o personalizar».
4. Paso 4 (solo ruta personalizada) — Cuestiones de cableado por sensor agrupadas y rellenadas automáticamente a partir del mapa de pines del operador.
5. Paso 5 — Añade exactamente UN fragmento /* custom-bsp: camera: */ al archivo .dts de superposición personalizada compuesta (véase ../../references/bsp-customization-kernel-dtb.md). La ruta «Clone» expande mediante C++ el DTSI integrado en el árbol; la ruta personalizada empalma las respuestas del paso 4 y las tablas de modos in situ. Establece de forma idempotente jetson-header-name en la raíz compuesta. Verifica con dtc + fdtoverlay (puerta de fragmento único previa a la compilación; puerta de unicidad de árbol profundo posterior a la compilación). Confirma a través de la puerta de vista previa del mensaje de confirmación del flujo de trabajo.
6. Paso 6 — Verifica los SFIO de pines CAM auxiliares (cam_i2c_*,, pines GPIO de reset/PWDN/PWR_EN) mediante pin_verifier.py; deriva las discrepancias a /jetson-customize-pinmux.
7. Paso 7 — Realiza una escritura atómica del archivo JSON de estado de ejecución en /target-platform/.jetson-customize-camera.json y emite el titular; a continuación, impulsa la cadena de pasos siguientes mediante solicitudes secuenciales de «AskUserQuestion» según references/procedure.md Paso 7. La cadena es una etapa documentada del flujo de trabajo, no una pregunta aclaratoria: el modo automático NO la exime. Nunca sustituyas las solicitudes por una línea impresa que diga «Siguiente paso: …».

Puntos a tener en cuenta

• Trampa de doble fragmento. Aporta exactamente UNfragmento etiquetado por la cámara @N a la composición. Un segundo fragmento que contenga anulaciones de estado desencadena una fusión profunda de dtc → subárboles hermanos duplicados (p. ej., dos tca9546@70) → la primera coincidencia en tiempo de ejecución descarta el árbol profundo proporcionado por dtsi → la cámara, de forma silenciosa, no enumera. Aplica la compuerta únicamente al marcador de esta habilidad (Paso 5c).
• La raíz del compuesto compatible es de propiedad global, no de esta habilidad. No amplíes a partir de ningún dtbo por sensor dentro del árbol que sea compatible (restringido por devkit-SKU). Corrige la raíz del compuesto si es necesario.
• jetson-header-name de cualquier DTB per-sensor del árbol. Corregido, independiente del operador; léelo una vez y pégalo en la raíz de metadatos.
• NO añadas también el dtbo por sensor incluido en el árbol a OVERLAY_DTB_FILE. Si registras tanto tu superposición renderizada como el dtbo de superposición de Tegraincluido en el árbol -p3971-camera--overlay.dtbo se produce un enlace de subdispositivo fantasma que bloquea la enumeración de la cámara.
• La superposición «stub» es un error conocido. Al confirmar tegra-capture-vi { status="okay"; num-channels=; } sin el cuerpo de puertos / sensor / nvcsi, la cámara deja de funcionar (fallo en la inicialización de todos los canales). Incorpora el cuerpo COMPLETO del sensor mediante cpp + dtc.
• Las tablas de modos del sensor deben insertarse, nunca escribirse a mano. mode, sensor_modes, pixel_phase: cópialas tal cual del DTSI más parecido del árbol de fuentes.
• camera_common_regulator_get (null) ERR: -EINVAL = faltan las cadenasavdd-reg / iovdd-reg / dvdd-reg — integra el cuerpo COMPLETO del sensor; los raíles siempre activos recurren a un regulador ficticio.
• Las referencias externas a etiquetas deben existir en __symbols__ del DTB base. Utiliza target-path = "/tegra-capture-vi" cuando la etiqueta no esté presente; de lo contrario,fdtoverlay devuelve un valor distinto de cero con FDT_ERR_NOTFOUND.
• Errorde cpp en dt-bindings/gpio/gpio.h: No existe tal archivo = el árbol de código fuente de L4T no está preparado. Vuelve a ejecutar /jetson-init-source ( el script source_sync.sh de la rama B recupera los encabezados). Nunca inventes la expansión de la macro.
• No se edita ODMDATA ni la configuración de la memoria flash. La cámara no consume carriles UPHY. El valor ODMDATA="..." de la configuración del carrier no se modifica. OVERLAY_DTB_FILE+= pertenece al paso 5.0a de /jetson-build-source: esta tarea nunca modifica la configuración de la memoria flash del carrier.
• No modifiques el BSP de origen en . Todas las modificaciones se realizan en /Linux_for_Tegra/ (rastreador de superposiciones) y /bsp_sources/ ( archivos .dts de superposición) siguiendo el patrón de commits «pristine + personalización».

Referencias

• references/procedure.md — procedimiento completo paso a paso de los pasos 1 a 7 (extraído de este SKILL.md).
• references/csi-dt-bindings.md — Notas de referencia sobre enlaces DT de CSI / nvcsi / vi.
• references/overlay-template.md — orientación sobre la forma de superposición «metadata-root + clone-body».
• references/camera-overlay-templates/ — plantillas .dts.tmpl de inicio: dphy-direct.dts.tmpl, gmsl-serdes.dts.tmpl.
• ../../scripts/pin_verifier.py — verificador compartido de pines HSIO (Paso 6).
• ../../references/platform_template.yaml — Documentos: bloque utilizado en el paso 1.
• ../../context/bsp-customization-workflow.md — Protocolo de edición de superposiciones.
• ../jetson-customize-pinmux/SKILL.md — habilidad homóloga invocada automáticamente por el paso 6 para corregir las discrepancias entre pines HSIO y SFIO (CAM I²C, MCLK, GPIO de reinicio).
• ../jetson-derive-carrier/SKILL.md — debe ejecutarse en primer lugar; genera la superposición base del carrier (el *-dynamic.dtbo) sobre la que se apilan posteriormente las pilas compuestas de esta habilidad.
• ../jetson-init-source/SKILL.md — genera el rastreador de superposición y el repositorio bsp_sources (con el árbol DTSI por sensorde hardware/nvidia/ ) que esta habilidad lee y en el que realiza confirmaciones.