SkillAgentSearch skills...

jetson-derive-carrier

Bootstrap a custom carrier board by forking carrier files and scaffolding a DT overlay from the reference devkit. Use after jetson-init-source; not for module-level or kernel-DTB changes.

Install / Use

npx skills add NVIDIA/skills --skill jetson-derive-carrier

Installs into whichever agent you are using.

About this skill
📄

SKILL.md

Installable skill definition

Quality Score

93/100

Category

Legal

Supported Platforms

Universal

Tags

Our assessment of jetson-derive-carrier

jetson-derive-carrier scores 93/100 on our quality scale, 24th of 123 Legal skills we index (top 20%).

Its SKILL.md is 16 KB long, well organised into 10 sections with 2 code examples: a thorough specification that gives an agent plenty to work with.

With 3,421 GitHub stars, it is one of the more widely adopted skills in the catalogue.

Substance
30/30
Structure
18/20
Description
15/15
Adoption
15/20
Freshness
15/15

Maintenance, license and trust

  • The repository was last updated 5 days ago, so jetson-derive-carrier is actively maintained.
  • It is released under the Apache-2.0 license, a permissive license that allows use, modification and commercial use with attribution.
  • Its trust signals score 100/100, with no cautions. These come from repository metadata, not a code audit — read the skill file before letting an agent act on it.

jetson-derive-carrier compared with similar skills

All 4 of these similar skills score higher than jetson-derive-carrier; compare them before choosing.

SkillScoreStarsUpdatedFormat
jetson-derive-carrier (this skill)by NVIDIA933.4k5d agoSKILL.md
algorithmic-artby anthropics100177.9k6d agoSKILL.md
pptxby anthropics100177.9k6d agoSKILL.md
designby nextlevelbuilder100130.2k7d agoSKILL.md
ui-ux-pro-maxby nextlevelbuilder100130.2k7d agoSKILL.md

Frequently asked questions

How do I install jetson-derive-carrier?
Run npx skills add NVIDIA/skills --skill jetson-derive-carrier. The install tabs above show the steps for each supported agent.
Which AI agents does jetson-derive-carrier work with?
It is written for Universal, as a SKILL.md file. Other agents that read the same format can often use it too.
Is jetson-derive-carrier safe to use?
It is Apache-2.0-licensed and scores 100/100 on trust signals. Skills are instructions an agent will follow, so read the file before installing it and do not approve commands you do not understand.
Is jetson-derive-carrier still maintained?
The repository was last updated 5 days ago, so jetson-derive-carrier is actively maintained.

name: jetson-derive-carrier description: >- Bootstrap a custom carrier board by forking carrier files and scaffolding a DT overlay from the reference devkit. Use after jetson-init-source; not for module-level or kernel-DTB changes. version: 0.0.1 license: "Apache-2.0" metadata: data-classification: public author: "Jetson Team" tags: - target-platform - custom-carrier - bring-up - setup domain: meta

jetson-derive-carrier

Customize first-run gate for any customize-* skill on a custom carrier. Resolve the active target per target-platform-contract.md. Refuse if no custom_carrier: block, or if <source.root_path>/Linux_for_Tegra/.git is missing (jetson-init-source first). Template file create/copy rows land in a single overlay-tracker commit and copy directly to the custom-carrier-renamed target path — reference-named pristine files are never staged (see Fork plan for the local rule, which overrides the standard pristine + customization split from the workflow); conf-chain discovery follows per-board conf dispatch. Kernel base DTB is not forked — carrier deltas layer as a DT overlay wired via OVERLAY_DTB_FILE.

Identifiers (from active profile): <chip> from reference_devkit.module.id via catalogue (unknown → warn, fallback tegra234); <module-id>/<module-sku> from reference_devkit.module; <carrier-id>/<carrier-sku> from reference_devkit.carrier; <custom-id>/<custom-sku>/ <custom-flash-conf> from custom_carrier. <real-conf> = readlink <bsp_image.root_path>/Linux_for_Tegra/<reference_devkit.flash_config> (NVIDIA convention <devkit>.conf → <carrier>-<module>-a<rev>.conf; warn + treat top-level as real + skip symlink-wrapper row if not a symlink).

<custom-id> is a custom carrier board token, not necessarily an NVIDIA-style pNNNN ID. Use it verbatim in dash-form filenames and DT compatible strings. When a target file family uses p-stripped numeric tokens, derive <custom-id-file-token> as NNNN only if <custom-id> matches ^p[0-9]{4}$; otherwise use <custom-id> unchanged. Do not reject custom carrier IDs merely because they do not start with p.

Instructions

The fork plan below is the instruction set: one discovery pass, then a row-by-row fork of the per-board fileset, gated by the commit-message preview before each git commit.

Fork plan

Every git commit produced by this skill — in the overlay tracker (Linux_for_Tegra/) or the hardware/ source repo — runs through the commit message preview gate. Surface the staged file list + proposed message to the operator and require accept / edit / cancel before each git commit; on cancel leave the index staged for manual resolution.

Materialize renamed forks even when bytes do not change. For every accepted fork-plan row, create and track the custom-carrier target path; do not skip a missing target because the fork is only a rename/copy or is byte-identical to the reference. This includes BCT forks such as pinmux, GPIO/GPIOINT, padvoltage/PMC, misc, and MB2 misc. Skip only when the Acceptance column allows it, the source is an explicit warn-and-skip miss, or the expected target path is already tracked; in the last case, report it as already derived and do not create an empty commit.

Template file create/copy rows squash into one overlay-tracker commit, and reference-named pristine files are never staged. All rows that materialize a new (template-derived) file in the overlay tracker — board flash-conf, flash-conf symlink, MB1 BCT (pinmux, GPIO/GPIOINT, padvoltage/PMC, misc), MB2 BCT (misc), BPMP DTB (when opted in), nvpmodel, nvfancontrol — copy directly from <bsp_image.root_path>/Linux_for_Tegra/<rel>/<reference-name> to <source.root_path>/Linux_for_Tegra/<rel>/<custom-name> with any content edits applied before staging. The reference-named (<carrier-id>-<carrier-sku>-keyed) filename is never staged or committed in the overlay tracker — only the custom-carrier-renamed file is tracked. This overrides the standard pristine + customization split from commit batching. All such rows land in a single overlay-tracker commit that adds: (i) the custom-carrier-named files at their target paths with content already applied, (ii) the flash-conf symlink, and (iii) the targeted flash-conf content rewrites inside the renamed flash-conf for PINMUX_CONFIG / GPIO_CONFIG / GPIOINT_CONFIG / PMC_CONFIG / MISC_CONFIG / MB2_BCT (plus BPFDTB_FILE when BPMP DTB is opted in). Rows that edit existing upstream files instead of creating templates — the nvpower.sh patch — and the overlay wire-up (OVERLAY_DTB_FILE+= append to the just-created flash-conf fork, treated as a temporally distinct phase per commit batching) remain separate commits per their own rows. The DT overlay skeleton commits in bsp_sources/hardware/, not the overlay tracker, so it is unaffected. The commit message preview gate fires once on the squashed commit; warn-and-skipped rows do not contribute, and if every row in the bundle is already tracked the commit is omitted entirely.

Discovery (single batched pass)

Run one discovery pass; do not interleave with staging. Do not truncate listings — every candidate filename in each scanned directory must be visible to the matcher. head, tail, | head -N, | tail -N, and any other row-limiting filter are out of bounds for this step; use ls -1 / find unclipped, or grep on the full output. Truncating risks false warn-and-skip calls when the matching file sits past the cutoff. Capture:

  • Flash-conf vars: DTB_FILE / TBCDTB_FILE / BPFDTB_FILE / PINMUX_CONFIG / PMC_CONFIG / GPIO_CONFIG / GPIOINT_CONFIG. DTB_FILE / TBCDTB_FILE are captured for reference only so the overlay wire-up can derive <dtb-stem> for the overlay filename — they are never rewritten by this skill.
  • BCT .dts at bootloader/generic/BCT/; .dtsi siblings live one level up at bootloader/ — NOT alongside.
  • nvpmodel: nvpmodel_<module-id>_<module-sku>*.conf. nvfancontrol: nvfancontrol_<module-id>_<module-sku>_<carrier-id>_<carrier-sku>.conf.
  • nvpower.sh anchors for (a)–(d): <carrier-id> cvb branch, <module-id>-<module-sku> SKU elif, tegra<chip> nvpmodel cascade, tegra<chip> nvfancontrol cascade.

| File / category | Discovery | Acceptance | Fork rule | |---|---|---|---| | Board flash conf | <real-conf> | Always | Filename sub <carrier-id>-<carrier-sku> → <custom-id>-<custom-sku>. Content sub is targeted, not blanket: rewrite RHS only for vars whose file this skill forks — PINMUX_CONFIG, PMC_CONFIG, GPIO_CONFIG / GPIOINT_CONFIG, MISC_CONFIG, MB2_BCT. Other carrier-keyed vars (DTB_FILE, TBCDTB_FILE, SCR_CONFIG, PMIC_CONFIG, DEVICEPROD_CONFIG, PROD_CONFIG, MINRATCHET_CONFIG, UPHY_CONFIG, dynamic OVERLAY_DTB_FILE+=) MUST stay at reference values — their files aren't forked here and a blanket sed would point them at nonexistent files. DTB_FILE / TBCDTB_FILE specifically: base DTB is not forked; the overlay row appends a new OVERLAY_DTB_FILE+= line instead. BPFDTB_FILE: opt-in extra commit. Never touch <chip>, <module-id>, xxxx. | | Flash-conf symlink | Unconditional | Always (skip if <real-conf> not a symlink) | New symlink <custom-flash-conf> → flash-conf fork | | MB1 BCT pinmux | PINMUX_CONFIG + #include follow ¶ | Always | Rename rule † | | MB1 BCT GPIO | GPIO_CONFIG/GPIOINT_CONFIG + #include follow ¶ | Always | Rename rule † | | MB1 BCT padvoltage | PMC_CONFIG + #include follow ¶ | Always | Rename rule † | | MB1 BCT misc | MISC_CONFIG + #include follow ¶ | Always | Rename rule † | | MB2 BCT misc | MB2_BCT + #include follow ¶ | Always | Rename rule † | | Kernel DTB + source DTS | (reference only — see header) | Never forked | Base DTB stays at reference. No pristine binary copy in the overlay tracker; no source DTS fork in bsp_sources/hardware/. Carrier deltas live entirely in the DT overlay (next row). | | DT overlay skeleton (NEW) | Unconditional | Always | Create <source.root_path>/hardware/nvidia/<chip>/nv-public/overlay/<chip>-<custom-id>-<custom-sku>+<module-id>-<module-sku>.dts (skeleton ‡); commit in hardware/, push to origin | | Per-dir Makefile registration | <source.root_path>/bsp_sources/hardware/nvidia/<chip>/nv-public/overlay/Makefile | Always | Append dtbo-y += <chip>-<custom-id>-<custom-sku>+<module-id>-<module-sku>.dtbo after the last literal-named dtbo-y += entry (BEFORE the $(addprefix $(makefile-path)/,$(dtbo-y)) prefix block — inserting after dtbo-y += $(old-dtbo) silently drops the .dtbo). Same position-sensitive idiom and snippet as the composite slot's Makefile patch in ../jetson-build-source/references/composite-registration.md#makefile-patch-idempotent-position-sensitive. Commit in hardware/. Without this row, nvidia-dtbs never produces the .dtbo referenced by the next row's OVERLAY_DTB_FILE+= line and flash.sh aborts mid-flash on the missing file. | | Overlay wire-up | Unconditional | Always | Append OVERLAY_DTB_FILE+=",<chip>-<custom-id>-<custom-sku>+<module-id>-<module-sku>.dtbo" to flash-conf fork (extra commit) | | nvpmodel config | rootfs/etc/nvpmodel/nvpmodel_<module-id-num>_<module-sku>.conf | Always | Filename: append _<custom-id-file-token>_<custom-sku> | | nvfancontrol config | rootfs/etc/nvpower/nvfancontrol/nvfancontrol_<module-id-num>_<module-sku>_<carrier-id-num>_<carrier-sku>.conf | Always | Filename: substitute carrier portion (append _<custom-id-file-token>_<custom-sku> if source is module-keyed only) | | nvpower.sh patch | rootfs/etc/systemd/nvpower.sh | Always | Pristine + single customization commit with 4 insertions: (a) cvb cascade elif [[ "${machine}" =~ "<custom-id>" ]]; then cvb="<custom-id-file-token>" before reference; (b) inside module-SKU branch set machine="<module-id>-<module-sku>-<custom-id>-<custom-sku>"; (c) nvpmodel cascade branch for composite machine key → conf_file= nvpmodel fork; (d) cvb-keyed nvfancontrol cascade branch → conf_file= nvfancontrol fork | | BPMP DTB | prebuilt at bootloader/generic/<BPFDTB_FILE> (alt naming: no p prefix, xxxx SKU) | Opt-in y/N, default N — module-level, usually shared with reference | Fork binary: pristine + filename sub -<carrier-id-num>- → -<custom-id-file-token>- (content unchanged). Extra commit on flash-conf fork rewriting BPFDTB_FILE to the renamed binary. |

#include follow. Scan each captured .dts for #include "..." directives anywhere in the file (NVIDIA BSPs put them inside BCT node bodies); carrier-keyed includes join the fork list. Stop at one level.

† Rename rule. Carrier-keyed source (e.g. …-p3834-xxxx-p4071-0000.dts) → filename sub <carrier-id>-<carrier-sku> → <custom-id>-<custom-sku>; rewrite the flash-conf variable (e.g. PINMUX_CONFIG) to the renamed filename in the same customization commit. Module portion is preserved verbatim from pristine — if pristine has p3834-xxxx, fork keeps p3834-xxxx; if pristine has p3834-0008, fork keeps p3834-0008. Never pin module-SKU on your own. Same rule for any other xxxx wildcard in the carrier-SKU position when pristine uses it (e.g. p4071-xxxx → `p12

Truncated for display — read the full file on GitHub.

Related Skills

View on GitHub
GitHub Stars3.4k
CategoryLegal
Updated5d ago
Forks412

Languages

Python

Trust signals

100/100

From repository metadata: license, adoption, age and documentation. Not a code audit — see the Safety scan above for what the skill file itself contains.

No cautions