jetson-customize-mgbe

Generate validated kernel device-tree overlays for NVIDIA Jetson Thor MGBE controllers.

1|Updated Jun 12, 2026
One-click install
npx skills add https://github.com/JORDAN0615/bsp_factory --skill jetson-customize-mgbe
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: jetson-customize-mgbe
Source: https://github.com/JORDAN0615/bsp_factory/tree/main/skills/jetson-customize-mgbe
Command: npx skills add https://github.com/JORDAN0615/bsp_factory --skill jetson-customize-mgbe

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) and assets (resource) components.

What problem does it solve?

Configuring multi-gigabit Ethernet MGBE controllers on custom NVIDIA Jetson Thor carrier boards requires precise coordination of UPHY lane allocations, PHY plumbing, and kernel device-tree overlay configuration, a process that is highly error-prone and requires deep expertise in Jetson BSP internals, with mistakes leading to non-booting systems or non-functional Ethernet interfaces.

Core Features & Use Cases

  • Validated Kernel Overlay Generation: Creates idempotent, pre-flight validated device-tree overlay fragments to enable MGBE controllers for 25G/10G/1G QSFP connectivity, with mandatory compatible string matching to ensure the overlay is loaded by UEFI.
  • Dual PHY Mode Support: Handles both external MDIO PHY configurations (with I2C addressing, reset GPIO, and MDIO child node generation) and direct SerDes-to-cage wiring, with automated HSIO pin verification to catch pinmux mismatches early.
  • Workflow Integration: Coordinates with sibling Jetson BSP skills (UPHY allocation, pinmux, build, flash) to ensure end-to-end compatibility, with strict guardrails to avoid conflicting edits to ODMDATA or upstream BSP sources.
  • Use Case: An engineer building a custom Jetson Thor carrier with a 25G QSFP port can use this skill, after running the UPHY allocation skill, to automatically generate the correct device-tree overlay to bring up the MGBE interface, with pre-flight validation to catch errors before flashing.

Quick Start

Use the jetson-customize-mgbe skill to generate a validated kernel device-tree overlay that enables your selected MGBE controller for 25G/10G/1G QSFP connectivity on your custom Jetson Thor carrier board, following the guided per-controller configuration prompts.

Frequently Asked Questions about jetson-customize-mgbe

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enable MGBE Ethernet on a custom Jetson Thor carrier board?▼

To enable MGBE Ethernet on a Jetson Thor carrier, generate a validated kernel device-tree overlay that pairs UPHY lane allocations with PHY plumbing and controller enablement for QSFP connectivity.

How do I configure a device-tree overlay for 25G QSFP fiber on Jetson Thor?▼

Configuring a 25G QSFP fiber device-tree overlay involves creating kernel fragments with mandatory compatible string matching for UEFI loading, alongside automated HSIO pin verification to catch pinmux mismatches early.

Can I use an external MDIO PHY with Jetson MGBE device-tree configuration?▼

Yes, MGBE device-tree configuration supports external MDIO PHY setups by generating I2C addressing, reset GPIO, and MDIO child nodes, as well as direct SerDes-to-cage wiring configurations.

Why does my Jetson Thor MGBE overlay fail to load during boot?▼

MGBE overlay boot failures often stem from missing compatible string matching for UEFI loading, incorrect BPMP DTB token grammar, or HSIO pinmux mismatches that pre-flight validation with dtc and fdtoverlay catches.

Do I need to allocate UPHY lanes before configuring the MGBE controller?▼

Yes, you must complete UPHY lane allocation using the sibling jetson-customize-uphy skill before configuring the MGBE controller to ensure correct SerDes-to-cage wiring and avoid conflicting ODMDATA edits.

What is the best way to validate a Jetson device-tree overlay before flashing?▼

The best way to validate a Jetson device-tree overlay before flashing is to run pre-flight validation using dtc and fdtoverlay, ensuring idempotent commit generation to the bsp_sources hardware repository.