jetson-build-source
>-
Works with
0
total installs
0
this week
1.7K
GitHub stars
0
upvotes
Install Skill
Run in your terminal
0
installs
0
this week
1.7K
stars
Installation Guide
How to use jetson-build-source on Cursor
AI-first code editor with Composer
Prerequisites
Before installing skills in Cursor, ensure your development environment meets these requirements:
- ›Cursor installed and configured on your machine
- ›Node.js 16+ with npm — verify with
node --version - ›Active project directory where you want to add
jetson-build-source
Run the install command
Execute the skills CLI command in your project's root directory to begin installation:
Fetches jetson-build-source from nvidia/skills and configures it for Cursor.
Select Cursor when prompted
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Verify installation
Confirm successful installation by checking the skill directory location:
Restart Cursor to activate jetson-build-source. Access via /jetson-build-source in your agent's command palette.
Security Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Documentation
| name | jetson-build-source |
| description | >- Use when you need to rebuild the BSP overlay — DT, OOT modules, or kernel — from changes under bsp_sources/. Triggers: build bsp, rebuild dtb, rebuild kernel. |
| version | 0.0.1 |
| license | "Apache-2.0" |
| argument-hint | "dt | oot | kernel | full" |
| metadata | data-classification: public author: "Jetson Team" team: pts tags: - bsp - build domain: meta |
Build BSP Source
Purpose
Rebuild the kernel-side artifacts (DTBs, OOT modules, in-tree
modules, kernel Image) implied by changes under
<source.root_path>/bsp_sources/, and write a manifest that
/jetson-promote-image reads to stage those outputs into the BSP
image. The skill never writes into <bsp_image.root_path> itself.
Prerequisites
- Active target-platform profile with
bsp_image:andsource.toolchain:resolved (run/jetson-init-imageand/jetson-init-sourcefirst). <source.root_path>/bsp_sources/populated with the kernel-side checkout layout/jetson-init-sourcematerializes.<bsp_image.root_path>/Linux_for_Tegra/source/kernel_src_build_env.shpresent (extracted frompublic_sources.tbz2).- Host packages:
flex,bison,libssl-dev(hard);git,build-essential,bc,zstd(warn-only). - Cross-toolchain at
${source.toolchain}gccresolvable on disk.
Overview
This skill is the Build stage of the workflow — see
../../context/bsp-customization-workflow.md
for where it sits in the Setup → Customize → Build → Deploy pipeline
and what triggers it. The skill takes source-side customization
commits, rebuilds the implied artifacts, and records which were
rebuilt in a manifest. Outputs stay in-tree under
<source.root_path>/bsp_sources/;
jetson-promote-image reads the
manifest at Deploy to copy each rebuilt artifact into the matching
path under <bsp_image.root_path>/Linux_for_Tegra/.
Overlay-only edits (nvpmodel.conf, nvfancontrol.conf, BPMP DTB)
skip Build — customize-* stages them directly to the overlay
tracker; BPMP DTB uses the dtc decompile → edit → recompile loop in
../../references/bsp-customization-bpmp-dtb.md.
Custom-overlay slot ownership. Kernel-DT customizations from
every customize-* skill collect into a single composite
tegra<soc>-<carrier-id-sku>+<module-id>-xxxx-custom.dts per
active target — see
../../references/bsp-customization-kernel-dtb.md
for the filename / location / append protocol. This skill is the
sole owner of the composite's per-dir Makefile registration
(dtbo-y += <name>.dtbo) and the carrier flash conf's
OVERLAY_DTB_FILE+= line (the "Register composite custom overlay" step).
Four build modes matched to the dirty-repo profile:
| Mode | What's built | Auto-picks when |
|---|---|---|
| dt | NVIDIA DTBs only | only hardware/nvidia/* or kernel-devicetree dirty |
| oot | OOT modules (six repos) | only OOT repos dirty |
| kernel | Kernel Image + full in-tree .ko set + kernel-side dtbs | only kernel/$KERNEL_SRC_DIR dirty |
| full | Everything above + optional install consolidation | mixed dirty set |
Mode selection: auto (default — invoke /jetson-build-source
with no argument) walks the dirty-repo set; force a specific mode
by passing it as the skill argument.
Design principle: delegate to upstream. Every build primitive
already exists in <bsp_image.root_path>/Linux_for_Tegra/source/
— the env file, top-level Makefile (nvidia-dtbs / modules /
modules_install), kernel Makefile (kernel / install). The
skill drives those primitives against
<source.root_path>/bsp_sources/ — never duplicates their
logic in shell.
When to invoke
- Auto-chained at the end of a Customize
customize-*invocation whenever Customize committed to a kernel-side source repo. - Manual re-run via
/jetson-build-source [<mode>]when:- the auto-chained build was interrupted,
- source commits arrived via
git pullfrom other users, - the user wants to force a rebuild without a fresh edit,
- the user wants a specific mode (e.g. install consolidation for a manual scp deploy to a DUT).
Instructions
Resolve active target + paths + upstream env
Resolve the active profile per
../../context/target-platform-contract.md.
Refuse and route in these cases:
| Condition | Route to |
|---|---|
No active profile, or active: NA | /jetson-set-target or /jetson-init-target |
Profile lacks bsp_image: | /jetson-init-image |
Profile lacks source.toolchain: | /jetson-init-source |
<source.root_path>/bsp_sources/ missing or empty | /jetson-init-source |
<bsp_image.root_path>/Linux_for_Tegra/source/kernel_src_build_env.sh missing | /jetson-init-image (BSP not properly extracted) |
Bind:
WORKSPACE=<parent of target-platform/>
BSP_SRC=<bsp_image.root_path>/Linux_for_Tegra/source # NVIDIA's build primitives
KS=<source.root_path>/bsp_sources # our kernel-side checkout
KOUT=<source.root_path>/.build/kernel-out # DT-mode out-of-tree build dir
STAGE=<source.root_path>/.build/install-stage # install consolidation (full mode / opt-in)
STATE=<source.root_path>/.build-state.yaml # per-repo watermark
MANIFEST=<source.root_path>/.build-manifest.yaml # rebuilt-artifact list for jetson-promote-image
Source the NVIDIA build env to inherit canonical names — never
hardcode kernel-noble, the OOT module list, or KERNEL_DEF_CONFIG:
source "$BSP_SRC/kernel_src_build_env.sh"
# Now in scope: KERNEL_SRC_DIR (e.g. kernel-noble), KERNEL_DEF_CONFIG,
# OOT_SOURCE_LIST, kernel_name (e.g. noble), KERNEL_MODULAR_BUILD
Refuse if $KS/kernel/$KERNEL_SRC_DIR/ is missing or if any name
in $OOT_SOURCE_LIST is missing under $KS/. Route to
/jetson-init-source.
Resolve toolchain (read-only)
Read source.toolchain from the active profile (authored by
jetson-init-source). Validate:
export ARCH=arm64
export CROSS_COMPILE=<source.toolchain> # trailing dash mandatory
[ -f "${CROSS_COMPILE}gcc" ] || refuse \
"source.toolchain points at ${CROSS_COMPILE}gcc which does not exist. Re-run /jetson-init-source."
A trailing dash on CROSS_COMPILE is mandatory — kbuild treats it
as a prefix (${CROSS_COMPILE}gcc); a missing dash breaks with
command not found. The [ -f ] check catches it before any
make runs.
This skill never prompts for the toolchain or attempts to
resolve a missing one — that's jetson-init-source's exclusive
responsibility. A missing field is a Setup gap; route there.
Verify build-host prerequisites once:
for p in flex bison libssl-dev; do
dpkg -s "$p" >/dev/null 2>&1 || refuse "host package missing: $p"
done
for p in git build-essential bc zstd; do
dpkg -s "$p" >/dev/null 2>&1 || warn "host package missing: $p"
done
Detect dirty source repos
The watermark file $STATE records the last successfully built
commit per kernel-side repo. The repo list is derived at runtime
from OOT_SOURCE_LIST + kernel/$KERNEL_SRC_DIR. For each repo:
HEAD ≠ watermark → dirty; uncommitted edits (git diff --quiet
non-zero) → also dirty.
Branch-A note: when bsp_sources/ is one mono-repo with a
single .git, every canonical sub-path shares the same HEAD —
the watermark schema still keys per-sub-path and the dirty set
still works (any change anywhere flips every sub-path's HEAD).
If STATE is absent (first build), treat all repos as clean
unless the auto-chain context says "Customize just committed". If
DIRTY is empty and no mode argument was passed: report
"nothing to build" and return.
Pick build mode
Map the dirty set to a mode (auto), or honor the mode argument:
| Dirty repos (auto) | Mode |
|---|---|
Only hardware/nvidia/* or kernel-devicetree | dt |
Only OOT subset of $OOT_SOURCE_LIST | oot |
Only kernel/$KERNEL_SRC_DIR | kernel |
| Any mix spanning the above | full |
Modes are union-able: full runs kernel → oot → dt in that
order (kernel produces headers OOT needs; nvidia-dtbs uses the
same generated headers). A manually passed mode argument skips
auto-detection.
Execute build
Common setup + per-mode build snippets
Common setup (validate orchestrator Makefiles, cd $KS) and the
exact make invocations for each mode (dt, oot, kernel,
full) plus the optional install consolidation pass live in
references/build-modes.md. Drive
the relevant mode's snippet against the bindings from the
"Resolve active target + paths + upstream env" step.
Register composite custom overlay (dt + full only)
Skip unless the selected mode is dt or full. The composite
overlay slot is documented in
../../references/bsp-customization-kernel-dtb.md;
this sub-step owns the build / Makefile / flash-conf side of it.
Resolve the composite path for the active target ($COMPOSITE_BASE,
$COMPOSITE_DTS, $COMPOSITE_MK) using the active profile's
chip family, carrier ID/SKU, and module ID — full snippet in
references/composite-registration.md.
Gate (symmetric). $COMPOSITE_DTS drives both directions:
present → apply the two idempotent patches below; absent → run the
cleanup pass
to strip any stale dtbo-y += / OVERLAY_DTB_FILE+= line from a
prior run. Either path keeps OVERLAY_DTB_FILE+= from referencing
an unbuilt .dtbo — the build-time enforcement of the
no-direct-in-tree-DT-edits rule.
- Per-dir Makefile — append
dtbo-y += <name>.dtboafter the last literal-nameddtbo-y +=entry. Inserting after the$(old-dtbo)merge-back line skips the$(addprefix makefile-path/,…)prefix pass and the build silently drops the composite. Commit to thebsp_sources/mono-repo. Full snippet + rationale:references/composite-registration.md. - Carrier flash conf — append
OVERLAY_DTB_FILE+=",<name>.dtbo"with first-touch pristine import on the overlay tracker. On a fresh workspace the tracker is empty git-init; import the conf frombsp_imageand commit aspristine:before the customization commit (workflow contract). Full snippet:references/composite-registration.md.
The composite's parent sub-repo flipping HEAD during a customize-* append is what the "Detect dirty source repos" step's dirty detection consumes — no extra bookkeeping needed here.
Self-check before invoking nvidia-dtbs:
grep -qxF "dtbo-y += ${COMPOSITE_BASE}.dtbo" "$COMPOSITE_MK" \
|| refuse "Composite Makefile registration missing after patch."
grep -qxF "$line" "$FLASH_CONF" \
|| refuse "Composite flash-conf registration missing after patch."
Write the build manifest
Walk the DIRTY set and emit a manifest entry per implied artifact,
following the trace-to-dirty policy — only artifacts traceable
to a dirty source repo. Promoting baseline-divergence noise would
attribute it to a customization's audit trail (forbidden).
The full source → kbuild → destination mapping, YAML schema, and
filter rules live in
references/manifest-schema.md.
Atomic write: stage to ${MANIFEST}.tmp, then mv -f.
Update watermark + summary
On success, rewrite $STATE with the new per-repo HEADs, toolchain,
bsp_image.version, and last-run mode (schema in
references/manifest-schema.md).
Report:
- Toolchain (from
source.toolchain). - Build mode:
<dt|oot|kernel|full>(auto-picked or forced by skill argument). - Dirty repos and their new HEADs.
- Artifacts built: counts per kind (
.dtb, in-tree.ko, OOT.ko,Image). - Manifest path + entry count.
- Consolidated install stage path (if the "Install consolidation" step ran).
- Next step:
/jetson-promote-image.
If a Customize skill triggered this run, prompt the user to re-issue their original request.
Limitations
The top tier — failure modes that block a build or silently
produce wrong artifacts. See
references/long-tail-gotchas.md
for invariants, deploy patterns, and performance hints.
- Toolchain resolution is
jetson-init-source's job. This skill only readssource.toolchainand exportsCROSS_COMPILE. Missing field → refuse and route, never resolve in-skill. - R36.x Branch-A
$KS/Makefilecollision. R36.x'spublic_sources.tbz2can leave the dGPU/OpenRM proprietary Makefile at$KS/Makefileinstead of the Tegra orchestrator; itsmodulestarget recurses intokernel-open/+src/nvidia/, pulls host/lib/modulesheaders, and breaks arm64 cross-builds with'-mlittle-endian' unrecognized. R38+ extractions are unaffected./jetson-init-source's step 3a is the primary defense (extract-time); the "Common setup" check here is the safety net. Don't relax the regex. - Kernel-DT changes: composite-overlay-only, split ownership.
Direct edits to in-tree
.dts/.dtsifiles underbsp_sources/are forbidden for customize-* skills — every kernel-DT change lands as a fragment in the composite overlay slot (rule + rationale). The composite.dtscontent is owned by each customize-* skill; the build / Makefile / flash-conf registration is owned by this skill (gated on the composite.dtsexisting — soOVERLAY_DTB_FILE+=can't reference an unbuilt.dtbo). - the "Register composite custom overlay" step Makefile insertion point matters. Insert after
the last literal-named
dtbo-y +=entry; inserting after$(old-dtbo)skips the$(addprefix makefile-path/,…)prefix pass and the build silently drops your.dtbo. The regex^dtbo-y *+= *[a-zA-Z0-9]filters correctly; do not relax it. - the "Register composite custom overlay" step first-touch needs pristine import. On a fresh
workspace the overlay tracker is empty git-init — the carrier
flash conf is imported from
bsp_imageand committed aspristine:before the customization commit. Both commits go through the workflow acceptance gate. - Avoid bare
$0in shell snippets inside this SKILL.md. When invoked with an argument, the harness expands skill-body$0against the caller's$0before handing the rendered prompt to the model. Use sed-based line splicing orawk -v ROW="$0". Seereferences/composite-registration.md. - No overlay staging. Build outputs stay where the build put
them; the manifest is the contract to
jetson-promote-image. Deliberate divergence from the original overlay→promote indirection — keeps the full build output set out of the overlay tracker's git history. KERNEL_HEADERSvsKERNEL_OUTPUTin DT mode. Different semantics (srctree vs objtree); do not collapse. the "DT-only" step's snippet is correct as written.- OOT mode prereq: previously-built kernel headers. A manual
ootinvocation against a never-built tree refuses with "runkernel(orfull) first" rather than producing a confusing build error.
Examples
Auto-detect mode from the dirty source tree (typical invocation):
/jetson-build-source
Force a single mode (skips auto-detect):
/jetson-build-source dt # rebuild NVIDIA DTBs only
/jetson-build-source oot # rebuild OOT modules only
/jetson-build-source kernel # rebuild kernel Image + in-tree modules
/jetson-build-source full # rebuild everything + install consolidation
Typical chain after a customize-* skill commits to a kernel-side repo (the customize-* skill calls this automatically):
/jetson-customize-pcie ... # commits to hardware/nvidia/.../nv-public
↓
/jetson-build-source # auto-picks `dt` from the dirty set
↓
/jetson-promote-image # reads .build-manifest.yaml, stages into bsp_image
↓
/jetson-flash-image # flashes
Troubleshooting
| Error | Cause | Solution |
|---|---|---|
source.toolchain points at <...>gcc which does not exist | Toolchain field stale (path moved, install missing) | Re-run /jetson-init-source to re-resolve. This skill never resolves toolchain itself. |
No rule to make target '$KOUT/scripts/Makefile.compiler' | KERNEL_HEADERS set to $KOUT instead of $KS/kernel/$KERNEL_SRC_DIR | Use the DT-mode snippet in references/build-modes.md verbatim — srctree vs objtree must not collapse. |
'-mlittle-endian' unrecognized during make modules | R36.x Branch-A $KS/Makefile collision — dGPU/OpenRM Makefile in place of Tegra orchestrator | The Common-setup safety net normally repairs it; if not, git checkout HEAD -- Makefile then re-run /jetson-init-source step 3a. |
run kernel (or full) first on manual oot invocation | Kernel source tree never prepared | Run /jetson-build-source kernel (or full) once, then oot. |
nothing to build and dirty edits exist | Edits uncommitted in a sub-repo but .build-state.yaml watermark already matches HEAD | Commit the edits, or re-run with an explicit mode argument (/jetson-build-source dt etc.). |
Composite .dtbo silently missing from the output set | Per-dir Makefile insertion landed after $(old-dtbo) merge-back line | See references/composite-registration.md — insert after the last literal-named dtbo-y += entry. |
| Promote step copies stale baseline artifacts | Trace-to-dirty filter skipped after a manual cp into $KS | Only edit via a customize-* skill or git; the dirty detector keys on git HEAD, not file mtime. |
host package missing: <pkg> | flex/bison/libssl-dev refuse; others warn. | sudo apt install <pkg> per references/upstream-recipe.md. |
See also
references/build-modes.md— per-modemakesnippets + install consolidation.references/manifest-schema.md—.build-manifest.yaml+.build-state.yamlschemas.references/composite-registration.md— the "Register composite custom overlay" step full snippets + rationale.references/long-tail-gotchas.md— invariants, deploy patterns, performance hints.references/upstream-recipe.md— verbatim NVIDIA recipe, divergences, spec status.../../context/bsp-customization-workflow.md— workspace edit protocol.../../references/bsp-customization-kernel-dtb.md— composite custom-overlay contract.../../references/bsp-customization-bpmp-dtb.md— BPMP-DTB edit contract (routed around this skill).../jetson-init-source/SKILL.md— Setup; authorssource.toolchain.../jetson-promote-image/SKILL.md— Deploy promoter; reads this skill's manifest.
List & Monetize Your Skill
Submit your Claude Code skill and start earning
Use Cases
Task Automation & Efficiency
Automate repetitive workflows and reduce manual effort
Example
Generate reports, summarize documents, draft communications
Save 3-5 hours per week on routine tasks
Knowledge Enhancement
Learn new skills, understand complex topics, get expert guidance
Example
Explain concepts, provide examples, suggest learning resources
Accelerate learning and skill development by 2x
Quality Improvement
Enhance output quality through reviews, suggestions, and refinements
Example
Review drafts, suggest improvements, catch errors
Improve work quality by 30-40% with less effort
Implementation Guide
Prerequisites
- ›Claude Desktop or compatible AI client with skill support
- ›Clear understanding of task or problem to solve
- ›Willingness to iterate and refine outputs
Time Estimate
15-45 minutes depending on use case complexity
Steps
- 1Install skill using provided installation command
- 2Test with simple use case relevant to your work
- 3Evaluate output quality and relevance
- 4Iterate on prompts to improve results
- 5Integrate into regular workflow if valuable
Common Pitfalls
- ⚠Expecting perfect results without iteration
- ⚠Not providing enough context in prompts
- ⚠Using skill for tasks outside its intended scope
- ⚠Accepting outputs without review and validation
Best Practices
✓ Do
- +Start with clear, specific prompts
- +Provide relevant context and constraints
- +Review and refine all outputs before using
- +Iterate to improve output quality
- +Document successful prompt patterns
✗ Don't
- −Don't use without understanding skill limitations
- −Don't skip validation of outputs
- −Don't share sensitive information in prompts
- −Don't expect skill to replace human judgment
💡 Pro Tips
- ★Be specific about desired format and style
- ★Ask for multiple options to choose from
- ★Request explanations to understand reasoning
- ★Combine AI efficiency with human expertise
When to Use This
✓ Use when
Use when skill capabilities match your task, clear ROI on time saved, and you can validate outputs. Best for repetitive tasks, learning, and quality improvement.
✗ Avoid when
Avoid when task requires deep expertise you can't validate, involves sensitive decisions, or when learning process is more valuable than speed of completion.
Learning Path
- 1Familiarize yourself with skill capabilities and limitations
- 2Start with low-risk, non-critical tasks
- 3Progress to more complex and valuable use cases
- 4Build expertise through regular use and experimentation
Related Skills
Reviews
- CCamila Jackson★★★★★Dec 24, 2024
Useful defaults in jetson-build-source — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
- CCarlos Li★★★★★Dec 20, 2024
I recommend jetson-build-source for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
- AArjun Ghosh★★★★★Nov 15, 2024
jetson-build-source has been reliable in day-to-day use. Documentation quality is above average for community skills.
- WWilliam Mensah★★★★★Nov 11, 2024
jetson-build-source fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
- AAnika Torres★★★★★Oct 6, 2024
Keeps context tight: jetson-build-source is the kind of skill you can hand to a new teammate without a long onboarding doc.
- RRen Gupta★★★★★Oct 2, 2024
Registry listing for jetson-build-source matched our evaluation — installs cleanly and behaves as described in the markdown.
- RRahul Santra★★★★★Sep 25, 2024
jetson-build-source fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
- NNoor Haddad★★★★★Sep 17, 2024
I recommend jetson-build-source for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
- SSakura Li★★★★★Sep 9, 2024
We added jetson-build-source from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
- SSakura Thomas★★★★★Aug 28, 2024
Solid pick for teams standardizing on skills: jetson-build-source is focused, and the summary matches what you get after install.
showing 1-10 of 40
Discussion
Comments — not star reviews- No comments yet — start the thread.