옵션
집집 Skill DevOps 및 CI/CD jetson-customize-camera

jetson-customize-camera

NVIDIA/skills NVIDIA/skills

트리 내 센서 DTSI를 기반으로 커널 DT 오버레이를 렌더링하여 Jetson Thor 또는 Orin 맞춤형 캐리어에서 MIPI/GMSL 카메라 센서를 활성화합니다.

...모든 것을 확장하십시오
0
업데이트 된 시간 2026년 9월 25일

카메라 사용자 정의 (CSI / MIPI / GMSL 센서 초기화)

개요

Tegra264(Thor) 및 Tegra234(Orin)는 NVCSI와 고정된 CSI 포트 세트로 구성된 단일 tegra-capture-vi 컨트롤러를 노출합니다. 카메라 가동 절차는 다음과 같습니다.

  1. 센서 선택 — 활성 플랫폼에 대해 NVIDIA가 트리 내에 제공하는 .dtsi 참조 세트에서 선택합니다.
  2. 캐리어 + 모듈 지원 확인 — 카메라 개발 가이드, 적응 가이드 §카메라, 캐리어 회로도, 모듈 TRM 및 캐리어 핀맵을 기준으로 검증합니다.
  3. 배선 — 트리 내의 tegra-camera-*.dtsi 파일이 존재할 경우 이를 기반으로 도출합니다(DTSI가 배선에 대한 유일한 신뢰할 수 있는 소스입니다); 센서가 커스텀인 경우 사용자로부터 센서별로 정보를 수집합니다.
  4. 커널-DT 오버레이 — 트리 내 DTSI를 cpp-expand하여, 해당 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 행은 이 스킬에 의해 변경되지 않습니다.

출력은 하나의 커밋입니다:

  • 카메라 프래그먼트@N 블록(아직 존재하지 않는 경우 컴포지트 루트에 jetson-header-name 추가)이 다음 경로의 컴포지트 커스텀 오버레이 .dts 파일에 추가됩니다. ../../references/bsp-customization-kernel-dtb.md → bsp_sources/ 하드웨어 저장소에 커밋됩니다. /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의 Branch A 아카이브 추출본에서 가져온 것입니다).
  • /bsp_sources/kernel/kernel-noble/include/dt-bindings/ 에는 C++에 필요한 매크로 헤더가 포함되어 있습니다(브랜치 B를 사용한 경우source_sync.sh를 실행해야 할 수 있습니다 — 아래 5a.i 단계를 참조하십시오).
  • 프롬프트에서 등록되거나 제공된 신뢰할 수 있는 문서: 카메라 개발 가이드( bsp_developer_guide 미러 또는 별도의 경로에 있음), 적용 가이드 §카메라, 캐리어 회로도, SoC TRM, 모듈 설계 가이드.
  • PATH에dtc, cpp, fdtoverlay가 포함되어 있어야 합니다.

절차

자세한 단계별 절차(1~7단계, 모든 표, 코드 블록 및 게이트 포함)는 references/procedure.md에 있습니다. 요약:

  1. 1단계 — 활성 타겟 및 신뢰할 수 있는 오픈 소스 문서를 확인합니다.
  2. 2단계 — 트리 내의 플랫폼별 카메라 dtbos를 글로빙하여 지원되는 센서를 열거하고, DPHY-direct / GMSL / 커스텀으로 분류합니다. 절대 센서를 임의로 만들어서는 안 됩니다.
  3. 3단계 / 3a단계 — 캐리어 및 모듈 지원 여부를 DTSI, 카메라 개발 가이드, 적응 가이드 §카메라, SoC TRM, 모듈 설계 가이드, 회로도 및 캐리어 핀맵과 대조하여 확인합니다. 먼저 배선 테이블을 생성한 후, 확인 또는 사용자 정의 게이트를 실행합니다.
  4. 4단계 (커스텀 경로 전용) — 캐리어 핀맵에서 자동으로 채워진 센서별 배선 질문을 일괄 처리합니다.
  5. 5단계 — 복합 사용자 정의 오버레이 .dts 파일에 정확히 하나만 /* custom-bsp: camera: */ 단편을 추가합니다(참조: ../../references/bsp-customization-kernel-dtb.md). 클론 경로는 트리 내 DTSI를 C++로 확장하며, 사용자 정의 경로는 4단계의 답변과 모드 테이블을 제자리에 병합합니다. 복합 루트에서 jetson-header-name을 이뎀포텐트하게 설정합니다. dtc + fdtoverlay를 통해 검증합니다(컴파일 전 단일 프래그먼트 게이트; 컴파일 후 딥 트리 고유성 게이트). 워크플로의 커밋 메시지 미리보기 게이트를 통해 커밋합니다.
  6. 6단계 —pin_verifier.py를 통해 보조 CAM 핀 SFIO(cam_i2c_*, extperiph_clk, 리셋/PWDN/PWR_EN GPIO)를 검증합니다. 불일치 사항은 /jetson-customize-pinmux로 전달합니다.
  7. 7단계 —/target-platform/에있는 run-state JSON 사이드카를 원자적 쓰기 방식으로 저장합니다.jetson-customize-camera.json 헤드라인을 출력한 후, references/procedure.md에따라 순차적인 AskUserQuestion 프롬프트를 통해 하류 다음 단계 체인을 진행합니다. 7단계. 이 체인은 문서화된 워크플로우 게이트이며, 단순한 확인용 질문이 아닙니다 — 자동 모드에서도 이 단계는 생략되지 않습니다. 절대로 프롬프트 대신 "다음 단계: …"라는 문구를 사용해서는 안 됩니다.

주의 사항

  • 이중 프래그먼트 함정. 카메라 태그가 지정된 프래그먼트@N을 정확히 하나만 복합체에 기여하십시오. 상태를 덮어쓰는 두 번째 프래그먼트는 dtc 심층 병합을 유발하여 → 중복된 형제 서브트리를 생성합니다 (예: 두 개의 tca9546@70) → 런타임 첫 번째 일치 시 dtsi에서 제공된 딥 트리가 제거됨 → 카메라가 아무런 오류 메시지 없이 열거되지 않음. 이 스킬의 마커에만 게이트를 설정하십시오(5c단계).
  • 컴포지트 루트 호환성은 이 스킬이 아닌 전역적으로 소유됩니다. 트리 내 센서별 dtbo의호환성 (devkit-SKU 제한)을 기반으로 범위를 확장하지 마십시오. 필요한 경우 컴포지트 루트를 수정하십시오.
  • 트리 내 센서별 DTBO의jetson-header-name. 수정됨, 캐리어에 구애받지 않음; 한 번 읽은 후 메타데이터 루트에 붙여넣으십시오.
  • 트리 내 센서별 DTB를 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) 오류: -EINVAL = avdd-reg / iovdd-reg / dvdd-reg 문자열 누락 — 전체 센서 본문을 삽입하십시오; 상시 작동 레일은 더미 레귤레이터로 대체됩니다.
  • 외부 &label 참조는 기본 DTB의 __symbols__에 존재해야 합니다. 라벨이 없는 경우 target-path = "/tegra-capture-vi"를 사용하십시오. 그렇지 않으면fdtoverlay가 FDT_ERR_NOTFOUND 오류와 함께 0이 아닌 값으로 종료됩니다.
  • dt-bindings/gpio/gpio.h에서cpp 오류 : 해당 파일 없음 = L4T 소스 트리가 스테이징되지 않았습니다. /jetson-init-source를 다시 실행하십시오(브랜치 B의 source_sync.sh가 헤더를 가져옵니다). 절대 매크로 확장을 임의로 생성하지 마십시오.
  • ODMDATA 편집 없음, 플래시 구성 편집 없음. 카메라는 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
업데이트 된 시간 2026년 6월 29일
klingai-upgrade-migration
업데이트 된 시간 2026년 7월 3일
base44-cli
업데이트 된 시간 2026년 6월 29일
Railway CLI Management
업데이트 된 시간 2026년 7월 2일
OR