[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7A9CZ2MA3AV3G2EFJMSNACT":3,"skill-same:01M7A9CZ2MA3AV3G2EFJMSNACT":88},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":32,"commitSha":33,"skillDirectory":34,"forksCount":35,"repositoryHtmlUrl":36,"repositoryHomepageUrl":37,"ownerHtmlUrl":38,"ownerBlogUrl":39,"ownerDescription":40,"updatedAt":41,"install":42,"resources":55},"01M7A9CZ2MA3AV3G2EFJMSNACT","jetson-flash-image",null,"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.","themusebook\u002Fskills","themusebook","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F349927247?v=4","01M7A5C1RV5S3V5FF6ZACVDNRN","musebook","01M7A5C1SFC3KRZAXNN60XJ7KM",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fjetson-flash-image\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: jetson-flash-image\ndescription: 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.\nversion: 0.0.1\nlicense: \"Apache-2.0\"\nmetadata:\n  data-classification: public\n  author: \"Jetson Team\"\n  tags:\n    - bsp\n    - flash\n  domain: meta\n---\n\n# Flash BSP Image\n\n## Purpose\n\nPush a promoted `bsp_image` to a Jetson DUT by running the NVIDIA flashing toolchain (`flash.sh` or `l4t_initrd_flash.sh`) from the in-tree `Linux_for_Tegra\u002F`. The DUT must be in RCM (recovery) mode at flash time. This is the **flash leg** of the BSP overlay deploy chain (`\u002Fjetson-promote-image` → `\u002Fjetson-flash-image`); see the BSP overlay workflow at `..\u002F..\u002Fcontext\u002Fbsp-customization-workflow.md`.\n\n**Design principle.** Four invariants govern this skill; each is fully explained in the Instructions step that owns it.\n\n- Host-side flash variables (`\u003Cboard>`, `\u003Cboot-dev>`, flow tool, per-board `.conf`, `boardctl`) are resolved from the active profile or the in-tree BSP.\n- Artifact paths (`DTB_FILE`, `BPFDTB_FILE`, partition XML, BCTs, DRAM training) are resolved inside `flash.sh` \u002F `l4t_initrd_flash.sh` at flash time from `board_sku` \u002F `board_FAB` read off the DUT's EEPROM.\n- 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.\n- The user explicitly confirms a printed *resolution* before flashing.\n\nOut of scope: BSP customization (use the `\u002Fjetson-customize-*` skills), promoting the overlay tracker into `bsp_image` (use `\u002Fjetson-promote-image`), and producing a custom carrier's flash conf (use `\u002Fjetson-derive-carrier`).\n\n## Prerequisites\n\n- Active target-platform profile resolved per `..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md` with a populated `bsp_image:` block. Refuse and route to `\u002Fjetson-init-image` if missing.\n- `\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002F` exists on the host and has been through `apply_binaries.sh` (route to `\u002Fjetson-init-image` otherwise).\n- A per-board flash `.conf` resolvable via the active-block precedence rule (`custom_carrier.flash_config` → `reference_devkit.flash_config`). Refuse and route to `\u002Fjetson-derive-carrier` or `\u002Fjetson-init-image` if absent.\n- For the prior overlay → image leg: `\u002Fjetson-promote-image` has already run (or a standalone re-flash with no promotion changes since the last flash).\n- A DUT cabled to the host that can be driven into RCM mode either via the in-tree `boardctl` or by manual recovery + reset buttons.\n\n## When to invoke\n\n- After `\u002Fjetson-promote-image` has updated `bsp_image` to carry the desired customizations.\n- Standalone re-flash with no promotion changes since the last flash.\n- DUT must be in RCM mode before invocation.\n\n## Instructions\n\n### Resolve target and `bsp_image`\n\nResolve the active profile per\n[`..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md`](..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md).\nRefuse if `bsp_image:` is missing or `\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002F`\ndoes not exist (route the user to `\u002Fjetson-init-image`).\n\n### Resolve the flash conf path\n\nPick the per-board `.conf` using the active-block precedence rule\nfrom\n[`target-platform-contract.md`](..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md):\n`custom_carrier.flash_config` when present, else\n`reference_devkit.flash_config`. Verify the chosen file exists under\n`\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002F`. Refuse if absent — route\nthe user at `\u002Fjetson-derive-carrier` (custom carrier) or\n`\u002Fjetson-promote-image` \u002F `\u002Fjetson-init-image` (reference devkit).\n\nBind `\u003Cboard>` as the basename of the resolved `.conf` minus the\n`.conf` suffix (e.g. `jetson-agx-thor-devkit.conf` →\n`\u003Cboard>=jetson-agx-thor-devkit`). the \"Invoke the flash\" step's command shape consumes\nthis binding directly.\n\n**No dispatch preview at this stage.** Artifact resolution (`DTB_FILE`,\n`BPFDTB_FILE`, partition XML, MB1 BCTs, DRAM training tables) happens\ninside `flash.sh` \u002F `l4t_initrd_flash.sh` during image generation,\nusing `board_sku` and `board_FAB` **read from the DUT's EEPROM in\nrecovery mode** — not values typed in from the profile. The profile\nis an authoring-time *prediction*; the DUT EEPROM is *authoritative*\nat flash time. The \"Preflight checks\" step's EEPROM cross-check reads EEPROM and refuses the flash on profile\n\u002F EEPROM mismatch, so passing preflight is what guarantees the\nflash-time dispatch will pick the artifacts the profile expects.\n\nFor static analyses outside the flash flow that need predicted\nartifact paths (KB generation, `customize-*` skills locating files\nto edit), see the standalone snippet in\n[per-board conf dispatch](..\u002F..\u002Fcontext\u002Fbsp-customization-software-layers.md#per-board-conf-dispatch--update_flash_args_common)\n— that snippet is valid for *BSP-side* resolution but **not** as a\nflash-time preview.\n\n### Select `\u003Cboot-dev>` and flash flow\n\n`\u003Cboot-dev>` is resolved deliberately, never assumed. Source order:\n\n1. If the active profile records the boot device, use it.\n2. Otherwise, prompt the user with the choices the per-board conf\n   actually supports (`internal`, `external`, `nvme0n1p1`, `mmcblk0p1`,\n   etc., depending on chip family and conf variant).\n\nPick the flow tool from the matrix below:\n\n| Chip family | Default boot media | Tool |\n|---|---|---|\n| T234 \u002F Orin | eMMC \u002F SD | `flash.sh` |\n| T234 \u002F Orin | NVMe \u002F USB | `l4t_initrd_flash.sh` |\n| T264 \u002F Thor | NVMe \u002F UFS | `l4t_initrd_flash.sh` |\n\nMassflash and `--flash-only` re-runs use the same tool selection but\nadd their respective flags.\n\n### Put the DUT into recovery mode\n\nDrive the device into recovery via the in-tree `boardctl` (preferred)\nor by manually pressing the recovery button followed by the reset button.\n\nThe full procedure — where to find `boardctl` under `Linux_for_Tegra\u002F`,\nhow to enumerate `-t` targets and pick one (recommend `topo`), the\nexact `recovery` verb to use, and the manual fallback — lives in\n[`references\u002Frecovery-mode-boardctl.md`](references\u002Frecovery-mode-boardctl.md).\n\nBind the resolved binary path as `\u003Cboardctl>` for the remainder of\nthis skill. Never substitute a `$PATH` `boardctl`, never invent a\ntarget name not present in `\u003Cboardctl> -h`. The \"Preflight checks\" step's DUT-recovery verification covers — for\nboth paths — that the DUT actually landed in RCM mode.\n\n### Preflight checks\n\nPerforming the following preflight checks in the specified order,\nand never skip each check. Host-side checks run first (fail early\nbefore asking the user to flip recovery), then DUT-side checks once\nthe user has put the device in RCM mode. EEPROM-dependent checks come\nafter RCM detection, since the recovery channel is what makes the read\npossible.\n\n**5.1 `bsp_image` readiness (host-side).**\n\n- Per-board conf exists at `\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002F\u003Cflash_config>`.\n- Artifact subtrees populated: `kernel\u002Fdtb\u002F`, `bootloader\u002F`,\n  `bootloader\u002Fgeneric\u002FBCT\u002F`, `rootfs\u002F`.\n- `apply_binaries.sh` has been run — check for\n  `rootfs\u002Fetc\u002Fnv_tegra_release` and the chip's `nvidia-l4t-bsp-*`\n  marker package files.\n- The *exact* resolved `DTB_FILE` \u002F `BPFDTB_FILE` \u002F BCT filenames\n  are intentionally not checked here — those are picked from\n  EEPROM at flash time (see the \"Resolve the flash conf path\" step).\n- **Kernel `Image` mirror invariant.** When both\n  `\u003CLFT_DST>\u002Fkernel\u002FImage` and `\u003CLFT_DST>\u002Frootfs\u002Fboot\u002FImage` exist,\n  they must be byte-identical (`cmp -s`); drift means\n  `\u002Fjetson-promote-image`'s [Mirror step](..\u002Fjetson-promote-image\u002FSKILL.md#mirror-kernel-image-into-rootfs-when-kernel-changed)\n  was skipped — route back. **Initramfs presence.**\n  `l4t_initrd_flash.sh` requires `\u003CLFT_DST>\u002Fbootloader\u002Fl4t_initrd.img`\n  and `\u003CLFT_DST>\u002Frootfs\u002Fboot\u002Finitrd`; absent → route to\n  `\u002Fjetson-init-image`. (Freshness vs.\n  `rootfs\u002Flib\u002Fmodules\u002F\u003Cver>\u002F` is not checked here — owned by\n  `\u002Fjetson-promote-image`'s\n  [Refresh initramfs step](..\u002Fjetson-promote-image\u002FSKILL.md#refresh-initramfs-when-kernel-or-modules-changed).)\n\n**5.2 DUT in RCM mode.**\n\n- Verifies the outcome of the \"Put the DUT into recovery mode\" step (either the user-selected\n  `\u003Cboardctl> -t \u003Ctarget>` invocation or the manual fallback).\n- `lsusb -d 0955:` must report at least one device matching the\n  active chip family's recovery VID:PID pair:\n\n  | Chip family | Recovery VID:PID |\n  |---|---|\n  | T23x \u002F Orin | `0955:7X23` (X is any hex digit — module variant) |\n  | T26x \u002F Thor | `0955:7026` |\n\n  For T23x, match on the trailing `23` (e.g. `lsusb -d 0955: | grep -E ' 0955:7.23 '`); a literal `0955:7023` check will miss valid T23x variants.\n\n- Absent → if the \"Put the DUT into recovery mode\" step used `boardctl`, surface its output and\n  refuse; if the \"Put the DUT into recovery mode\" step used the manual path, re-prompt the user to\n  confirm the jumper \u002F button and power-cycle.\n- **This is the gate for everything downstream.** `flash.sh`'s\n  image-generation phase reads EEPROM over the same recovery\n  channel; a device that's not in RCM here will fail there too.\n\n**5.3 EEPROM cross-check vs. active profile.**\n\nRead `board_sku` and `board_FAB` (and any additional dispatch inputs\nthe active chip family uses) from the DUT's EEPROM in recovery mode\nusing `sudo .\u002Fnvautoflash.sh --print_boardid` from\n`\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002F`. The full reference —\nsample output, label-to-dispatch-input mapping, empty-value\nsemantics, and the EEPROM-vs-profile reconciliation table — lives in\n[`references\u002Feeprom-cross-check.md`](references\u002Feeprom-cross-check.md).\n\nRefusal trigger is a *real non-empty disagreement*, never a missing\nvalue. Empty EEPROM values are valid and not a refusal trigger. The\ncross-check is the primary defense against the wrong-target \u002F\nwrong-SKU class of failures whenever both sides supply enough\ninformation to disagree.\n\n**5.4 Default user staging (host-side, interactive).**\n\nA freshly applied `bsp_image` has no Linux user pre-staged. Detect via\n`\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002Frootfs\u002Fhome\u002F` and\n`rootfs\u002Fetc\u002Fpasswd` UID ≥ 1000. If none, issue one `AskUserQuestion`\nwith four click-to-select options: `ubuntu \u002F ubuntu`, `nvidia \u002F nvidia`,\n`custom` (sub-prompt for username + password), or `skip` (OEM wizard\non first boot). Non-`skip` picks run\n`l4t_create_default_user.sh --autologin --accept-license`. Full\ninvocation + rationale in\n[`references\u002Fdefault-user-staging.md`](references\u002Fdefault-user-staging.md).\n\nRecord the resolution so the \"Confirm resolution\" step can display it. This step is **not**\na refusal gate — it is a user-interaction point.\n\n### Confirm resolution\n\nPrint the resolved plan and require explicit acceptance. The format\nis the resolution, not the shell command — the user is approving\n*what* will flash, not the *string* that will be executed:\n\n```\nTarget:         \u003Creference_devkit.name> [+ custom_carrier.name]\nProfile:        target-platform\u002F\u003Cactive>.yaml\nbsp_image:      \u003Cbsp_image.root_path>\u002FLinux_for_Tegra  (version \u003CX>)\nFlash conf:     \u003Cflash_config>   (path verified in the \"Resolve the flash conf path\" step)\n\nDUT EEPROM  →   board_sku=\u003Cvalue-or-(empty)>  board_FAB=\u003Cvalue-or-(empty)>\nProfile     →   module.sku=\u003Cvalue-or-(any)>    module.revision=\u003Cvalue-or-(any)>\n                (reconciled per the \"Preflight checks\" step's EEPROM cross-check)\n\nBoot device:    \u003Cboot-dev>\nFlow tool:      flash.sh  |  l4t_initrd_flash.sh\nboardctl:       \u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002Ftools\u002Fboard_automation\u002Fboardctl\n                (or the path the \"Put the DUT into recovery mode\" step resolved)\nRCM entry:      \u003Cboardctl> -t \u003Cuser-selected target> recovery  |  manual recovery + reset buttons\nPost-flash:     \u003Cboardctl> -t \u003Cuser-selected target> reset   (T26x \u002F Thor)\n                not required — flash tool resets internally    (T23x \u002F Orin)\nDefault user:   \u003Cusername> (autologin)\n              | already staged in rootfs (kept)\n              | none — OEM config wizard on first boot\n```\n\nArtifact paths (`DTB_FILE`, `BPFDTB_FILE`, partition XML, BCTs) are\nnot shown — they are resolved by `flash.sh` from EEPROM at flash\ntime, not by this skill. The \"Preflight checks\" step's EEPROM cross-check is what\nguarantees those flash-time picks will line up with what the profile\nexpects.\n\nThis is the user-acceptance gate. Refuse to fall back to a raw\n\"paste this command\" workflow — that path is how stale doc snippets,\nwrong dashes, and prompt-character paste artifacts make it into\nproduction flashes.\n\n### Invoke the flash\n\nConstruct the command from the resolved variables — never accept a\nverbatim command from the user, the docs, or memory:\n\n```bash\ncd \u003Cbsp_image.root_path>\u002FLinux_for_Tegra\nsudo .\u002F\u003Cflow-tool> [\u003Cresolved flags>] \u003Cboard> \u003Cboot-dev>\n```\n\nAbort and surface the failed step on the first non-zero exit. Do\nnot auto-retry on transient USB errors.\n\n### Post-flash reset (T26x \u002F Thor only)\n\nT26x platforms do **not** auto-reboot from the freshly flashed image\nwhen `flash.sh` \u002F `l4t_initrd_flash.sh` returns. Run, using the\n`\u003Cboardctl>` resolved in the \"Put the DUT into recovery mode\" step and the same target the user\nselected for RCM entry:\n\n```bash\n\u003Cboardctl> -t \u003Cuser-selected target> reset\n```\n\nT23x \u002F Orin issues the reset internally; skip this step on Orin. If\nthe \"Put the DUT into recovery mode\" step used the manual path, prompt the user to remove the\nforce-recovery jumper \u002F button and power-cycle by hand. Gate this\nstep on chip family resolved from the active profile.\n\n### Summary\n\nReport: command line(s) used (flash + post-flash reset if it ran),\nexit code, log location (if teed). Persist the resolved plan and\noutcome where validation can re-read it.\n\n## Limitations\n\n- **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.\n- **Artifact paths resolved at flash time.** `DTB_FILE`, `BPFDTB_FILE`, partition XML, BCTs, DRAM training are picked from EEPROM (`board_sku` \u002F `board_FAB`) by `flash.sh` \u002F `l4t_initrd_flash.sh`; this skill validates only host-side scaffolding.\n- **EEPROM is authoritative over the profile.** Real non-empty disagreement refuses; *empty* EEPROM values are valid.\n- **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.\n- **No transient-error auto-retry.** USB hiccups abort; re-enter RCM and re-invoke.\n- **T26x needs an explicit post-flash reset.** T26x doesn't auto-reboot from a freshly flashed image; `\u003Cboardctl> -t \u003Ctarget> reset` (or manual power-cycle) required. T23x resets internally.\n- **Massflash \u002F `--flash-only`** uses the same tool selection + respective flags; massflash topology setup is out of scope here.\n\n## Troubleshooting\n\n| Error | Cause | Solution |\n|---|---|---|\n| `lsusb -d 0955:` reports nothing matching `0955:7X23` (T23x) or `0955:7026` (T26x) | DUT did not enter RCM mode — `boardctl recovery` failed or the manual recovery + reset sequence didn't take. | If `boardctl` was used, surface its output and re-prompt; manual path, re-confirm the recovery jumper \u002F button and power-cycle. Re-run the \"DUT in RCM mode\" preflight. |\n| Preflight EEPROM cross-check refuses with `board_sku` \u002F `board_FAB` mismatch vs. profile | EEPROM holds a *real non-empty* value that disagrees with `module.sku` \u002F `module.revision` in the active profile. | Fix the profile (`\u002Fjetson-set-target` or `\u002Fjetson-init-target`) to match the DUT's actual EEPROM. Do **not** override EEPROM from the profile — EEPROM is authoritative. |\n| Preflight refuses with \"per-board conf not found\" | Active profile points at a `flash_config` that does not exist under `\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002F`. | For custom carriers: run `\u002Fjetson-derive-carrier` to produce the conf. For reference devkits: re-run `\u002Fjetson-promote-image` \u002F `\u002Fjetson-init-image` to repopulate the BSP image. |\n| Preflight refuses because `rootfs\u002Fetc\u002Fnv_tegra_release` is missing | `apply_binaries.sh` has not been run against `\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002F`. | Re-run `\u002Fjetson-init-image` (which invokes `apply_binaries.sh`) or run `apply_binaries.sh` manually from `Linux_for_Tegra\u002F`. |\n| `boardctl -t \u003Ctarget> recovery` errors out or has no effect | Wrong `boardctl` (a `$PATH` binary instead of the in-tree one) or a target name not enumerated by `\u003Cboardctl> -h`. | Use the in-tree `\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002Ftools\u002Fboard_automation\u002Fboardctl`; pick the target from `\u003Cboardctl> -h`. Fall back to manual recovery + reset buttons if needed. |\n| Flash succeeds on T26x but the DUT stays in recovery \u002F does not boot the new image | T26x does not auto-reset out of recovery after `flash.sh` \u002F `l4t_initrd_flash.sh` returns. | Run `\u003Cboardctl> -t \u003Ctarget> reset` (same target used for RCM entry), or for the manual path remove the force-recovery jumper \u002F button and power-cycle. T23x \u002F Orin needs no extra step. |\n| First boot lands on Ubuntu's OEM configuration wizard despite expecting autologin | No default user was staged into `rootfs` before flashing. | Either re-flash after staging via `l4t_create_default_user.sh --autologin --accept-license` (see the default-user-staging step), or complete the OEM wizard on the DUT this once. |\n| `flash.sh` exits non-zero on an artifact-not-found error (DTB \u002F BPFDTB \u002F partition XML) | EEPROM-driven dispatch resolved a filename that doesn't exist in `bsp_image` — usually `\u002Fjetson-promote-image` didn't copy the customized artifact, or the EEPROM SKU is unsupported by the BSP. | Re-run `\u002Fjetson-promote-image`. If the SKU is unsupported, the DUT needs a different BSP version. |\n| `kernel\u002FImage` ↔ `rootfs\u002Fboot\u002FImage` drift, missing `bootloader\u002Fl4t_initrd.img` \u002F `rootfs\u002Fboot\u002Finitrd`, or `modprobe` \"disagrees about version of symbol …\" on the DUT | `\u002Fjetson-promote-image`'s mirror \u002F refresh steps were skipped, or `bsp_image` was hand-edited outside Deploy. | Re-run `\u002Fjetson-promote-image` and re-flash. If initramfs files are entirely absent, run `\u002Fjetson-init-image` first. See [promote-image's kernel-image-and-initramfs reference](..\u002Fjetson-promote-image\u002Freferences\u002Fkernel-image-and-initramfs.md) for the manual escape hatch. |\n\n## References\n\n- [`references\u002Frecovery-mode-boardctl.md`](references\u002Frecovery-mode-boardctl.md) — locate the in-tree `boardctl`, enumerate targets, invoke `recovery` \u002F `reset`, manual fallback (the \"Put the DUT into recovery mode\" step \u002F the \"Post-flash reset\" step details).\n- [`references\u002Feeprom-cross-check.md`](references\u002Feeprom-cross-check.md) — `nvautoflash.sh --print_boardid` sample, label-to-dispatch-input map, EEPROM-vs-profile reconciliation table (used by the \"Preflight checks\" step).\n- [`references\u002Fdefault-user-staging.md`](references\u002Fdefault-user-staging.md) — `l4t_create_default_user.sh` invocation + flag rationale (used by the \"Preflight checks\" step).\n- [`..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md`](..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md) — target-platform contract.\n- [`..\u002F..\u002Fcontext\u002Fbsp-customization-workflow.md`](..\u002F..\u002Fcontext\u002Fbsp-customization-workflow.md#workflow-invariants) — Workspace edit protocol (this skill is the flash leg of Deploy).\n- [Per-board conf dispatch](..\u002F..\u002Fcontext\u002Fbsp-customization-software-layers.md#per-board-conf-dispatch--update_flash_args_common) — `\u003Cboard>`, DTB, and BCT resolution from the active profile.\n- [`..\u002Fjetson-promote-image\u002FSKILL.md`](..\u002Fjetson-promote-image\u002FSKILL.md) — prior leg; copies overlay → bsp_image.\n- [`..\u002Fjetson-derive-carrier\u002FSKILL.md`](..\u002Fjetson-derive-carrier\u002FSKILL.md) — produces the custom carrier's flash conf consumed by the \"Resolve the flash conf path\" step.\n","# Flash BSP Image\n\n## Purpose\n\nPush a promoted `bsp_image` to a Jetson DUT by running the NVIDIA flashing toolchain (`flash.sh` or `l4t_initrd_flash.sh`) from the in-tree `Linux_for_Tegra\u002F`. The DUT must be in RCM (recovery) mode at flash time. This is the **flash leg** of the BSP overlay deploy chain (`\u002Fjetson-promote-image` → `\u002Fjetson-flash-image`); see the BSP overlay workflow at `..\u002F..\u002Fcontext\u002Fbsp-customization-workflow.md`.\n\n**Design principle.** Four invariants govern this skill; each is fully explained in the Instructions step that owns it.\n\n- Host-side flash variables (`\u003Cboard>`, `\u003Cboot-dev>`, flow tool, per-board `.conf`, `boardctl`) are resolved from the active profile or the in-tree BSP.\n- Artifact paths (`DTB_FILE`, `BPFDTB_FILE`, partition XML, BCTs, DRAM training) are resolved inside `flash.sh` \u002F `l4t_initrd_flash.sh` at flash time from `board_sku` \u002F `board_FAB` read off the DUT's EEPROM.\n- 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.\n- The user explicitly confirms a printed *resolution* before flashing.\n\nOut of scope: BSP customization (use the `\u002Fjetson-customize-*` skills), promoting the overlay tracker into `bsp_image` (use `\u002Fjetson-promote-image`), and producing a custom carrier's flash conf (use `\u002Fjetson-derive-carrier`).\n\n## Prerequisites\n\n- Active target-platform profile resolved per `..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md` with a populated `bsp_image:` block. Refuse and route to `\u002Fjetson-init-image` if missing.\n- `\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002F` exists on the host and has been through `apply_binaries.sh` (route to `\u002Fjetson-init-image` otherwise).\n- A per-board flash `.conf` resolvable via the active-block precedence rule (`custom_carrier.flash_config` → `reference_devkit.flash_config`). Refuse and route to `\u002Fjetson-derive-carrier` or `\u002Fjetson-init-image` if absent.\n- For the prior overlay → image leg: `\u002Fjetson-promote-image` has already run (or a standalone re-flash with no promotion changes since the last flash).\n- A DUT cabled to the host that can be driven into RCM mode either via the in-tree `boardctl` or by manual recovery + reset buttons.\n\n## When to invoke\n\n- After `\u002Fjetson-promote-image` has updated `bsp_image` to carry the desired customizations.\n- Standalone re-flash with no promotion changes since the last flash.\n- DUT must be in RCM mode before invocation.\n\n## Instructions\n\n### Resolve target and `bsp_image`\n\nResolve the active profile per\n[`..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md`](..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md).\nRefuse if `bsp_image:` is missing or `\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002F`\ndoes not exist (route the user to `\u002Fjetson-init-image`).\n\n### Resolve the flash conf path\n\nPick the per-board `.conf` using the active-block precedence rule\nfrom\n[`target-platform-contract.md`](..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md):\n`custom_carrier.flash_config` when present, else\n`reference_devkit.flash_config`. Verify the chosen file exists under\n`\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002F`. Refuse if absent — route\nthe user at `\u002Fjetson-derive-carrier` (custom carrier) or\n`\u002Fjetson-promote-image` \u002F `\u002Fjetson-init-image` (reference devkit).\n\nBind `\u003Cboard>` as the basename of the resolved `.conf` minus the\n`.conf` suffix (e.g. `jetson-agx-thor-devkit.conf` →\n`\u003Cboard>=jetson-agx-thor-devkit`). the \"Invoke the flash\" step's command shape consumes\nthis binding directly.\n\n**No dispatch preview at this stage.** Artifact resolution (`DTB_FILE`,\n`BPFDTB_FILE`, partition XML, MB1 BCTs, DRAM training tables) happens\ninside `flash.sh` \u002F `l4t_initrd_flash.sh` during image generation,\nusing `board_sku` and `board_FAB` **read from the DUT's EEPROM in\nrecovery mode** — not values typed in from the profile. The profile\nis an authoring-time *prediction*; the DUT EEPROM is *authoritative*\nat flash time. The \"Preflight checks\" step's EEPROM cross-check reads EEPROM and refuses the flash on profile\n\u002F EEPROM mismatch, so passing preflight is what guarantees the\nflash-time dispatch will pick the artifacts the profile expects.\n\nFor static analyses outside the flash flow that need predicted\nartifact paths (KB generation, `customize-*` skills locating files\nto edit), see the standalone snippet in\n[per-board conf dispatch](..\u002F..\u002Fcontext\u002Fbsp-customization-software-layers.md#per-board-conf-dispatch--update_flash_args_common)\n— that snippet is valid for *BSP-side* resolution but **not** as a\nflash-time preview.\n\n### Select `\u003Cboot-dev>` and flash flow\n\n`\u003Cboot-dev>` is resolved deliberately, never assumed. Source order:\n\n1. If the active profile records the boot device, use it.\n2. Otherwise, prompt the user with the choices the per-board conf\n   actually supports (`internal`, `external`, `nvme0n1p1`, `mmcblk0p1`,\n   etc., depending on chip family and conf variant).\n\nPick the flow tool from the matrix below:\n\n| Chip family | Default boot media | Tool |\n|---|---|---|\n| T234 \u002F Orin | eMMC \u002F SD | `flash.sh` |\n| T234 \u002F Orin | NVMe \u002F USB | `l4t_initrd_flash.sh` |\n| T264 \u002F Thor | NVMe \u002F UFS | `l4t_initrd_flash.sh` |\n\nMassflash and `--flash-only` re-runs use the same tool selection but\nadd their respective flags.\n\n### Put the DUT into recovery mode\n\nDrive the device into recovery via the in-tree `boardctl` (preferred)\nor by manually pressing the recovery button followed by the reset button.\n\nThe full procedure — where to find `boardctl` under `Linux_for_Tegra\u002F`,\nhow to enumerate `-t` targets and pick one (recommend `topo`), the\nexact `recovery` verb to use, and the manual fallback — lives in\n[`references\u002Frecovery-mode-boardctl.md`](references\u002Frecovery-mode-boardctl.md).\n\nBind the resolved binary path as `\u003Cboardctl>` for the remainder of\nthis skill. Never substitute a `$PATH` `boardctl`, never invent a\ntarget name not present in `\u003Cboardctl> -h`. The \"Preflight checks\" step's DUT-recovery verification covers — for\nboth paths — that the DUT actually landed in RCM mode.\n\n### Preflight checks\n\nPerforming the following preflight checks in the specified order,\nand never skip each check. Host-side checks run first (fail early\nbefore asking the user to flip recovery), then DUT-side checks once\nthe user has put the device in RCM mode. EEPROM-dependent checks come\nafter RCM detection, since the recovery channel is what makes the read\npossible.\n\n**5.1 `bsp_image` readiness (host-side).**\n\n- Per-board conf exists at `\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002F\u003Cflash_config>`.\n- Artifact subtrees populated: `kernel\u002Fdtb\u002F`, `bootloader\u002F`,\n  `bootloader\u002Fgeneric\u002FBCT\u002F`, `rootfs\u002F`.\n- `apply_binaries.sh` has been run — check for\n  `rootfs\u002Fetc\u002Fnv_tegra_release` and the chip's `nvidia-l4t-bsp-*`\n  marker package files.\n- The *exact* resolved `DTB_FILE` \u002F `BPFDTB_FILE` \u002F BCT filenames\n  are intentionally not checked here — those are picked from\n  EEPROM at flash time (see the \"Resolve the flash conf path\" step).\n- **Kernel `Image` mirror invariant.** When both\n  `\u003CLFT_DST>\u002Fkernel\u002FImage` and `\u003CLFT_DST>\u002Frootfs\u002Fboot\u002FImage` exist,\n  they must be byte-identical (`cmp -s`); drift means\n  `\u002Fjetson-promote-image`'s [Mirror step](..\u002Fjetson-promote-image\u002FSKILL.md#mirror-kernel-image-into-rootfs-when-kernel-changed)\n  was skipped — route back. **Initramfs presence.**\n  `l4t_initrd_flash.sh` requires `\u003CLFT_DST>\u002Fbootloader\u002Fl4t_initrd.img`\n  and `\u003CLFT_DST>\u002Frootfs\u002Fboot\u002Finitrd`; absent → route to\n  `\u002Fjetson-init-image`. (Freshness vs.\n  `rootfs\u002Flib\u002Fmodules\u002F\u003Cver>\u002F` is not checked here — owned by\n  `\u002Fjetson-promote-image`'s\n  [Refresh initramfs step](..\u002Fjetson-promote-image\u002FSKILL.md#refresh-initramfs-when-kernel-or-modules-changed).)\n\n**5.2 DUT in RCM mode.**\n\n- Verifies the outcome of the \"Put the DUT into recovery mode\" step (either the user-selected\n  `\u003Cboardctl> -t \u003Ctarget>` invocation or the manual fallback).\n- `lsusb -d 0955:` must report at least one device matching the\n  active chip family's recovery VID:PID pair:\n\n  | Chip family | Recovery VID:PID |\n  |---|---|\n  | T23x \u002F Orin | `0955:7X23` (X is any hex digit — module variant) |\n  | T26x \u002F Thor | `0955:7026` |\n\n  For T23x, match on the trailing `23` (e.g. `lsusb -d 0955: | grep -E ' 0955:7.23 '`); a literal `0955:7023` check will miss valid T23x variants.\n\n- Absent → if the \"Put the DUT into recovery mode\" step used `boardctl`, surface its output and\n  refuse; if the \"Put the DUT into recovery mode\" step used the manual path, re-prompt the user to\n  confirm the jumper \u002F button and power-cycle.\n- **This is the gate for everything downstream.** `flash.sh`'s\n  image-generation phase reads EEPROM over the same recovery\n  channel; a device that's not in RCM here will fail there too.\n\n**5.3 EEPROM cross-check vs. active profile.**\n\nRead `board_sku` and `board_FAB` (and any additional dispatch inputs\nthe active chip family uses) from the DUT's EEPROM in recovery mode\nusing `sudo .\u002Fnvautoflash.sh --print_boardid` from\n`\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002F`. The full reference —\nsample output, label-to-dispatch-input mapping, empty-value\nsemantics, and the EEPROM-vs-profile reconciliation table — lives in\n[`references\u002Feeprom-cross-check.md`](references\u002Feeprom-cross-check.md).\n\nRefusal trigger is a *real non-empty disagreement*, never a missing\nvalue. Empty EEPROM values are valid and not a refusal trigger. The\ncross-check is the primary defense against the wrong-target \u002F\nwrong-SKU class of failures whenever both sides supply enough\ninformation to disagree.\n\n**5.4 Default user staging (host-side, interactive).**\n\nA freshly applied `bsp_image` has no Linux user pre-staged. Detect via\n`\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002Frootfs\u002Fhome\u002F` and\n`rootfs\u002Fetc\u002Fpasswd` UID ≥ 1000. If none, issue one `AskUserQuestion`\nwith four click-to-select options: `ubuntu \u002F ubuntu`, `nvidia \u002F nvidia`,\n`custom` (sub-prompt for username + password), or `skip` (OEM wizard\non first boot). Non-`skip` picks run\n`l4t_create_default_user.sh --autologin --accept-license`. Full\ninvocation + rationale in\n[`references\u002Fdefault-user-staging.md`](references\u002Fdefault-user-staging.md).\n\nRecord the resolution so the \"Confirm resolution\" step can display it. This step is **not**\na refusal gate — it is a user-interaction point.\n\n### Confirm resolution\n\nPrint the resolved plan and require explicit acceptance. The format\nis the resolution, not the shell command — the user is approving\n*what* will flash, not the *string* that will be executed:\n\n```\nTarget:         \u003Creference_devkit.name> [+ custom_carrier.name]\nProfile:        target-platform\u002F\u003Cactive>.yaml\nbsp_image:      \u003Cbsp_image.root_path>\u002FLinux_for_Tegra  (version \u003CX>)\nFlash conf:     \u003Cflash_config>   (path verified in the \"Resolve the flash conf path\" step)\n\nDUT EEPROM  →   board_sku=\u003Cvalue-or-(empty)>  board_FAB=\u003Cvalue-or-(empty)>\nProfile     →   module.sku=\u003Cvalue-or-(any)>    module.revision=\u003Cvalue-or-(any)>\n                (reconciled per the \"Preflight checks\" step's EEPROM cross-check)\n\nBoot device:    \u003Cboot-dev>\nFlow tool:      flash.sh  |  l4t_initrd_flash.sh\nboardctl:       \u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002Ftools\u002Fboard_automation\u002Fboardctl\n                (or the path the \"Put the DUT into recovery mode\" step resolved)\nRCM entry:      \u003Cboardctl> -t \u003Cuser-selected target> recovery  |  manual recovery + reset buttons\nPost-flash:     \u003Cboardctl> -t \u003Cuser-selected target> reset   (T26x \u002F Thor)\n                not required — flash tool resets internally    (T23x \u002F Orin)\nDefault user:   \u003Cusername> (autologin)\n              | already staged in rootfs (kept)\n              | none — OEM config wizard on first boot\n```\n\nArtifact paths (`DTB_FILE`, `BPFDTB_FILE`, partition XML, BCTs) are\nnot shown — they are resolved by `flash.sh` from EEPROM at flash\ntime, not by this skill. The \"Preflight checks\" step's EEPROM cross-check is what\nguarantees those flash-time picks will line up with what the profile\nexpects.\n\nThis is the user-acceptance gate. Refuse to fall back to a raw\n\"paste this command\" workflow — that path is how stale doc snippets,\nwrong dashes, and prompt-character paste artifacts make it into\nproduction flashes.\n\n### Invoke the flash\n\nConstruct the command from the resolved variables — never accept a\nverbatim command from the user, the docs, or memory:\n\n```bash\ncd \u003Cbsp_image.root_path>\u002FLinux_for_Tegra\nsudo .\u002F\u003Cflow-tool> [\u003Cresolved flags>] \u003Cboard> \u003Cboot-dev>\n```\n\nAbort and surface the failed step on the first non-zero exit. Do\nnot auto-retry on transient USB errors.\n\n### Post-flash reset (T26x \u002F Thor only)\n\nT26x platforms do **not** auto-reboot from the freshly flashed image\nwhen `flash.sh` \u002F `l4t_initrd_flash.sh` returns. Run, using the\n`\u003Cboardctl>` resolved in the \"Put the DUT into recovery mode\" step and the same target the user\nselected for RCM entry:\n\n```bash\n\u003Cboardctl> -t \u003Cuser-selected target> reset\n```\n\nT23x \u002F Orin issues the reset internally; skip this step on Orin. If\nthe \"Put the DUT into recovery mode\" step used the manual path, prompt the user to remove the\nforce-recovery jumper \u002F button and power-cycle by hand. Gate this\nstep on chip family resolved from the active profile.\n\n### Summary\n\nReport: command line(s) used (flash + post-flash reset if it ran),\nexit code, log location (if teed). Persist the resolved plan and\noutcome where validation can re-read it.\n\n## Limitations\n\n- **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.\n- **Artifact paths resolved at flash time.** `DTB_FILE`, `BPFDTB_FILE`, partition XML, BCTs, DRAM training are picked from EEPROM (`board_sku` \u002F `board_FAB`) by `flash.sh` \u002F `l4t_initrd_flash.sh`; this skill validates only host-side scaffolding.\n- **EEPROM is authoritative over the profile.** Real non-empty disagreement refuses; *empty* EEPROM values are valid.\n- **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.\n- **No transient-error auto-retry.** USB hiccups abort; re-enter RCM and re-invoke.\n- **T26x needs an explicit post-flash reset.** T26x doesn't auto-reboot from a freshly flashed image; `\u003Cboardctl> -t \u003Ctarget> reset` (or manual power-cycle) required. T23x resets internally.\n- **Massflash \u002F `--flash-only`** uses the same tool selection + respective flags; massflash topology setup is out of scope here.\n\n## Troubleshooting\n\n| Error | Cause | Solution |\n|---|---|---|\n| `lsusb -d 0955:` reports nothing matching `0955:7X23` (T23x) or `0955:7026` (T26x) | DUT did not enter RCM mode — `boardctl recovery` failed or the manual recovery + reset sequence didn't take. | If `boardctl` was used, surface its output and re-prompt; manual path, re-confirm the recovery jumper \u002F button and power-cycle. Re-run the \"DUT in RCM mode\" preflight. |\n| Preflight EEPROM cross-check refuses with `board_sku` \u002F `board_FAB` mismatch vs. profile | EEPROM holds a *real non-empty* value that disagrees with `module.sku` \u002F `module.revision` in the active profile. | Fix the profile (`\u002Fjetson-set-target` or `\u002Fjetson-init-target`) to match the DUT's actual EEPROM. Do **not** override EEPROM from the profile — EEPROM is authoritative. |\n| Preflight refuses with \"per-board conf not found\" | Active profile points at a `flash_config` that does not exist under `\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002F`. | For custom carriers: run `\u002Fjetson-derive-carrier` to produce the conf. For reference devkits: re-run `\u002Fjetson-promote-image` \u002F `\u002Fjetson-init-image` to repopulate the BSP image. |\n| Preflight refuses because `rootfs\u002Fetc\u002Fnv_tegra_release` is missing | `apply_binaries.sh` has not been run against `\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002F`. | Re-run `\u002Fjetson-init-image` (which invokes `apply_binaries.sh`) or run `apply_binaries.sh` manually from `Linux_for_Tegra\u002F`. |\n| `boardctl -t \u003Ctarget> recovery` errors out or has no effect | Wrong `boardctl` (a `$PATH` binary instead of the in-tree one) or a target name not enumerated by `\u003Cboardctl> -h`. | Use the in-tree `\u003Cbsp_image.root_path>\u002FLinux_for_Tegra\u002Ftools\u002Fboard_automation\u002Fboardctl`; pick the target from `\u003Cboardctl> -h`. Fall back to manual recovery + reset buttons if needed. |\n| Flash succeeds on T26x but the DUT stays in recovery \u002F does not boot the new image | T26x does not auto-reset out of recovery after `flash.sh` \u002F `l4t_initrd_flash.sh` returns. | Run `\u003Cboardctl> -t \u003Ctarget> reset` (same target used for RCM entry), or for the manual path remove the force-recovery jumper \u002F button and power-cycle. T23x \u002F Orin needs no extra step. |\n| First boot lands on Ubuntu's OEM configuration wizard despite expecting autologin | No default user was staged into `rootfs` before flashing. | Either re-flash after staging via `l4t_create_default_user.sh --autologin --accept-license` (see the default-user-staging step), or complete the OEM wizard on the DUT this once. |\n| `flash.sh` exits non-zero on an artifact-not-found error (DTB \u002F BPFDTB \u002F partition XML) | EEPROM-driven dispatch resolved a filename that doesn't exist in `bsp_image` — usually `\u002Fjetson-promote-image` didn't copy the customized artifact, or the EEPROM SKU is unsupported by the BSP. | Re-run `\u002Fjetson-promote-image`. If the SKU is unsupported, the DUT needs a different BSP version. |\n| `kernel\u002FImage` ↔ `rootfs\u002Fboot\u002FImage` drift, missing `bootloader\u002Fl4t_initrd.img` \u002F `rootfs\u002Fboot\u002Finitrd`, or `modprobe` \"disagrees about version of symbol …\" on the DUT | `\u002Fjetson-promote-image`'s mirror \u002F refresh steps were skipped, or `bsp_image` was hand-edited outside Deploy. | Re-run `\u002Fjetson-promote-image` and re-flash. If initramfs files are entirely absent, run `\u002Fjetson-init-image` first. See [promote-image's kernel-image-and-initramfs reference](..\u002Fjetson-promote-image\u002Freferences\u002Fkernel-image-and-initramfs.md) for the manual escape hatch. |\n\n## References\n\n- [`references\u002Frecovery-mode-boardctl.md`](references\u002Frecovery-mode-boardctl.md) — locate the in-tree `boardctl`, enumerate targets, invoke `recovery` \u002F `reset`, manual fallback (the \"Put the DUT into recovery mode\" step \u002F the \"Post-flash reset\" step details).\n- [`references\u002Feeprom-cross-check.md`](references\u002Feeprom-cross-check.md) — `nvautoflash.sh --print_boardid` sample, label-to-dispatch-input map, EEPROM-vs-profile reconciliation table (used by the \"Preflight checks\" step).\n- [`references\u002Fdefault-user-staging.md`](references\u002Fdefault-user-staging.md) — `l4t_create_default_user.sh` invocation + flag rationale (used by the \"Preflight checks\" step).\n- [`..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md`](..\u002F..\u002Fcontext\u002Ftarget-platform-contract.md) — target-platform contract.\n- [`..\u002F..\u002Fcontext\u002Fbsp-customization-workflow.md`](..\u002F..\u002Fcontext\u002Fbsp-customization-workflow.md#workflow-invariants) — Workspace edit protocol (this skill is the flash leg of Deploy).\n- [Per-board conf dispatch](..\u002F..\u002Fcontext\u002Fbsp-customization-software-layers.md#per-board-conf-dispatch--update_flash_args_common) — `\u003Cboard>`, DTB, and BCT resolution from the active profile.\n- [`..\u002Fjetson-promote-image\u002FSKILL.md`](..\u002Fjetson-promote-image\u002FSKILL.md) — prior leg; copies overlay → bsp_image.\n- [`..\u002Fjetson-derive-carrier\u002FSKILL.md`](..\u002Fjetson-derive-carrier\u002FSKILL.md) — produces the custom carrier's flash conf consumed by the \"Resolve the flash conf path\" step.\n",{"name":5,"license":15,"version":24,"metadata":25,"description":7},"0.0.1",{"tags":26,"author":29,"domain":30,"data-classification":31},[27,28],"bsp","flash","Jetson Team","meta","public","main","1c523aba5cdf867a79f078847075492d7778092a","skills\u002Fnvidia\u002Fjetson-flash-image",1,"https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills","https:\u002F\u002Fskills.x402.wtf","https:\u002F\u002Fgithub.com\u002Fthemusebook","https:\u002F\u002Fmusebook.trade","The official Github of musebook","2026-11-02 23:42:26",{"source":8,"skillName":5,"commands":43,"prompt":53,"zipAvailable":54},[44,47,50],{"tool":45,"command":46},"npx","npx skills add themusebook\u002Fskills --skill jetson-flash-image",{"tool":48,"command":49},"bunx","bunx skills add themusebook\u002Fskills --skill jetson-flash-image",{"tool":51,"command":52},"pnpm","pnpm dlx skills add themusebook\u002Fskills --skill jetson-flash-image","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fjetson-flash-image\u002FSKILL.md",true,[56,62,66,70,74,78,82],{"path":57,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":60,"sourceHtmlUrl":61},"BENCHMARK.md","REFERENCE","参考文档",3689,"https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fjetson-flash-image\u002FBENCHMARK.md",{"path":63,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":64,"sourceHtmlUrl":65},"evals\u002Fevals.json",5927,"https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fjetson-flash-image\u002Fevals\u002Fevals.json",{"path":67,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":68,"sourceHtmlUrl":69},"references\u002Fdefault-user-staging.md",1814,"https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fjetson-flash-image\u002Freferences\u002Fdefault-user-staging.md",{"path":71,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Feeprom-cross-check.md",3343,"https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fjetson-flash-image\u002Freferences\u002Feeprom-cross-check.md",{"path":75,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Frecovery-mode-boardctl.md",3044,"https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fjetson-flash-image\u002Freferences\u002Frecovery-mode-boardctl.md",{"path":79,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":80,"sourceHtmlUrl":81},"skill-card.md",3771,"https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fjetson-flash-image\u002Fskill-card.md",{"path":83,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":87},"skill.oms.sig","OTHER","其他",5337,"https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fnvidia\u002Fjetson-flash-image\u002Fskill.oms.sig",[89,98,105,112,119,126],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":93,"licenseFileUrl":94,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":19},"01M7AB34SPKVSDRRG009PM1CZH","youtube-clipper","YouTube 视频智能剪辑工具。下载视频和字幕，AI 分析生成精细章节（几分钟级别）， 用户选择片段后自动剪辑、翻译字幕为中英双语、烧录字幕到视频，并生成总结文案。 使用场景：当用户需要剪辑 YouTube 视频、生成短视频片段、制作双语字幕版本时。 关键词：视频剪辑、YouTube、字幕翻译、双语字幕、视频下载、clip video","MIT","https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube-clipper\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube-clipper\u002FSKILL.md",[],[],{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":93,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":19},"01M7AB18BH6N7KR7939HRNWVMQ","viem-integration","Integrate EVM blockchains using viem. Use when user says \"read blockchain data\", \"send transaction\", \"interact with smart contract\", \"connect to Ethereum\", \"use viem\", \"use wagmi\", \"wallet integration\", \"viem setup\", or mentions blockchain\u002FEVM development with TypeScript.","https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fviem-integration\u002FSKILL.md",[],[],{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":93,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":19},"01M7AB12GHGP48WCNXDQQ9222H","v4-security-foundations","Security-first Uniswap v4 hook development. Use when user mentions \"v4 hooks\", \"hook security\", \"PoolManager\", \"beforeSwap\", \"afterSwap\", or asks about V4 hook best practices, vulnerabilities, or audit requirements.","https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fv4-security-foundations\u002FSKILL.md",[],[],{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":93,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":19},"01M7AB0XM3PSR7V3Q2ZRR0Q0FB","v4-sdk-integration","App-layer SDK guide for building swap and liquidity experiences directly with the Uniswap v4 SDK. Use when user asks about \"v4 sdk\", \"uniswap v4\", \"v4 swap\", \"v4 liquidity\", \"PoolManager\", \"V4Planner\", \"StateView\", \"PositionManager\", \"pool state\", \"v4 position\", \"uniswap sdk\", or when building swap\u002Fliquidity UX directly with SDKs rather than via the Trading API.","https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fv4-sdk-integration\u002FSKILL.md",[],[],{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":93,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":19},"01M7AB0SGA93ASA588DJW4P9WT","v4-hook-generator","Generate Uniswap v4 hook contracts via OpenZeppelin MCP. Use when building custom swap logic, async swaps, hook-owned liquidity, custom curves, dynamic fees, MEV protection, limit orders, or oracle hooks.","https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fv4-hook-generator\u002FSKILL.md",[],[],{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":93,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":19},"01M7AAZYH75H4CS03WSW2EZ8DM","testing","For testing with Light Protocol programs and clients on localnet, devnet, and mainnet validation.","https:\u002F\u002Fgithub.com\u002Fthemusebook\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002FSKILL.md",[],[]]