jetson-customize-mgbe — Claude Code skill: MGBE QSFP on Jetson Thor
This skill renders the kernel-DT overlay that brings up an MGBE controller on Jetson Thor for 25G, 10G or 1G QSFP. Useful when the link stays down after a cold boot.
npx skills add NVIDIA/skills --skill jetson-customize-mgbe -a claude-codeWhat jetson-customize-mgbe does
The skill handles the kernel side of MGBE. It renders an overlay that sets status="okay" on the target &mgbeN and wires up the PHY. It works with mgbe0..mgbe3, the controllers Thor T264 exposes. On a custom carrier the 25G QSFP cage, or a 10G/1G fiber path, lands on one of them through SerDes, with or without an external MDIO PHY in front of the cage.
The procedure has eight steps. First it validates the active profile and documents, then asks about the controller: phy_mode, attach kind, I²C bus and address, reset GPIO, compatible list. Next it decompiles the BPMP DTB to pick the right token grammar, runs pin_verifier.py over MDC/MDIO/RESET/INT, and appends one fragment per controller to the composite overlay .dts. A pre-flight through cpp, dtc and fdtoverlay runs before anything is written. Output is a single commit plus a <profile-stem>.jetson-customize-mgbe.json sidecar.
When the profile carries custom_carrier:, both documents.custom_carrier_schematic and documents.custom_carrier_pinmux_xls are required. Miss either one and the skill refuses to run, because MGBE routing on a custom carrier cannot be guessed. You also need dtc on PATH and a UPHY config that already allocates lanes for the target controller. ODMDATA is off limits here — that belongs to /jetson-customize-uphy.
What it helps with
- enable a 25G QSFP cage on a custom Thor carrier
- bring up a 10G or 1G fiber path
- debug why
ip link show mgbe<N>reportsNO-CARRIER - set up an MDIO PHY with its address and reset GPIO
- append an overlay fragment to the composite
.dtsand pre-flight it
Example prompts for the agent
- enable 25G on mgbe0, external PHY, bus i2c-1
- configure QSFP for MGBE in 10G mode
- mgbe2 stays down after cold boot — check the overlay
How to install jetson-customize-mgbe
1Skills CLI (Vercel)
npx skills add NVIDIA/skills --skill jetson-customize-mgbe -a claude-code2Manually: put the files in place
~/.claude/skills/jetson-customize-mgbe/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/jetson-customize-mgbe/
1Skills CLI (Vercel)
npx skills add NVIDIA/skills --skill jetson-customize-mgbe -a codex2Manually: put the files in place
.agents/skills/jetson-customize-mgbe/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add NVIDIA/skills --skill jetson-customize-mgbe -a cursor2Manually: put the files in place
.cursor/skills/jetson-customize-mgbe/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install NVIDIA/skills jetson-customize-mgbe2Manually: put the files in place
.github/skills/jetson-customize-mgbe/SKILL.md1Skills CLI (Vercel)
npx skills add NVIDIA/skills --skill jetson-customize-mgbe -a gemini-cli2Platform CLI
gemini skills install https://github.com/NVIDIA/skills --path skills/jetson-customize-mgbeManually: put the files in place
.devin/skills/jetson-customize-mgbe/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add NVIDIA/skills --skill jetson-customize-mgbe -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about jetson-customize-mgbe
How do I install jetson-customize-mgbe in Claude?
Run npx skills add NVIDIA/skills --skill jetson-customize-mgbe -a claude-code. The skill lands in ~/.claude/skills/jetson-customize-mgbe/SKILL.md.
What does jetson-customize-mgbe do?
It renders the kernel-DT overlay for an MGBE controller on Jetson Thor, enabling 25G, 10G or 1G QSFP and plumbing the PHY on &mgbeN. It writes one commit to the composite overlay .dts.
Can this skill edit ODMDATA?
No. Every ODMDATA token, including mgbeN-speed-* and the mgbeN_status=* sub-nodes, belongs to /jetson-customize-uphy. This skill never touches them.
Source text
SKILL.md · Apache-2.0
---
name: jetson-customize-mgbe
description: >-
Enable Jetson Thor 25G/10G/1G MGBE QSFP via kernel-DT overlay.
Do NOT use for UPHY lane allocation or ODMDATA edits.
version: 0.0.1
license: "Apache-2.0"
metadata:
data-classification: public
author: "Jetson Team"
tags:
- bsp
- phase-2
- io
- mgbe
- ethernet
domain: meta
permissions:
file_read:
- "{workspace}/target-platform/"
- "{source.root_path}/"
- "{bsp_image.root_path}/Linux_for_Tegra/"
- "{documents.root_path}/"
file_write:
- "{workspace}/target-platform/"
- "{source.root_path}/bsp_sources/hardware/nvidia/"
shell:
- "dtc"
- "fdtoverlay"
- "cpp"
- "git"
---
# Customize MGBE / 25G QSFP
## Overview
Thor T264 exposes mgbe0..mgbe3. On a custom carrier, the 25G QSFP cage
(or 10G / 1G fiber path) is wired to one of them through SerDes — with
or without an external MDIO PHY in front of the cage. This skill
renders the kernel-DT overlay that pairs the BPMP allocation with
kernel-side `status="okay"` + PHY plumbing on `&mgbeN`.
**Out of scope:**
- UPHY lane allocation — owned by `/jetson-customize-uphy`. Refuse if
the chosen `uphy1-config-N` doesn't allocate the target MGBE.
- All ODMDATA tokens (`mgbeN-speed-*`, sub-node `mgbeN_status=*`) —
owned by `/jetson-customize-uphy` in its single atomic ODMDATA
commit. This skill MUST NOT touch `ODMDATA=`.
Output is **one commit** to the composite custom overlay `.dts` in the
`bsp_sources/` hardware repo. `/jetson-build-source` compiles the
composite to `.dtbo` and owns its Makefile + flash-conf registration.
## When to invoke
- The user says "enable 25G", "configure QSFP", "set MGBE PHY mode",
"wire MGBE to QSFP", or asks to bring up a 10G / 1G fiber path.
- Cold boot succeeds but `ip link show mgbe<N>` reports `state DOWN`
or `NO-CARRIER` on the configured controller, OR the controller
never appears at all.
- `jetson-customize-uphy` ran with `uphy1-config-8` (or another config
allocating MGBE) and you now need to bring up the per-controller
side.
**Prerequisites:**
- Active profile selected with `reference_devkit:` (Thor) +
`custom_carrier:` blocks.
- `<source.root_path>/Linux_for_Tegra/.git` exists
(`/jetson-init-source`).
- `/jetson-derive-carrier` has run — carrier flash-conf fork is in
the overlay tracker.
- `/jetson-customize-uphy` chose a UPHY config that allocates the target
MGBE controller's lanes (`uphy1-config-8` on Thor for MGBE0..3 25G).
- Source-of-truth docs registered or supplied at prompt:
Adaptation Guide, Module Design Guide, SoC TRM.
- **When `custom_carrier:` is present, both
`documents.custom_carrier_schematic` AND
`documents.custom_carrier_pinmux_xls` are REQUIRED.** Refuse the run
if either is missing — MGBE routing on a custom carrier cannot be
guessed. Reference-devkit-only profiles skip this check.
- `dtc` on PATH.
## Procedure
See `references/procedure.md` for the full step-by-step procedure (Steps 1–8). Summary:
1. **Resolve active target + documents.** Validate active profile, custom_carrier, overlay tracker; locate the relevant Adaptation Guide chapter and pinmap.
2. **Per-controller question loop.** AskUserQuestion driven by `questions.json` (controller, phy_mode, attach kind, I²C bus/addr, reset GPIO, compatible_list).
3. **Derive max-speed from phy_mode.** Decompile the BPMP DTB to pick sub-node vs top-level token grammar; cite the inspection in notes.
4. **Verify HSIO pins + auto-fix.** Run `pin_verifier.py` for MDC/MDIO/RESET/INT; surface mismatches and route to `/jetson-customize-pinmux`.
5. **(no ODMDATA edits.)** MGBE ODMDATA tokens are emitted by `/jetson-customize-uphy`. Step 5 only records the BPMP DTB token-form inspection (sub-node vs top-level) in `notes[]` for audit.
6. **Append composite-overlay fragments.** Write one fragment per controller into the composite custom overlay `.dts`; obey the `/* custom-bsp: mgbe:mgbe... */` marker contract; run the cpp/dtc/fdtoverlay pre-flight.
7. **(Reserved.)** Sibling-skill ordering / cross-cutting validation.
8. **Run-state sidecar + summary + next-step chain.** Write `<profile-stem>.jetson-customize-mgbe.json` and emit the one-line + table summary, then drive the downstream chain via sequential `AskUserQuestion` prompts per `references/procedure.md` Step 8. Never substitute a printed "Next step: …" line for the prompts.
## Gotchas
- **Stock Thor BPMP DTB has no `/mgbe/mgbe@N` subtree** — only
`mgbe<N>-speed` under `/uphy`. The `mgbe<N>_status=disabled`
sub-node token is silently rejected on these releases; the whole
ODMDATA line is then dropped at flash time. Always decompile BPMP
DTB (Step 3) before emitting; use the top-level dashed form
(`mgbe<N>-speed-del` to remove, `mgbe<N>-speed-25G` to set) when
the sub-node isn't there. Same wrong-form failure surface as
`jetson-customize-uphy`.
- **`mdio` child needs both `#address-cells = <1>` AND
`#size-cells = <0>`** when `phy_attach_kind=="phy"`. Missing either
→ kernel rejects `phy@<addr>` reg property at probe; MGBE never
comes up.
- **Overlay root `compatible` must intersect live DT compatible.**
UEFI plugin-manager filters by compatible match. A mismatched
overlay is silently skipped — flash succeeds, MGBE stays disabled,
no error in dmesg. Always sanity-check against
`/proc/device-tree/compatible` on a booted reference DUT.
- **`OVERLAY_DTB_FILE` ordering is `jetson-build-source`'s problem,
not this skill's.** This skill never touches the carrier flash
conf. The composite custom overlay is registered (by
`/jetson-build-source` Step 5.0a) AFTER the platform
`*-dynamic.dtbo`, which is the correct ordering. If you find
yourself appending `OVERLAY_DTB_FILE+=` in this skill, you're
duplicating ownership — stop, and let the build skill do it.
- **UPHY lane allocation is `jetson-customize-uphy`'s job.** If the chosen
`uphy1-config-N` doesn't allocate lanes for the target MGBE
controller, BL31 SError (`fmon_update_config: detected fault
0x80`) on cold boot. Always run `/jetson-customize-uphy` first; cite the
chosen `uphy1-config-N` in this skill's run-summary `notes[]`.
- **Don't disable a stock-okay controller via ODMDATA alone.** Same
rule as `jetson-customize-uphy`: `mgbe<N>_status=disabled` for a
controller that's already disabled in BPMP DTB is a no-op the
parser may treat as ambiguous → drops the rest of the ODMDATA
line. Disable via the kernel-DT overlay (`status="disabled"`) only.
- **Don't touch the upstream BSP at `<bsp_image.root_path>`.** All
edits land in the overlay tracker / `bsp_sources` mono-repo under
the pristine + customization commit pattern.
- **JSON sidecar is structured state, not authoritative.** Same
caveat as `jetson-customize-uphy`: ODMDATA + overlay `.dts` + two git
commits are the device-facing outputs; the sidecar is for tooling
and idempotency only.
## References
- [`questions.json`](references/questions.json) — Q-1..Q-8 prompt schema
consumed by Step 2.
- [`../../scripts/pin_verifier.py`](../../scripts/pin_verifier.py)
— shared HSIO pin verifier (Step 4).
- [`../../references/platform_template.yaml`](../../references/platform_template.yaml)
— `documents:` block consumed by Step 1.
- [`../../context/bsp-customization-workflow.md`](../../context/bsp-customization-workflow.md#commit-batching-in-the-overlay-tracker)
— overlay edit protocol (batched pristine + customization commit).
- [`../jetson-customize-uphy/SKILL.md`](../jetson-customize-uphy/SKILL.md) — sibling
skill that owns UPHY lane allocation. Must run before this skill to
set `uphy1-config-N` for MGBE-allocated configurations.
- [`../jetson-customize-pinmux/SKILL.md`](../jetson-customize-pinmux/SKILL.md) —
sibling skill invoked by Step 4 (with operator confirmation) to
fix pin SFIO mismatches.
- [`../jetson-derive-carrier/SKILL.md`](../jetson-derive-carrier/SKILL.md)
— must run first; produces the carrier flash-conf fork edited in
Step 5 and the carrier base overlay this skill orders after.
- [`../jetson-init-source/SKILL.md`](../jetson-init-source/SKILL.md) —
produces the overlay tracker + bsp_sources repo this skill commits
into.
© Jetson Team · Apache-2.0 · NVIDIA/skills