
Jetson Pinmux Customizer
OfficialFreeEfficiently configure pinmux settings for Jetson carriers.
Free · Opens the source repo
What Jetson Pinmux Customizer does
The Jetson Pinmux Customizer skill is designed for developers working with NVIDIA's Jetson Orin or Thor custom carriers. It allows users to configure per-pin settings such as SFIO, direction, and initial state directly from the pinmux XLSM spreadsheet. This skill is particularly useful for developers who need to manage pin configurations in a structured and efficient manner, ensuring that the settings align with the requirements of their custom hardware designs.
This skill operates by parsing the provided pinmux XLSM file, which serves as the authoritative source for all pin configurations. It initiates an interactive loop that guides users through the configuration process for each pin, allowing for precise adjustments to be made. The output consists of three Device Tree Source Include (DTSI) files—pinmux, gpio, and padvoltage—that are generated in one go and placed in the appropriate directory for bootloader integration. This streamlines the process of preparing the custom carrier for deployment.
The Jetson Pinmux Customizer is especially valuable for users who have already derived a custom carrier using the /jetson-derive-carrier command and need to finalize their pin configurations. By leveraging this skill, developers can avoid common pitfalls associated with manual edits and ensure that their configurations are consistent with the underlying hardware capabilities. The skill also includes a robust procedure for validating prerequisites, making it easier to integrate into existing workflows.
However, it is important to note that this skill does not support kernel-DT overlay or ODMDATA edits, and is strictly focused on generating the necessary DTSIs based on the XLSM input. This makes it ideal for specific use cases where direct pin configuration is required without additional modifications to the device tree overlays.
When to use it
Use this skill when you need to configure pin settings for a Jetson Orin or Thor custom carrier based on the pinmux XLSM spreadsheet.
When not to use it
Avoid this skill if you require kernel-DT overlay modifications or ODMDATA edits, as it does not support those functionalities.
What you can build with it
Configuring a Custom Carrier
After deriving a custom carrier, use this skill to configure the pinmux settings based on the latest XLSM.
Fixing HSIO Pin Mismatches
When a sibling skill reports a pin mismatch, utilize this tool to adjust the pin configurations accordingly.
Setting Up for Production
Before deploying a custom Jetson carrier, use this skill to ensure all pin settings are correctly configured and validated.
How to install Jetson Pinmux Customizer
View source1. Install with the skills CLI
npx skills add nvidia/skills/jetson-customize-pinmux --agent claude-code2. Or install it manually
Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.
Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs
Inside SKILL.md
Written by nvidiaCustomize pinmux (per-pin SFIO / direction / state)
Overview
The Tegra pinmux spreadsheet (.xlsm) is the ground truth for every
CVM ball: SoC pin name, supported SFIOs, customer-selected function,
direction, and initial state. This skill parses that XLSM, runs a
per-pin Q1–Q6 interactive loop, and emits the three BCT DTSIs
(pinmux, gpio, padvoltage) in one shot into the overlay tracker
at <source.root_path>/Linux_for_Tegra/bootloader/.
Unlike sibling skills jetson-customize-uphy / jetson-customize-pcie /
jetson-customize-camera, pinmux has no kernel-DT overlay surface and no
ODMDATA edit. The XLSM is the source of truth; the three emitted
DTSIs land at flash time via the carrier conf's
PINMUX_CONFIG= / GPIOINT_CONFIG= / PMC_CONFIG= references (which
/jetson-derive-carrier set up).
Pad classification (silicon-fixed): only BD* and BI* pads have
configurable pull / drive / open-drain attributes. LP5XA_*,
UPHYDS_*, DP_SINGLE_*, BDMIPI16X_*, BDUSB2_*, OSCI27_* are
fixed-function and skip Q4–Q6 (configurable: no).
The bundled scripts/modify_pinmux.py is the workhorse: it parses
the XLSM via openpyxl>=3.1, builds the per-carrier pinmap JSON,
captures pin edits into a session shim, and (on generate) writes
the three DTSIs.
When to invoke
- The user says "configure pin", "set SFIO", "edit pinmux DTSI", "set pin direction", "set initial state", or asks to repurpose a CVM ball (e.g. flip a pin between GPIO and a peripheral function).
- A sibling skill (
jetson-customize-camera,jetson-customize-pcie,jetson-customize-usb,jetson-customize-mgbe) reports an HSIO pin mismatch viapin_verifier.pyand the user wants to fix it. - The user pre-derived a custom carrier with
/jetson-derive-carrierand now wants to author the pinmux from a freshly-edited.xlsm.
Prerequisites:
- Active profile selected (
target-platform/active_target.yml→<profile>.yamlwithreference_devkit:ANDcustom_carrier:). <source.root_path>/Linux_for_Tegra/exists as a git repo (/jetson-init-source)./jetson-derive-carrierhas run — the three pinmux-side BCT DTSIs (PINMUX_CONFIG,GPIOINT_CONFIG,PMC_CONFIGreferences in the carrier conf) exist in the overlay tracker.- A pinmux
.xlsmis registered in the active profile atdocuments.custom_carrier_pinmux_xls(preferred when custom-carrier- specific) ordocuments.ref_devkit_pinmux_xls(fallback). The bundledmodify_pinmux.pyrequiresopenpyxl>=3.1.
Procedure
See references/procedure.md for the full
step-by-step procedure (Steps 1–8). Summary:
- Resolve active target + XLSM. Validate active profile,
custom_carrier:, overlay-tracker prerequisites; resolve the pinmux.xlsmpath fromdocuments.custom_carrier_pinmux_xls→documents.ref_devkit_pinmux_xls→ single XLSM underdocuments.root_path→ user prompt. - Probe. Run
modify_pinmux.py probeto parse the XLSM into the per-skill scratch<KB>/pinmap/<custom-carrier>.jsonplussession.jsonshim. - Lookup. Resolve a free-form user query (CVM ball, Verilog
name, signal, DT pin) via
modify_pinmux.py lookup; surface supported SFIO list, defaults, andconfigurable: yes/no. - Set-pin (HARD GATE — Q1–Q6 via
AskUserQuestion). Q1–Q3 (sfio/direction/initial_state) always asked; Q4–Q6 (pull/drive_type/open_drain) only whenconfigurable: yes.tristateande_inputare derived fromdirection, never asked. - Generate.
modify_pinmux.py generate --out-dir <source.root_path>/Linux_for_Tegra/bootloader/(root, notbootloader/generic/BCT/— derive-carrier.dtsforks live there, do not colocate). Emits:tegra<soc>-mb1-bct-{pinmux,gpio,padvoltage}-<carrier-key>.dtsi.<carrier-key>comes from the carrier conf'sPINMUX_CONFIG=reference, NOT the kebab-cased carrier name. - Commit (single batched commit per workflow rule). All three DTSIs are one logical edit → one customization commit. Run the commit-preview gate before each commit.
- Run-state sidecar + session shim. Write the user-facing
<profile-stem>.jetson-customize-pinmux.jsonsidecar and the transientsession.jsonshim under<workspace>/target-platform/. - Summary. Emit the standard one-line + table summary.
Gotchas
- No kernel-DT overlay; no
OVERLAY_DTB_FILEedit; norender_conf.pyhand-off. This skill ends at the three BCT DTSIs — the carrier conf already references them viaPINMUX_CONFIG=/GPIOINT_CONFIG=/PMC_CONFIG=(set up by/jetson-derive-carrier). - Re-point the
.dtswrapper's#includeaftergenerate./jetson-derive-carrierforks the.dtswrappers atbootloader/generic/BCT/, but their#includelines may still pull the upstream devkit.dtsi(e.g.…-p3834-xxxx-p4071-0000.dtsi). Aftergeneratewrites the new<CARRIER_KEY>.dtsitobootloader/root, edit each wrapper's#includeto the new filename — by bare basename (#include "tegra<soc>-mb1-bct-pinmux-<CARRIER_KEY>.dtsi"), not../../…filesystem-relative. The BCT build'scpp -I bootloader/resolves bare basenames; that's the convention every other BCT include in the tree follows. Roll the wrapper edits into the same customization commit as the three DTSIs. Seereferences/procedure.mdStep 5 ("Sanity-check the carrier.dtswrapper"). - Q4–Q6 gated on
configurable: yes. Asking pull / drive_type / open_drain on a fixed-function pad (LP5XA_*,UPHYDS_*,BDMIPI16X_*, etc.) is silently dropped by the script and confuses the user.lookupprintsconfigurable: yes/no— always check it before prompting Q4–Q6. tristateande_inputare derived, never asked.unused→ tristate=ENABLE;input/bidirectional→ enable-input=ENABLE. Exposing them as separate prompts produces inconsistent DTSIs.sfio=gpiorequires a parseablegpio=GPIOn_PD.NNentry in the pinmap row'ssfiolist. Pins without one are GPIO-incapable silicon;set-pinrejects the call. Surface the rejection — don't silently fall back to a non-GPIO SFIO.- Marker idempotency. Every per-pin edit carries
// custom-bsp: pinmuxon the closing brace; gpio default-state entries carry the same marker as a trailing comment. Re-runninggeneratemust detect and update — never duplicate. modify_pinmux.pyis unchanged from the original framework — it reads its ownsession.jsonshim under--kb-dir. The shim is regenerated each run from the active profile + the user-facing sidecar. Do not hand-edit the shim; it's transient.- Multiple pinmux DTSI variants per Thor module SKU. Some carrier
pins live in a different DTSI variant than the one the carrier
conf references.
modify_pinmux.py commit(legacy patch-in-place flow) tolerates missing per-pin blocks viapinmux.warnings[]rather than failing. Surface the warning; point at the alternate DTSI variant. - Don't touch the upstream BSP at
<bsp_image.root_path>. All edits land in<source.root_path>/Linux_for_Tegra/bootloader/under the pristine + customization commit pattern.
Available Scripts
| Script | Purpose | Arguments |
|---|---|---|
scripts/modify_pinmux.py | XLSM parser + per-pin DTSI generator. Invoked via run_script() from Steps 3-6 with the subcommand of the current phase. | probe | lookup | set-pin | apply | generate | commit [...] (see --help) |
scripts/generate_dtsi.py | Renders pinmux/GPIO/padvoltage DTSI fragments from the bundled session state. Called by modify_pinmux.py generate. | --session <path> --out-dir <dir> |
Invoke from the skill body as a subprocess via run_script():
# run_script: probe the carrier pinmux XLSM and write a session state
scripts/modify_pinmux.py probe --xlsm carrier.xlsm --session .pinmux-session.json
# run_script: render DTSI fragments from the final session state
scripts/modify_pinmux.py generate --session .pinmux-session.json --out-dir bsp_sources/pinmux/
References
references/procedure.md— full Step 1–8 procedure prose.questions.json— Q1–Q6 prompt schema consumed by Step 4.../../references/platform_template.yaml—documents:block (ref_devkit_pinmux_xls,custom_carrier_pinmux_xls).../../context/bsp-customization-workflow.md— overlay edit protocol (single-commit per DTSI fork).../jetson-derive-carrier/SKILL.md— must run first; produces the pinmux / gpio / padvoltage DTSI forks this skill edits, and rewrites the carrier conf'sPINMUX_CONFIG=/GPIOINT_CONFIG=/PMC_CONFIG=lines to point at them.../jetson-init-source/SKILL.md— produces the overlay tracker this skill commits into.../jetson-link-docs/SKILL.md— author the profile'sdocuments:block, including the pinmux XLSM bindings.
Frequently asked questions about Jetson Pinmux Customizer
Similar skills
Rhino 3D Scripting
Streamline your Rhinoceros 3D scripting tasks.
MVVM Toolkit
Streamline ViewModel development with source generators.
FreeCAD Scripts
Generate Python scripts for FreeCAD automation and modeling.
Azure Architecture Builder
Design and deploy Azure infrastructure using natural language.
Command Development
Streamline your command creation for Claude Code.
Create Cowork Plugin
Easily build and package plugins through guided sessions.
