A two-month trial of the XuanTie A210 Melon Pi ended with only I2C and UART usable: HDMI, GPIO, SPI and USB UVC all failed. We map each symptom to a triage step and contrast it with what upstream BSP work actually decides.
A two-month hands-on review of a RISC-V development board is worth reading when the author is willing to say the project failed. On 4 November 2026, 21ic user donatello1996 published a trial report on the Zhizhu XuanTie A210 "Melon Pi" board that ends with the board being returned early and the author admitting the demo was cut down to whatever the hardware would actually do.
The report is not a rant. It is a fairly precise inventory of which interfaces worked and which did not, and inventories like this are the most useful thing the RISC-V ecosystem produces at this stage - more useful than another benchmark table. Below is the substance of it, followed by the diagnostics we would run against each failure.The I2C work is worth noting because it is a complete, working pattern: raw i2c-dev with ioctl(I2C_RDWR) using a two-message transaction for register reads and a single-message transaction for writes, with I2C_TIMEOUT and I2C_RETRIES set per file descriptor. That is the portable path on any Linux board, and the author's BME680 and PAJ7620 glue code is a clean reference for it. The PAJ7620 initialisation in particular requires about 220 register writes across two banks, selected by writing 0xEF, and the gesture result comes back from register 0x43.
Five failures, in the order the author hit them.
These are hypotheses, not confirmed fixes - the report gives symptoms without logs, so treat them as a triage order.
For HDMI: confirm a DRM driver is actually bound before blaming modetest. Check /sys/class/drm for card0-* connector entries and dmesg for the display controller probe. Then run modetest -M <driver-name> -c -p instead of the bare command; without -M, modetest guesses and often guesses wrong on vendor kernels. If /sys/class/drm shows connectors but modetest still lists nothing, the problem is the tool's argument parsing, not the driver. kmscube or wlr-randr are quick cross-checks.For GPIO: the most common cause of "correct chip and line number, still fails" is a libgpiod version mismatch. The CLI grammar changed between v1 and v2 - v1 took gpioset <chip> <offset> <value>, while v2 takes key=value style line assignments, and a few tools were renamed or dropped. Scripts and tutorials written against v1 produce confusing errors on a v2 userspace. Run gpiodetect and gpioinfo first: if gpioinfo shows the line already claimed by a kernel driver (LEDs, regulators, card detect), the failure is a device tree conflict and no amount of CLI syntax will fix it.
For SPI: spidev is not enabled by default on most vendor trees for good reason, but a board that breaks the pins out is expected to ship an overlay. Check /sys/bus/spi/devices and lsmod for spidev; if the controller node exists but no child device does, it is a device tree overlay away.For UVC: an ioctl failure on VIDIOC_S_FMT usually means the requested format or size is not in the device's supported list. Enumerate with v4l2-ctl --list-formats-ext before setting anything, and prefer MJPEG at the requested resolution over raw YUYV, which can exceed USB 2.0 bandwidth at 720p and above.
For Remote-SSH: this one is not the board's fault. Microsoft does not publish a riscv64 vscode-server, so the extension has nothing to install. Practical alternatives are code-server (a browser IDE that runs wherever Node runs), editing over sshfs or SFTP, or JetBrains Gateway with a remote backend - all of which is a tooling gap that affects every RISC-V Linux board equally.Every one of those five failures is a software maturity problem, not a silicon limitation. The A210 core is not the issue; the BSP is. A board whose display controller, GPIO controller and SPI controller are not wired into a documented, working device tree is a board you cannot prototype on, no matter how good the core is.
This is also the argument for choosing a platform by its upstream footprint rather than by its datasheet. SpacemiT's September-October upstream report, which we covered separately, lists exactly the kind of work that decides whether a board is usable: K3 PDMA base-address fix accepted, I2S0-I2S5 nodes in the maintenance tree, CPU PLL table fix into clk-fixes, ACLINT bindings and the SSWI driver merged, K1 DVFS patches for MusePi Pro and OrangePi RV2/R2S accepted, EEPROM MAC address support for the same boards, the K1 EMAC TX descriptor cleanup merged into net, CTF2301 thermal sensor bindings accepted, K1 USB2 PHY support accepted, and CoM260 USB/rfkill/power DTS in the maintenance tree. Display, PCIe, UFS and genpd are still under review - the report is honest about that too.None of it is glamorous. All of it is the difference between a demo that ends with an I2C sensor and a serial frame, and a board you can ship on.
If you are selecting a RISC-V SBC for a product and want to compare BSP maturity rather than peak TOPS, contact us at contact@open-riscv.com or use the inquiry form.