Introduce ROCK 5 Model B - ARM Desktop level SBC

Maybe an X3 could be next or whatever matches the mid range Mali-G715 GPU (7 - 9) cores…

1 Like

@hipboi Could you please recommend wifi6e tri band capable WiFi module for upcoming rock5b. I see you recommend dual band wifi6 module by realtek. Please also recommend tri band solution as well. Thank you.

Intel ax210ngw should work just ok like it does on rock 3A :slight_smile:

is Google Play gonna be available in the radxa’s release of Android 12?


Not sure if there were any updates since the last time I read.

But will there be any compatible cases made available on any of the distributor sites for ROCK5B upon release of the board?


It seems as if there aren’t any answers right now. Radxa must have sent out the boards to all the devs because I haven’t seen any of them post lately. Good for them. As for the rest of us ‘nobody’s’ I suppose we will get our preorder when Radxa gets around to it. I know things take time. I also know other sbcs with same soc have been available for at least a month. Oh well good things come to those that have inexhaustible amounts of patience lol

1 Like

For the sbc-bench numbers, do they give us any sort of ballpark performance estimate of how this SBC compares to RPi4, a Jetson Xavier NX, etc?


Of course there’s a results list.

But you need to keep in mind that synthetic benchmarks are something different than real-world tasks and that ‘use case’ always matters more than some numbers or graphs that could be compared without using a brain. If the benchmark numbers do not represent your use case then they’re worthless for you.

And since sbc-bench focuses on ‘server workloads in general’ (the 7-zip-MIPS score) I highly doubt these numbers are that useful for average Rock 5B buyers.

Since with this focus on integer and memory performance all the other stuff that makes up RK3588 is not even remotely considered:

  • GPU (2D/3D acceleration)
  • VPU (accelerated video encoding/decoding)
  • NPU
  • in general the media capabilities like display and camera support, ‘picture in picture’ and so on (maybe only ever working in Android and not Linux)
  • IO: RK3588 has serious IO capabilities especially compared to toys like an RPi 4

Raspberry Pi V 4xC A72 4xc A52 + G78 MP8 with RISCV ISA with LPDDR4x 4266MHz from 5 to 10v overclockable is perfect for people. :ok_hand:t2:
2x faster than previous one that can run every OS from Ubuntu to Manjaro, Linux mint up to custom Raspbian OS (mix between RaspOS and Twister funny and original than others).

What I want is, the team should have to add PCI-E 3.0 for VGA eGPU that works in parallel with iGPU of the processor in three cuts:1 G78
MP14 MP20 and the most powerful MP24 :muscle:t2: :fire:.

They will be millionaires :partying_face:.

We happy because save energy

thanks for the link, it seems like even 3A is almost as fast as Pi 4B, so perhaps it is time for me to sell it (just don’t wanna waste it) and consider a 3A as replacement, and perhaps overclock it a bit to match Pi 4B;

and 5B is like 3x of Pi 4B… on that “server workload in general”. I think it is still useful, as it should tell the integer ALU performance and likely branching performance as well. for GPU, VPU, NPU and else, they depend on the maturity of drivers, so I won’t be considering them for the time being.

Do you have a recipe for this with any recent Rockchip SoC like RK3568 or RK3588?

We’re currently struggling to understand what determines clockspeeds since all those devices show ‘random’ behaviour, see here and there.

The mechanism at work seems to be called Process-Voltage-Temperature Monitor (PVTM).


Thanks. I’m probably not an average Arm SBC user.
I’m a developer for Altair Accelerator, and we have some limited support in our product for Armv8. Whatever customers are using that are probably doing so on Arm server systems, maybe even proprietary ones that aren’t available to the generic public.

But because we do support the platform, I’m interested in tinkering at home on an Arm system, but more as a C/C++/Python development box rather than a Desktop, NAS, or a game emulation platform. Sure, I have access to some Arm hosts in the cloud, but they’re slow and inconvenient for me to use, and I don’t want to ask for $$ to spin up an AWS instance just so that I can play. The Honeycomb LX2, NVidia Jetson SBC, or rk3588 are probably closest to what I’m looking for, but there’s a lot in the NVidia hardware that I probably wouldn’t ever make use of. For me, it would be a host I put on my LAN and ssh into.

Thanks for the numbers.

Presume it just tweaks the timings so everything is optimum, dunno PVTM is new to me but been wondering if the OPP table does anything or really its like the amlogic where everything seems hardcoded in the MCU blob.

Have you tried DTC and editing the OPP table either under or overclock and see if its totally ignored?
Preferably OC to see if it does?

Hi @Mecca, read this yesterday and gained even more appreciation for the work that goes into finalizing a SBC for release:

1 Like

Hi @NGBRO, this is what I did with my R0. Thinking I’ll do something similar with the 5B, likely adding an inlet and outlet for the fan until something I like becomes available to purchase or 3D print :wink:

Check sbc-bench output in detail. That’s two different phenomenons:

  1. the cpufreq driver is hiding certain cpufreq OPP (on @willy’s board also the top ones)
  2. real clockspeeds differ from cpufreq OPP in different directions

As an example ‘my’ board:

Checking cpufreq OPP for cpu0-cpu3 (Cortex-A55):

Cpufreq OPP: 1800    Measured: 1828 (1828.663/1828.622/1828.125)     (+1.6%)
Cpufreq OPP: 1608    Measured: 1645 (1645.519/1645.452/1644.982)     (+2.3%)
Cpufreq OPP: 1416    Measured: 1422 (1422.748/1422.654/1422.544)
Cpufreq OPP: 1200    Measured: 1230 (1231.014/1230.882/1230.354)     (+2.5%)
Cpufreq OPP: 1008    Measured: 1062 (1062.635/1062.504/1061.903)     (+5.4%)
Cpufreq OPP:  816    Measured:  845    (845.559/845.516/844.695)     (+3.6%)
Cpufreq OPP:  600    Measured:  587    (590.172/589.922/583.196)     (-2.2%)
Cpufreq OPP:  408    Measured:  391    (391.348/391.180/390.991)     (-4.2%)

Checking cpufreq OPP for cpu4-cpu5 (Cortex-A76):

Cpufreq OPP: 2400    Measured: 2348 (2348.432/2348.405/2348.268)     (-2.2%)
Cpufreq OPP: 2208    Measured: 2185 (2185.642/2185.619/2185.571)
Cpufreq OPP: 2016    Measured: 2016 (2017.078/2016.977/2016.750)
Cpufreq OPP: 1800    Measured: 1817 (1817.134/1817.114/1816.991)
Cpufreq OPP: 1608    Measured: 1625 (1625.664/1625.632/1625.255)     (+1.1%)
Cpufreq OPP: 1416    Measured: 1437 (1437.125/1437.110/1436.982)     (+1.5%)
Cpufreq OPP: 1200    Measured: 1259 (1259.240/1259.132/1258.933)     (+4.9%)
Cpufreq OPP: 1008    Measured: 1056 (1056.646/1056.527/1056.387)     (+4.8%)
Cpufreq OPP:  816    Measured:  849    (850.073/850.012/849.793)     (+4.0%)
Cpufreq OPP:  600    Measured:  592    (592.260/592.234/592.154)     (-1.3%)
Cpufreq OPP:  408    Measured:  394    (394.444/394.302/394.288)     (-3.4%)

Checking cpufreq OPP for cpu6-cpu7 (Cortex-A76):

Cpufreq OPP: 2400    Measured: 2348 (2348.350/2348.268/2348.159)     (-2.2%)
Cpufreq OPP: 2208    Measured: 2185 (2185.548/2185.453/2185.311)
Cpufreq OPP: 2016    Measured: 2015 (2015.390/2015.315/2015.114)
Cpufreq OPP: 1800    Measured: 1813 (1813.888/1813.888/1813.847)
Cpufreq OPP: 1608    Measured: 1620 (1620.361/1620.263/1620.149)
Cpufreq OPP: 1416    Measured: 1429 (1429.315/1429.204/1429.204)
Cpufreq OPP: 1200    Measured: 1246 (1246.176/1246.056/1246.026)     (+3.8%)
Cpufreq OPP: 1008    Measured: 1048 (1048.325/1048.240/1048.229)     (+4.0%)
Cpufreq OPP:  816    Measured:  842    (842.671/842.611/842.422)     (+3.2%)
Cpufreq OPP:  600    Measured:  592    (592.273/592.234/592.161)     (-1.3%)
Cpufreq OPP:  408    Measured:  394    (394.366/394.288/394.233)     (-3.4%)

The cpufreq driver decides to hide 2256, 2304 and 2352 from the OPP table (which might be a reasonable choice since the 200 MHz step between 2208-2400 is ok) but in @willy’s case cpu4-5 get 2304 MHz as highest OPP and cpu6-7 get 2352 MHz. The driver hides the 2400 OPP regardless what the MCU inside the SoC decides to use as real clockspeeds for each cpufreq OPP.

And you should be aware that Amlogic’s clockspeed cheating stopped with most recent SoCs. The last ones where we observed a hardcoded difference between cpufreq OPP and real clockspeeds was GXL/GXM (S905X and S912 where cpufreq OPP says 1.5 GHz while in reality it’s 1.4 GHz)

For such a use case I would ssh into a locally running Linux VM (having to admit that I’m typing these lines on an ARMv8.5-A laptop)

Anyway, I don’t understand the 8nm process
I put this down here,