The Ox64 board (left) linked via UART to a KB2040 bridge (right) to enable flashing.
*An $8 RISC‑V board can run Linux, but only after a maze of UART hacks, tool patches, and missing peripherals. The community’s work shows both the promise and the pain of ultra‑cheap hardware.*
On December 15, 2022 a blog post announced the Ox64, an $8 RISC‑V board that can run Linux. The claim stunned hobbyists: a full Unix environment on a price tag lower than a coffee. The reality, however, is a gauntlet of hardware quirks and software roadblocks. Ethernet, Wi‑Fi and SD‑Card are dead on arrival, and the board refuses USB programming. The only path forward is a UART‑only flash process that demands a separate microcontroller, a patched flashing tool, and a Linux desktop running Xorg. The community’s step‑by‑step documentation turns a $8 curiosity into a barely functional Linux host.
The Ox64 is an $8 single‑board computer built around capable RISC‑V cores. It ships with three heterogeneous cores, not a stripped‑down kernel, and advertises Linux capability. At the time of writing, Ethernet, Wi‑Fi and SD‑Card interfaces are non‑functional, limiting its out‑of‑the‑box usefulness. Its form factor resembles a microcontroller, yet it behaves like a UNIX machine. This duality makes it a tantalizing target for hobbyists seeking a full OS on a minimal budget, while also exposing the gaps between spec and reality.
The board cannot be programmed via USB like an Arduino or ESP32. Flashing must occur over the UART TX/RX pins, specifically GPIO14 and GPIO15 plus ground. Early attempts with a CH340G dongle failed handshake in DevCube. The community discovered that an RP2040 device (e.g., a KB2040) can act as a serial bridge. The bridge wiring ties RP2040 GPIO‑4 to Ox64 GPIO‑15 and RP2040 GPIO‑5 to Ox64 GPIO‑14, with grounds shared. Loading the RP2040 with picoprobe (boot hold + UF2 upload) enables the bridge. DevCube still refuses to flash, so users switch to the open‑source bflb‑mcu‑tool, after stripping DTR/RTS handling from its Python UART library. The final command—bflb‑mcu‑tool --chipname=bl808 --port=/dev/ttyACM2 --baudrate=2000000 --firmware=out/low_load_bl808_m0.bin—successfully loads the low‑load binary.
Running the DevCube flashing tool on Ubuntu with Wayland triggers a core dump. The error log shows missing symbols in libdconfsettings.so and a GLib‑GIO schema mismatch. The tool expects an Xorg session; switching the desktop environment or forcing X11 (e.g., GDK_BACKEND=x11) avoids the crash. Community comments confirm the same issue on Ubuntu 22.04, noting that the warning flood can be ignored once X11 is forced.
After the UART bridge and tool patch, the Ox64 boots the low‑load BL808 M0 firmware. The console reports "dynamic memory init success, heap size = 156 Kbyte" followed by "E907 start... mtimer clk:1000000 psram clk init ok!" This confirms basic CPU and memory initialization and a functional serial link to the host PC. However, higher‑level components—Ethernet, Wi‑Fi, SD‑Card, and the full Linux OS—remain unflashed. The author promises a follow‑up to load the D0 core and the complete OS.
No, the Ox64 must be programmed through its UART TX/RX pins (GPIO14 and GPIO15) using an external serial bridge.
The tool fails due to missing GLib‑GIO symbols and schema keys under Wayland; switching to Xorg or forcing X11 resolves the crash.
The console prints "dynamic memory init success, heap size = 156 Kbyte" and "E907 start... mtimer clk:1000000 psram clk init ok!" after flashing the low_load_bl808_m0.bin.
The Ox64 illustrates how ultra‑low‑cost hardware can deliver on headline specs, yet still require deep technical gymnastics to become usable. The current milestone—getting a console output—shows the board is alive, but the missing peripherals and unfinished OS stack keep it in the prototype zone. Future updates will reveal whether the community can bridge that gap or if the $8 promise remains a proof‑of‑concept.
Sources: [Hacker News – The $8 Linux Computer (2022)]