research: audit and publish Pico/Pico 2 USB identities

[zackees]

Context

The boards registry already contains some Raspberry Pi / Arduino-Pico records, but Pico-family coverage is currently an aggregate of several upstream layers and does not guarantee that every official and common variant is published with a provenance-backed USB identity. fbuild now consumes the published FastLED/boards artifacts, so missing or conflated identities directly affect strict device selection and stock-board bring-up.

The initial investigation found these authoritative anchors:

• Raspberry Pi's USB PID allocation registry assigns VID 0x2E8A, including 0x000A for Pico SDK CDC UART and 0x000F for RP2350 boot, plus commercial allocations: https://github.com/raspberrypi/usb-pid
• Arduino-Pico's core sets the default runtime CDC identity to USBD_VID=0x2E8A, USBD_PID=0x000A for RP2040 and defines the Pico 2 board with 0x000F: https://github.com/earlephilhower/arduino-pico/blob/master/platform.txt
• Raspberry Pi's picotool explicitly supports RP2040/RP2350 BOOTSEL devices and should be used as a cross-check for bootloader identities: https://github.com/raspberrypi/picotool

Proposal

Perform an internet-backed, source-by-source sweep of Raspberry Pi-branded Pico variants and the common RP2040/RP2350-compatible variants represented by the Arduino-Pico board catalog. Confirm each USB identity from an upstream board definition, vendor allocation, firmware source, datasheet, or reproducible OS/descriptor report. Record the result on the appropriate data branch (arduino, vendors, other, or platformio) rather than editing generated site artifacts directly.

The sweep should explicitly cover:

• Pico / Pico H / Pico W / Pico WH
• Pico 2 / Pico 2 H / Pico 2 W / Pico 2 WH
• RP2040 and RP2350 board variants present in Arduino-Pico (including boards whose runtime VID/PID is inherited from the Raspberry Pi default)
• ROM BOOTSEL versus application CDC identities, including composite-mode PID variants
• Boards with a dedicated vendor VID/PID versus boards that intentionally reuse 2e8a:000a or 2e8a:000f

Every accepted record must include normalized lowercase VID/PID, product/board name, source URL or immutable upstream reference, source class, and a note when the PID is a bootloader-only identity or a runtime-only identity. Do not infer a runtime serial endpoint from the 2e8a:0003 mass-storage BOOTSEL device.

Acceptance criteria

• The internet research covers all official Pico/Pico 2 variants and the in-scope Arduino-Pico RP2040/RP2350 variant set.
• Each published VID:PID has authoritative provenance and clearly distinguishes BOOTSEL, runtime CDC, and composite-mode variants.
• Confirmed records land on the correct source data branch and are regenerated through the normal boards pipeline; no generated site-src/public hand edits.
• usb-ids.json, usb-vids.proto.zstd, SQLite, and portal search contain the new records after the site build.
• Duplicate/collision handling is documented where multiple boards intentionally share a VID:PID.
• fbuild can ingest the published artifacts without maintaining a second hard-coded Pico VID/PID table.
• Add regression tests for stock 2e8a:0003, RP2040 CDC 2e8a:000a, and RP2350/Pico 2 identities, including a negative case proving an unrelated CP210x device is not selected.
• Report unresolved or vendor-customized identities separately rather than guessing.

Open questions

• Which third-party boards should be considered “common” enough for the first publication pass beyond the Arduino-Pico catalog? Prefer a documented cutoff (for example, boards present in the current upstream catalog) over an unbounded scrape.
• Should composite PID aliases be published as separate product rows with a shared board link, or represented only in board metadata?

Related issues

• vendors: ingest upstream PID allocation registries + Arduino-core boards.txt (vendors branch sync) #43 tracks the broader upstream vendor/Arduino synchronization work; this issue is the Pico-family research and curation deliverable that must be verified as part of that pipeline.

[zackees]

Source audit update (2026-07-14): the current curated Pico rows need one material correction before closeout.

Authoritative identities:

• Raspberry Pi USB allocation registry at commit 48da2334: VID 2e8a; 0003 = RP2040 USB boot, 000f = RP2350 USB boot, 000a = RP2040 SDK CDC, with additional allocated SDK/MicroPython/debug IDs. https://github.com/raspberrypi/usb-pid/blob/48da2334f523aaca93a5afab4c926a5530997917/Readme.md
• Official picotool source at 282a3ca: 2e8a:0003 RP2040 USBBOOT/BOOTSEL, 2e8a:000f RP2350 USBBOOT/BOOTSEL, and 2e8a:000a RP2040 stdio USB. https://github.com/raspberrypi/picotool/blob/282a3ca05edde0375ec3481be56d59e2c256a8ce/picoboot_connection/picoboot_connection.h#L19-L25
• Arduino-Pico MakeBoard source at 49c5f9a: Pico 2e8a:000a, Pico W 2e8a:f00a, Pico 2 2e8a:000f, Pico 2 W 2e8a:f00f. https://github.com/earlephilhower/arduino-pico/blob/49c5f9a9b7c6eaff0aad79437aac5523044da386/tools/makeboards.py

Therefore the #45 row describing 2e8a:0003 as BOOTSEL for both RP2040 and RP2350 is wrong. It must be split/corrected: RP2040 BOOTSEL=0003; RP2350 BOOTSEL=000f. Note that 000f is also Arduino-Pico's Pico 2 runtime identity, so typed role/profile metadata—not VID:PID alone—must distinguish the two states.

Pico H/WH and Pico 2 H/WH are header/mechanical variants of their base silicon families; publish them as aliases to the base profiles, not guessed new IDs. Raspberry Pi's product documentation is the product-family source: https://www.raspberrypi.com/documentation/microcontrollers/pico-series.html

Arduino-Pico currently defines 148 profiles / 111 base VID:PID pairs and programmatically generates composite PID aliases. Those aliases should be represented as descriptor modes/masks in the semantic profile artifact, not expanded into hundreds of independent board claims. The audit found intentional collisions across many third-party profiles, including 2e8a:000a, 2e8a:000f, 2e8a:f00a, 2e8a:f00f, 1b4f:0026, and others; strict selection therefore needs board/profile/role metadata and ambiguity handling.

Required data changes for this issue:

1. Correct/split RP2040 and RP2350 BOOTSEL roles.
2. Add Pico W and Pico 2 W runtime profiles and H/WH aliases.
3. Import Arduino-Pico identities as software-configured runtime profiles with immutable source provenance, not as stock bootloader claims.
4. Preserve collisions and composite aliases explicitly.
5. Add negative coverage proving CP210x 10c4:ea60 is not selected as a Pico.
6. Report vendor-customized boot identities as unresolved unless a primary source or physical descriptor proves them.

#47 and PR #48 provide the typed role/profile schema needed to publish these distinctions without hardcoding them in fbuild.