Jetson Customize Mgbe

NVIDIAOfficialCreated by Jetson TeamDistributed by NVIDIA

Skill
Tool integration
Cloud and DevOps
Apache-2.0
Medium risk

Download ZIP

From the author

Enable Jetson Thor 25G/10G/1G MGBE QSFP via kernel-DT overlay. Do NOT use for UPHY lane allocation or ODMDATA edits.

— the description by Jetson Team

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured workflow for enabling MGBE (Multi-Gigabit Ethernet) controllers on Jetson Thor platforms. It handles the creation of kernel-DT overlays to configure MGBE interfaces for 25G, 10G, or 1G fiber paths, including PHY plumbing. It is designed to work in conjunction with UPHY lane allocation and pinmux customization skills, ensuring that the hardware configuration is correctly represented in the device tree without interfering with ODMDATA or UPHY lane settings.

What it does

Generates kernel-DT overlay fragments to enable MGBE controllers.
Configures PHY modes and MDIO/I2C settings for external PHYs.
Validates HSIO pin configurations for MGBE signals.
Ensures correct device tree compatibility matching for UEFI plugin-manager.
Provides a structured audit trail for hardware configuration changes.
Integrates with existing BSP source repositories and overlay trackers.

When to use it

When enabling 25G, 10G, or 1G Ethernet on a custom carrier board.
When an MGBE controller is configured but reports state DOWN or NO-CARRIER.
After successfully running jetson-customize-uphy for lane allocation.
When integrating an external MDIO PHY with a QSFP cage.

Advantages

Prevents common configuration errors by enforcing prerequisite checks.
Maintains clean separation between UPHY, pinmux, and MGBE configurations.
Automates the complex process of device tree overlay generation.
Ensures compatibility with the Jetson BSP build system.

Usage examples

“Enable 25G QSFP on mgbe0 for my custom Thor carrier.”: The agent initiates the MGBE configuration workflow, validates the UPHY allocation, and generates the necessary kernel-DT overlay for the 25G interface.
“My 10G fiber link is not coming up on mgbe1.”: The agent checks the current device tree status, verifies the PHY mode and MDIO settings, and helps identify if the issue is in the overlay or pinmux.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/nvidia/jetson-customize-mgbe/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip jetson-customize-mgbe.zip -d .agents/skills

Documentation by Jetson Team

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:

Resolve active target + documents. Validate active profile, custom_carrier, overlay tracker; locate the relevant Adaptation Guide chapter and pinmap.
Per-controller question loop. AskUserQuestion driven by questions.json (controller, phy_mode, attach kind, I²C bus/addr, reset GPIO, compatible_list).
Derive max-speed from phy_mode. Decompile the BPMP DTB to pick sub-node vs top-level token grammar; cite the inspection in notes.
Verify HSIO pins + auto-fix. Run pin_verifier.py for MDC/MDIO/RESET/INT; surface mismatches and route to /jetson-customize-pinmux.
(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.
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.
(Reserved.) Sibling-skill ordering / cross-cutting validation.
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 — Q-1..Q-8 prompt schema consumed by Step 2.
../../scripts/pin_verifier.py — shared HSIO pin verifier (Step 4).
../../references/platform_template.yaml — documents: block consumed by Step 1.
../../context/bsp-customization-workflow.md — overlay edit protocol (batched pristine + customization commit).
../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 — sibling skill invoked by Step 4 (with operator confirmation) to fix pin SFIO mismatches.
../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 — produces the overlay tracker + bsp_sources repo this skill commits into.

Files

ATTRIBUTION.mdAdded by AutoGineer926 B
BENCHMARK.md3.7 KiB
LICENSELicence file added by AutoGineer11.2 KiB
SKILL.md8.1 KiB
assets/questions.json5.7 KiB
evals/evals.json6.2 KiB
references/procedure.md13.6 KiB
references/questions.json5.7 KiB
skill-card.md3.6 KiB
skill.oms.sig5.2 KiB

evals/evals.json

[
  {
    "id": "jetson-customize-mgbe-001",
    "question": "I just ran /jetson-customize-uphy with uphy1-config-8 to allocate lanes for MGBE0 25G on my Thor custom carrier. Now bring up the per-controller side via /jetson-customize-mgbe.",
    "expected_skill": "jetson-customize-mgbe",
    "expected_script": null,
    "ground_truth": "Run /jetson-customize-mgbe. Step 1 resolves the active target, validates custom_carrier, and locates the Adaptation Guide chapter and pinmap — both documents.custom_carrier_schematic AND documents.custom_carrier_pinmux_xls are required when custom_carrier: is present, refusing if either is missing. Step 2 drives the per-controller question loop via questions.json (controller, phy_mode, attach kind, I²C bus/addr, reset GPIO, compatible_list). Step 3 derives max-speed from phy_mode by decompiling the BPMP DTB to choose between sub-node and top-level token grammar (Thor stock BPMP DTB has no /mgbe/mgbe@N subtree, only mgbe<N>-speed under /uphy, so the top-level dashed form mgbe<N>-speed-25G is required). Step 4 runs pin_verifier.py over MDC/MDIO/RESET/INT and routes mismatches to /jetson-customize-pinmux. Step 5 records the BPMP DTB token-form inspection in notes[] but emits no ODMDATA — those tokens are owned by /jetson-customize-uphy. Step 6 appends one /* custom-bsp: mgbe:mgbeN */ fragment per controller into the composite custom overlay .dts in bsp_sources/, runs the cpp/dtc/fdtoverlay pre-flight, and commits one commit. Step 8 writes <profile-stem>.jetson-customize-mgbe.json and emits the one-line + table summary, then drives the downstream chain via sequential AskUserQuestion prompts. /jetson-build-source compiles the composite .dtbo and owns the OVERLAY_DTB_FILE+= registration — this skill never edits ODMDATA or the carrier flash conf.",
    "expected_behavior": [
      "Read skills/jetson-customize-mgbe/SKILL.md",
      "Step 1: validate active profile with reference_devkit + custom_carrier; require both documents.custom_carrier_schematic and documents.custom_carrier_pinmux_xls and refuse if either is missing",
      "Cite uphy1-config-8 from /jetson-customize-uphy in run-summary notes[] (lanes for MGBE0..3 25G)",
      "Step 2: run the per-controller AskUserQuestion loop driven by references/questions.json (Q-1..Q-8: controller, phy_mode, attach kind, I²C bus/addr, reset GPIO, compatible_list)",
      "Step 3: decompile the BPMP DTB to detect that Thor stock has no /mgbe/mgbe@N subtree and use the top-level dashed token grammar (mgbe<N>-speed-25G); record the inspection in notes[]",
      "Step 4: run pin_verifier.py over MDC/MDIO/RESET/INT and route mismatches to /jetson-customize-pinmux",
      "Step 5: emit no ODMDATA edits — record only the BPMP DTB token-form inspection (sub-node vs top-level) in notes[] for audit",
      "Step 6: append one /* custom-bsp: mgbe:mgbeN */ fragment per controller into the composite custom overlay .dts in bsp_sources/, ensure mdio child has both #address-cells = <1> AND #size-cells = <0> when phy_attach_kind=='phy', run cpp/dtc/fdtoverlay pre-flight and commit",
      "Step 8: write <workspace>/target-platform/<profile-stem>.jetson-customize-mgbe.json and drive the downstream chain via sequential AskUserQuestion prompts",
      "Hand off to /jetson-build-source for composite .dtbo compilation and OVERLAY_DTB_FILE+= registration; never touch ODMDATA or the carrier flash conf"
    ]
  },
  {
    "id": "jetson-customize-mgbe-002",
    "question": "I ran /jetson-customize-mgbe and the flash succeeded but ip link show mgbe0 reports state DOWN with NO-CARRIER and dmesg says BL31 SError 'fmon_update_config: detected fault 0x80' on cold boot. What's wrong?",
    "expected_skill": "jetson-customize-mgbe",
    "expected_script": null,
    "ground_truth": "The BL31 SError 'fmon_update_config: detected fault 0x80' is the documented failure when UPHY lane allocation does not include lanes for the target MGBE controller — UPHY allocation is /jetson-customize-uphy's job, not this skill's. Run /jetson-customize-uphy first to pick a uphy1-config-N that allocates the target MGBE controller's lanes (uphy1-config-8 on Thor for MGBE0..3 25G), and cite the chosen config in this skill's run-summary notes[]. Two adjacent failure modes to check: (a) a mismatched overlay root compatible — UEFI plugin-manager filters by compatible match, a mismatched overlay is silently skipped, flash succeeds, MGBE stays disabled, no error in dmesg; sanity-check against /proc/device-tree/compatible on a booted reference DUT and fix the composite root if needed. (b) Stock Thor BPMP DTB has no /mgbe/mgbe@N subtree, only mgbe<N>-speed under /uphy, so the mgbe<N>_status=disabled sub-node token is silently rejected and the whole ODMDATA line drops; always decompile BPMP DTB (Step 3) before emitting and use the top-level dashed form (mgbe<N>-speed-25G to set, mgbe<N>-speed-del to remove). Disable a stock-okay controller via the kernel-DT overlay (status=\"disabled\") only — never via ODMDATA alone. All edits land in <source.root_path>/bsp_sources/hardware/nvidia/, never in <bsp_image.root_path>.",
    "expected_behavior": [
      "Read skills/jetson-customize-mgbe/SKILL.md and consult the Gotchas section",
      "Identify BL31 SError 'fmon_update_config: detected fault 0x80' as a UPHY lane allocation gap and route to /jetson-customize-uphy first",
      "Confirm /jetson-customize-uphy chose a uphy1-config-N that allocates lanes for the target MGBE controller (e.g. uphy1-config-8 on Thor for MGBE0..3 25G)",
      "Cross-check overlay root compatible against /proc/device-tree/compatible on a booted reference DUT — UEFI plugin-manager silently skips mismatched overlays",
      "Decompile the BPMP DTB before emitting; on stock Thor (no /mgbe/mgbe@N subtree) use the top-level dashed token grammar (mgbe<N>-speed-25G)",
      "Never disable a stock-okay controller via ODMDATA alone — use status=\"disabled\" in the kernel-DT overlay only",
      "Confirm all edits land in <source.root_path>/bsp_sources/hardware/nvidia/ under the pristine + customization commit pattern; never touch <bsp_image.root_path>",
      "Re-run /jetson-customize-mgbe Step 6 to re-emit the composite overlay fragment and Step 8 to refresh the run-state sidecar"
    ]
  }
]

Requirements and compatibility

Written for: Claude Code

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Names Claude Code tools, Needs Node.js

Security

What our scanner noticed· Medium risk

Large base64-encoded blobs

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by

Jetson Team

Publisher

NVIDIA (Official)

Distributed by

NVIDIA

Source

NVIDIA/skills · skills/jetson-customize-mgbe · commit fce3cca

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE-APACHE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by Jetson Team or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download jetson-customize-mgbe.zip

From the author

AutoGineer summary

What it does

When to use it

Advantages

Usage examples

Install

Documentation by Jetson Team

Customize MGBE / 25G QSFP

Overview

When to invoke

Procedure

Gotchas

References

Files

evals/evals.json

Requirements and compatibility

Security

Attribution and licence

Related skills

Modal

Cloud Infrastructure Network Engineer

Deployment Validation Cloud Architect

Airflow Dag Patterns

Cost Optimization

Hybrid Cloud Networking

Download ZIP