free-wili-2¶
Free-WiLi 2 — multi-function hardware-hacking tool presenting six USB devices
Vendor: Intrepid Control Systems / FREE-WILi
Status: supported — the identifiers and setup recipe are believed correct.
Maintainer-verified 2026-08-26 on Pop!_OS 22.04: Attached and enumerated. All six USB devices captured with scripts/identify-device.sh, including vendor and product strings and serials. Nothing was run against the hardware and no firmware was flashed.
What it is¶
A multi-function hardware-hacking tool that presents as an internal USB hub carrying six devices: a main interface with four serial ports, a secondary interface, a mass-storage interface, an FTDI FT232H bridge, an RP2040 CMSIS-DAP debug probe, and an ESP32-S3.
What you can do with it¶
Drive several hardware interfaces from one board — serial, SPI/I2C through the FT232H, SWD debugging through the CMSIS-DAP probe, and whatever the ESP32-S3 is running. Per D-026 this catalog installs the tooling to talk to it, not the capability of the firmware it runs.
Setup¶
Join dialout and plugdev, then log out and back in — group membership does not apply to a session already open. Attach it and expect SIX entries in lsusb, not one; that is correct and not a fault. The four ACM ports appear as /dev/ttyACM0 through ACM3 in plug order, so use /dev/serial/by-id/ rather than a raw device path.
Known problems¶
Plug order determines which /dev/ttyACM number each port gets, and there are four of them on one device plus more from the debug probe — this is exactly the case /dev/serial/by-id/ exists for. Two of the six identifiers are shared silicon rather than this product: the FT232H is distinguishable only by its product string, and the ESP32-S3's 303a:1001 is byte-identical to the Clip-Boy's, product string included, so nothing but the serial separates them. Any udev rule for this board must match on product, never on VID:PID alone.
How it identifies itself¶
| USB id | What | Confirmed | Node |
|---|---|---|---|
093c:2059 |
Free-WiLi 2 main interface — four CDC ACM ports | yes | serial |
093c:205a |
Free-WiLi 2 secondary interface, reporting firmware v07 | yes | serial |
093c:205f |
Free-WiLi 2 mass-storage interface ("FW Ultra Fast Media") | yes | storage |
0403:6014 |
FTDI FT232H bridge inside the Free-WiLi 2 | yes | serial |
2e8a:000c |
RP2040 CMSIS-DAP debug probe built into the board | yes | serial |
303a:1001 |
Espressif ESP32-S3 native USB JTAG/serial peripheral | yes | serial |
⚠ 0403:6014 is not unique to this device (kernel_generic_driver; also used by: any board using an FTDI FT232H). Debian 13 modules.alias binds 0403:6014 to ftdi_sio, and usb.ids names it "FT232H Single HS USB-UART/FIFO IC" — a chip, not a product. It is on the generated ambiguity list. What makes it usable here is that this board sets a device-specific product string, "FW2", so ATTRS{product} distinguishes it from any other FT232H.
⚠ 2e8a:000c is not unique to this device (vendor_chip_default; also used by: any RP2040 running the CMSIS-DAP debug-probe firmware). Vendor 2e8a is Raspberry Pi and 000c is the stock identifier for the RP2040-based debug probe firmware, so any board running it presents the same pair. Not on the generated list, which reads Debian's udev rules and the kernel's module table: this device is claimed by cdc_acm on class rather than by identifier, so neither source sees it. That is a limit of the sweep, recorded here rather than left implicit.
⚠ 303a:1001 is not unique to this device (vendor_chip_default; also used by: clip-boy, minino, every ESP32-S3 or ESP32-C3 board using native USB). esptool calls 0x1001 USB_JTAG_SERIAL_PID, a constant of the ESP32-S3/C3 USB-serial-JTAG peripheral. CONFIRMED BY CAPTURE rather than inferred: the Clip-Boy and the Minino present the identical pair AND the identical product string, and all three are unrelated products. Only the serial differs, and a serial is per-unit.
What is not yet known¶
Narrowed to one thing, and it is now a named field rather than a paragraph. Every identifier is confirmed against hardware, but 093c:2059 presents four CDC ACM ports and port_roles on it is empty because which port carries which function is not known here. Naming one of them /dev/free-wili would be a coin toss, and /dev/serial/by-id/ gives all four a stable path while labelling none of them — a stable path to a port you cannot identify is not an answer. Upstream documentation or a functional test settles it; the schema will then take four names in order, and it takes four or none, because a partial map reads as a complete one.
Who can close it: the maintainer owns this hardware; the gap closes at the next capture session.
Access and permissions¶
Group membership required: dialout, plugdev — added at install, applies at next login.
Software that makes it useful¶
Upstream: https://freewili.com/