The MangoPi MQ Pro: One RISC-V Core, Two Hours, and What That Actually Proves

A.C. Jokela — Fri, 11 Sep 2026 14:30:00 GMT

The MangoPi MQ Pro compiled my benchmark in 7,824 seconds. Two hours and ten minutes for a 16,639-line Rust project that a NanoPC-T6N finishes in 52.55 seconds. That is 149 times slower, and it puts the MangoPi last of the twelve boards on my bench by a margin larger than the entire spread of the other eleven.

That number is not the reason to read about this board.

Three other things came out of the run, and each one contradicted what I expected going in. Per core, this chip is only 4.2x behind the SiFive U74 in the Pine64 Star64, so most of that 149x is core count rather than core quality. Its 486 MB of RAM, which I was sure would be the thing that killed the build, never became the bottleneck at all, and the reason is counterintuitive. And getting a Rust toolchain onto the board in the first place was the hard part, harder than the two-hour compile, for a reason that has nothing to do with performance.

The hardware

Running. The D1-H is the bare die at center, unlidded and without a heatsink, which is all it needs: this board completed a two hour ten minute compile without passing 50 °C. The 32 GB card is the one the benchmark ran from, and the whole thing is Raspberry Pi Zero sized.

Component	Specification
SoC	Allwinner D1
CPU	1x T-Head C906, single core, no cpufreq
ISA	`rv64imafdc_zicntr_zicsr_zifencei_zihpm_zca_zcd`
RAM	486 MB usable
Storage	32 GB microSD
Host OS	OpenWrt 25.12.5, kernel 6.12.94
Idle temp	44.7 °C

Two entries decide everything that follows. The core count is one, which is not a configuration choice or a boot-time limitation but the whole chip: /proc/cpuinfo lists processor : 0 and stops. And the ISA string is RV64GC plus six Z extensions that are all counters, CSRs, fences and compressed-instruction variants. No V, so no vector unit. No K, so no scalar crypto.

I checked that ISA string with the rv64 prefix stripped before matching, because a naive substring search for v finds the v in rv64 and cheerfully reports a vector unit that does not exist. That mistake cost me an hour on the Star64 review and I am not repeating it.

The C906 does have RVV 0.7.1 in silicon, a draft vector extension that predates the ratified 1.0 spec. The kernel does not advertise it, no toolchain targets it usefully, and nothing in a Rust compile would touch it regardless. Treat it as absent.

The part that was actually hard

The board runs OpenWrt. That is a reasonable choice for a 486 MB router-class SoC, and it is also why the standard benchmark would not run.

OpenWrt is musl. There is a /lib/ld-musl-riscv64.so.1 and there is no glibc loader anywhere on the system. rustup distributes riscv64gc-unknown-linux-musl as a target, meaning something you cross-compile to, but not as a host, meaning there are no prebuilt compiler binaries that run on a musl riscv64 machine. OpenWrt's package repository has gcc, git, make and 10,503 other things, but no rust and no cargo.

So the options were: cross-bootstrap rustc itself for a musl host, which is a multi-hour x.py build on a separate machine and fragile in ways that would have eaten the day; reflash the board to Debian and lose the OpenWrt install; or supply glibc some other way.

I supplied glibc some other way. The 32 GB card had 30.8 GB of unallocated space sitting after the 109 MB OpenWrt root, so I created a third partition there, put a Debian trixie riscv64 rootfs on it, and chrooted in. OpenWrt was never modified. It still owns mmcblk0p2 and still boots. The chroot is native execution, not emulation: uname -m inside it returns riscv64 and the binaries are riscv64 ELFs running on the C906.

Host OS : OpenWrt 25.12.5   kernel 6.12.94
Chroot  : Debian GNU/Linux 13 (trixie)
rustc 1.98.1 (48a229cea 2026-09-01)
Default host: riscv64gc-unknown-linux-gnu

That rustc version matters more than it looks. It is byte-for-byte the same compiler the Star64 and the Milk-V Mars ran. Every cross-board comparison in this fleet normally carries a "different toolchain version, treat the margin as directional" caveat. This one does not.

I also gave it a 6 GB swapfile on the new partition and set vm.swappiness=60. On the Star64 I added swap as insurance and it went completely unused. Here I was certain it would be load-bearing. I was wrong about that too, and I will come back to it.

The result

Pinned tree 2821bba: 43 source files, 16,639 lines, 144 crates. Three runs after cargo clean, same as every other board.

Run	Time
1	7,856 s
2	7,839 s
3	7,777 s
Mean	7,824 s (2 h 10 min, σ 41.6 s, 0.53% CV)

The warm-up build came in at 7,864 seconds, within 0.51% of the timed mean. A half-percent coefficient of variation across three two-hour builds is tighter than most of the fast boards manage, which tells you there is nothing dynamic happening on this chip at all: fixed clock, no boost, no thermal headroom being negotiated, no scheduler deciding anything. It just grinds.

I did not attempt the current-HEAD tier. That tree is 155,867 lines and 243 crates, roughly nine times the pinned one, and the Star64 took 6.36x longer on it. Extrapolating puts the MangoPi somewhere near fourteen hours per run, three runs deep. There is no question worth answering that badly.

Where it lands

#	System	SoC	Cores	Arch	Mean
1	NanoPC-T6N	Rockchip RK3588	8	arm64	52.55 s
5	Raspberry Pi 5	BCM2712	4	arm64	76.65 s
6	MacBookPro8,1 (FreeBSD)	Core i5-2435M	2C/4T	x86_64	131.00 s
8	Horizon X3 CM	Sunrise X3 (A53)	4	arm64	378.81 s
9	Milk-V Mars	StarFive JH7110	4	riscv64	458.00 s
10	Pine64 Star64	StarFive JH7110	4	riscv64	461.28 s
11	Orange Pi RV2	Ky X1	8	riscv64	650.60 s
12	MangoPi MQ Pro	Allwinner D1	1	riscv64	7,824.00 s

Eleven boards fit inside a 12x spread. Adding this one stretches the bench to 149x.

Per core, it is a different story

Left: wall clock, where the MangoPi takes 17x the Star64. Right: the same four boards in core-seconds, wall clock multiplied by core count. The MangoPi bar is identical in both panels because it has one core. Everyone else's bar grows, which is the point: they were spending four or eight cores to get their number.

Multiply each board's time by the cores it used and the picture inverts:

Board	Cores	Wall clock	Core-seconds
Milk-V Mars	4	458.00 s	1,832
Pine64 Star64	4	461.28 s	1,845
Orange Pi RV2	8	650.60 s	5,205
MangoPi MQ Pro	1	7,824.00 s	7,824

The MangoPi is 16.96x slower than the Star64 in wall clock but 4.24x slower per core. Roughly a quarter of that headline gap is the C906 being a weaker core. The rest is simply having one of them.

A 4.2x per-core deficit is a real and large gap, and I am not going to dress it up as a moral victory. The C906 is a simple in-order pipeline at about 1 GHz against the U74's dual-issue in-order design at 1.5 GHz, and the clock alone accounts for 1.5x of it. But 4.2x is the number that describes the silicon. 149x describes a product decision about how many cores to put on a $20 board, and those are different claims about different things.

The Orange Pi RV2 is the interesting comparison in that table. Eight Ky X1 cores spend 5,205 core-seconds to finish in 650.60 s, while four U74s spend 1,845 to finish in 461.28 s. The RV2 burns 2.8x more silicon-time and still loses. Per core, SpacemiT's newer eight-core design is closer to the MangoPi's single C906 than it is to SiFive's U74. That was true in the Star64 review and having a third and fourth data point makes it harder to dismiss.

The memory surprise

I provisioned 6 GB of swap because 486 MB against 144 crates looked like the run-ending problem. Peak swap usage across the entire benchmark was 5.6 MB.

Not 5.6 GB. Five point six megabytes, out of six thousand available. Free memory sat at 460 MB before each run and 278 MB after.

Being single-core is what saved it. cargo schedules one rustc per available core, so on this board exactly one compilation unit is resident at a time and peak memory is whatever the largest single crate needs. On a four-core board, -j4 puts four rustc processes in memory simultaneously, and that is where the 486 MB would have died. The constraint I was worried about was neutralized by the limitation I was complaining about.

This has a practical consequence worth stating plainly: if you are building large Rust projects on a memory-starved board, cargo build -j1 is not merely a slower option, it is sometimes the only option that completes. The MangoPi gets that for free by having nothing else to offer.

Thermals, briefly

State	Temperature
Idle	44.7 °C
Under a 2.2-hour build	48.6 to 49.8 °C

Five degrees of rise across two hours of continuous compilation, peaking under 50 °C, on a bare board with no heatsink. There is no cpufreq driver, so the clock is fixed and there is no throttling behaviour to characterize and no governor to second-guess. This is the one area where the board is genuinely, completely untroubled.

It is also a reminder of what the 149x buys in the other direction. The MangoPi did that build at a power draw I would estimate in single-digit watts, and it never got warm enough to need cooling.

What this board is for

Not this. Compiling Rust on a MangoPi MQ Pro is a benchmark stunt, and I ran it because a number with a commit hash attached is worth more than a guess.

What the board is genuinely good for is the thing OpenWrt implies: a tiny, cool, cheap RISC-V target for embedded and networking work. It has a real ISA with a real mainline kernel, the package repository has 10,506 packages including gcc and git, and it will sit at 45 °C indefinitely. If you want to find out whether your daemon, driver or protocol implementation works on RISC-V hardware, this is a legitimate and inexpensive way to find out, and the answer you get is a real answer rather than a QEMU approximation.

What it is not is a machine you develop on. Build your code somewhere with four cores, then run it here.

The comparison that puts this in perspective is the Horizon X3 CM, a board I reviewed as a cautionary tale. Its quad Cortex-A53, a core design Arm announced in 2012, finishes the same build in 378.81 seconds, 20.7x faster than the MangoPi. Current-generation RISC-V application silicon at the low end is not competing with modern ARM. It is competing with the bottom of ARM's fourteen-year-old catalogue, and losing.

Conclusion

The MangoPi MQ Pro is the slowest machine I have benchmarked, by a wide margin, and the number that proves it is the least interesting thing I learned from it.

Per core it is 4.2x behind a SiFive U74, which is a genuine deficit and also five times smaller than the wall-clock gap implies. Its 486 MB never became a problem because single-core scheduling kept exactly one rustc in memory, which is the kind of thing you only discover by running the build instead of reasoning about it. And the real work of this review was not the two-hour compile but the forty minutes of partition, rootfs and chroot plumbing needed to put a glibc userland on a musl board, because rustup has no musl-hosted riscv64 compiler and probably never will.

That last point is the one I would generalize. RISC-V's hardware gap is closing slowly and measurably. Its software gap shows up as an afternoon spent on debootstrap before you can run the benchmark at all, and that gap does not appear in any performance table.

By the numbers:

Rust clean release build, pinned tree (2821bba, 16,639 LOC, 144 crates): 7,824.00 s mean, 2 h 10 min (σ 41.6 s, 0.53% CV)
Warm-up build: 7,864 s, within 0.51% of the timed mean
Fleet position: 12th of 12, 148.9x the NanoPC-T6N
vs Pine64 Star64 (same ISA baseline, same rustc 1.98.1): 16.96x wall clock, 4.24x per core
vs Horizon X3 CM (quad Cortex-A53, a 2012 core design): 20.7x slower
Core-seconds: 7,824 against the Star64's 1,845 and the Orange Pi RV2's 5,205
Peak swap used: 5.6 MB of 6,144 MB provisioned
Thermals: 44.7 °C idle, 49.8 °C peak across a 2.2-hour build, no throttling, no cpufreq
HEAD tier: not attempted, extrapolates to roughly fourteen hours per run

Caveats. The build ran inside a Debian trixie riscv64 chroot on a separate partition, not on the OpenWrt host userland. Execution was native, but glibc and Debian's toolchain packaging are not what the host OS provides. Commit 2821bba predates the project having a Cargo.lock, so dependency versions resolved fresh. The chroot partition and swapfile are not persistent across reboot, since I added no fstab entry. Power draw was not measured.

Review Date: September 10, 2026

Hardware Tested: MangoPi MQ Pro, Allwinner D1 (1x T-Head C906), 486 MB RAM, 32 GB microSD

OS Tested: OpenWrt 25.12.5 (kernel 6.12.94) hosting a Debian 13 riscv64 chroot

Benchmark Workload: ballistics-engine clean release build at commit 2821bba, rustc 1.98.1

Conclusion: The slowest board on my bench and a perfectly reasonable embedded RISC-V target, which are not contradictory statements. Per core it is 4.2x behind SiFive's U74 rather than the 17x the wall clock suggests, and the afternoon it took to get a compiler onto a musl-only board says more about where RISC-V actually stands than the compile time does.

TinyComputers.io (Posts about debootstrap)