Jetson Init Image
NVIDIAOfficialCreated by Jetson TeamDistributed by NVIDIA
- Skill
- Workflow
- Cloud and DevOps
- Apache-2.0
- Medium risk
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
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/nvidia/jetson-init-image/downloadUnzip 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 state | Action |
|---|---|
bsp_image.root_path exists | Use it without prompting. |
bsp_image: exists without root_path | Use <workspace>/Image. |
No bsp_image: block | Ask 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 family | Module IDs | Stack | apply_binaries.sh flag |
|---|---|---|---|
| T234 / Orin | p3701, p3767 | nvgpu | none |
| T264 and later / Thor+ | p3834 | OpenRM | --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:
Do not extract over it unless the user explicitly requested re-extraction and accepted the overwrite risk.
Derive the on-disk version from
Linux_for_Tegra/nv_tegra_release. Ask before replacing a different recordedbsp_image.version.Verify the installed GPU stack against the platform-derived expectation when possible. Detection precedence (first probe that yields a definitive answer wins):
Linux_for_Tegra/rootfs/etc/nv_tegra_releasecarries anINSTALL_TYPE=token on BSP releases that expose it (newer lines). Read and compare directly.Otherwise,
find Linux_for_Tegra -name nvgpu.ko: present → nvgpu, absent → OpenRM.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:
<bsp_image.root_path>/<workspace>/current working directory
Prompt for absolute paths for anything missing. Required filenames:
Jetson_Linux_R<ver>_aarch64.tbz2Tegra_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
fiSet 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-bspor hand-placed).Write access to the workspace
Image/root (or the overridebsp_image.root_path).sudoavailable forapply_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-bspor hand-stage the inputs.
Troubleshooting
apply_binaries.shexits non-zero — re-read its console output; most failures are missingsudo, missing rootfs tarball, or wrong GPU stack flag for the SoC generation.nv_tegra_releaseabsent after extract — extraction stopped early; verify tarball integrity and rerun.Recorded
versiondisagrees with the tarball filename — the tarball was renamed; trust the value parsed fromLinux_for_Tegra/nv_tegra_releaseover filenames.Different recorded
root_pathalready 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
- ATTRIBUTION.mdAdded by AutoGineer914 B
- BENCHMARK.md3.7 KiB
- LICENSELicence file added by AutoGineer11.2 KiB
- SKILL.md7.1 KiB
- evals/evals.json3.9 KiB
- skill-card.md4.0 KiB
- skill.oms.sig4.5 KiB
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