jetson-customize-camera
NVIDIA/skills
Jetson Thor または Orin のカスタムキャリアボード上で、ツリー内のセンサー DTSI からカーネル DT オーバーレイを生成することで、MIPI/GMSL カメラセンサーを有効にします。
...すべて拡張しますカメラのカスタマイズ(CSI/MIPI/GMSLセンサーの起動)
概要
Tegra264 (Thor) および Tegra234 (Orin) は、NVCSI と固定セットの CSI ポートを介して、単一のtegra-capture-vi
コントローラを提供します。カメラの
起動手順は以下の通りです:
- センサーの選択— NVIDIAがツリー内に提供するセットから選択します。
.dtsiは、アクティブなプラットフォームを参照します。 - キャリアおよびモジュールのサポート確認— 『Camera Development Guide』、『Adaptation Guide』の「Camera」セクション、キャリアの回路図、 モジュールのTRM、およびキャリアのピンマップに基づいて検証されます。
- 配線— ツリー内の
tegraが存在する場合、そこから導出されます(DTSIこそが 配線の信頼できる情報源です)。センサーがカスタムの場合、ユーザーから センサーごとに情報を取得します。-camera- *.dtsi - カーネル-DTオーバーレイ— ツリー内のDTSIをcpp-expandし、その
fragment@N本体を抽出して、アクティブなターゲット用の 複合カスタムオーバーレイ.dtsに追加する (../../references/bsp-customization-kernel-dtb.md参照)、fdtoverlayを使用して複合オーバーレイを検証する。/jetson-build-source は複合オーバーレイをコンパイルし、 キャリア設定のOVERLAY_DTB_FILE+=登録を管理する。
テーブル駆動型ではなくエージェント型— センサーリストは実行時に、
ツリー内のセンサーごとの dtbos をグロブ処理することで構築される。_THOR_CAMERAS辞書も、
questions.json も、クエスチョンパス内の Python レンダラーも存在しない。
ODMDATAの編集は不要— カメラはUPHYレーンを消費しません(CSIは 別のPHYプールです)。このスキルはカーネルDTオーバーレイのみを生成し、 キャリア設定ファイル内のODMDATA行はこのスキルによって変更されません。
出力は1つのコミットです:
- カメラの
fragment@Nブロック(まだ存在しない場合は、コンポジットルートのjetson-header-nameも追加)が、以下のパスにあるコンポジット カスタムオーバーレイ.dtsに付加されます../../references/bsp-customization-kernel-dtb.mdに従って、コンポジットカスタムオーバーレイ .dts に追加されます。 →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ファイルが含まれていること(これらは/jetson-init-source のブランチ A アーカイブの展開によって読み込まれている)。には、C++ が必要とするマクロヘッダーが含まれています(ブランチ B を使用した場合、/bsp_sources/kernel/kernel-noble/include/dt-bindings/ source_sync.shを実行する必要がある場合があります — 以下のステップ 5a.i を参照してください)。- プロンプトで登録または指定された「信頼できる情報源」のドキュメント:
『Camera Development Guide』(
bsp_developer_guideミラーまたは 別のパス内)、『Adaptation Guide』の「§Camera」セクション、キャリア回路図、SoC TRM、『Module Design Guide』。 - PATH
にdtc、cpp、fdtoverlayが設定されていること。
手順
詳細な手順(ステップ1~7、すべての表、コード
ブロック、およびゲートを含む)は
references/procedure.md に記載されています。概要:
- ステップ 1— アクティブなターゲットを特定し、信頼できるオープンソースのドキュメントを確認する。
- ステップ 2— ツリー内のプラットフォームごとのカメラ dtbos をグロブ処理して、 サポートされているセンサーを列挙する。DPHY ダイレクト / GMSL / カスタムに分類する。センサーを勝手に作り出してはならない。
- ステップ 3 / 3a— キャリアおよびモジュールのサポート状況を、 DTSI、カメラ開発ガイド、適応ガイド §Camera、SoC TRM、 モジュール設計ガイド、回路図、およびキャリアのピンマップと照合する。まず 配線テーブルを生成し、その後「確認またはカスタマイズ」ゲートを発行する。
- ステップ 4(カスタムパス限定) — キャリアのピンマップから 自動入力された、センサーごとの配線に関する質問をバッチ処理する。
- ステップ 5— 複合カスタムオーバーレイ
.dtsに、正確に 1 つの/* custom-bsp: camera:フラグメントを追加する(*/ ../../references/bsp-customization-kernel-dtb.mdを参照)。 パス「clone」ではツリー内のDTSIがC++展開されます。カスタムパスでは、ステップ4の 回答とモードテーブルがインプレースでスプライスされます。 複合ルートのjetson-header-name を冪等的に設定します。dtcおよびfdtoverlayを使用して検証します(コンパイル前のシングルフラグメントゲート、 コンパイル後のディープツリー一意性ゲート)。ワークフローの コミットメッセージプレビューゲートを介してコミットします。 - ステップ 6— 補助的な CAM ピン SFIO(
cam_i2c_*、extperiph、リセット/PWDN/PWR_EN GPIO)を_clk pin_verifier.pyを使用して検証する。不一致は/jetson-customize-pinmuxにルーティングする。 - ステップ 7—
に/target-platform/ jetson-customize-camera .json run-state JSON サイドカーをアトミック書き込みで保存し、見出しを出力した後、references/procedure.mdに記載された 順次的なAskUserQuestionプロンプトを通じて、下流の次のステップチェーンを駆動します。 ステップ7.このチェーンは、文書化されたワークフローのゲートであり、単なる確認の 質問ではありません — 自動モードであっても、この要件は免除されません。決して、 プロンプトの代わりに「次のステップ:…」といった表示行を代用してはいけません。
注意点
- デュアルフラグメントの落とし穴。コンポジットには、カメラタグ付きの
フラグメント@Nを正確に1つだけ含めること。ステータスを保持する 2つ目のフラグメントを含めると、dtcのディープマージがトリガーされ、 同一レベルのサブツリーが重複する (例:2つのtca9546@70)→ 実行時のファーストマッチにより、dtsiから 提供されたディープツリーが破棄される → カメラは黙って列挙を行わない。ゲートは このスキルのマーカーのみに設定すること(ステップ5c)。 -
コンポジットルートの互換性情報は、この スキルではなくグローバルに所有される。ツリー内のセンサーごとの dtbo の互換性情報から拡張してはならない(devkit-SKU による制限あり)。必要に応じてコンポジットルートを修正する。 - ツリー内のセンサーごとの DTB から
jetson-header-name を取得します。修正済み、 キャリア非依存;一度読み取り、メタデータルートに貼り付けます。 - また、ツリー内のセンサーごとの dtbo を
OVERLAY_DTB_FILEに追加しないでください。レンダリングされたオーバーレイと、 ツリー内のtegraの両方を登録すると、ファントムサブデバイスバインドが発生し、カメラの列挙が機能しなくなります。-p3971-camera- -overlay.dtbo - スタブオーバーレイは既知の落とし穴です。
ports / sensor / nvcsi の本体を指定せずに
tegra-capture-vi { status="okay"; num-channels=をコミットすると、 カメラが動作不能になります(; } すべてのチャンネルの初期化に失敗)。cpp + dtc を使用して完全なセンサー本体を組み込んでください。 - センサーモードテーブルは必ずスプライスし、手作業で作成してはなりません。
mode、sensor_modes、pixel_phase— ツリー内の最も近い DTSI から そのままコピーしてください。 camera_common_regulator_get (null) ERR: -EINVAL= 欠落avdd-reg/iovdd-reg/dvdd-reg文字列 — 完全な センサー・ボディをスプライスする;常時オンのレールはダミー・レギュレータにフォールバックする。- 外部の
&label参照は、ベース DTB の__symbols__に存在する必要があります。 ラベルが存在しない場合はtarget-path = "/tegra-capture-vi"を使用してください。 そうでない場合、fdtoverlay はFDT_ERR_NOTFOUNDを返して非ゼロで終了します。 -
dt-bindings/gpio/gpio.hでのcppエラー: そのようなファイルはありません= L4T ソースツリーがステージングされていません。/jetson-init-sourceを再実行してください(ブランチ B のsource_sync.shがヘッダーを取得します)。マクロ展開を 決して偽造しないでください。 - 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 ツリーを含む)を生成します。 このスキルはこれを読み込み、コミットを行います。/
---
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
コピー





家
