You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The daemon's deploy dispatch has no CH32V arm — Platform::Ch32v falls into the catch-all in crates/fbuild-daemon/src/handlers/operations/deploy.rs (~line 805):
_ => {returnErr(FbuildError::DeployFailed(format!("deployer for {:?} not yet implemented", platform)));}
Meanwhile every one of the 17 CH32V board JSONs advertises a full upload story:
and docs/BOARD_STATUS.md lists "CH32V (RISC-V) Platform - Supported". So a user who builds successfully and runs fbuild deploy tests/platform/ch32v003 -e ch32v003 gets a hard failure after the daemon has already preempted the chosen serial port (preemption is correctly released in the error path, but the UX is: everything claims deploy works until the last step).
Supporting gaps
No WCH-Link probe recognition anywhere in the deploy/serial stack. crates/fbuild-serial/src/boards.rs (~line 602) classifies every0x1A86 (WCH/QinHeng) device as Esp32ExternalUart via a VID wildcard — a WCH-Link (RV mode 1a86:8010, DAP mode 1a86:8012) or a CH32V's native CDC gets labeled as an "ESP32 external UART bridge".
Per the repo rule, WCH-Link VID/PID identity must come from the FastLED/boards registry (the vid-ingest: WCH / QinHeng (0x1A86 — CH32V/X + CH340 bridges) #730 vid-ingest already covered 0x1A86 families — verify the probe entries are present there rather than hardcoding).
Suggested direction
Same shape as the LPC probe-rs path (crates/fbuild-deploy/src/probe_rs.rs): a pinned, checksummed wlink (or minichlink) binary managed under ~/.fbuild/{prod|dev}/tools/, a Ch32vDeployer implementing the Deployer trait, dispatch keyed off board.upload.protocol, and WCH-Link presence detection via FastLED/boards profiles. Until that lands, at minimum the error message should say "CH32V flashing is not implemented yet — use wlink/minichlink manually" instead of the generic not yet implemented, and BOARD_STATUS should say build-only.
Severity: HIGH (advertised user-facing capability is absent).
Part of the CH32V pipeline audit (#1102).
What happens
The daemon's deploy dispatch has no CH32V arm —
Platform::Ch32vfalls into the catch-all incrates/fbuild-daemon/src/handlers/operations/deploy.rs(~line 805):Meanwhile every one of the 17 CH32V board JSONs advertises a full upload story:
and
docs/BOARD_STATUS.mdlists "CH32V (RISC-V) Platform - Supported". So a user who builds successfully and runsfbuild deploy tests/platform/ch32v003 -e ch32v003gets a hard failure after the daemon has already preempted the chosen serial port (preemption is correctly released in the error path, but the UX is: everything claims deploy works until the last step).Supporting gaps
crates/fbuild-serial/src/boards.rs(~line 602) classifies every0x1A86(WCH/QinHeng) device asEsp32ExternalUartvia a VID wildcard — a WCH-Link (RV mode1a86:8010, DAP mode1a86:8012) or a CH32V's native CDC gets labeled as an "ESP32 external UART bridge".Suggested direction
Same shape as the LPC probe-rs path (
crates/fbuild-deploy/src/probe_rs.rs): a pinned, checksummedwlink(orminichlink) binary managed under~/.fbuild/{prod|dev}/tools/, aCh32vDeployerimplementing theDeployertrait, dispatch keyed offboard.upload.protocol, and WCH-Link presence detection via FastLED/boards profiles. Until that lands, at minimum the error message should say "CH32V flashing is not implemented yet — use wlink/minichlink manually" instead of the genericnot yet implemented, and BOARD_STATUS should say build-only.Severity: HIGH (advertised user-facing capability is absent).