Generated banner for Jetson Init Image
Generated logo for Jetson Init Image

Jetson Init Image

NVIDIAOfficialCreated by Jetson TeamDistributed by NVIDIA

  • Skill
  • Workflow
  • Cloud and DevOps
  • Apache-2.0
  • Medium risk

From the author

Extract Jetson Linux + sample-rootfs tarballs and run apply_binaries.sh for the active target, then record bsp_image in the profile. Use after jetson-init-target; not for source-tree setup.
— the description by Jetson Team

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill automates the setup of the Jetson Board Support Package (BSP) environment. It extracts the Jetson Linux and sample-rootfs tarballs, executes the necessary binary application scripts, and updates the active target profile with the BSP image metadata. It intelligently detects the required GPU stack (nvgpu or OpenRM) based on the target hardware and ensures the environment is correctly configured for subsequent development steps.

What it does

  • Locates and validates Jetson Linux and sample-rootfs tarballs on the local filesystem.
  • Extracts BSP components into the designated workspace directory.
  • Applies binaries using the appropriate GPU stack flag based on the target SoC generation.
  • Records the BSP version and root path in the active target profile.
  • Verifies existing installations to prevent accidental overwrites.
  • Ensures the environment is ready for source tree initialization.

When to use it

  • When setting up a new Jetson development workspace after defining the target platform.
  • When a downstream process reports a missing Linux_for_Tegra directory.
  • When the active profile lacks the required bsp_image configuration block.
  • When you need to ensure the correct GPU driver stack is applied for your specific Jetson module.

Advantages

  • Automates complex manual extraction and configuration steps.
  • Prevents configuration errors by automatically selecting the correct GPU stack.
  • Maintains consistency by updating the project profile with verified metadata.
  • Safeguards existing installations by requiring explicit confirmation for overwrites.

Usage examples

“Initialize the BSP image for my current target.”
The agent identifies the target, locates the required tarballs, extracts them, applies the correct GPU binaries, and updates the profile with the BSP version.
“Set up the Jetson Linux environment in /opt/jetson/bsp.”
The agent validates the path, performs the extraction and binary application, and records the custom root path in the active profile.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/nvidia/jetson-init-image/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip jetson-init-image.zip -d .agents/skills

Documentation by Jetson Team

Initialize BSP Image

Output is only bsp_image: in the active profile: derived version plus root_path only when overriding <workspace>/Image.

When to invoke

  • The user asks to extract, prepare, or initialize the BSP image.

  • A downstream skill reports missing <bsp_image.root_path>/Linux_for_Tegra/.

  • The active profile has no bsp_image: block yet.

Procedure

Resolve target and image path

Resolve the active profile per ../../context/target-platform-contract.md. Refuse if there is no active profile or reference_devkit: is missing.

<workspace> is the parent of the active profile's target-platform/ directory. <bsp_image.root_path> defaults to <workspace>/Image.

Profile stateAction
bsp_image.root_path existsUse it without prompting.
bsp_image: exists without root_pathUse <workspace>/Image.
No bsp_image: blockAsk once: Enter for default, or absolute override path.

For an override, validate that the closest existing parent is writable. Omit root_path when the default is used.

Determine GPU stack

Use the shared GPU-driver invariant from ../../context/target-platform-contract.md. Derive the expected stack from reference_devkit.module.id and the catalogue:

Chip familyModule IDsStackapply_binaries.sh flag
T234 / Orinp3701, p3767nvgpunone
T264 and later / Thor+p3834OpenRM--openrm

Refuse unknown module IDs. The --openrm flag is only valid on BSP releases that ship the OpenRM stack; if the active BSP doesn't expose the flag, omit it regardless of what the target wants.

Reuse or extract

If <bsp_image.root_path>/Linux_for_Tegra/ already exists:

  1. Do not extract over it unless the user explicitly requested re-extraction and accepted the overwrite risk.

  2. Derive the on-disk version from Linux_for_Tegra/nv_tegra_release. Ask before replacing a different recorded bsp_image.version.

  3. Verify the installed GPU stack against the platform-derived expectation when possible. Detection precedence (first probe that yields a definitive answer wins):

    1. Linux_for_Tegra/rootfs/etc/nv_tegra_release carries an INSTALL_TYPE= token on BSP releases that expose it (newer lines). Read and compare directly.

    2. Otherwise, find Linux_for_Tegra -name nvgpu.ko: present → nvgpu, absent → OpenRM.

    3. If the chip family has only ever shipped one stack (e.g. T234 / Orin is always nvgpu in current BSPs), fall back to the catalogue-derived expectation without disk probing.

If the installed stack conflicts with the active target, refuse and ask the user to re-extract with the correct stack or fix the target profile. Otherwise skip extraction and update the profile.

Locate tarballs

When extraction is needed, search:

  1. <bsp_image.root_path>/

  2. <workspace>/

  3. current working directory

Prompt for absolute paths for anything missing. Required filenames:

  • Jetson_Linux_R<ver>_aarch64.tbz2

  • Tegra_Linux_Sample-Root-Filesystem_R<ver>_aarch64.tbz2

Both filenames must contain the same R<ver> token. Refuse mismatches and record <ver> as bsp_image.version. Do not download tarballs.

Extract and apply binaries

Use absolute tarball paths; they may live outside <bsp_image.root_path>.

ROOT="<bsp_image.root_path>"
BSP_TARBALL="<absolute path to Jetson_Linux_R<ver>_aarch64.tbz2>"
ROOTFS_TARBALL="<absolute path to Tegra_Linux_Sample-Root-Filesystem_R<ver>_aarch64.tbz2>"

mkdir -p "$ROOT"
tar xjf "$BSP_TARBALL" -C "$ROOT"
sudo tar xpjf "$ROOTFS_TARBALL" -C "$ROOT/Linux_for_Tegra/rootfs"

cd "$ROOT/Linux_for_Tegra"
if [ "$GPU_STACK" = "openrm" ]; then
  sudo ./apply_binaries.sh --openrm
else
  sudo ./apply_binaries.sh
fi

Set GPU_STACK from the "Determine GPU stack" step above. Abort on the first failing command and surface the failed command.

Update the active profile

Persist the resolved BSP image metadata in the active target profile so later skills can find the BSP without re-prompting. Preserve existing blocks, comments, and quoted SKU values; use a round-tripping YAML writer such as ruamel.yaml.

bsp_image:
  root_path: <absolute override path>  # omit for <workspace>/Image
  version: "<derived version>"

Rules:

  • Same version and same root path: no rewrite.

  • Different version: ask before updating.

  • Different recorded root_path: refuse automatic rewrite.

  • Always quote version.

Finish

Report the image path, extracted vs reused state, GPU stack, derived version, and profile update status. Then suggest /jetson-init-source.

Purpose

Materialize Linux_for_Tegra/ on disk by extracting the right Jetson Linux + sample-rootfs tarballs and running apply_binaries.sh with the GPU-stack flag derived from the active target (nvgpu for T234, OpenRM for T264+). Then commit the derived BSP version into the profile's bsp_image: block.

Prerequisites

  • Active target profile resolved per ../../context/target-platform-contract.md.

  • Jetson Linux BSP tarball and matching sample-rootfs tarball staged on disk (e.g. by /jetson-download-bsp or hand-placed).

  • Write access to the workspace Image/ root (or the override bsp_image.root_path).

  • sudo available for apply_binaries.sh.

Limitations

  • Writes only the bsp_image: block; source tree, documents, and carrier profile are owned by sibling skills.

  • Refuses to overwrite an existing Linux_for_Tegra/ without explicit user direction.

  • Does not download tarballs; rely on /jetson-download-bsp or hand-stage the inputs.

Troubleshooting

  • apply_binaries.sh exits non-zero — re-read its console output; most failures are missing sudo, missing rootfs tarball, or wrong GPU stack flag for the SoC generation.

  • nv_tegra_release absent after extract — extraction stopped early; verify tarball integrity and rerun.

  • Recorded version disagrees with the tarball filename — the tarball was renamed; trust the value parsed from Linux_for_Tegra/nv_tegra_release over filenames.

  • Different recorded root_path already in profile — refuse and ask the user to confirm before overwriting.

References

  • ../../context/target-platform-contract.md

  • ../../references/bsp-platforms-catalogue.md

  • ../../references/platform_template.yaml

  • ../jetson-init-target/SKILL.md

  • ../jetson-init-source/SKILL.md

  • ../jetson-flash-image/SKILL.md

Files

evals/evals.json

[
  {
    "id": "jetson-init-image-001",
    "question": "I've staged Jetson_Linux_R36.4.0_aarch64.tbz2 and Tegra_Linux_Sample-Root-Filesystem_R36.4.0_aarch64.tbz2 in my workspace and just finished /jetson-init-target for an AGX Orin profile. How do I extract the BSP and get bsp_image: written into my profile?",
    "expected_skill": "jetson-init-image",
    "expected_script": null,
    "ground_truth": "Invoke /jetson-init-image; with no bsp_image: block in the profile it asks once for the path (Enter accepts the default <workspace>/Image and omits root_path from the profile). Module p3701 derives the nvgpu stack from the catalogue so apply_binaries.sh runs without --openrm. The skill searches <bsp_image.root_path>/, <workspace>/, and the cwd for the matching R36.4.0 tarballs, refuses if the R<ver> tokens disagree, then runs tar xjf for the BSP, sudo tar xpjf for the rootfs into Linux_for_Tegra/rootfs, cd Linux_for_Tegra, sudo ./apply_binaries.sh. Finally it writes bsp_image.version: \"36.4.0\" into the active profile via a round-tripping YAML writer and suggests /jetson-init-source.",
    "expected_behavior": [
      "Read skills/jetson-init-image/SKILL.md",
      "Resolve the active profile and confirm reference_devkit is present; refuse otherwise",
      "Ask once for bsp_image.root_path; on Enter use <workspace>/Image and omit root_path from the written profile",
      "Use the chip-family table to derive the GPU stack: p3701 -> nvgpu, no --openrm flag",
      "Locate both R<ver> tarballs across <bsp_image.root_path>/, <workspace>/, and cwd; refuse if R<ver> tokens differ",
      "Run tar xjf for the BSP, sudo tar xpjf for the sample rootfs into Linux_for_Tegra/rootfs, then sudo ./apply_binaries.sh from Linux_for_Tegra",
      "Persist bsp_image.version: \"36.4.0\" with a round-tripping YAML writer (e.g. ruamel.yaml) preserving comments and quoting",
      "Report extracted vs reused state, GPU stack, derived version, profile update status, and suggest /jetson-init-source"
    ]
  },
  {
    "id": "jetson-init-image-002",
    "question": "My profile already records bsp_image.root_path: /opt/jetson/Image with version \"36.3.0\" but Linux_for_Tegra/ at that path now reports R36.4.0 in nv_tegra_release. What does /jetson-init-image do, and how do I avoid losing my custom root_path?",
    "expected_skill": "jetson-init-image",
    "expected_script": null,
    "ground_truth": "Because Linux_for_Tegra/ already exists, the skill does not extract over it without explicit user direction. It derives the on-disk version from Linux_for_Tegra/nv_tegra_release (36.4.0) and asks before replacing the recorded 36.3.0 - trust the parsed value over filenames. It also probes the GPU stack via INSTALL_TYPE in nv_tegra_release first, then falls back to find -name nvgpu.ko, then to the catalogue expectation; conflicts with the active target are refused. The recorded root_path is honoured (\"different recorded root_path: refuse automatic rewrite\"), so /opt/jetson/Image is not silently changed - only version is updated in place, with quoting preserved, after you confirm.",
    "expected_behavior": [
      "Read skills/jetson-init-image/SKILL.md",
      "Identify that Linux_for_Tegra/ already exists, so the Reuse-or-extract path applies and the skill does not extract over it without explicit user direction",
      "Parse Linux_for_Tegra/nv_tegra_release for the on-disk version and trust it over tarball filenames",
      "Ask before replacing the recorded bsp_image.version with the new derived 36.4.0 value",
      "Run the GPU-stack detection ladder (nv_tegra_release INSTALL_TYPE -> find -name nvgpu.ko -> catalogue fallback) and refuse if it conflicts with the active target",
      "Refuse to silently overwrite a different recorded root_path; preserve /opt/jetson/Image and quote the version on update",
      "Cite the matching Troubleshooting bullets for nv_tegra_release / version disagreement / different recorded root_path"
    ]
  }
]

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

What our scanner noticed· Medium risk

  • Large base64-encoded blobs

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Jetson Team
Publisher
NVIDIA (Official)
Distributed by
NVIDIA
Source
NVIDIA/skills · skills/jetson-init-image · commit fce3cca
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE-APACHE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Jetson Team or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download jetson-init-image.zip