Radxa Rock 5C

[geerlingguy]

Basic information

• Board URL (official): https://radxa.com/products/rock5/5c/
• Board purchased from: Arace
• Board purchase date: April 4, 2024
• Board specs (as tested): 4GB RAM
• Board price (as tested): $59.90

Linux/system information

# output of `neofetch`
       _,met$$$$$gg.          radxa@rock-5c 
    ,g$$$$$$$$$$$$$$$P.       ------------- 
  ,g$$P"     """Y$$.".        OS: Debian GNU/Linux 12 (bookworm) aarch64 
 ,$$P'              `$$$.     Host: Radxa ROCK 5C 
',$$P       ,ggs.     `$$b:   Kernel: 6.1.43-7-rk2312 
`d$$'     ,$P"'   .    $$$    Uptime: 1 min 
 $$P      d$'     ,    $$P    Packages: 1830 (dpkg) 
 $$:      $$.   -    ,d$$'    Shell: bash 5.2.15 
 $$;      Y$b._   _,d$P'      Terminal: /dev/pts/0 
 Y$$.    `.`"Y$$$$P"'         CPU: (8) @ 1.800GHz 
 `$$b      "-.__              Memory: 341MiB / 3921MiB 
  `Y$$
   `Y$$.                                              
     `$$b.                                            
       `Y$$b.
          `"Y$b._
              `"""

# output of `uname -a`
Linux rock-5c 6.1.43-7-rk2312 #a5661faa3 SMP Thu May 16 08:29:55 UTC 2024 aarch64 GNU/Linux

Benchmark results

CPU

• Geekbench 6: (761 single / 2928 multi - https://browser.geekbench.com/v6/cpu/6134579)
• 49.285 Gflops at 12W (4.11 Gflops/W) (HPL result)

Power

• Idle power draw (at wall): 1.6 W (2W with HDMI and keyboard plugged in)
• Maximum simulated power draw (stress-ng --matrix 0): 9.5 W
• During Geekbench multicore benchmark: 10 W
• During top500 HPL benchmark: 12.4 W

Disk

Samsung Pro Plus 512GB A2 microSD card

Benchmark	Result
iozone 4K random read	23.62 MB/s
iozone 4K random write	7.24 MB/s
iozone 1M random read	88.42 MB/s
iozone 1M random write	63.65 MB/s
iozone 1M sequential read	88.39 MB/s
iozone 1M sequential write	63.66 MB/s

Pinedrive 256GB 2242 NVMe via Pi 5 PCIe HAT

Benchmark	Result
iozone 4K random read	51.84 MB/s
iozone 4K random write	160.88 MB/s
iozone 1M random read	371.43 MB/s
iozone 1M random write	366.07 MB/s
iozone 1M sequential read	352.27 MB/s
iozone 1M sequential write	365.62 MB/s

curl https://raw.githubusercontent.com/geerlingguy/pi-cluster/master/benchmarks/disk-benchmark.sh | sudo bash

Run benchmark on any attached storage device (e.g. eMMC, microSD, NVMe, SATA) and add results under an additional heading. Download the script with curl -o disk-benchmark.sh [URL_HERE] and run sudo DEVICE_UNDER_TEST=/dev/sda DEVICE_MOUNT_PATH=/mnt/sda1 ./disk-benchmark.sh (assuming the device is sda).

Also consider running PiBenchmarks.com script.

Network

iperf3 results:

• iperf3 -c $SERVER_IP: 937 Mbps
• iperf3 --reverse -c $SERVER_IP: 881 Mbps
• iperf3 --bidir -c $SERVER_IP: 930 Mbps up, 419 Mbps down

(Be sure to test all interfaces, noting any that are non-functional.)

GPU

glmark2-es2 results:

arm_release_ver: g13p0-01eac0, rk_so_ver: 10
=======================================================
    glmark2 2023.01
=======================================================
    OpenGL Information
    GL_VENDOR:      ARM
    GL_RENDERER:    Mali-G610
    GL_VERSION:     OpenGL ES 3.2 v1.g13p0-01eac0.68603db295fbf2c59ac6b927fdfb1c32
    Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0
    Surface Size:   800x600 windowed
=======================================================
[build] use-vbo=false: FPS: 287 FrameTime: 3.488 ms
[build] use-vbo=true: FPS: 321 FrameTime: 3.116 ms
[texture] texture-filter=nearest: FPS: 332 FrameTime: 3.014 ms
[texture] texture-filter=linear: FPS: 324 FrameTime: 3.087 ms
[texture] texture-filter=mipmap: FPS: 325 FrameTime: 3.081 ms
[shading] shading=gouraud: FPS: 296 FrameTime: 3.380 ms
[shading] shading=blinn-phong-inf: FPS: 298 FrameTime: 3.360 ms
[shading] shading=phong: FPS: 280 FrameTime: 3.582 ms
[shading] shading=cel: FPS: 291 FrameTime: 3.442 ms
[bump] bump-render=high-poly: FPS: 223 FrameTime: 4.490 ms
[bump] bump-render=normals: FPS: 336 FrameTime: 2.985 ms
[bump] bump-render=height: FPS: 332 FrameTime: 3.018 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 311 FrameTime: 3.219 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 251 FrameTime: 3.987 ms
[pulsar] light=false:quads=5:texture=false: FPS: 328 FrameTime: 3.050 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 190 FrameTime: 5.285 ms
[desktop] effect=shadow:windows=4: FPS: 282 FrameTime: 3.558 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 165 FrameTime: 6.069 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 156 FrameTime: 6.452 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 182 FrameTime: 5.519 ms
[ideas] speed=duration: FPS: 245 FrameTime: 4.092 ms
[jellyfish] <default>: FPS: 247 FrameTime: 4.062 ms
[terrain] <default>: FPS: 87 FrameTime: 11.625 ms
[shadow] <default>: FPS: 272 FrameTime: 3.687 ms
[refract] <default>: FPS: 124 FrameTime: 8.117 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 312 FrameTime: 3.210 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 302 FrameTime: 3.321 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 309 FrameTime: 3.244 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 314 FrameTime: 3.186 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 281 FrameTime: 3.565 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 484 FrameTime: 2.070 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 318 FrameTime: 3.146 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 307 FrameTime: 3.263 ms
=======================================================
                                  glmark2 Score: 275 
=======================================================

IMPORTANT NOTE: This test was run using the newest test release of Debian from Rockchip after the board was released. Apparently the GPU is better supported right now in Armbian builds with some custom patches applied. I have not run the board with that configuration yet, but it may be better to run Armbian if you want GPU acceleration.

TODO: See this issue for discussion about a full suite of standardized GPU benchmarks.

Memory

tinymembench results:

Click to expand memory benchmark result

tinymembench v0.4.10 (simple benchmark for memory throughput and latency)

==========================================================================
== Memory bandwidth tests                                               ==
==                                                                      ==
== Note 1: 1MB = 1000000 bytes                                          ==
== Note 2: Results for 'copy' tests show how many bytes can be          ==
==         copied per second (adding together read and writen           ==
==         bytes would have provided twice higher numbers)              ==
== Note 3: 2-pass copy means that we are using a small temporary buffer ==
==         to first fetch data into it, and only then write it to the   ==
==         destination (source -> L1 cache, L1 cache -> destination)    ==
== Note 4: If sample standard deviation exceeds 0.1%, it is shown in    ==
==         brackets                                                     ==
==========================================================================

 C copy backwards                                     :  12007.0 MB/s (2.9%)
 C copy backwards (32 byte blocks)                    :  11959.5 MB/s
 C copy backwards (64 byte blocks)                    :  11977.8 MB/s
 C copy                                               :  12239.5 MB/s
 C copy prefetched (32 bytes step)                    :  12564.9 MB/s
 C copy prefetched (64 bytes step)                    :  12588.2 MB/s
 C 2-pass copy                                        :   5405.8 MB/s (0.3%)
 C 2-pass copy prefetched (32 bytes step)             :   9733.2 MB/s
 C 2-pass copy prefetched (64 bytes step)             :  10402.0 MB/s
 C fill                                               :  29606.2 MB/s (0.2%)
 C fill (shuffle within 16 byte blocks)               :  29573.4 MB/s (0.2%)
 C fill (shuffle within 32 byte blocks)               :  29646.4 MB/s (0.2%)
 C fill (shuffle within 64 byte blocks)               :  29508.5 MB/s (0.2%)
 NEON 64x2 COPY                                       :  12423.9 MB/s
 NEON 64x2x4 COPY                                     :  12449.7 MB/s
 NEON 64x1x4_x2 COPY                                  :  12495.1 MB/s
 NEON 64x2 COPY prefetch x2                           :  11621.7 MB/s
 NEON 64x2x4 COPY prefetch x1                         :  11957.2 MB/s
 NEON 64x2 COPY prefetch x1                           :  11673.7 MB/s
 NEON 64x2x4 COPY prefetch x1                         :  11954.6 MB/s
 ---
 standard memcpy                                      :  12507.5 MB/s
 standard memset                                      :  29477.5 MB/s
 ---
 NEON LDP/STP copy                                    :  12537.3 MB/s
 NEON LDP/STP copy pldl2strm (32 bytes step)          :  12434.3 MB/s
 NEON LDP/STP copy pldl2strm (64 bytes step)          :  12462.2 MB/s
 NEON LDP/STP copy pldl1keep (32 bytes step)          :  12568.9 MB/s
 NEON LDP/STP copy pldl1keep (64 bytes step)          :  12571.8 MB/s
 NEON LD1/ST1 copy                                    :  12451.5 MB/s
 NEON STP fill                                        :  29455.0 MB/s (0.2%)
 NEON STNP fill                                       :  29431.4 MB/s
 ARM LDP/STP copy                                     :  12513.3 MB/s
 ARM STP fill                                         :  29506.0 MB/s (0.2%)
 ARM STNP fill                                        :  29458.7 MB/s

==========================================================================
== Memory latency test                                                  ==
==                                                                      ==
== Average time is measured for random memory accesses in the buffers   ==
== of different sizes. The larger is the buffer, the more significant   ==
== are relative contributions of TLB, L1/L2 cache misses and SDRAM      ==
== accesses. For extremely large buffer sizes we are expecting to see   ==
== page table walk with several requests to SDRAM for almost every      ==
== memory access (though 64MiB is not nearly large enough to experience ==
== this effect to its fullest).                                         ==
==                                                                      ==
== Note 1: All the numbers are representing extra time, which needs to  ==
==         be added to L1 cache latency. The cycle timings for L1 cache ==
==         latency can be usually found in the processor documentation. ==
== Note 2: Dual random read means that we are simultaneously performing ==
==         two independent memory accesses at a time. In the case if    ==
==         the memory subsystem can't handle multiple outstanding       ==
==         requests, dual random read has the same timings as two       ==
==         single reads performed one after another.                    ==
==========================================================================

block size : single random read / dual random read
      1024 :    0.0 ns          /     0.0 ns 
      2048 :    0.0 ns          /     0.0 ns 
      4096 :    0.0 ns          /     0.0 ns 
      8192 :    0.0 ns          /     0.0 ns 
     16384 :    0.0 ns          /     0.0 ns 
     32768 :    0.0 ns          /     0.0 ns 
     65536 :    0.0 ns          /     0.0 ns 
    131072 :    1.1 ns          /     1.5 ns 
    262144 :    2.2 ns          /     2.8 ns 
    524288 :    3.5 ns          /     4.0 ns 
   1048576 :   10.2 ns          /    13.2 ns 
   2097152 :   14.0 ns          /    15.9 ns 
   4194304 :   58.6 ns          /    92.5 ns 
   8388608 :  142.7 ns          /   198.5 ns 
  16777216 :  188.1 ns          /   233.3 ns 
  33554432 :  212.1 ns          /   245.3 ns 
  67108864 :  225.3 ns          /   251.5 ns 

sbc-bench results

https://sprunge.us/5pv8oh

Phoronix Test Suite

Results from pi-general-benchmark.sh:

• pts/encode-mp3: 12.496 sec
• pts/x264 4K: 4.22 fps
• pts/x264 1080p: 20.90 fps
• pts/phpbench: 413840
• pts/build-linux-kernel (defconfig): 1787.702 sec

[ThomasKaiser]

Radxa put a Rock-5-ITX and a Rock 5C Lite (RK3582 with some SoC cores disabled) in the mail. Interestingly idle consumption with 5C Lite is slightly higher than on my 5B (with same RPi USB-C power brick on same Netio powermeter):

root@rock-5c:/home/radxa# Netio=192.168.83.72/4 sbc-bench.sh -m
Power monitoring on socket 4 of powerbox-1 (Netio 4KF, FW v3.2.0, XML API v2.4, 235.23V @ 50.02Hz)

Rockchip RK3582 / 35 82 12 fe 21 41  32 47 41 31 00 00 00 00, Kernel: aarch64, Userland: arm64

CPU sysfs topology (clusters, cpufreq members, clockspeeds)
                 cpufreq   min    max
 CPU    cluster  policy   speed  speed   core type
  0        0        0      408    1800   Cortex-A55 / r2p0
  1        0        0      408    1800   Cortex-A55 / r2p0
  2        0        0      408    1800   Cortex-A55 / r2p0
  3        0        0      408    1800   Cortex-A55 / r2p0
  4        1        4      408    2400   Cortex-A76 / r4p0
  5        1        4      408    2400   Cortex-A76 / r4p0

Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (soc-thermal)

Time       big.LITTLE   load %cpu %sys %usr %nice %io %irq   Temp      mW
20:28:01:  408/ 600MHz  0.06   1%   1%   0%   0%   0%   0%  34.2°C     1640
20:28:06:  408/1800MHz  0.06   2%   1%   0%   0%   0%   0%  35.2°C     1640
20:28:11:  408/ 600MHz  0.05   0%   0%   0%   0%   0%   0%  35.2°C     1630
20:28:16:  408/ 600MHz  0.05   1%   1%   0%   0%   0%   0%  35.2°C     1630
20:28:21:  408/ 600MHz  0.04   1%   1%   0%   0%   0%   0%  34.2°C     1640
20:28:26:  600/ 600MHz  0.12   2%   1%   0%   0%   0%   0%  35.2°C     1660
20:28:31:  408/ 600MHz  0.11   1%   0%   0%   0%   0%   0%  35.2°C     1670
20:28:37:  408/ 600MHz  0.10   1%   1%   0%   0%   0%   0%  35.2°C     1660
20:28:42:  408/ 600MHz  0.09   2%   1%   0%   0%   0%   0%  35.2°C     1680
20:28:47:  408/1800MHz  0.08   1%   0%   0%   0%   0%   0%  35.2°C     1690
20:28:52:  408/1800MHz  0.08   1%   0%   0%   0%   0%   0%  35.2°C     1700
20:28:57:  408/ 600MHz  0.07   1%   1%   0%   0%   0%   0%  35.2°C     1710
20:29:02:  408/ 408MHz  0.23   1%   1%   0%   0%   0%   0%  35.2°C     1720
20:29:07:  408/1800MHz  0.21   1%   1%   0%   0%   0%   0%  35.2°C     1720
20:29:13:  408/ 600MHz  0.19   1%   1%   0%   0%   0%   0%  35.2°C     1720

And since you seem to have the RK3588S2 variant can you please post NVMEM contents from your board once you start testing?

For my RK3582 it looks like this:

root@rock-5c:/home/radxa# RK_NVMEM_FILE="$(find /sys/bus/nvmem/devices/rockchip*/* -name nvmem 2>/dev/null | head -n1)"
root@rock-5c:/home/radxa# hexdump -C <"${RK_NVMEM_FILE}"
00000000  52 4b 35 82 12 fe 21 41  32 47 41 31 00 00 00 00  |RK5...!A2GA1....|
00000010  00 00 00 00 18 15 04 07  07 09 20 0d 08 00 04 00  |.......... .....|
00000020  00 00 00 00 00 00 00 00  07 0a 00 00 00 c1 37 9b  |..............7.|
00000030  4e e6 07 00 00 a2 06 b3  06 00 00 91 03 00 00 00  |N...............|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

[geerlingguy]

@ThomasKaiser - Just got shipment notification today, so I'll test when it gets here!

[geerlingguy]

...and it finally arrived today. I have RS131-D4R26, Radxa ROCK 5C 4GB, and I went to the Getting Started link on the box (https://rock.sh/5c), but can't find any place to download an image for the board. The downloads section of the page just has:

I've asked over on the Radxa forums where I can find an image to boot the board and test it. I also don't see anything Armbian-wise for the Rock 5C yet, not sure where to go to get something to boot!

The downloads section of Radxa's site also doesn't have any images available, just an SPL Loader.

[geerlingguy]

It's also interesting the packaging says "Radxa Compute Module", and "ROCKPI 5C" whereas the board itself says "Radxa ROCK 5C V1.1" and it seems the official name is Rock 5C. Maybe an older packaging design got through to production, but it did make me do a double take, like I had ordered a weird model or something.

[ThomasKaiser]

https://github.com/radxa-build/rock-5c/releases/ / https://github.com/radxa-build/rock-5c-6_1/releases and https://github.com/armbian/community/releases/tag/24.5.0-trunk.559

[geerlingguy]

@ThomasKaiser - Thanks! It'd be nice if they linked to those anywhere on the Radxa site / Wiki :)

[ThomasKaiser]

Well, to arrive at Radxa's correct download locations it's quite a journey through various Github/wiki pages that contain deprecation notices, further links and so on. Also a bit worrying that the device is shipped to customers now and still only images labeled 'for internal testing' are available :)

BTW: I would either choose the t3 build from https://github.com/radxa-build/rock-5c-6_1/releases or the Armbian flavour of your choice. But no idea whether the 6.1 builds work correctly asides headless use (that's all I tried to far with my 5C Lite)

[geerlingguy]

Also a bit worrying that the device is shipped to customers now and still only images labeled 'for internal testing' are available.

Radxa seem to still be in the 'ship hardware, then customers help us get software side running' stage. I like their hardware, but it's impossible to recommend them over something like Pi until they get out of that mindset. At minium, a full tested build should be ready before the first board is shipped (and it should be linked from the product page, downloads, wiki, etc.), or they should very prominently mark the board as 'devkit' or 'beta/alpha' (kinda like what Lichee has done with the RISC-V boards).

The hardware > software side works better for accessories, like their Penta SATA HAT, than full SBCs/computers.

[geerlingguy]

@ThomasKaiser - That image download did work, I'm running kernel 6.1.x and things work okay; it seems like there's no GPU acceleration though; things are a little choppy, UI-wise.

HDMI output works fine, though, unlike on CM5 with the CM4 IO Board.

[geerlingguy]

Just a quick test of the UI, it's a little stuttery (enough to be a little jarring), like when resizing windows or dragging windows around (I'd rather that decoration be turned off if it's not buttery smooth). YouTube plays back okay in 1080p, with a little stuttering at 4K.

When I shut down the board, it actually powers off to < 1W (near 0W) poweroff state.

Pressing the power button, it boots right back up, and consumes around 2W idle (with or without HDMI plugged in).

[geerlingguy]

Geekbench 6 power draw:

[ginkage]

My experience is a bit different. I have full HW acceleration, and I'm successfully using an NVMe hat created for Pi 5...

But, I'm used to building my own system images and kernels, so I'm really non-representative. I'm the kind of person this board was made for. Happy to try and assist you in achieving the best possible experience with the board (although I'm not affiliated with Radxa in any way, I'm afraid, so I'm just doing some work for free, as you've rightly pointed out).

[geerlingguy]

@ginkage - What I don't get is how, if you can get that going as an individual in the community, Radxa can't get that going on their own OS image? Where is it even documented? Not sure if maybe Armbian has a better default image for the Rock 5C or if you have a custom concoction of kernel patches?

[ginkage]

I'm using a custom kernel, yes. And a custom image. And then I put some more magic on top, so I have this board running perfectly just a couple hours after having it delivered...
But, I'm a wizard, I've been preparing in advance for a few weeks, ordering the right accessories and figuring out the kernel quirks, and I had my own custom build scripts for rk3588 family for a while.
That's what I'm saying: I'm non-representative. Radxa works mostly with vanilla Rockchip kernel (which is a bad baseline from the start), and I'm using a slightly more recent Rockchip kernel, with Armbian patches on top, plus some of my bleeding edge findings to boot. I will do my best to try and figure out the minimal set of changes to make these things work out of the box with the next Armbian release (that's roughly two weeks from now), but all in all, it's indeed really tricky, as we all depend on the upstream work from Rockchip, and they're themselves lagging behind heavily.
If it weren't for Rockchip, we'd probably have Vulkan support on rk3588 in Linux a year ago.