Personalizar a câmera (configuração inicial do sensor CSI / MIPI / GMSL)

Visão geral

O Tegra264 (Thor) e o Tegra234 (Orin) expõem um único controlador tegra-capture-vi com interface NVCSI e um conjunto fixo de portas CSI. A configuração da câmera é:

1. Seleção do sensor — escolhido a partir do conjunto de referências.dtsi que a NVIDIA fornece no código-fonte para a plataforma ativa.
2. Verificação de compatibilidade da placa-mãe + módulo — verificada em relação ao Guia de Desenvolvimento de Câmeras, Guia de Adaptação §Câmera, esquema da placa-mãe, TRM do módulo e mapa de pinos da placa-mãe.
3. Fiação — derivada do *.dtsi do `tegra-camera-` na árvore do código-fonte, quando existir (o DTSI É a fonte de referência definitiva para a fiação); capturada por sensor a partir do usuário quando o sensor for personalizado.
4. Sobreposição do Kernel-DT — expanda com cpp o DTSI da árvore de código-fonte, extraia seu corpofragment@N e acrescente ao arquivo de sobreposição personalizado composto .dts para o alvo ativo (conforme ../../references/bsp-customization-kernel-dtb.md), verifique a sobreposição composta com fdtoverlay. O /jetson-build-source compila a sobreposição composta e é responsável pelo registro OVERLAY_DTB_FILE+= na configuração da plataforma.

Agente, não orientado por tabela — a lista de sensores é construída em tempo de execução por meio da inclusão de dtbos por sensor na árvore. Sem dicionário _THOR_CAMERAS, sem questions.json, sem renderizador Python no caminho da pergunta.

Sem edição de ODMDATA — as câmeras não consomem canais UPHY (o CSI é um pool PHY separado). A skill emite apenas uma sobreposição de kernel-DT; a linha ODMDATA na configuração da operadora não é alterada por esta skill.

A saída é um único commit:

• Bloco de fragmento de câmera @N (mais o nome do cabeçalho do Jetson na raiz do composto, caso ainda não esteja presente) anexado à sobreposição personalizada composta .dts conforme ../../references/bsp-customization-kernel-dtb.md → submetido ao repositório bsp_sources/hardware. O /jetson-build-source compila o composto para .dtbo e é responsável por seu Makefile e registro no flash-conf.

Quando invocar

• O usuário diz “ativar câmera”, “configurar CSI”, “conectar um sensor Hawk / Owl / IMX”, “câmera MIPI”, “câmera GMSL” ou solicita ativar o tegra-capture-vi / NVCSI em uma placa portadora personalizada.
• O flash inicializa, mas o v4l2-ctl --list-devices não mostra nenhum canaldo tegra-capture-vi, OU a enumeração de sensores em uma placa filha nova precisa ser confirmada.
• Um sensor já estava habilitado e o usuário deseja adicionar outro (ativação de múltiplos sensores).

Pré-requisitos:

• Perfil ativo com os blocos reference_devkit: + custom_carrier:
• /Linux_for_Tegra/.git existe (/jetson-init-source).
• O /jetson-derive-carrier foi executado — o fork da configuração flash da carrier está no rastreador de overlay.
• /bsp_sources/hardware/nvidia//nv-public/overlay/ existe e contém os arquivos .dtsi por sensor na árvore (originários da extração do arquivo do Branch A do /jetson-init-source).
• /bsp_sources/kernel/kernel-noble/include/dt-bindings/ contém os cabeçalhos de macro necessários para o C++ (pode ser necessário executaro source_sync.sh se o Branch B tiver sido usado — consulte a Etapa 5a.i abaixo).
• Documentos de referência registrados ou fornecidos no prompt: Guia de Desenvolvimento da Câmera (no espelho bsp_developer_guide ou em caminho separado), Guia de Adaptação §Câmera, esquema da placa-portadora, TRM do SoC, Guia de Projeto do Módulo.
• dtc, cpp, fdtoverlay no PATH.

Procedimento

O procedimento detalhado passo a passo (Etapas 1–7, com todas as tabelas, blocos de código e portas lógicas) está em references/procedure.md. Resumo:

1. Etapa 1 — Identifique o alvo ativo + abra os documentos de referência oficiais.
2. Etapa 2 — Enumerar os sensores suportados por meio de busca global nos dtbos de câmera por plataforma na árvore de código-fonte; classificar como DPHY direto / GMSL / personalizado. Nunca invente sensores.
3. Etapa 3 / 3a — Verifique o suporte da operadora e do módulo em relação ao DTSI, Guia de Desenvolvimento de Câmera, Guia de Adaptação §Câmera, TRM do SoC, Guia de Projeto de Módulo, esquema e mapa de pinos da operadora. Gere a tabela de fiação PRIMEIRO e, em seguida, acione o gate de confirmação ou personalização.
4. Etapa 4 (apenas no caminho personalizado) — Questões de fiação por sensor agrupadas preenchidas automaticamente a partir do mapa de pinos da operadora.
5. Etapa 5 — Acrescente exatamente UM fragmento /* custom-bsp: camera: */ ao arquivo .dts de sobreposição personalizada composta (consulte ../../references/bsp-customization-kernel-dtb.md). O caminho de clonagem expande via C++ o DTSI na árvore; o caminho personalizado une as respostas da Etapa 4 e as tabelas de modo no próprio local. Defina de forma idempotente o `jetson-header-name` na raiz composta. Verifique com `dtc` + `fdtoverlay` (porta de pré-compilação de fragmento único; porta de exclusividade de árvore profunda pós-compilação). Confirme por meio da porta de visualização da mensagem de confirmação do fluxo de trabalho.
6. Etapa 6 — Verifique os SFIOs de pinos CAM auxiliares (cam_i2c_*,_clk de extperiph, GPIOs de reset/PWDN/PWR_EN) por meio do pin_verifier.py; encaminhe as incompatibilidades para /jetson-customize-pinmux.
7. Etapa 7 — Grave de forma atômica o JSON de estado de execução no /target-platform/.jetson-customize-camera.json e exiba o título; em seguida, conduza a cadeia de próximas etapas a jusante por meio de solicitações sequenciais do tipo AskUserQuestion ,conforme references/procedure.md Passo 7. A cadeia é um portal de fluxo de trabalho documentado, não uma pergunta de esclarecimento — o modo automático NÃO a isenta. Nunca substitua as solicitações por uma linha impressa do tipo “Próximo passo: …”.

Armadilhas

• Armadilha de fragmentos duplos. Contribua com exatamente UMfragmento marcado pela câmera @N para a composição. Um segundo fragmento que contenha substituições de status aciona a fusão profunda do dtc → subárvores irmãs duplicadas (por exemplo, dois tca9546@70) → a primeira correspondência em tempo de execução descarta a árvore profunda fornecida pelo dtsi → a câmera silenciosamente não enumera. Aplique o portão apenas no marcador desta habilidade (Etapa 5c).
• A raiz do composto compatível pertence globalmente, não a esta habilidade. Não amplie a partir de nenhum dtbo por sensor dentro da árvore que seja compatível (restrito ao SKU do devkit). Corrija a raiz do composto, se necessário.
• jetson-header-name de qualquer dtbo por sensor na árvore. Corrigido, independente da operadora; leia uma vez, cole na raiz dos metadados.
• NÃO acrescente também o dtbo por sensor da árvore de código ao OVERLAY_DTB_FILE. Registrar tanto sua sobreposição renderizada quanto o dtbo da árvore de código do Tegra-p3971-camera--overlay.dtbo gera uma ligação de subdispositivo fantasma que bloqueia a enumeração da câmera.
• A sobreposição stub é uma armadilha conhecida. Submeter tegra-capture-vi { status="okay"; num-channels=; } sem o corpo de ports / sensor / nvcsi bloqueia a câmera (falha na inicialização de todos os canais). Inserir o corpo COMPLETO do sensor via cpp + dtc.
• As tabelas de modo do sensor devem ser inseridas, nunca criadas manualmente. mode, sensor_modes, pixel_phase — copie literalmente do DTSI mais próximo na árvore de código.
• camera_common_regulator_get (null) ERR: -EINVAL = faltam as stringsavdd-reg / iovdd-reg / dvdd-reg — insira o corpo COMPLETO do sensor; os trilhos sempre ativos recorrem ao regulador fictício.
• Referências externas a rótulos devem existir em __symbols__ do DTB base. Use target-path = "/tegra-capture-vi" quando o rótulo estiver ausente; caso contrário,fdtoverlay retorna um valor diferente de zero com FDT_ERR_NOTFOUND.
• Falhano cpp em dt-bindings/gpio/gpio.h: Arquivo inexistente = a árvore de código-fonte L4T não está preparada. Execute novamente /jetson-init-source (o script source_sync.sh do Ramo B busca os cabeçalhos). Nunca invente a expansão da macro.
• Sem edição do ODMDATA, sem edição da configuração do flash. A câmera não consome pistas UPHY. O ODMDATA="..." da configuração do carrier permanece inalterado. OVERLAY_DTB_FILE+= pertence à etapa /jetson-build-source 5.0a — esta tarefa nunca altera a configuração de flash do carrier.
• Não altere o BSP upstream em . Todas as alterações são feitas em /Linux_for_Tegra/ (rastreador de overlay) e /bsp_sources/ ( ficheiros .dts de overlay) seguindo o padrão de commit “pristine + personalização”.

Referências

• references/procedure.md — procedimento completo passo a passo das etapas 1 a 7 (extraído deste SKILL.md).
• references/csi-dt-bindings.md — notas de referência sobre ligações DT para CSI / nvcsi / vi.
• references/overlay-template.md — orientações sobre a forma da sobreposição com raiz de metadados + corpo clonado.
• references/camera-overlay-templates/ — modelos iniciais .dts.tmpl: dphy-direct.dts.tmpl, gmsl-serdes.dts.tmpl.
• ../../scripts/pin_verifier.py — verificador de pinos HSIO compartilhado (Etapa 6).
• ../../references/platform_template.yaml — documentos: bloco utilizado na Etapa 1.
• ../../context/bsp-customization-workflow.md — protocolo de edição de sobreposição.
• ../jetson-customize-pinmux/SKILL.md — skill irmã autoinvocada pela Etapa 6 para corrigir incompatibilidades de pinos HSIO com SFIO (CAM I²C, MCLK, GPIOs de reset).
• ../jetson-derive-carrier/SKILL.md — deve ser executada primeiro; produz a sobreposição base da portadora (o *-dynamic.dtbo) na qual as pilhas compostas desta habilidade são empilhadas posteriormente.
• ../jetson-init-source/SKILL.md — gera o rastreador de overlay + o repositório bsp_sources (com a árvore DTSI por sensorem hardware/nvidia/ ) que esta skill lê e no qual faz commits.