What does this skill do, and when should you use it?
This skill configures MGBE controllers on custom Jetson Thor T264 carrier boards for QSFP, 10G, or 1G fiber paths. It uses BPMP allocation, PHY attachment details, pin information, and carrier documentation to configure controller status and PHY plumbing. It writes the result as a composite custom overlay in the bsp_sources hardware repository, while jetson-build-source owns compilation and registration. It does not allocate UPHY lanes or modify ODMDATA.
It validates the active target, carrier configuration, overlay tracker, and required documents; collects controller, PHY mode, attachment type, I²C, reset GPIO, and compatible-string details through a question flow; decompiles the BPMP DTB to determine the speed-token form; runs pin_verifier.py for MDC, MDIO, RESET, and INT checks; appends per-controller fragments to the composite overlay DTS; runs cpp, dtc, and fdtoverlay pre-flight checks; and writes a run-state JSON sidecar and summary. It reads workspace, source, BSP-image Linux_for_Tegra, and document paths, and writes to the target-platform and bsp_sources hardware directories.
- A Jetson Thor custom carrier connects a QSFP cage to an MGBE controller and needs 25G enabled.
- A configured mgbe<N> reports DOWN or NO-CARRIER after cold boot.
- An MGBE controller does not appear at all and its kernel device-tree or PHY wiring needs inspection.
- jetson-customize-uphy has selected a UPHY configuration allocating the MGBE lanes, and the controller-side configuration is still required.
How do you install this skill?
- Before execution, reconcile uphy1-config versus uphy0-config, jetson-customize-uphy versus legacy paths, and verify the actual locations of pin_verifier.py and the context document.
- Add explicit user confirmation before committing the overlay and document a recoverable commit rollback plan; ensure the sidecar does not misleadingly record ODMDATA that this skill did not modify.
- Recheck all hardware parameters against the actual BPMP/kernel DTBs, schematics, pinmap, DUT compatible strings, and PHY datasheet; the supplied documentation alone does not prove correctness.
- Shell / CLI
- Local filesystem
dtcfdtoverlaycppgit
Install the individual skill with the NVIDIA/skills skills CLI: npx skills add nvidia/skills --skill jetson-customize-mgbe --yes. The CLI handles the installation destination; the supplied source does not specify a manual copy directory.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/NVIDIA/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/jetson-customize-mgbe" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Once installed, send your agent any of these to trigger it:
- Enable 25G QSFP on MGBE0 for my custom Jetson Thor carrier
- Configure the MGBE PHY mode and bring up a 10G fiber path.
In a prepared Jetson Thor BSP workspace, prompt the agent with wording such as “Enable 25G QSFP on MGBE0 for my custom Jetson Thor carrier” or “Configure the MGBE PHY mode and bring up a 10G fiber path.” Before running, provide an active profile, Linux_for_Tegra/.git, the carrier flash-configuration fork, the UPHY allocation result, and the Adaptation Guide, Module Design Guide, and SoC TRM. When custom_carrier is present, both the carrier schematic and pinmux XLS are required. The skill then gathers per-controller settings through its question flow.
What are this skill's strengths and limitations?
- Produces kernel device-tree overlay fragments and leaves composite-overlay compilation to jetson-build-source.
- Covers 25G, 10G, and 1G MGBE/QSFP or fiber paths with PHY-side checks.
- Clearly excludes ODMDATA, UPHY allocation, flash-conf registration, and direct upstream-BSP edits.
- Documents failure modes involving BPMP token grammar, MDIO cell properties, overlay compatibility, and pinmux mismatches.
- Focused on Jetson Thor T264 MGBE scenarios; it does not handle UPHY lane allocation, ODMDATA, or flash-conf registration.
- It must refuse custom-carrier runs when the schematic or pinmux XLS is missing.
- It requires dtc, fdtoverlay, cpp, git, and several prepared BSP workflow states.
- The supplied material provides no test suite, platform-support matrix, or hardware-validation results.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| Jetson Thor MGBE/QSFP Configuration this page ✓ NVIDIA · Official | 49 · Use with care | ★ 3.8k | today | Apache-2.0 |
| Jetson PCIe Controller Customizer ✓ NVIDIA · Official | 57 · Use with care | ★ 3.8k | today | Apache-2.0 |
| Jetson USB Port Customization ✓ NVIDIA · Official | 55 · Use with care | ★ 3.8k | today | Apache-2.0 |
| Jetson Custom Carrier Derivation ✓ NVIDIA · Official | 53 · Use with care | ★ 3.8k | today | Apache-2.0 |
| Jetson BSP Source Builder ✓ NVIDIA · Official | 58 · Recommended | ★ 3.8k | today | Apache-2.0 |
Unlike jetson-customize-uphy, this skill handles controller-side kernel device-tree and PHY configuration; jetson-customize-uphy owns lane allocation and the related ODMDATA commit. Pinmux mismatches are routed to jetson-customize-pinmux.
How did FollowSkills review this skill?
The skill declares scoped file and shell permissions, public data classification, prohibition on ODMDATA and upstream-BSP edits, and confirmation for pin fixes, reducing overreach risk; however, it directly writes and commits to bsp_sources without explicit pre-commit confirmation or a complete rollback/recovery procedure, so points are deducted.
The main workflow, prerequisites, preflight commands, failure conditions, and several troubleshooting cases are fairly concrete; however, referenced context files and scripts are not included in the supplied material, and questions.json contains inconsistent legacy names such as uphy0-config and /modify-uphy. Key-path execution therefore cannot be confirmed statically, and the score remains below the static ceiling.
The audience, Thor platform, QSFP/MGBE scenarios, and boundaries around UPHY, ODMDATA, and pinmux are clear, including non-fit cases; however, it is Thor-only, provides no Chinese-language interaction guidance, and gives limited broader trigger-boundary evidence. The core workflow depends on local BSPs, hardware schematics, and a DUT, not an overseas service.
The SKILL.md provides overview, triggers, procedure, gotchas, and references, with a recognizable version and team owner; however, Instructions, Examples, and FAQ sections are absent, as also noted by the benchmark, while license metadata says NOASSERTION and the skill card states CC-BY-4.0 plus Apache 2.0. No clear changelog or maintenance/update path is supplied.
The material specifies question collection, DT-overlay fragments, preflight, commits, and downstream handoff, so it plausibly addresses the core configuration task; however, reported effectiveness is only about 43%–44%, and naming, path, and sidecar ODMDATA-field inconsistencies remain. Static evidence cannot establish directly usable output, so the score is conservative and capped.
The fixed-revision materials include a procedure, question schema, benchmark report, and concrete commands, providing some auditability; however, the benchmark is a small internal single-run result, and the supplied files lack the referenced scripts, CI, committed outputs, or independent corroboration. Key technical claims cannot be independently reproduced from the supplied evidence.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →