jetson-customize-camera
NVIDIA/skills
Включить датчики камеры MIPI/GMSL на пользовательской несущей плате Jetson Thor или Orin путем рендеринга оверлея kernel-DT на основе DTSI датчика, встроенного в дерево ядра.
...Расширить всеНастройка камеры (запуск датчика CSI / MIPI / GMSL)
Обзор
Tegra264 (Thor) и Tegra234 (Orin) предоставляют доступ к единому контроллеру tegra-capture-vi
, управляемому через NVCSI и имеющему фиксированный набор портов CSI. Настройка
камеры осуществляется следующим образом:
- Выбор датчика — выбирается из набора ссылок на файлы
.dtsi, поставляемых NVIDIA в коревом дереве для активной платформы. - Проверка поддержки носителя и модуля — проверяется на соответствие «Руководству по разработке камер», «Руководству по адаптации» (§Camera), схеме носителя, TRM модуля и распиновке носителя.
- Подключение — определяется на основе файлов в дереве
tegra, если таковые имеются (файл DTSI ЯВЛЯЕТСЯ основополагающим источником информации о подключении); собирается для каждого датчика у пользователя, если датчик является пользовательским.-camera- *.dtsi - Наложение 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).содержит заголовочные файлы макросов, необходимые cpp (возможно, потребуется запустить/bsp_sources/kernel/kernel-noble/include/dt-bindings/ source_sync.sh, если использовалась ветка B — см. шаг 5a.i ниже).- Документация, являющаяся «источником достоверной информации», зарегистрированная или предоставленная по запросу:
Руководство по разработке камеры (в зеркале
bsp_developer_guideили по отдельному пути), Руководство по адаптации, раздел «Камера», схема носящей платы, TRM SoC, Руководство по проектированию модулей. dtc,cpp,fdtoverlayв PATH.
Процедура
Подробная пошаговая инструкция (шаги 1–7 со всеми таблицами, блоками
кода и логическими схемами) находится в файле
references/procedure.md. Краткое изложение:
- Шаг 1 — Определите активную целевую платформу и откройте авторитетные документы.
- Шаг 2 — Перечислите поддерживаемые датчики, используя глобальный поиск по dtbo-файлам камер для каждой платформы в дереве; классифицируйте их как DPHY-direct / GMSL / пользовательские. Никогда не придумывайте датчики.
- Шаг 3 / 3a — Перекрестная проверка поддержки носителя и модуля по DTSI, Руководству по разработке камер, Разделу «Камера» в Руководстве по адаптации, TRM SoC, Руководству по проектированию модулей, схеме и распиновке носителя. Сначала сформируйте таблицу подключений, а затем запустите контрольный этап «подтвердить или настроить».
- Шаг 4 (только для пользовательского пути) — Пакетная обработка вопросов о подключении по каждому датчику с автоматическим заполнением данных из схемы выводов несущей платы.
- Шаг 5 — Добавьте ровно ОДИН фрагмент
/* custom-bsp: camera:в составной пользовательский оверлей*/ .dts(см.../../references/bsp-customization-kernel-dtb.md). Путь «Clone» выполняет cpp-развертку DTSI внутри дерева; пользовательский путь вставляет ответы из шага 4 и таблицы режимов на месте. Идемпотентно установитеjetson-header-nameв корневом элементе композита. Проверьте с помощьюdtc+fdtoverlay(шлюз проверки на наличие одного фрагмента перед компиляцией; шлюз проверки уникальности глубокого дерева после компиляции). Зафиксируйте изменения через шлюз предварительного просмотра сообщения о фиксации в рабочем процессе. - Шаг 6 — Проверьте вспомогательные SFIO выводов CAM (
cam_i2c_*,выводыGPIOextperiph, reset/PWDN/PWR_EN) с помощью_clk pin_verifier.py; несоответствия направляйте в/jetson-customize-pinmux. - Шаг 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приводит к появлению фантомной привязки subdev, которая блокирует перечисление камер.-p3971-camera- -overlay.dtbo - Оверлей-заглушка — известная ловушка. Фиксация
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-source5.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 для каждого датчика), из которого этот с킬 считывает данные и в который он фиксирует изменения./
---
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.
Все файлы
11 файловУстановить 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
Копировать





Дом
