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
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:
| Var | Source |
|---|---|
<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:
| ID | Form | Notes |
|---|---|---|
controller_selection | multi-select mgbe0..mgbe3 | One controller per QSFP cage; multi-select only if the carrier has multiple MGBE-wired cages. |
phy_mode | 25g-r / 10g-kr / 1000base-x | Default 25g-r for QSFP 25G. |
phy_attach_kind | phy (external MDIO PHY) / direct (SerDes-direct) | Determines whether the overlay emits phy-handle + mdio { phy@<addr> }. |
phy_i2c_bus | One of i2c@3160000 .. i2c@c250000 | Only when phy_attach_kind=="phy". Pick the I²C controller whose SDA/SCL nets reach the PHY refdes per schematic. |
phy_i2c_addr_hex | 7-bit hex (^0x[0-7][0-9a-fA-F]$) | Only when phy_attach_kind=="phy". From PHY strap pins / datasheet. |
phy_reset_gpio_offset | decimal integer | Offset within the chosen bank; cross-check the carrier pinmap. |
phy_reset_gpio_bank | gpio_main / gpio_aon | |
compatible_list | multi-select strings | Root 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_mode | nvidia,max-speed | ODMDATA speed token |
|---|---|---|
25g-r | 25000 | mgbe<N>_speed=25G (sub-node form) or mgbe<N>-speed-25G (/uphy top-level form) |
10g-kr | 10000 | mgbe<N>_speed=10G / mgbe<N>-speed-10G |
1000base-x | 1000 | mgbe<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@Nsubtree exists in BPMP DTB → use sub-node form (mgbe<N>_status=okay,mgbe<N>_speed=25G).If only
/uphy/mgbe<N>-speedexists (stock Thor r38.4) → use top-level dashed form (mgbe<N>-speed-25G); thestatusknob 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:
Filter by
compatible, not by node name. The kernel DTB contains both NVIDIA controller nodes (compatible = "nvidia,tegra264-mgbe", one per controller, bearing the realstatus) and unrelated sibling Ethernet helpers in the sameethernet@<addr>namespace. Match on the compatible string, not on the bareethernet@glob.grep -nE 'compatible.*nvidia,tegra[0-9]+-mgbe\b' /tmp/k.dtsBound 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 wrongstatusfrom 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):
| Signal | SFIO | Direction | Initial state | Notes |
|---|---|---|---|---|
XFI<N>_MDC | mgbe<N>_mdc | output | n/a | |
XFI<N>_MDIO | mgbe<N>_mdio | bidirectional | n/a | open-drain enable |
XFI<N>_RESET | gpio (output) | output | high | drives PHY reset; offset/bank captured in Step 2 |
XFI<N>_INT_N (when wired) | gpio | input | n/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.pywas written for the legacysession.jsonmodel and readssession.carrier_pinmap/session.carrier_short. A compatible shim under<workspace>/target-platform/<profile-stem>.jetson-customize-mgbe/session.jsonis generated each run (same pattern asjetson-customize-pinmuxStep 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.dtboFail 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:
Re-run
/jetson-customize-pinmuxto fix the surfaced SFIO mismatches? — onyesinvoke/jetson-customize-pinmux, then continue to (1).
Then in order:
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, andno(proceed). On any non-nopick, invoke the chosen sub-skill inline; when it returns, re-ask this same question (loop) until the user picksno. Then continue to (2).Build & promote? — on
yesinvoke/jetson-build-source, then on success invoke/jetson-promote-image.Flash the board? — only offer if (2) ran and succeeded; on
yesinvoke/jetson-flash-image.Validate on the DUT? — only offer if (3) ran and succeeded; on
yesinvoke/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