Skip to main content
skill CX Codex

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.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add NVIDIA/skills --skill jetson-customize-mgbe -a claude-code
Open on GitHub

What 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> reports NO-CARRIER
  • set up an MDIO PHY with its address and reset GPIO
  • append an overlay fragment to the composite .dts and 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-code

2Manually: put the files in place

~/.claude/skills/jetson-customize-mgbe/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/jetson-customize-mgbe/

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

Similar skills

Everything for DevOps and infrastructure →

From the same set178

jetson-package Selects Jetson-compatible containers, vLLM runtimes, and Jetson AI Lab PyPI indexes for Orin and Thor. Prevents loading generic ARM64 wheels that lack target SM kernels. CX Codex +1 1,200installs jetson-quick-start Starts a setup questionnaire for Jetson or IGX BSP customization and passes the answers to downstream skills. Use it before preparing a new workspace or working with an existing one. CX Codex +1 1,200installs jetson-memory-audit A skill that snapshots Jetson memory and checks how much DRAM actually came back after you stop a workload. CX Codex +1 1,200installs nemoclaw-user-guide Directs AI assistants to official NemoClaw docs via an MCP server or llms.txt. Useful when installing, running, or troubleshooting OpenClaw, Hermes, and Deep Agents. CX Codex +1 1,200installs jetson-generate-kb Generates a markdown reference next to the active profile by inspecting the NVIDIA Jetson BSP and source tree. Handy after unpacking a BSP or editing target settings. CX Codex +1 1,100installs jetson-customize-clocks Prepares Jetson CPU, GPU and EMC clock changes before an image is flashed. Use it to lock rates, set ceilings, or change DVFS behaviour. CX Codex +1 1,100installs jetson-speculative-decoding A skill that adds EAGLE-3 or draft-model speculative decoding to a Jetson vLLM server when token generation is the slow part. CX Codex +1 1,100installs jetson-validate-image Validates NVIDIA Jetson BSP builds statically on disk or directly on the device. Catches kernel, initramfs, and module mismatches. CX Codex +1 1,100installs

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor