вариант
ДомДом Skill DevOps и CI/CD jetson-customize-camera

jetson-customize-camera

NVIDIA/skills NVIDIA/skills

Включить датчики камеры MIPI/GMSL на пользовательской несущей плате Jetson Thor или Orin путем рендеринга оверлея kernel-DT на основе DTSI датчика, встроенного в дерево ядра.

...Расширить все
0
Обновлено время 25 сентября 2026 г.

Настройка камеры (запуск датчика CSI / MIPI / GMSL)

Обзор

Tegra264 (Thor) и Tegra234 (Orin) предоставляют доступ к единому контроллеру tegra-capture-vi , управляемому через NVCSI и имеющему фиксированный набор портов CSI. Настройка камеры осуществляется следующим образом:

  1. Выбор датчика — выбирается из набора ссылок на файлы.dtsi, поставляемых NVIDIA в коревом дереве для активной платформы.
  2. Проверка поддержки носителя и модуля — проверяется на соответствие «Руководству по разработке камер», «Руководству по адаптации» (§Camera), схеме носителя, TRM модуля и распиновке носителя.
  3. Подключение — определяется на основе файлов в дереве tegra-camera-*.dtsi, если таковые имеются (файл DTSI ЯВЛЯЕТСЯ основополагающим источником информации о подключении); собирается для каждого датчика у пользователя, если датчик является пользовательским.
  4. Наложение Kernel-DT — выполнять cpp-expand для DTSI из основного дерева, извлекать его телоfragment@N и добавлять в составной пользовательский оверлей .dts для активной целевой платформы (согласно ../../references/bsp-customization-kernel-dtb.md), проверка композита с помощью fdtoverlay. /jetson-build-source компилирует композит и отвечает за регистрацию OVERLAY_DTB_FILE+= в конфигурации носителя.

Агентный подход, а не табличный — список датчиков формируется во время выполнения путем глобального поиска по именам dtb-файлов для каждого датчика, находящихся в дереве. Нет словаря _THOR_CAMERAS, нет файла questions.json, нет рендерера на Python в пути к вопросу.

Нет редактирования ODMDATA — камеры не используют каналы UPHY (CSI — это отдельный пул PHY). Скилл генерирует только оверлей ядра-DT; строка ODMDATA в конфигурации носителя не затрагивается этим скиллом.

Результатом является одна фиксация:

  • Блок Camera fragment@N (плюс jetson-header-name в корневом файле composite, если он ещё не присутствует) добавлен к пользовательскому наложению composite .dts согласно ../../references/bsp-customization-kernel-dtb.md → закоммитирован в репозиторий bsp_sources/hardware. /jetson-build-source компилирует композит в .dtbo и отвечает за его Makefile + регистрацию в flash-conf.

Когда вызывать

  • Пользователь запрашивает «включить камеру», «настроить CSI», «подключить датчик Hawk / Owl / IMX», «камеру MIPI», «камеру GMSL» или просит запустить tegra-capture-vi / NVCSI на пользовательской несущей плате.
  • Флеш-память загружается, но v4l2-ctl --list-devices не показывает каналовtegra-capture-vi, ИЛИ необходимо подтвердить перечисление датчиков на новой дочерней плате.
  • Датчик был ранее включён, и пользователь хочет добавить ещё один (запуск нескольких датчиков).

Необходимые условия:

  • Активный профиль с блоками reference_devkit: + custom_carrier.
  • Существует/Linux_for_Tegra/.git (/jetson-init-source).
  • Запущена команда/jetson-derive-carrier — форк flash-conf несущей находится в трекере оверлея.
  • Существуеткаталог /bsp_sources/hardware/nvidia//nv-public/overlay/ и содержит файлы .dtsi для каждого датчика, встроенные в дерево (источником которых является извлечение из архива ветки A команды /jetson-init-source).
  • /bsp_sources/kernel/kernel-noble/include/dt-bindings/ содержит заголовочные файлы макросов, необходимые cpp (возможно, потребуется запуститьsource_sync.sh, если использовалась ветка B — см. шаг 5a.i ниже).
  • Документация, являющаяся «источником достоверной информации», зарегистрированная или предоставленная по запросу: Руководство по разработке камеры (в зеркале bsp_developer_guide или по отдельному пути), Руководство по адаптации, раздел «Камера», схема носящей платы, TRM SoC, Руководство по проектированию модулей.
  • dtc, cpp, fdtoverlay в PATH.

Процедура

Подробная пошаговая инструкция (шаги 1–7 со всеми таблицами, блоками кода и логическими схемами) находится в файле references/procedure.md. Краткое изложение:

  1. Шаг 1 — Определите активную целевую платформу и откройте авторитетные документы.
  2. Шаг 2 — Перечислите поддерживаемые датчики, используя глобальный поиск по dtbo-файлам камер для каждой платформы в дереве; классифицируйте их как DPHY-direct / GMSL / пользовательские. Никогда не придумывайте датчики.
  3. Шаг 3 / 3a — Перекрестная проверка поддержки носителя и модуля по DTSI, Руководству по разработке камер, Разделу «Камера» в Руководстве по адаптации, TRM SoC, Руководству по проектированию модулей, схеме и распиновке носителя. Сначала сформируйте таблицу подключений, а затем запустите контрольный этап «подтвердить или настроить».
  4. Шаг 4 (только для пользовательского пути) — Пакетная обработка вопросов о подключении по каждому датчику с автоматическим заполнением данных из схемы выводов несущей платы.
  5. Шаг 5 — Добавьте ровно ОДИН фрагмент /* custom-bsp: camera: */ в составной пользовательский оверлей .dts (см. ../../references/bsp-customization-kernel-dtb.md). Путь «Clone» выполняет cpp-развертку DTSI внутри дерева; пользовательский путь вставляет ответы из шага 4 и таблицы режимов на месте. Идемпотентно установите jetson-header-name в корневом элементе композита. Проверьте с помощью dtc + fdtoverlay (шлюз проверки на наличие одного фрагмента перед компиляцией; шлюз проверки уникальности глубокого дерева после компиляции). Зафиксируйте изменения через шлюз предварительного просмотра сообщения о фиксации в рабочем процессе.
  6. Шаг 6 — Проверьте вспомогательные SFIO выводов CAM (cam_i2c_*, выводы GPIOextperiph_clk, reset/PWDN/PWR_EN) с помощью pin_verifier.py; несоответствия направляйте в /jetson-customize-pinmux.
  7. Шаг 7 — Выполните атомарную запись JSON-файла состояния выполнения в /target-platform/.jetson-customize-camera.json и выведите заголовок, затем запустите последующую цепочку следующих шагов с помощью последовательных запросов AskUserQuestion в соответствии с references/procedure.md Шаг 7. Эта цепочка представляет собой задокументированный контрольный пункт рабочего процесса, а не уточняющий вопрос — автоматический режим НЕ освобождает от его выполнения. Ни в коем случае не заменяйте запросы на напечатанную строку «Следующий шаг: …».

Ловушки

  • Ловушка двойных фрагментов. Включайте в композит ровно ОДИНфрагмент@N, помеченный камерой. Наличие второго фрагмента, несущего переопределения статуса, запускает глубокое слияние dtc → дублирование родственных поддеревьев (например, два tca9546@70) → при первом совпадении во время выполнения отбрасывается предоставленное dtsi глубокое дерево → камера незаметно не выполняет перечисление. Контроль только по маркеру данного навыка (Шаг 5c).
  • Совместимость корня композита определяется глобально, а не этим скилом. Не расширяйте с помощьюсовместимости каких-либо внутренних dtbo для отдельных датчиков (ограничено SKU-комплекта разработчика). При необходимости исправьте корень композита.
  • jetson-header-name из любого dtbo внутри дерева для каждого датчика. Исправлено, независимо от оператора связи; прочитать один раз, вставить в корень метаданных.
  • НЕ добавляйте также встроенный dtbo для каждого датчика в OVERLAY_DTB_FILE. Регистрация как вашего рендерируемого оверлея, так и встроенного tegra-p3971-camera--overlay.dtbo приводит к появлению фантомной привязки subdev, которая блокирует перечисление камер.
  • Оверлей-заглушка — известная ловушка. Фиксация tegra-capture-vi { status="okay"; num-channels=; } без тела с указанием портов / датчика / nvcsi приводит к выходу камеры из строя (сбой инициализации всех каналов). Склейте ПОЛНОЕ тело датчика с помощью cpp + dtc.
  • Таблицы режимов датчика необходимо вставлять, а не создавать вручную. mode, sensor_modes, pixel_phase — скопируйте дословно из ближайшего DTSI в дереве.
  • camera_common_regulator_get (null) ERR: -EINVAL = отсутствуют строкиavdd-reg / iovdd-reg / dvdd-reg — вставьте ПОЛНЫЙ блок датчика; постоянно включенные шины переключаются на фиктивный регулятор.
  • Внешние ссылки на метки должны присутствовать в __symbols__ базового DTB. Используйте target-path = "/tegra-capture-vi", если метка отсутствует; в противном случаеfdtoverlay завершает работу с ненулевым кодом ошибки FDT_ERR_NOTFOUND.
  • Ошибкакомпиляции cpp в dt-bindings/gpio/gpio.h: Такого файла нет = дерево исходных кодов L4T не подготовлено. Запустите заново /jetson-init-source (скрип т source_sync.sh ветки B загружает заголовочные файлы). Ни в коем случае не создавайте расширение макроса.
  • Редактирование ODMDATA не производится, редактирование flash-conf не производится. Камера не использует линии UPHY. Параметр ODMDATA="..." в конфигурации носителя остаётся неизменённым. OVERLAY_DTB_FILE+= принадлежит шагу /jetson-build-source 5.0a — этот процесс никогда не затрагивает конфигурацию флэш-памяти носителя.
  • Не трогайте исходный BSP по адресу . Все изменения попадают в /Linux_for_Tegra/ (трекер оверлеев) и /bsp_sources/ ( файлы .dts оверлеев) в соответствии со схемой фиксации изменений «исходный код + настройки».

Ссылки

  • references/procedure.md — полная пошаговая инструкция по шагам 1–7 (извлечена из этого файла SKILL.md).
  • references/csi-dt-bindings.md — справочные заметки по привязке CSI / nvcsi / vi DT.
  • references/overlay-template.md — рекомендации по структуре оверлея с корнем метаданных и клонированным телом.
  • references/camera-overlay-templates/ — исходные шаблоны .dts.tmpl: dphy-direct.dts.tmpl, gmsl-serdes.dts.tmpl.
  • ../../scripts/pin_verifier.py — общий верификатор выводов HSIO (шаг 6).
  • ../../references/platform_template.yaml — документы: блок, используемый на этапе 1.
  • ../../context/bsp-customization-workflow.md — протокол редактирования оверлея.
  • ../jetson-customize-pinmux/SKILL.md — навык-собрат, автоматически вызываемый на этапе 6 для устранения несоответствий выводов HSIO и SFIO (CAM I²C, MCLK, GPIO сброса).
  • ../jetson-derive-carrier/SKILL.md — должен запускаться первым; генерирует базовый оверлей носителя (*-dynamic.dtbo), после чего этот навык компоновка стеков.
  • ../jetson-init-source/SKILL.md — создаёт репозиторий трекера оверлея + bsp_sources (с деревом hardware/nvidia// DTSI для каждого датчика), из которого этот с킬 считывает данные и в который он фиксирует изменения.
Посмотреть на GitHub
---
name: jetson-customize-camera
description: Enable MIPI/GMSL camera sensors on a Jetson Thor or Orin custom carrier by rendering a kernel-DT overlay from the in-tree sensor DTSI.
license: Apache-2.0
---

# Customize camera (CSI / MIPI / GMSL sensor bring-up)

## Overview

Tegra264 (Thor) and Tegra234 (Orin) expose a single `tegra-capture-vi`
controller fronted by NVCSI and a fixed set of CSI ports. Camera
bring-up is:

1. **Sensor selection** — picked from the set NVIDIA ships in-tree
   `.dtsi` references for on the active platform.
2. **Carrier + module support check** — verified against the Camera
   Development Guide, Adaptation Guide §Camera, carrier schematic,
   Module TRM, and carrier pinmap.
3. **Wiring** — derived from the in-tree
   `tegra<soc>-camera-<sensor>*.dtsi` when one exists (**the DTSI IS
   the wiring source of truth**); captured per-sensor from the user
   when the sensor is custom.
4. **Kernel-DT overlay** — cpp-expand the in-tree DTSI, extract its
   `fragment@N` body, append into the composite custom overlay
   `.dts` for the active target (per
   [`../../references/bsp-customization-kernel-dtb.md`](../../references/bsp-customization-kernel-dtb.md)),
   verify the composite with `fdtoverlay`.
   `/jetson-build-source` compiles the composite and owns the
   carrier conf's `OVERLAY_DTB_FILE+=` registration.

**Agentic, not table-driven** — sensor list is built at runtime by
globbing in-tree per-sensor dtbos. No `_THOR_CAMERAS` dict, no
`questions.json`, no Python renderer in the question path.

**No ODMDATA edit** — cameras don't consume UPHY lanes (CSI is a
separate PHY pool). The skill emits only a kernel-DT overlay; the
ODMDATA line in the carrier conf is untouched by this skill.

The output is **one commit**:
- Camera `fragment@N` block (plus `jetson-header-name` on the
  composite root if not already present) appended to the composite
  custom overlay `.dts` per
  [`../../references/bsp-customization-kernel-dtb.md`](../../references/bsp-customization-kernel-dtb.md)
  → committed to the `bsp_sources/` hardware repo.
  `/jetson-build-source` compiles the composite to `.dtbo` and
  owns its Makefile + flash-conf registration.

## When to invoke

- The user says "enable camera", "configure CSI", "wire a Hawk /
  Owl / IMX sensor", "MIPI camera", "GMSL camera", or asks to bring
  up `tegra-capture-vi` / NVCSI on a custom carrier.
- Flash boots but `v4l2-ctl --list-devices` shows no
  `tegra-capture-vi` channels, OR sensor enumeration on a fresh
  daughter-card needs to be confirmed.
- A sensor was previously enabled and the user wants to add another
  (multi-sensor bring-up).

**Prerequisites:**

- Active profile with `reference_devkit:` + `custom_carrier:` blocks.
- `<source.root_path>/Linux_for_Tegra/.git` exists
  (`/jetson-init-source`).
- `/jetson-derive-carrier` has run — the carrier flash-conf fork is
  in the overlay tracker.
- `<source.root_path>/bsp_sources/hardware/nvidia/<chip-dir>/nv-public/overlay/`
  exists and contains the in-tree per-sensor `.dtsi` files (sourced
  by `/jetson-init-source`'s Branch A archive extract).
- `<source.root_path>/bsp_sources/kernel/kernel-noble/include/dt-bindings/`
  contains the macro headers cpp needs (`source_sync.sh` may need to
  run if Branch B was used — see Step 5a.i below).
- Source-of-truth docs registered or supplied at prompt:
  Camera Development Guide (in `bsp_developer_guide` mirror or
  separate path), Adaptation Guide §Camera, carrier schematic, SoC
  TRM, Module Design Guide.
- `dtc`, `cpp`, `fdtoverlay` on PATH.

## Procedure

Detailed step-by-step procedure (Steps 1–7, with all tables, code
blocks, and gates) lives in
[`references/procedure.md`](references/procedure.md). Summary:

1. **Step 1** — Resolve active target + open source-of-truth docs.
2. **Step 2** — Enumerate supported sensors by globbing in-tree
   per-platform camera dtbos; classify as DPHY-direct / GMSL /
   custom. Never invent sensors.
3. **Step 3 / 3a** — Cross-check carrier + module support against
   DTSI, Camera Development Guide, Adaptation Guide §Camera, SoC TRM,
   Module Design Guide, schematic, and carrier pinmap. Render the
   wiring table FIRST, then issue the confirm-or-customize gate.
4. **Step 4** (custom path only) — Batched per-sensor wiring
   questions auto-filled from the carrier pinmap.
5. **Step 5** — Append exactly ONE `/* custom-bsp: camera:<sensor> */`
   fragment to the composite custom overlay `.dts` (see
   [`../../references/bsp-customization-kernel-dtb.md`](../../references/bsp-customization-kernel-dtb.md)).
   Clone path cpp-expands the in-tree DTSI; custom path splices Step-4
   answers + mode tables in-place. Idempotently set
   `jetson-header-name` on the composite root. Verify with
   `dtc` + `fdtoverlay` (pre-compile single-fragment gate;
   post-compile deep-tree uniqueness gate). Commit via the
   workflow's commit-message preview gate.
6. **Step 6** — Verify ancillary CAM pin SFIOs (`cam_i2c_*`,
   `extperiph<m>_clk`, reset/PWDN/PWR_EN GPIOs) via
   `pin_verifier.py`; route mismatches to `/jetson-customize-pinmux`.
7. **Step 7** — Atomic-write run-state JSON sidecar at
   `<workspace>/target-platform/<profile-stem>.jetson-customize-camera.json`
   and emit the headline, then drive the downstream next-step chain via
   sequential `AskUserQuestion` prompts per `references/procedure.md`
   Step 7. **The chain is a documented workflow gate, not a clarifying
   question — auto-mode does NOT exempt it.** Never substitute a
   printed "Next step: …" line for the prompts.

## Gotchas

- **Dual-fragment trap.** Contribute exactly ONE camera-tagged
  `fragment@N` to the composite. A second one carrying status
  overrides triggers dtc deep-merge → duplicate sibling subtrees
  (e.g. two `tca9546@70`) → runtime first-match drops the dtsi-
  supplied deep tree → camera silently doesn't enumerate. Gate on
  this skill's marker only (Step 5c).
- **Composite root `compatible` is owned globally, not by this
  skill.** Don't widen from any in-tree per-sensor dtbo's
  `compatible` (devkit-SKU-gated). Fix the composite root if needed.
- **`jetson-header-name` from any in-tree per-sensor dtbo.** Fixed,
  carrier-agnostic; read once, paste onto the metadata root.
- **DO NOT also append the in-tree per-sensor dtbo to
  `OVERLAY_DTB_FILE`.** Registering both your rendered overlay AND
  the in-tree `tegra<soc>-p3971-camera-<sensor>-overlay.dtbo`
  produces a phantom subdev bind that bricks camera enumeration.
- **Stub overlay is a known footgun.** Committing
  `tegra-capture-vi { status="okay"; num-channels=<N>; }` with no
  ports / sensor / nvcsi body bricks the camera (`all channel init
  failed`). Splice the FULL sensor body via cpp + dtc.
- **Sensor mode tables must be spliced, never hand-authored.**
  `mode<N>`, `sensor_modes`, `pixel_phase` — copy verbatim from the
  closest in-tree DTSI.
- **`camera_common_regulator_get (null) ERR: -EINVAL`** = missing
  `avdd-reg` / `iovdd-reg` / `dvdd-reg` strings — splice the FULL
  sensor body; always-on rails fall back to dummy regulator.
- **External `&label` refs must exist in base DTB's `__symbols__`.**
  Use `target-path = "/tegra-capture-vi"` when the label is absent;
  `fdtoverlay` exits non-zero with `FDT_ERR_NOTFOUND` otherwise.
- **`cpp` failure on `dt-bindings/gpio/gpio.h: No such file`** =
  L4T source tree isn't staged. Re-run `/jetson-init-source` (Branch
  B's `source_sync.sh` fetches the headers). Never fabricate the
  macro expansion.
- **No ODMDATA edit, no flash-conf edit.** Camera doesn't consume
  UPHY lanes. The carrier conf's `ODMDATA="..."` is untouched.
  `OVERLAY_DTB_FILE+=` is owned by `/jetson-build-source` Step
  5.0a — this skill never touches the carrier flash conf.
- **Don't touch the upstream BSP at `<bsp_image.root_path>`.** All
  edits land in `<source.root_path>/Linux_for_Tegra/` (overlay
  tracker) and `<source.root_path>/bsp_sources/` (overlay `.dts`)
  under the pristine + customization commit pattern.

## References

- [`references/procedure.md`](references/procedure.md) — full
  step-by-step Steps 1–7 procedure (extracted from this SKILL.md).
- [`references/csi-dt-bindings.md`](references/csi-dt-bindings.md) —
  CSI / nvcsi / vi DT binding reference notes.
- [`references/overlay-template.md`](references/overlay-template.md) —
  guidance on the metadata-root + clone-body overlay shape.
- [`references/camera-overlay-templates/`](references/camera-overlay-templates/)
  — starter `.dts.tmpl` templates: `dphy-direct.dts.tmpl`,
  `gmsl-serdes.dts.tmpl`.
- [`../../scripts/pin_verifier.py`](../../scripts/pin_verifier.py)
  — shared HSIO pin verifier (Step 6).
- [`../../references/platform_template.yaml`](../../references/platform_template.yaml)
  — `documents:` block consumed by Step 1.
- [`../../context/bsp-customization-workflow.md`](../../context/bsp-customization-workflow.md#workflow-invariants)
  — overlay edit protocol.
- [`../jetson-customize-pinmux/SKILL.md`](../jetson-customize-pinmux/SKILL.md) —
  sibling skill auto-invoked by Step 6 to fix HSIO pin SFIO
  mismatches (CAM I²C, MCLK, reset GPIOs).
- [`../jetson-derive-carrier/SKILL.md`](../jetson-derive-carrier/SKILL.md)
  — must run first; produces the carrier base overlay (the
  `*-dynamic.dtbo`) this skill's composite stacks after.
- [`../jetson-init-source/SKILL.md`](../jetson-init-source/SKILL.md) —
  produces the overlay tracker + `bsp_sources` repo (with the
  `hardware/nvidia/<chip-dir>/` per-sensor DTSI tree) this skill
  reads and commits into.

Установить jetson-customize-camera

Скачайте файлы навыков и распакуйте их в каталог .claude/skills/.

Скачать ZIP

Клонируйте репозиторий и скопируйте файлы навыка в свой проект.

git clone https://github.com/NVIDIA/skills/tree/main/skills/jetson-customize-camera # Copy SKILL.md to your .claude/skills/ directory

Копировать Копировать
Быстрая настройка: Скопируйте папку со скиллом в каталог .claude/skills/ Claude автоматически обнаружит и запустит этот скилл
Репозиторий NVIDIA/skills

Похожие навыки

Verification &amp; Quality Assurance
Обновлено время 29 июня 2026 г.
klingai-upgrade-migration
Обновлено время 3 июля 2026 г.
base44-cli
Обновлено время 29 июня 2026 г.
Railway CLI Management
Обновлено время 2 июля 2026 г.
OR