fix(rp2040): encode complete firmware at XIP address

CLAUDE.md

@@ -21,6 +21,15 @@ The four rules an agent must internalize before doing anything else (all listed
 
 ## Essential Rules
 
+- **USB VID/PID source of truth:** Never add or embed a board/device VID or PID
+  in fbuild code, tests used by production, generated Rust tables, or release
+  artifacts. All VID/PID records must come from the published
+  [FastLED/boards](https://github.com/FastLED/boards) registry and be ingested
+  through its normal build/publish pipeline. Test-only fixtures may use
+  synthetic or copied IDs to exercise parsing and selection, but they must not
+  become runtime defaults. If a VID/PID is missing, fix the boards registry;
+  do not add an exception here.
+
 - **Modules-first for new functionality; crate splits only for compile parallelism (backed by `--timings`).** New *functionality* is still folded into an existing crate as a *module*, never a drive-by new crate — that original rule (no scope-creep crates) stands. The one sanctioned reason to add a workspace member is **splitting an existing giant crate to compile in parallel**, backed by `cargo build --timings` data and maintainer sign-off (FastLED/fbuild#1008 is that sign-off for the `fbuild-build` / `fbuild-packages` splits). Such splits keep the original crate as a thin **facade** that re-exports the extracted crates at their old paths, so consumers are unchanged. If code is needed by two crates that can't depend on each other (e.g. the CLI and the daemon), put the shared, dependency-free pieces in a crate both already depend on (`fbuild-core` / `fbuild-paths`). Enforced by CI (`crate-gate.yml` → `ci/check_workspace_crates.py`): adding a workspace member fails the build unless you also add it to the approved allowlist (and `ci/hooks/crate_guard.py`) with a maintainer-reviewed rationale.
 - **Always use a globally-installed `soldr` to execute Rust commands.** Bare cargo/rustc and legacy `uv run cargo` shims are blocked by hook. soldr uses `rustup which` to pick the rustup-managed toolchain from `rust-toolchain.toml`. The standard Cargo path is `soldr cargo ...`, so repo Rust builds get soldr's managed zccache path by default; do not add repo-specific `RUSTC_WRAPPER` wiring for normal builds. Install soldr globally via `uv tool install soldr` (or see https://github.com/zackees/soldr).
 - **Always use `uv` for Python.** Bare `python`/`pip` are blocked by hook. Use `uv run ...` or `uv pip ...`.

crates/fbuild-core/data/README.md

@@ -1,11 +1,13 @@
 # fbuild-core embedded data
 
-Binary blobs `include_bytes!`'d into `fbuild-core` at compile time.
+This directory contains test fixtures and build-cache documentation. Board USB
+VID/PID data is **not** a built-in fbuild runtime table: it is ingested from
+the published FastLED/boards artifacts during the build/cache phase.
 
 | File                    | Purpose                                                                                                                                                                                                                          |
 | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `usb-vendors.tar.zst`   | USB Vendor-ID → vendor-name map (long-tail fallback, ~2.2k VIDs). Produced by `online-data-tools/build_vendor_archive.py`. See `crate::usb::embedded`. |
-| `usb-vids.proto.zstd`   | Compact VID:PID → {vendor, product} overlay **and** a VID → vendor map, in one artifact. Produced by the **FastLED/boards** data pipeline (`builders/build_usb_ids.py` over the `platformio`/`arduino`/`vendors`/`other` branches). Baked in so full VID + VID:PID resolution works OFFLINE with no hardcoded per-board tables. See `crate::usb::data` (`embedded()`), consumed by `usb::resolve`. |
+| `usb-vids.proto.zstd`   | Test fixture for the compact VID:PID overlay produced by **FastLED/boards**. It must never be used as a production built-in catalogue. Production ingestion fetches/consumes the published boards artifact. |
 
 ## How to refresh the VID:PID overlay (`usb-vids.proto.zstd`)
 
@@ -15,16 +17,17 @@ workflow regenerates the artifact on every push to a data branch
 (`platformio`/`arduino`/`vendors`/`other`).
 
 ```bash
-# Regenerate from the boards repo (all four data branches), then copy in:
-#   cd ../boards && python builders/site.py ...   # or fetch the published artifact
-cp <boards-out>/usb-vids.proto.zstd crates/fbuild-core/data/usb-vids.proto.zstd
+# The production path consumes the published artifact directly; do not copy
+# it into a runtime source file or commit a refreshed built-in VID/PID table:
+curl -fsSLo <cache>/usb-vids.proto.zstd https://fastled.github.io/boards/usb-vids.proto.zstd
 soldr cargo test -p fbuild-core usb::
 ```
 
 To add a new board/probe resolution (e.g. a debug-probe VID:PID), edit the
-data on the FastLED/boards `vendors` (or `other`) branch — NOT a hardcoded
-table in fbuild — and re-run the boards pipeline. The proto then carries it
-through to fbuild's `usb::resolve` on the next refresh.
+data on the FastLED/boards `vendors` (or `other`) branch — **never** a
+hardcoded table or embedded runtime blob in fbuild — and re-run the boards
+pipeline. The published artifact then carries it through to fbuild's
+`usb::resolve` on the next ingestion.
 
 ## How to refresh the vendor archive
 

crates/fbuild-deploy/src/rp2040.rs

@@ -19,9 +19,12 @@ const UF2_MAGIC_END: u32 = 0x0AB1_6F30;
 const UF2_FLAG_FAMILY_ID_PRESENT: u32 = 0x0000_2000;
 const RP2040_FAMILY_ID: u32 = 0xE48B_FF56;
 const RP2350_FAMILY_ID: u32 = 0xE48B_FF59;
-// The RP2040 ROM UF2 converter addresses flash as an offset. The official
-// Arduino-Pico converter defaults BIN input to 0x2000, not the MCU XIP alias.
-const RP2040_UF2_BASE_ADDRESS: u32 = 0x0000_2000;
+// fbuild's firmware.bin is the complete flash image: it starts with the
+// second-stage bootloader at the RP2040 XIP address 0x1000_0000. The 0x2000
+// default used by Arduino-Pico's uf2conv.py is only for app-only BINs whose
+// boot2 has already been stripped. Encoding this full image at 0x2000 leaves
+// stock ROM BOOTSEL in place after an apparently successful copy.
+const RP2040_UF2_BASE_ADDRESS: u32 = 0x1000_0000;
 const UF2_PAYLOAD_SIZE: usize = 256;
 const UF2_BLOCK_SIZE: usize = 512;
 
@@ -386,6 +389,19 @@ mod tests {
         );
     }
 
+    #[test]
+    fn full_image_boot2_uses_xip_address() {
+        // Prefix emitted by the RP2040 second-stage bootloader in FastLED's
+        // complete firmware.bin artifact.
+        let boot2_prefix = [0x00, 0xB5, 0x32, 0x4B, 0x21, 0x20, 0x58, 0x60];
+        let uf2 = encode_uf2(&boot2_prefix);
+        assert_eq!(
+            u32::from_le_bytes(uf2[12..16].try_into().unwrap()),
+            0x1000_0000
+        );
+        assert_eq!(&uf2[32..40], &boot2_prefix);
+    }
+
     #[test]
     fn finds_marker_volume_without_requiring_a_drive_letter() {
         let root = tempdir().unwrap();