Jetson BSP Image Flasher
Safely flash a promoted Jetson BSP image onto a Jetson device in RCM mode.
The skill requires host preflight checks, RCM detection, EEPROM reconciliation, and explicit confirmation of the resolved plan before flashing; it uses the in-tree boardctl and rejects arbitrary pasted commands, showing scope and external-effect awareness. Deductions apply because flashing modifies the device with sudo but provides no backup, rollback, or recovery procedure; default choices include public ubuntu/ubuntu and nvidia/nvidia credentials, so sensitive-credential handling is weak; data-flow and log-persistence boundaries are also underspecified.
The ordered workflow, refusal conditions, T23x/T26x branches, failure feedback, and no-auto-retry rule are relatively detailed, and the happy path is plausible from static reading. Deductions apply because it depends on external BSP tools, board configuration, EEPROM formats, and shared context files, with no executable tests covering key paths; static calibration caps this dimension at 10.
The name, activation scenarios, prerequisites, and explicit non-fit boundaries are clear, and the main Orin and Thor flashing flows are covered. Deductions apply because it is limited to particular Jetson BSP, RCM hardware, and target-profile environments; host compatibility, permissions, network reachability, and Chinese-language interaction are not addressed, while invocation boundaries depend on other skills and context files.
SKILL.md has clear purpose, prerequisites, staged instructions, limitations, troubleshooting, and references; version, Apache-2.0 licensing, Jetson Team authorship, and NVIDIA maintenance provenance are visible. Deductions apply because the benchmark reports a missing Examples section and a nonconforming author format; no changelog, explicit maintenance commitment, or update path is provided, and several shared-context dependencies are outside the assessed skill path.
The skill directly covers the core task from profile resolution and preflight through confirmation, flashing, reset, and summary, with actionable command shapes and troubleshooting. The committed internal evaluation reports two positive tasks passing. Deductions apply because the sample is very small, has no negative tasks, and static review cannot verify actual flashing success, output completeness, or benefit over manual operation; static calibration caps this dimension at 7.
The documentation supplies concrete commands, checks, EEPROM mappings, sample output, evaluation files, and a committed benchmark report, providing some auditability. Deductions apply because there are no independently reproducible execution records, real CI workflows, or committed key-path test suites available in the supplied material; the benchmark is internal, and static calibration caps this dimension at 5.
- Flashing is a high-impact device write that may be difficult to reverse; verify the DUT, boot medium, image, and backup/recovery plan before confirmation.
- The default-user options include public credentials and should not be used directly in production; custom passwords may appear in command lines or logs.
- No commands were executed for this review, so success across Jetson models, BSP versions, EEPROM values, and host environments was not verified.
- The target-platform contract and related skills must match this revision; otherwise routing or preflight behavior may fail or become unsafe.
What does this skill do, and when should you use it?
This skill flashes a promoted BSP image to a Jetson DUT through NVIDIA’s Linux_for_Tegra toolchain. It resolves the target profile, board flash configuration, boot device, and flash utility, then validates host files, RCM mode, and EEPROM/profile agreement before flashing. The agent must present the resolved plan and receive explicit user approval before execution. BSP customization, image promotion, and custom-carrier configuration generation are out of scope.
Reads the active target-platform profile, bsp_image, board flash configuration, and Linux_for_Tegra files; checks BSP directories, rootfs, kernel images, initramfs files, and NVIDIA marker files; enters RCM using the in-tree boardctl or a manual button procedure; verifies the recovery device with lsusb; reads board_sku and board_FAB from EEPROM using sudo ./nvautoflash.sh --print_boardid and reconciles them with the profile; selects flash.sh or l4t_initrd_flash.sh based on chip family and boot media; optionally stages a default user with l4t_create_default_user.sh; flashes the image; runs boardctl reset for T26x/Thor; and reports commands, exit status, and log location.
- A Jetson engineer needs to flash a promoted BSP image to a reference development board already prepared for RCM recovery.
- A team needs to re-flash a Jetson device without new promotion changes.
- A deployment workflow must verify the DUT’s EEPROM SKU/FAB against the active target profile before selecting flash artifacts.
- A T26x/Thor device requires an explicit reset after flashing to leave recovery mode.
What are this skill's strengths and limitations?
- Checks BSP readiness, RCM status, and real non-empty EEPROM/profile conflicts before flashing.
- Selects flash.sh or l4t_initrd_flash.sh according to chip family and boot media.
- Requires approval of the resolved target and flash plan instead of accepting a raw pasted command.
- Explicitly handles the reset difference between T23x/Orin and T26x/Thor.
- Only flashes an already promoted BSP image; it does not customize BSPs, promote images, or derive carrier configurations.
- Requires an RCM-capable DUT, Linux_for_Tegra tooling, and the referenced host commands.
- Does not automatically retry transient USB failures; the device must be re-entered into RCM and invoked again.
- The supplied material does not provide a complete supported BSP-version matrix or evidence of an independent test suite.
How do you install this skill?
Install the skill from NVIDIA’s catalog with:
npx skills add nvidia/skills --skill jetson-flash-image --yes
The CLI prompts for the installation destination. The source does not require manually cloning the repository or copying the folder. A compatible Agent Skills client must load the installed directory.
How do you use this skill?
Ask an agent with the skill loaded, for example: “Flash the promoted bsp_image to the Jetson DUT in RCM mode.” The environment must provide an active target-platform profile, a valid Linux_for_Tegra tree, a BSP that has run apply_binaries.sh, a resolvable per-board .conf, and a connected DUT that can enter RCM. The skill performs host and device preflight checks, prints the resolved plan for approval, then constructs and runs flash.sh or l4t_initrd_flash.sh. The supplied material does not fully document the target-profile schema or boardctl target names.
How does this skill compare with similar options?
The skill uses two NVIDIA flashing tools depending on the target: flash.sh is the default for T234/Orin with eMMC or SD, while l4t_initrd_flash.sh is used for T234/Orin with NVMe or USB and for T264/Thor with NVMe or UFS. RCM entry can use the preferred in-tree boardctl or a manual recovery-and-reset-button procedure.