Agent Skill · NVIDIA NIM

jetson-customize-camera

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. Do NOT use for UPHY lane allocation or ODMDATA edits.

Provider: NVIDIA NIM Path in repo: skills/jetson-customize-camera/SKILL.md

Skill body

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), 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:

When to invoke

Prerequisites:

Procedure

Detailed step-by-step procedure (Steps 1–7, with all tables, code blocks, and gates) lives in 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). 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

References

Skill frontmatter

version: 0.0.1 license: Apache-2.0 metadata: {"data-classification" => "public", "author" => "Jetson Team", "tags" => ["bsp", "phase-2", "io", "camera", "csi"], "domain" => "meta"}