
Customize Camera
OfficialFreeEasily configure MIPI/GMSL cameras on Jetson platforms.
Free · Opens the source repo
What Customize Camera does
The Customize Camera skill provides a systematic approach to enabling MIPI and GMSL camera sensors on NVIDIA Jetson Thor and Orin custom carriers. By leveraging existing in-tree device tree source files (DTSI), this skill allows developers to create a kernel device tree overlay that accurately represents the wiring and configuration of the selected camera sensor. This process is crucial for ensuring that the camera is correctly recognized and enumerated by the system, allowing for proper functionality in applications that depend on camera input.
The skill operates by first selecting the appropriate sensor from a predefined list provided by NVIDIA. It then checks compatibility against various documentation resources, including the Camera Development Guide and carrier schematics. The wiring is derived from the in-tree DTSI files, ensuring that the configuration is based on verified data. Once the necessary information is gathered, the skill generates a composite custom overlay that integrates the selected sensor's configuration, which is then compiled and registered for use.
This tool is particularly beneficial for developers working on custom hardware that requires specific camera configurations. It streamlines the complex process of camera bring-up, reducing the potential for errors that can arise from manual configurations. The skill is designed to handle multiple sensors, making it suitable for projects that involve multi-camera setups. By automating the overlay generation and verification process, it saves time and enhances the reliability of camera integration on Jetson platforms.
When to use it
Use this skill when you need to enable or configure MIPI or GMSL camera sensors on Jetson Thor or Orin platforms, especially in custom hardware setups.
When not to use it
This skill is not suitable for general camera usage outside of NVIDIA Jetson platforms or for configurations that require ODMDATA edits.
What you can build with it
Single Camera Setup
Use this skill to enable a single MIPI or GMSL camera on a custom Jetson carrier, ensuring proper enumeration.
Multi-Camera Configuration
Configure multiple camera sensors on a Jetson platform, streamlining the setup process for complex applications.
Custom Carrier Development
Integrate camera sensors into a new custom carrier design, utilizing the skill to handle the device tree overlay generation.
How to install Customize Camera
View source1. Install with the skills CLI
npx skills add nvidia/skills/jetson-customize-camera --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by nvidiaCustomize 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:
- Sensor selection — picked from the set NVIDIA ships in-tree
.dtsireferences for on the active platform. - Carrier + module support check — verified against the Camera Development Guide, Adaptation Guide §Camera, carrier schematic, Module TRM, and carrier pinmap.
- Wiring — derived from the in-tree
tegra<soc>-camera-<sensor>*.dtsiwhen one exists (the DTSI IS the wiring source of truth); captured per-sensor from the user when the sensor is custom. - Kernel-DT overlay — cpp-expand the in-tree DTSI, extract its
fragment@Nbody, append into the composite custom overlay.dtsfor the active target (per../../references/bsp-customization-kernel-dtb.md), verify the composite withfdtoverlay./jetson-build-sourcecompiles the composite and owns the carrier conf'sOVERLAY_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@Nblock (plusjetson-header-nameon the composite root if not already present) appended to the composite custom overlay.dtsper../../references/bsp-customization-kernel-dtb.md→ committed to thebsp_sources/hardware repo./jetson-build-sourcecompiles the composite to.dtboand 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-devicesshows notegra-capture-vichannels, 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/.gitexists (/jetson-init-source)./jetson-derive-carrierhas 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.dtsifiles (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.shmay 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_guidemirror or separate path), Adaptation Guide §Camera, carrier schematic, SoC TRM, Module Design Guide. dtc,cpp,fdtoverlayon PATH.
Procedure
Detailed step-by-step procedure (Steps 1–7, with all tables, code
blocks, and gates) lives in
references/procedure.md. Summary:
- Step 1 — Resolve active target + open source-of-truth docs.
- Step 2 — Enumerate supported sensors by globbing in-tree per-platform camera dtbos; classify as DPHY-direct / GMSL / custom. Never invent sensors.
- 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.
- Step 4 (custom path only) — Batched per-sensor wiring questions auto-filled from the carrier pinmap.
- Step 5 — Append exactly ONE
/* custom-bsp: camera:<sensor> */fragment to the composite custom overlay.dts(see../../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 setjetson-header-nameon the composite root. Verify withdtc+fdtoverlay(pre-compile single-fragment gate; post-compile deep-tree uniqueness gate). Commit via the workflow's commit-message preview gate. - Step 6 — Verify ancillary CAM pin SFIOs (
cam_i2c_*,extperiph<m>_clk, reset/PWDN/PWR_EN GPIOs) viapin_verifier.py; route mismatches to/jetson-customize-pinmux. - Step 7 — Atomic-write run-state JSON sidecar at
<workspace>/target-platform/<profile-stem>.jetson-customize-camera.jsonand emit the headline, then drive the downstream next-step chain via sequentialAskUserQuestionprompts perreferences/procedure.mdStep 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@Nto the composite. A second one carrying status overrides triggers dtc deep-merge → duplicate sibling subtrees (e.g. twotca9546@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
compatibleis owned globally, not by this skill. Don't widen from any in-tree per-sensor dtbo'scompatible(devkit-SKU-gated). Fix the composite root if needed. jetson-header-namefrom 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-treetegra<soc>-p3971-camera-<sensor>-overlay.dtboproduces 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= missingavdd-reg/iovdd-reg/dvdd-regstrings — splice the FULL sensor body; always-on rails fall back to dummy regulator.- External
&labelrefs must exist in base DTB's__symbols__. Usetarget-path = "/tegra-capture-vi"when the label is absent;fdtoverlayexits non-zero withFDT_ERR_NOTFOUNDotherwise. cppfailure ondt-bindings/gpio/gpio.h: No such file= L4T source tree isn't staged. Re-run/jetson-init-source(Branch B'ssource_sync.shfetches 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-sourceStep 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— full step-by-step Steps 1–7 procedure (extracted from this SKILL.md).references/csi-dt-bindings.md— CSI / nvcsi / vi DT binding reference notes.references/overlay-template.md— guidance on the metadata-root + clone-body overlay shape.references/camera-overlay-templates/— starter.dts.tmpltemplates:dphy-direct.dts.tmpl,gmsl-serdes.dts.tmpl.../../scripts/pin_verifier.py— shared HSIO pin verifier (Step 6).../../references/platform_template.yaml—documents:block consumed by Step 1.../../context/bsp-customization-workflow.md— overlay edit protocol.../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— must run first; produces the carrier base overlay (the*-dynamic.dtbo) this skill's composite stacks after.../jetson-init-source/SKILL.md— produces the overlay tracker +bsp_sourcesrepo (with thehardware/nvidia/<chip-dir>/per-sensor DTSI tree) this skill reads and commits into.
Frequently asked questions about Customize Camera
Similar skills
WinMD API Search
Easily find and explore Windows desktop APIs.
WebMCPify
Transform any web app into an agent-ready platform.
Phoenix Tracing
Instrument LLM applications with OpenInference tracing.
Foundry Hosted Agent CopilotKit
Guidance for developing agentic web apps on Azure.
Power Automate Foundation
Connect AI agents to Power Automate seamlessly.
Power Automate Flow Builder
Efficiently build and deploy Power Automate flows programmatically.
