Generated banner for Jetson Customize Mgbe
Generated logo for Jetson Customize Mgbe

Jetson Customize Mgbe

NVIDIAOfficialCreated by Jetson TeamDistributed by NVIDIA

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • Medium risk

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

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/nvidia/jetson-customize-mgbe/download
  2. 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:

  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 — 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

references/procedure.md

Procedure

Step 1 — Resolve active target + open source-of-truth documents

Same as jetson-customize-uphy Step 1 (refuse table + identifier resolution

  • document resolution from documents: block). The Adaptation Guide chapter relevant here is "Enable 25 Gigabit Ethernet on QSFP Port".

Additionally resolve:

VarSource
<platform>thor (T264) — this skill is Thor-only at present
<carrier-pinmap><workspace>/target-platform/<profile-stem>.jetson-customize-pinmux/pinmap/<custom-carrier>.json (produced by jetson-customize-pinmux probe; optional but required for Step 4 auto-fix)
Step 2 — Per-controller question loop

Drive the loop with AskUserQuestion using the schema in questions.json. Per-controller fields:

IDFormNotes
controller_selectionmulti-select mgbe0..mgbe3One controller per QSFP cage; multi-select only if the carrier has multiple MGBE-wired cages.
phy_mode25g-r / 10g-kr / 1000base-xDefault 25g-r for QSFP 25G.
phy_attach_kindphy (external MDIO PHY) / direct (SerDes-direct)Determines whether the overlay emits phy-handle + mdio { phy@<addr> }.
phy_i2c_busOne of i2c@3160000 .. i2c@c250000Only when phy_attach_kind=="phy". Pick the I²C controller whose SDA/SCL nets reach the PHY refdes per schematic.
phy_i2c_addr_hex7-bit hex (^0x[0-7][0-9a-fA-F]$)Only when phy_attach_kind=="phy". From PHY strap pins / datasheet.
phy_reset_gpio_offsetdecimal integerOffset within the chosen bank; cross-check the carrier pinmap.
phy_reset_gpio_bankgpio_main / gpio_aon
compatible_listmulti-select stringsRoot compatible for the overlay. MUST contain at least one string that appears in the live DUT's /proc/device-tree/compatible. Defaults from catalogue (Thor): nvidia,<custom-id>-<custom-sku>+<module-id>-<module-sku>, nvidia,<chip>. Reuse prior jetson-customize-camera / jetson-customize-pcie runs' compatible list when present.
Step 3 — Derive nvidia,max-speed from phy_mode
phy_modenvidia,max-speedODMDATA speed token
25g-r25000mgbe<N>_speed=25G (sub-node form) or mgbe<N>-speed-25G (/uphy top-level form)
10g-kr10000mgbe<N>_speed=10G / mgbe<N>-speed-10G
1000base-x1000mgbe<N>_speed=1G / mgbe<N>-speed-1G

Choice between sub-node vs top-level token form is dictated by the live BPMP DTB schema — decompile and check before emitting:

BPMP_DTB="<bsp_image.root_path>/Linux_for_Tegra/bootloader/$(grep '^BPFDTB_FILE=' <carrier conf> | cut -d'"' -f2)"
dtc -I dtb -O dts "$BPMP_DTB" | sed -n '/^\t\(uphy\|mgbe\) /,/^\t};/p'
  • If /mgbe/mgbe@N subtree exists in BPMP DTB → use sub-node form (mgbe<N>_status=okay, mgbe<N>_speed=25G).

  • If only /uphy/mgbe<N>-speed exists (stock Thor r38.4) → use top-level dashed form (mgbe<N>-speed-25G); the status knob is not available — kernel-DT overlay alone owns enable/disable.

Kernel-DT K-stock probe — node-selection + indent-bounded extraction (REQUIRED). Before emitting any kernel-DT overlay fragment, re-read each target MGBE node's stock status from the reference kernel DTB. Two parser traps to avoid:

  1. Filter by compatible, not by node name. The kernel DTB contains both NVIDIA controller nodes (compatible = "nvidia,tegra264-mgbe", one per controller, bearing the real status) and unrelated sibling Ethernet helpers in the same ethernet@<addr> namespace. Match on the compatible string, not on the bare ethernet@ glob.

    grep -nE 'compatible.*nvidia,tegra[0-9]+-mgbe\b' /tmp/k.dts
  2. Bound the block by matching the closing brace at the same indent as the opening line. A naive awk '/ethernet@<addr> {/,/^\t};/' range will trip on the first }; of any nested child (mdio, PHY, ipv4 subnodes) and return the wrong status from the inside of a sub-node. Use:

    ln=$(grep -nE "^[[:space:]]+ethernet@$addr \{" /tmp/k.dts | head -1 | cut -d: -f1)
    indent=$(sed -n "${ln}p" /tmp/k.dts | sed -E 's/[^[:space:]].*//')
    awk -v start="$ln" -v ind="$indent" \
      'NR>=start { if (NR>start && $0==ind"};") exit; print }' /tmp/k.dts

This is the same fix that protects /jetson-customize-pcie from reading pci-host-ecam-generic instead of nvidia,tegra264-pcie. Apply both rules whenever you decode a Tegra IP block.

The two grammars are not interchangeable; same rule as jetson-customize-uphy Step 6's "wrong forms" table. Cite the BPMP DTB inspection in notes[].

Step 4 — Verify HSIO pins + auto-fix via /jetson-customize-pinmux

For every controller with phy_attach_kind=="phy", verify ancillary pin SFIOs and route mismatches to /jetson-customize-pinmux. Expected per controller (where <N> is the controller index):

SignalSFIODirectionInitial stateNotes
XFI<N>_MDCmgbe<N>_mdcoutputn/a
XFI<N>_MDIOmgbe<N>_mdiobidirectionaln/aopen-drain enable
XFI<N>_RESETgpio (output)outputhighdrives PHY reset; offset/bank captured in Step 2
XFI<N>_INT_N (when wired)gpioinputn/a

Invoke the shared verifier:

# Pseudo-flow — actual call from agent
from pin_verifier import verify_pins
result = verify_pins(
    kb_dir=<workspace>/target-platform/<profile-stem>.jetson-customize-mgbe,
    l4t_dir=<source.root_path>/Linux_for_Tegra,
    expected=[
        {"signal_or_pin": f"XFI{N}_MDC",    "sfio": f"mgbe{N}_mdc",  "direction": "output",        "initial_state": "n/a", "reason": f"MGBE{N} MDC"},
        {"signal_or_pin": f"XFI{N}_MDIO",   "sfio": f"mgbe{N}_mdio", "direction": "bidirectional", "initial_state": "n/a", "reason": f"MGBE{N} MDIO (open-drain)"},
        {"signal_or_pin": f"XFI{N}_RESET",  "sfio": "gpio",          "direction": "output",        "initial_state": "high", "reason": f"MGBE{N} PHY reset"},
    ],
    io_label="mgbe",
)

pin_verifier.py is located at <workspace>/.claude/scripts/pin_verifier.py. It is read-only; it reports {ok: [...], mismatches: [...]}. For each mismatch, surface a "I'm setting pin X to SFIO Y because <reason>" message and call /jetson-customize-pinmux set-pin (or have the user re-run /jetson-customize-pinmux directly) to stage the fix. Do not auto-fix without confirmation.

Integration note: pin_verifier.py was written for the legacy session.json model and reads session.carrier_pinmap / session.carrier_short. A compatible shim under <workspace>/target-platform/<profile-stem>.jetson-customize-mgbe/session.json is generated each run (same pattern as jetson-customize-pinmux Step 7) so the verifier's interface keeps working unchanged.

Step 5 — (no ODMDATA edits)

All MGBE ODMDATA tokens (mgbeN-speed-<rate>, mgbeN-speed-del, sub-node mgbeN_status=* where the BPMP DTB exposes it) are emitted by /jetson-customize-uphy in its single atomic ODMDATA commit. This skill MUST NOT touch ODMDATA=. Cite the BPMP DTB token-form inspection (sub-node vs top-level) in notes[] so the UPHY skill's emission can be audited.

Step 6 — Append fragments to the composite custom overlay

This skill writes per-controller fragments into the single composite custom overlay .dts for the active target. Filename / location / skeleton / append protocol are documented in ../../../references/bsp-customization-kernel-dtb.md — follow that doc exactly. The notes below cover only what's MGBE-specific.

Marker for this skill's fragments: /* custom-bsp: mgbe:mgbe<N> */ (one fragment per controller; sub-key is the controller name). On re-run, delete every fragment matching this skill's marker pattern before appending the new ones (see context doc Step 5 of the append protocol).

Fragment body — one per enabled controller:

fragment@<N> { /* custom-bsp: mgbe:mgbe<id> */
    target = <&mgbe<id>>;
    __overlay__ {
        status = "okay";
        phy-mode = "<phy_mode>";
        nvidia,max-speed = <<max_speed_mbps>>;

        /* phy_attach_kind == "phy" only — omit block for "direct": */
        phy-handle = <&mgbe<id>_phy>;
        nvidia,phy-reset-gpios = <&gpio_main <pin> 0>;
        mdio {
            #address-cells = <1>;
            #size-cells = <0>;
            mgbe<id>_phy: phy@<addr> {
                reg = <<addr>>;
            };
        };
    };
};

#address-cells = <1>; #size-cells = <0>; on the mdio child is mandatory when phy_attach_kind=="phy". Without it the kernel rejects the phy@<addr> reg property at probe.

For phy_attach_kind=="direct", drop phy-handle, nvidia,phy-reset-gpios, and the entire mdio { ... } subnode; the SerDes auto-negotiates without an external PHY.

Compatible string is set on the composite root, not per-fragment — see the context doc. This skill does not touch compatible; if the composite root's compatible is missing your active-DUT string, fix the composite root (which any previous run set), don't widen inside the fragment.

Mandatory marker comment metadata (same audit-trail contract as jetson-customize-uphy Step 7.5): the fragment marker /* custom-bsp: mgbe:mgbe<N> */ is enough for grep-based discovery, but include a one-line provenance comment inside the fragment summarizing (a) phy mode + speed + attach kind, (b) pin & reset GPIO, (c) source citation (Adaptation Guide section, schematic page range, MDG table, PHY datasheet). Place it as the first line inside __overlay__.

Commit the composite .dts in the bsp_sources/ mono-repo (filename resolved per the context doc):

git -C <source.root_path>/bsp_sources add <composite-relative-path>
git -C <source.root_path>/bsp_sources commit -m "jetson-customize-mgbe: append mgbe<N> @ <phy_mode> to <board-tag>-custom"

Pre-flight sanity check (also documented in the context doc Step 10 of the append protocol):

cpp -nostdinc -x assembler-with-cpp <composite-abs-path> /tmp/composite.tmp.dts
dtc -@ -I dts -O dtb -o /tmp/composite.dtbo /tmp/composite.tmp.dts
fdtoverlay -i <bsp_image.root_path>/Linux_for_Tegra/kernel/dtb/<carrier-base>.dtb \
           -o /tmp/merged.dtb /tmp/composite.dtbo

Fail the commit (git restore --staged <composite-path> and exit) if either step errors. /jetson-build-source re-compiles the composite via nvidia-dtbs; this is a pre-flight sanity check only.

Flash-conf and Makefile registration are NOT this skill's job — jetson-build-source Step 5.0a owns both (it idempotently adds dtbo-y += <composite>.dtbo and the single OVERLAY_DTB_FILE+= line on its next run). Do not patch the carrier flash conf here.

Step 8 — Run-state JSON sidecar + summary

Sidecar at <workspace>/target-platform/<profile-stem>.jetson-customize-mgbe.json:

{
  "generator": "jetson-customize-mgbe",
  "generator_version": "0.1.0",
  "generated_at": "<ISO-8601 UTC>",
  "active_profile": "<profile-stem>.yaml",
  "bsp_version": "<bsp_image.version>",
  "controllers": [{
    "id": "mgbe0",
    "enable": true,
    "phy_mode": "25g-r",
    "phy_attach_kind": "phy",
    "phy_i2c_bus": "i2c@3160000",
    "phy_i2c_addr_hex": "0x56",
    "phy_reset_gpio_offset": 12,
    "phy_reset_gpio_bank": "gpio_main",
    "max_speed_mbps": 25000
  }],
  "compatible_list": ["nvidia,p8181-0001+p3834-0008", "nvidia,tegra264"],
  "bpmp_token_grammar": "subnode" | "top_level_uphy",
  "odmdata_tokens": ["mgbe0_status=okay", "mgbe0_speed=25G"],
  "overlay": {
    "composite_dts_path": "<source.root_path>/bsp_sources/hardware/nvidia/<chip-dir>/nv-public/<sub>/tegra<soc>-<carrier-id-sku>+<module-id>-xxxx-custom.dts",
    "composite_dtbo": "tegra<soc>-<carrier-id-sku>+<module-id>-xxxx-custom.dtbo",
    "fragments_appended": ["mgbe:mgbe<N>"],
    "skipped": false
  },
  "pin_verifier_mismatches": [],
  "warnings": [],
  "notes": [],
  "sources": ["..."],
  "commit_shas": {
    "overlay_tracker": "<short SHA>",
    "bsp_sources": "<short SHA>"
  }
}

Atomic write + idempotency contract: same as jetson-customize-uphy Step 5.

Headline + breakdown mirrors jetson-customize-uphy Step 8 — adapted for MGBE (controller list, PHY mode/speed/attach, ODMDATA tokens, overlay path, commit SHAs, BPMP DTB grammar choice, pin-verifier mismatches surfaced).

Next step (interactive prompt chain):

After the summary table is printed, drive the downstream chain via sequential AskUserQuestion prompts. Each prompt needs an explicit yes. On no (or any abort), print the remaining manual run-chain and exit. Never substitute a printed "Next step: …" line for the prompts.

If Step 4 surfaced SFIO mismatches, prepend prompt (0) first:

  1. Re-run /jetson-customize-pinmux to fix the surfaced SFIO mismatches? — on yes invoke /jetson-customize-pinmux, then continue to (1).

Then in order:

  1. Customize any other I/O before build? — offer /jetson-customize-pinmux, /jetson-customize-uphy, /jetson-customize-pcie, /jetson-customize-camera, /jetson-customize-usb, /jetson-customize-clocks, /jetson-customize-fan, /jetson-customize-nvpmodel, /jetson-customize-memory, and no (proceed). On any non-no pick, invoke the chosen sub-skill inline; when it returns, re-ask this same question (loop) until the user picks no. Then continue to (2).

  2. Build & promote? — on yes invoke /jetson-build-source, then on success invoke /jetson-promote-image.

  3. Flash the board? — only offer if (2) ran and succeeded; on yes invoke /jetson-flash-image.

  4. Validate on the DUT? — only offer if (3) ran and succeeded; on yes invoke /jetson-validate-image.

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