The Pine64 Star64: RISC-V's Baseline Problem

A.C. Jokela — Thu, 10 Sep 2026 14:15:00 GMT

The Pine64 Star64 is the third RISC-V board to go through my benchmark fleet, and it makes a better showing than the one everybody would expect it to beat. That is a lower bar than it sounds.

It is built on StarFive's JH7110: four SiFive U74-MC cores at 1.5 GHz, 4 GB of RAM, and an ISA string that turns out to be the entire story. That string is rv64imafdc. Plain RV64GC. No vector extension, no scalar crypto extension, no bit-manipulation extensions, and an isa-ext field that is simply empty. This is the RISC-V baseline profile and nothing above it.

For compiling Rust that hardly matters. A compiler is integer and branch work, and baseline RV64GC does integer and branch work perfectly well. The Star64 posts 461.28 seconds on my fleet-comparable tree, tenth of eleven. For cryptography it matters enormously. The same board manages 21.7 MB/s of AES-128-GCM, roughly one hundredth of what a Cortex-A76 does on the identical benchmark.

That hundredfold gap is the most interesting number this fleet has produced, and it decomposes into two very different things. Unpacking it says something precise about where RISC-V actually stands in 2026, and the answer is not "the cores are bad."

The Hardware

The 4 GB variant: the sticker on the USB stack matches the 3.8 GiB the OS reports. The JH7110 sits under the metal lid at center; the PCIe slot along the top edge and the 40-pin header are the expansion this board leans on, since its microSD is stuck in high-speed mode.

Component	Specification
SoC	StarFive JH7110
CPU	4 × SiFive U74-MC, dual-issue in-order, 1.5 GHz
ISA	`rv64imafdc`: RV64GC baseline; no V, no K, no Z*
RAM	4 GB (3.8 GiB usable), 32-bit LPDDR4
Storage	SanDisk SN64G microSD, 59.5 GB, ext4
GPU	Imagination BXE-4-32, DRM nodes present
Video	JH7110 VPU, `/dev/video0`–`7`
Network	2 × gigabit (`st_gmac`)
OS	PinIx 2.1, kernel 5.15.131 (vendor BSP, Sept 2023)
Toolchain	rustc / cargo 1.98.1, `riscv64gc-unknown-linux-gnu`

Three practical notes for anyone setting one of these up, each of which cost me time. Root's home directory is /home/root, not /root. My first toolchain install failed outright because I assumed otherwise. The login shell is /bin/sh, so anything wanting bash has to say so explicitly. And the board ships with no Rust toolchain at all; rustup's riscv64gc-unknown-linux-gnu target installs cleanly, which is itself a quiet sign of how far RISC-V tooling has come.

The Benchmark, and Why It Has Two Numbers

My standard workload is a clean release build of ballistics-engine, three runs after cargo clean. As I wrote in the NanoPC-T6N review, that project outgrew its own benchmark. The tree the October 2025 fleet compiled was 16,639 lines, and today's main is 155,867. Numbers from the two are not the same measurement.

So every run now comes in two tiers:

Pinned: 2821bba, verified on the board at 43 .rs files / 16,639 LOC / 144 crates. Byte-for-byte the tree the archived fleet was measured against. Every fleet comparison below uses this.
HEAD: b0cfcd4, 196 files / 155,867 LOC / 243 crates. Deliberately the same commit the FreeBSD MacBook ran a couple of weeks ago, so those two HEAD figures are directly comparable to each other rather than being another orphan.

Before the HEAD tier I added an 8 GB swapfile, reasoning that 243 crates at -j4 might blow past 3.8 GB of RAM. It was never touched: zero swap use across all 2,455 samples of the run. A sensible precaution that turned out to be unnecessary, which I would rather say plainly than let you assume it rescued something.

Compilation Results

Pinned tier (2821bba):

Run	Time
1	458.17 s
2	463.08 s
3	462.59 s
Mean	461.28 s (median 462.59, σ 2.71, 0.59% CV)

HEAD tier (b0cfcd4):

Run	Time
1	2933.59 s
2	2927.88 s
3	2934.15 s
Mean	2931.88 s, 48.9 minutes (σ 3.47, 0.12% CV)

A 0.12% coefficient of variation across three 49-minute builds is the most consistent result on my bench, and the instrumentation says exactly why: nothing varied. Across 2,455 samples spanning 3.4 hours, all four cores held 1.5 GHz for 100% of under-load samples, temperature stayed between 56.9 and 70.0 °C, and swap was never touched. No thermal ceiling, no memory pressure, no clock wobble.

Left: the fleet on the pinned September-2025 tree, the only apples-to-apples axis I have. Right: the same board and toolchain against both sizes of the same project, 6.36x the build time for 9.37x the code.

The HEAD/pinned ratio of 6.36× compares against the MacBook's 5.45× on the identical commit. With clock and memory both ruled out as causes, that difference is architectural rather than environmental: the bigger tree leans harder on whatever the U74 is worse at.

Two Comparisons That Matter

Against the other RISC-V design, the Star64 wins convincingly. It beats the Orange Pi RV2 by 1.41× while carrying half the cores (four U74s against eight Ky X1s), which works out to 2.82× better per core-second. The RV2's cores bring RVV 1.0 vector units that a Rust compile never touches, while their scalar integer throughput lags well behind SiFive's. For general-purpose work, four decent cores beat eight weak ones, and it is not close.

Against ARM, it loses to a design from 2012. The quad Cortex-A53 in the Horizon X3 CM, a board I reviewed as a cautionary tale running a core Arm announced fourteen years ago, still finishes 1.22× faster. That is the honest framing of where this silicon sits on ordinary work: current-generation RISC-V application cores trailing decade-old budget ARM.

Against a Raspberry Pi 5, the Star64 is 6.02× slower. Hold onto that number; it comes back.

The Same-Silicon Control

The Milk-V Mars runs the same JH7110 SoC as the Star64 (same four U74 cores, same 1.5 GHz, same rv64imafdc) with twice the RAM. That makes it the best control I have ever had for one of these reviews, so I re-ran it.

I need to be upfront about why a re-run was necessary. When I reviewed the Mars in February, I reported 936 seconds and called it the slowest board in my fleet. That figure recorded no commit hash and no line count, so it was measured against whatever main happened to be in February 2026, a tree substantially larger than the pinned one. It was an orphan number, comparable to nothing, and the "slowest in the fleet" claim built on it was simply wrong. This is exactly the failure the T6N review warned about, and my own archive was already carrying an instance of it.

So: both boards, both tiers, the same two pinned commits, and (because the Mars needed a fresh toolchain anyway) the identical rustc 1.98.1.

	Pinned `2821bba`	HEAD `b0cfcd4`
Milk-V Mars (8 GB)	458.00 s	2932.35 s
Pine64 Star64 (4 GB)	461.28 s	2931.88 s
difference	3.28 s (0.71%)	0.48 s (0.016%)

On the long tier the two boards finish a 49-minute build within half a second of each other. That gap is 0.11× the pooled run-to-run noise, and the sign flips between tiers (the Mars is marginally ahead on the pinned tree, the Star64 marginally ahead on HEAD), which is the signature of noise rather than a real difference. These boards are the same speed.

Two things follow. First, the Mars's extra 4 GB of RAM buys it exactly nothing, consistent with the Star64 never touching swap. Second, and more useful: the ~6× deficit against contemporary ARM is a property of the JH7110 itself, not of one board's BSP, distro, kernel, or microSD. Two independent implementations landing within 0.02% of each other is about as clean a confirmation of that as this bench can produce.

The corrected fleet ordering puts the two JH7110 boards adjacent, where identical silicon belongs, and moves the actual slowest board back to the Orange Pi RV2 at 650.60 s.

Cryptography: Where the Baseline ISA Bites

Now the interesting part. Single-threaded OpenSSL 3.x, 16 KB blocks:

Left: absolute throughput on a linear scale. I deliberately did not use a log axis, because the Star64's bars really are that small and a log plot would flatter them. Right: how far behind the Cortex-A76 each algorithm falls, with the dashed line marking the 5.9x gap that is the core itself.

Algorithm	Star64 U74	i5-2435M	RK3588 A76	A76 / Star64
AES-128-GCM	21.7 MB/s	1112.4	2185.7	100.9×
AES-256-GCM	17.9	988.2	1763.9	98.3×
AES-128-CBC	31.4	575.6	1831.8	58.4×
SHA-256	35.4	251.8	1429.4	40.4×
SHA-512	63.5	361.2	376.1	5.9×
ChaCha20-Poly1305	51.0	761.9	674.4	13.2×

SHA-512 is the control, and it decomposes everything else. None of these three chips has SHA-512 acceleration: not the U74, not the Cortex-A76, not Sandy Bridge. All three run software implementations. On that even footing the U74 sits 5.9× behind the A76, and that is the honest measure of the core itself.

Every gap wider than 5.9× is the instruction set talking. AES-128-GCM's 100.9× factors cleanly into roughly 6× "the U74 is a slower core" multiplied by about 17× "the A76 has AES instructions and this chip has none."

And that 5.9× independently corroborates the compile result. The Star64 is 6.02× slower than a Raspberry Pi 5, both quad-core, measured by a completely unrelated workload, landing on the same number. When two independent measurements agree that closely, the figure is real and the decomposition holds.

The asymmetric results split along the same seam:

Operation	Star64	RK3588 A76	Gap
RSA-2048 sign	66.5 /s	269.6 /s	4.1×
ECDSA P-256 sign	211.2 /s	16,917.2 /s	80.1×

RSA-2048 is bignum arithmetic that nobody accelerates in silicon here, and its 4.1× gap sits right in the neighborhood of the core's raw deficit. ECDSA P-256's 80× gap is not silicon at all. It is OpenSSL shipping hand-tuned P-256 assembly for ARM and x86 and generic C for RISC-V. Some of RISC-V's disadvantage is missing hardware. A good deal of it is missing software investment, which is a different problem with a different fix.

The Practical Inversion

On the Star64, ChaCha20-Poly1305 runs 2.35× faster than AES-128-GCM. On the RK3588, that comparison runs the other way, with AES 3.2× ahead.

The correct cipher suite flips depending on whether the silicon has AES instructions, which is exactly the case ChaCha20 was designed for. If you are terminating TLS on a baseline RISC-V board, prefer ChaCha20. Anyone who copies an AES-first cipher preference list off an ARM server onto this hardware leaves more than half their throughput on the floor.

The Hardware Engine Nobody Can Reach

Here I have to correct my own framing, because my first pass at this section was wrong.

The JH7110 does have a hardware crypto block. The kernel registers 21 algorithms from the jh7110 driver: AES in ECB, CBC, CTR, CFB, OFB, GCM and CCM; SHA-1 through SHA-512 with HMAC variants; SM3; and RSA at priority 3000. I had written "software-only crypto" before I actually looked at /proc/crypto, and that was not true.

What is true is narrower and more annoying. openssl engine lists only dynamic: there is no AF_ALG or cryptodev bridge wired up, so userspace OpenSSL never sees any of it and falls back to pure software. The 21.7 MB/s figure is real for userspace TLS; it is what nginx or a userspace WireGuard would actually get. But it is not the ceiling of what this silicon can do. Kernel-space consumers (dm-crypt, IPsec, kernel TLS) should reach the accelerator and do considerably better.

So the accurate statement is not "RISC-V is terrible at crypto." It is: this SoC's crypto acceleration is real but stranded behind missing userspace plumbing, and the ISA itself offers nothing to fall back on when it is unreachable. Fixing the plumbing is a software task, and it would move these numbers a long way for the workloads that can use it.

Thermals and Scaling: The Good News

Left top: SoC temperature across 3.4 hours of continuous compilation. Left bottom: the CPU clock over the same window: flat at the 1.5 GHz maximum for the entire run. Right: thread scaling against perfect linear.

The temperature trace has a shape worth reading. Each build ramps to a peak near 70 °C, then decays to a plateau around 62 °C and holds there. That is not cooling catching up. It is the build's own structure. The early phase compiles many independent crates across four cores and runs hot; the long tail is a single rustc doing final codegen on the main crate, one core busy and three idle. The same asymmetry showed up in the memory sampling, where peak pressure landed at load 1.00.

The sharp dips to 57 °C are the cargo clean and cache-drop gaps between runs.

Thread scaling is genuinely excellent:

Threads	Time	Events/s	Scaling
1	12.15 s	246.96	1.00×
2	6.07 s	494.19	2.00×
4	3.09 s	970.90	3.93×

Essentially perfect. Four real cores, no SMT, no floating-point units shared between siblings, no thermal limit and no memory bottleneck. This board scales about as well as it is physically possible to scale, a useful contrast with the FreeBSD MacBook, where Hyper-Threading contributed literally nothing to SIMD work because SMT siblings share the FP pipeline. The Star64 has fewer and slower cores, but the ones it has are entirely independent.

One Measurement Trap

The benchmark's own before-and-after readings showed 625 MHz and 750 MHz, which looks like severe throttling, and for about twenty minutes I believed it was. Those samples are taken between builds, while the CPU is idle and the ondemand governor has wound down. Only continuous sampling during the runs showed the truth: 100% of 677 under-load samples at the full 1.5 GHz.

An instantaneous clock reading taken at an arbitrary moment is not a measurement. That is the same lesson the MacBook's MSR readings taught me two weeks ago, on completely different hardware, and I nearly published the wrong conclusion twice.

Memory and Storage

Memory measured 5,488 MB/s read and 5,070 MB/s write. Notably (and unlike every other board in this fleet) those numbers are plausible. The JH7110's 32-bit LPDDR4 interface tops out near 11 GB/s, so ~5.5 GB/s is about half of theoretical rather than a physical impossibility. The 1 MB block size still means part of the working set is cache-resident, so treat it as an upper bound. But this is the first time in this benchmark series that sysbench's memory test has not handed me a number that beats physics.

Storage is the weak point:

Test	Result
hdparm buffered read	22.38 MB/s
dd write 1 GB	19.9 MB/s
dd read 1 GB (caches dropped)	23.5 MB/s

The card is not the problem: the controller is. The exact same SanDisk SN64G model read at 64.85 MB/s in the NanoPC-T6N. Checking /sys/kernel/debug/mmc1/ios explains it:

clock:        50000000 Hz
bus width:    2 (4 bits)
timing spec:  2 (sd high-speed)

The Star64 runs the card in SD High-Speed mode at 50 MHz, not UHS-I SDR104 at 208 MHz. Four-bit high-speed caps out near 25 MB/s in practice, which is exactly what I measured. This is a board or BSP limitation, and it means microSD performance here is about a third of what the same card delivers elsewhere.

For the compile benchmark it barely mattered: 0.12% run-to-run variance says the build was CPU-bound with its working set in page cache. For a NAS, a container host, or anything doing bulk I/O, it would be the whole story.

What Works, What Doesn't

Better than expected. The GPU has real DRM nodes (/dev/dri/card1 and renderD128, backed by the Imagination BXE-4-32), plus /dev/video0 through 7 for the video engine. That is more functional graphics support than the FreeBSD MacBook managed. Gigabit Ethernet is live via st_gmac. Four independent cores scale nearly perfectly. Nothing throttles.

Not working, or not measured. The hardware crypto engine is unreachable from userspace. The microSD controller is stuck in high-speed mode. The kernel is a vendor BSP from September 2023, with everything that implies for long-term support. And network throughput was never measured. I had a live gigabit link and simply did not set up an iperf3 peer, so that section is a gap in my testing rather than a finding about the board.

Three Things I Got Wrong

I keep a section like this in these reviews because benchmarking unfamiliar hardware generates plausible nonsense, and the nonsense is instructive.

My ISA check reported the vector extension as present. It substring-matched single-letter extensions against the full ISA string, and rv64imafdc contains a literal "v" in the rv64 prefix. Re-parsed with the prefix stripped, V is absent, isa-ext is empty, and the kernel has no vector support compiled in at all. Had I trusted that line, this entire review would have rested on a false premise about what the chip can do.

sysbench silently produced nothing. This board ships sysbench 0.4.12, whose CLI differs from the 1.0.x I use everywhere else. My 1.0-syntax invocations failed and emitted empty sections, which is worse than an error because it looks like missing data rather than a broken command. The figures above are re-runs with 0.4 syntax; the scaling ratios are sound, but the absolute numbers cannot be compared to the T6N's sysbench results.

/usr/bin/time -v reports zero for every rusage field on this board: max RSS, page faults, context switches, all zero, from a GNU time build that identifies its own version as "UNKNOWN." I lost peak-memory instrumentation and fell back to sampling free -m, which turned out to be the better instrument anyway.

The general rule, and the reason these sections keep earning their place: a benchmark number that beats the hardware's physical limits is a bug report, not a result.

Who Is This For?

Reasonable uses. As a RISC-V development and porting target, this is a sound machine. Four independent cores that scale cleanly, 4 GB of RAM, working GPU and video nodes, gigabit networking, and enough compile throughput to build real software locally instead of cross-compiling. If your goal is finding out whether your code works on RISC-V, it does that job without drama.

Poor uses. Anything crypto-heavy in userspace is off the table until the AF_ALG plumbing exists. Anything I/O-bound is throttled to a third of the microSD's capability. And anything where you simply want the work finished quickly is better served by nearly any ARM board on this list, including, remarkably, one built on a 2012-era Cortex-A53.

The honest framing is that you buy a Star64 because it is RISC-V, not because it is fast. That is a completely legitimate reason to buy one. Somebody has to run real software on this architecture for the ecosystem to mature, and the JH7110 is a reasonable place to do it. But it should be a deliberate choice rather than a value comparison you expect to win.

Conclusion

The Star64's defining characteristic is its ISA string. rv64imafdc is RISC-V's baseline, and everything above baseline (vectors, crypto, bit manipulation) is simply absent.

On integer work that costs relatively little: 5.9× behind a Cortex-A76 on software SHA-512, corroborated by 6.02× behind a Raspberry Pi 5 on compilation. Those are the numbers for the core itself, and while they are not flattering, they are not disastrous either. A 6× deficit against the best ARM cores in this price class is a gap you can live with for development work.

Where it becomes disastrous is anywhere the competition has dedicated instructions. AES-128-GCM at 100× behind is not a core-quality problem. It is an extensions problem, and it multiplies a manageable 6× disadvantage into an unusable one. That the SoC has a perfectly good crypto engine sitting unreachable behind missing userspace plumbing makes that worse rather than better: the silicon is there, and software is the thing in the way.

RISC-V's problem in this benchmark is not that its cores cannot compete. It is that the baseline profile ships without accelerators everyone else has had for a decade, and the software stack has not yet caught up to the hardware that does exist. Both are fixable. Neither is fixed on this board today.

By the numbers:

Rust clean release build, pinned tree (2821bba, 16,639 LOC): 461.28 s mean (σ 2.71), 10th of 11 on my bench
Rust clean release build, current tree (b0cfcd4, 155,867 LOC, 243 crates): 2931.88 s mean (σ 3.47)
vs. the other RISC-V design: 1.41× faster than the Orange Pi RV2 with half the cores (2.82× per core-second)
vs. its own twin: within 0.016% of the Milk-V Mars on HEAD: same JH7110, same rustc, statistically identical
vs. a 2012-era Cortex-A53: 1.22× slower than the Horizon X3 CM
SHA-512 (no hardware anywhere): 63.5 MB/s, only 5.9× behind a Cortex-A76, the honest core-to-core figure
AES-128-GCM: 21.7 MB/s, 100.9× behind: the cost of no K extension
ChaCha20-Poly1305 51.0 MB/s, 2.35× faster than AES-GCM on this board: the inversion that matters for TLS
ECDSA P-256 211.2 sign/s (80× behind, mostly missing assembly); RSA-2048 66.5 sign/s (4.1× behind)
Hardware crypto: 21 jh7110 algorithms registered in the kernel, zero reachable from OpenSSL
Thread scaling: 2.00× at 2 threads, 3.93× at 4, near perfect
Thermals: 55.7 °C idle, 70.0 °C peak, 1.5 GHz held for 100% of 677 under-load samples
microSD 22.4 MB/s: SD high-speed 50 MHz, not UHS-I; the same card does 64.85 MB/s elsewhere
Memory 5,488 MB/s read, the first sysbench memory figure in this series that does not exceed physics

Caveats. My run used rustc 1.98.1; the archived October 2025 fleet used 1.90/1.91. Commit 2821bba predates the repository having a Cargo.lock, so dependency versions resolved fresh. sysbench is 0.4.12 here and 1.0.20 elsewhere, so those absolute figures are intra-machine only. OpenSSL numbers are userspace software crypto and are not this silicon's AES ceiling. The governor was left at the as-shipped ondemand, and no performance comparison was run because sampling showed the clock already pinned at maximum. Network throughput was never measured. The February 2026 Milk-V Mars result uses this same SoC but recorded no commit or LOC, so it is excluded from every comparison here.

Review Date: September 9, 2026

Hardware Tested: Pine64 Star64, StarFive JH7110 (4 × SiFive U74-MC @ 1.5 GHz), 4 GB LPDDR4, 64 GB SanDisk microSD

OS Tested: PinIx 2.1, kernel 5.15.131 (vendor BSP)

Benchmark Workload: ballistics-engine clean release builds at commits 2821bba (fleet-comparable) and b0cfcd4 (current), rustc 1.98.1

Conclusion: Competent baseline RISC-V silicon whose cores are roughly 6× behind contemporary ARM and whose crypto is 100× behind. The first number is the hardware, the second is the missing instruction set, and a stranded on-chip accelerator sits between them waiting for someone to write the plumbing.

TinyComputers.io (Posts about sd high-speed)