domains / families / devops / jetson-flash-image

jetson-flash-image

separate

Use to flash a promoted BSP image to a Jetson DUT in RCM mode via flash.sh or l4t_initrd_flash.sh. Do NOT use for BSP customization, image promotion, or carrier derivation.

When to use

• Host-side flash variables (`<board>`, `<boot-dev>`, flow tool, per-board `.conf`, `boardctl`) are resolved from the active profile or the in-tree BSP.
• Artifact paths (`DTB_FILE`, `BPFDTB_FILE`, partition XML, BCTs, DRAM training) are resolved inside `flash.sh` / `l4t_initrd_flash.sh` at flash time from `board_sku` / `board_FAB` read off the DUT's EEPROM.
• The DUT's EEPROM is authoritative; the profile is an authoring-time prediction reconciled by the preflight cross-check. Empty EEPROM values are valid, not refusal triggers.
• The user explicitly confirms a printed *resolution* before flashing.

When not to use

• **DUT must be in RCM mode.** Image-generation (EEPROM read) and the flash itself both use the recovery USB channel; not-in-RCM at the gate fails image-gen too.
• **Artifact paths resolved at flash time.** `DTB_FILE`, `BPFDTB_FILE`, partition XML, BCTs, DRAM training are picked from EEPROM (`board_sku` / `board_FAB`) by `flash.sh` / `l4t_initrd_flash.sh`; this skill validates only host-side scaffold…
• **EEPROM is authoritative over the profile.** Real non-empty disagreement refuses; *empty* EEPROM values are valid.
• **No raw-command bypass.** Refuses to fall back to user-supplied "paste this command" — that path is how stale doc snippets and prompt-character paste artifacts reach production flashes.
• **No transient-error auto-retry.** USB hiccups abort; re-enter RCM and re-invoke.
• **T26x needs an explicit post-flash reset.** T26x doesn't auto-reboot from a freshly flashed image; `<boardctl> -t <target> reset` (or manual power-cycle) required. T23x resets internally.
• **Massflash / `--flash-only`** uses the same tool selection + respective flags; massflash topology setup is out of scope here.

Skill page

Source