[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71NKPZ9ENMAJJ1VRPVRNB1W":3,"skill-same:01M71NKPZ9ENMAJJ1VRPVRNB1W":102},{"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":23,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":14,"repositoryHtmlUrl":52,"repositoryHomepageUrl":53,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M71NKPZ9ENMAJJ1VRPVRNB1W","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.","pattanation\u002FNorvik","pattanation","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F235419268?v=4","01M71M5THHYYB15ME8R2E4FCZG","Patta","01M71M5TJM1NDM992M8PDKYR2K",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fjetson-flash-image\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37],"jetson flash image","image","flash","do","for","mode","Meta","promotion","use","team","via","customization","public","rcm","2026-11-10 10:56:23",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":43,"metadata":44,"description":7},"0.0.1",{"tags":45,"author":47,"domain":48,"data-classification":36},[46,26],"bsp","Jetson Team","meta","claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Fjetson-flash-image","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik","https:\u002F\u002Fnorvik-orpin.vercel.app","https:\u002F\u002Fgithub.com\u002Fpattanation","2026-07-17 11:17:04",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add pattanation\u002FNorvik --skill jetson-flash-image",{"tool":62,"command":63},"bunx","bunx skills add pattanation\u002FNorvik --skill jetson-flash-image",{"tool":65,"command":66},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill jetson-flash-image","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fjetson-flash-image\u002FSKILL.md",true,[70,76,80,84,88,92,96],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"BENCHMARK.md","REFERENCE","参考文档",3689,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fjetson-flash-image\u002FBENCHMARK.md",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"evals\u002Fevals.json",5927,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fjetson-flash-image\u002Fevals\u002Fevals.json",{"path":81,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fdefault-user-staging.md",1814,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fjetson-flash-image\u002Freferences\u002Fdefault-user-staging.md",{"path":85,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Feeprom-cross-check.md",3343,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fjetson-flash-image\u002Freferences\u002Feeprom-cross-check.md",{"path":89,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Frecovery-mode-boardctl.md",3044,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fjetson-flash-image\u002Freferences\u002Frecovery-mode-boardctl.md",{"path":93,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":94,"sourceHtmlUrl":95},"skill-card.md",3771,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fjetson-flash-image\u002Fskill-card.md",{"path":97,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":100,"sourceHtmlUrl":101},"skill.oms.sig","OTHER","其他",5337,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fjetson-flash-image\u002Fskill.oms.sig",[103,111,118,125,156,181],{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":110},"01M73Z1NPMJ667E0DSPBS9FH0B","jetson-set-target","Switch the active Jetson target-platform pointer to an existing profile YAML. Use before customize\u002Fbuild\u002Fflash to change target; not for authoring profiles — use jetson-init-target instead.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fjetson-set-target\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":110},"01M73YC29YWGCW521P7B0NM3HQ","earth2studio-data-fetch","Fetch weather\u002Fclimate data via Earth2Studio data sources for specific variables and times. Do NOT use for inference pipelines, model discovery, or installation.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fearth2studio-data-fetch\u002FSKILL.md",[],[],{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":110},"01M73YBNHMHFDFP83MAVGQQ92N","earth2studio-create-datasource","Create and validate Earth2Studio data source wrappers (DataSource, ForecastSource, DataFrameSource, ForecastFrameSource) from remote stores. Do NOT use for fetching data with existing sources, model inference, or installation tasks.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fearth2studio-create-datasource\u002FSKILL.md",[],[],{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":129,"sourceHtmlUrl":130,"categories":131,"keywords":138,"publishedAt":155},"01M71QDV4DM8T19HEHWATEF1K4","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[132,135],{"categoryNo":133,"categoryName":134,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":136,"categoryName":137,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[139,140,141,142,143,28,144,145,146,147,148,149,150,151,152,153,154],"webapp","testing","webapp testing","local","screenshots","applications","browser","ui","behavior","web","playwright","with","frontend","debugging","toolkit","logs","2026-11-10 13:02:02",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":160,"sourceHtmlUrl":161,"categories":162,"keywords":164,"publishedAt":155},"01M71QDH2GGMXGA9105C9W1N7B","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FSKILL.md",[163],{"categoryNo":136,"categoryName":137,"taxonomyType":21,"taxonomyTypeDesc":22},[165,148,166,167,168,169,170,171,172,173,174,175,28,176,177,151,178,32,179,180],"web artifacts builder","artifacts","artifacts builder","builder","multi","state","routing","state management","react","single-file","css","Tailwind","ui components","single","file","components",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":185,"licenseFileUrl":186,"sourceHtmlUrl":187,"categories":188,"keywords":190,"publishedAt":155},"01M71QD9T2XC3EWMQNN9ACNWQ1","vueuse-functions","Apply VueUse composables where appropriate to build concise, maintainable Vue.js \u002F Nuxt features.","MIT","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FSKILL.md",[189],{"categoryNo":136,"categoryName":137,"taxonomyType":21,"taxonomyTypeDesc":22},[191,192,193,194,195,196,197,198,199,200,201,202,203,204],"vueuse","vueuse functions","functions","composables","project","nuxt","apply","github","concise","build","https","features","vue","js"]