Jetson Customize Mgbe
NVIDIAOfficialCreated by Jetson TeamDistributed by NVIDIA
- Skill
- Tool integration
- Cloud and DevOps
- Apache-2.0
- Medium risk
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://mp-staging.autogineer.com/agent-skills/nvidia/jetson-customize-mgbe/downloadUnzip 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 chosenuphy1-config-Ndoesn't allocate the target MGBE.All ODMDATA tokens (
mgbeN-speed-*, sub-nodemgbeN_status=*) — owned by/jetson-customize-uphyin its single atomic ODMDATA commit. This skill MUST NOT touchODMDATA=.
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>reportsstate DOWNorNO-CARRIERon the configured controller, OR the controller never appears at all.jetson-customize-uphyran withuphy1-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/.gitexists (/jetson-init-source)./jetson-derive-carrierhas run — carrier flash-conf fork is in the overlay tracker./jetson-customize-uphychose a UPHY config that allocates the target MGBE controller's lanes (uphy1-config-8on 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, bothdocuments.custom_carrier_schematicANDdocuments.custom_carrier_pinmux_xlsare REQUIRED. Refuse the run if either is missing — MGBE routing on a custom carrier cannot be guessed. Reference-devkit-only profiles skip this check.dtcon 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.pyfor 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) innotes[]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.jsonand emit the one-line + table summary, then drive the downstream chain via sequentialAskUserQuestionprompts perreferences/procedure.mdStep 8. Never substitute a printed "Next step: …" line for the prompts.
Gotchas
Stock Thor BPMP DTB has no
/mgbe/mgbe@Nsubtree — onlymgbe<N>-speedunder/uphy. Themgbe<N>_status=disabledsub-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-delto remove,mgbe<N>-speed-25Gto set) when the sub-node isn't there. Same wrong-form failure surface asjetson-customize-uphy.mdiochild needs both#address-cells = <1>AND#size-cells = <0>whenphy_attach_kind=="phy". Missing either → kernel rejectsphy@<addr>reg property at probe; MGBE never comes up.Overlay root
compatiblemust 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/compatibleon a booted reference DUT.OVERLAY_DTB_FILEordering isjetson-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-sourceStep 5.0a) AFTER the platform*-dynamic.dtbo, which is the correct ordering. If you find yourself appendingOVERLAY_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 chosenuphy1-config-Ndoesn't allocate lanes for the target MGBE controller, BL31 SError (fmon_update_config: detected fault 0x80) on cold boot. Always run/jetson-customize-uphyfirst; cite the chosenuphy1-config-Nin this skill's run-summarynotes[].Don't disable a stock-okay controller via ODMDATA alone. Same rule as
jetson-customize-uphy:mgbe<N>_status=disabledfor 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_sourcesmono-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 setuphy1-config-Nfor 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
BENCHMARK.md
Evaluation Report
Evaluation of the jetson-customize-mgbe skill before publication through NVSkills-Eval.
This benchmark summarizes 3-Tier Evaluation from NVSkills-Eval results for the skill. The goal is to document whether the skill is safe, discoverable, effective, and useful for agents before it is published for broader workflow use.
Evaluation Summary
Skill:
jetson-customize-mgbeEvaluation date: 2026-06-16
NVSkills-Eval profile:
externalEnvironment:
astra-sandboxDataset: 2 evaluation tasks
Attempts per task: 1
Pass threshold: 50%
Overall verdict: PASS
Agents Used
claude-codecodex
Metrics Used
Reported benchmark dimensions:
Security: checks whether skill-assisted execution avoids unsafe behavior such as secret leakage, destructive commands, or unauthorized access.
Correctness: checks whether the agent follows the expected workflow and produces the correct final output.
Discoverability: checks whether the agent loads the skill when relevant and avoids using it when irrelevant.
Effectiveness: checks whether the agent performs measurably better with the skill than without it.
Efficiency: checks whether the agent uses fewer tokens and avoids redundant work.
Underlying evaluation signals used in this run:
security(Security): checks for unsafe operations, secret leakage, and unauthorized access.skill_execution(Skill Execution): verifies that the agent loaded the expected skill and workflow.skill_efficiency(Efficiency): checks routing quality, decoy avoidance, and redundant tool usage.accuracy(Accuracy): grades final-answer correctness against the reference answer.goal_accuracy(Goal Accuracy): checks whether the overall user task completed successfully.behavior_check(Behavior Check): verifies expected behavior steps, including safety expectations.token_efficiency(Token Efficiency): compares token usage with and without the skill.
Test Tasks
The benchmark dataset contained 2 evaluation tasks:
Positive tasks: 2 tasks where the skill was expected to activate.
Negative tasks: 0 tasks where no skill was expected.
Unlabeled tasks: 0 tasks where positive/negative intent could not be inferred.
Task composition is derived from the evaluation dataset when possible. Entries with expected_skill set are treated as positive skill-activation cases, while entries with expected_skill: null are treated as negative activation cases.
Results
| Dimension | Num | claude-code | codex |
|---|---|---|---|
| Security | 2 | 100% (+0%) | 100% (+0%) |
| Correctness | 2 | 90% (+80%) | 84% (+39%) |
| Discoverability | 2 | 94% (+94%) | 91% (+40%) |
| Effectiveness | 2 | 44% (+31%) | 43% (+30%) |
| Efficiency | 2 | 84% (+57%) | 87% (+44%) |
Score values show skill-assisted performance. Values in parentheses show uplift versus the no-skill baseline when baseline data is available.
Tier 1: Static Validation Summary
Tier 1 validation passed with observations. NVSkills-Eval ran 1 checks and found 3 total findings.
Top findings:
MEDIUM SCHEMA/body_recommended_section: Missing recommended section: '## Instructions' (
skills/jetson-customize-mgbe/SKILL.md)MEDIUM SCHEMA/body_recommended_section: Missing recommended section: '## Examples' (
skills/jetson-customize-mgbe/SKILL.md)LOW SCHEMA/author_format: Author must be of the form 'Name <email@host>' (
skills/jetson-customize-mgbe/SKILL.md)
Tier 2: Deduplication Summary
This tier was not run or did not produce findings in this report.
Publication Recommendation
The skill is suitable to proceed toward NVSkills-Eval publication based on this benchmark. Skill owners should keep this file with the skill and refresh it when the evaluation dataset, skill behavior, or target agents materially change.
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
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