Announcing the ROCK 5C: Power, Performance, and Versatility for Just $30

FYI

Armbian_community_24.5.0-trunk.532_Rock-5c_bookworm_vendor_6.1.43_minimal.img didn’t work
Armbian_community_24.5.0-trunk.563_Rock-5c_bookworm_vendor_6.1.43_minimal.img didn’t work
Armbian_community_24.5.0-trunk.563_Rock-5c_bookworm_edge_6.8.9_minimal.img is working

There may be some commits missing in the Armbian kernel branch. E.g.:



My board is almost here, and when I have it, I will test it and create a PR with whatever is missing (unless somebody beats me to it).

1 Like

I just received my Rock 5C V1.1 today; it’s model RS131-D4R26, Radxa ROCK 5C 4GB, and if I go to the getting started URL, and click on Downloads, there are only schematics and drawings available: https://radxa.com/products/rock5/5c/#downloads

Are there any official images available, or should I try to find an Armbian release?

1 Like

Probably it’s still in progress but You may look at radxa github builds:


1 Like

Resolved: https://github.com/geerlingguy/sbc-reviews/issues/41#issuecomment-2115557250

1 Like

Boom! Delivered today. :slight_smile:

1 Like

Also confirmed that a random Pi 5 nvme hat just works.


3 Likes

Can anyone of the 5C owners (with RK3588S2) please provide the output of the following:

hexdump -C <"$(find /sys/bus/nvmem/devices/rockchip*/* -name nvmem 2>/dev/null | head -n1)"

(it’s about differentiating RK3588S2 from RK3588/RK3588s based on nvmem contents)

Hi There,
I have 5C and here is the output:

radxa@rock-5c:~$ hexdump -C <"$(find /sys/bus/nvmem/devices/rockchip*/* -name nvmem 2>/dev/null | head -n1)"
00000000  52 4b 35 88 12 fe 53 41  32 58 4b 5a 00 00 00 00  |RK5...SA2XKZ....|
00000010  00 00 00 00 17 13 0f 0a  0a 0d 2c 15 08 00 00 00  |..........,.....|
00000020  00 00 00 00 00 00 00 00  0b 10 00 00 00 40 b8 1c  |.............@..|
00000030  53 65 09 7c 09 3c 07 3c  07 f7 03 ea 03 00 00 00  |Se.|.<.<........|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400
2 Likes

It works for me. didn't work means no useful information to me.

1 Like

Are the ROCK 5C’s ARM SystemReady certified?
Will they be? If yes, which SystemReady track & version?

Also - what do you think about SR in general? Is it a good initiative?
How is it doing? I did not come across much recent progress during my web research.

How? All we have wrt SystemReady are some vague announcements:

And 5C / 5C Lite lack any SPI NOR flash as such where should EDK2 live?

1 Like

Use the SPI flash module on the eMMC connector:

https://radxa.com/products/accessories/spi-flash-module

1 Like

The Rock PI 4B Plus has some SR certification.
That’s in fact how I found out about Radxa.

Is EDK2 a hard requirement for SystemReady?
Apologies for my low-level questions. They reflect my overall knowledge of the matter, but I want to learn.

SystemReady sounds interesting to me.
A SBC supporting a standard boot flow, allowing me to boot any mainline linux criteria, that would be a pretty big purchase criteria for me.

That’s why I’m curious about the status and the plans for SystemReady adoption by Radxa.

Who should ‘use’ this?

The question was about an SBC being able to boot generic aarch64 OS images. So if you (as Radxa) want to make this happen, then ship Rock 5C with this SPI flash module in the eMMC slot and preflash something to it that would allow users to insert an USB stick containing an installation media of any generic aarch64 OS image.

Won’t happen anytime soon or at all. Linux on ARM is pretty much PITA.

now on the offical website
https://www.armbian.com/radxa-rock-5c/

1 Like

now on the offical website https://www.armbian.com/radxa-rock-5c/

Only the versions linked from 2 weeks ago. At least the image with 6.1 BSP kernel still doesn’t boot my 5C Lite. So I built a new Armbian image just to realize that I seem to also be a winner of the silicon lottery (all four A76 enabled thanks to Jianfeng’s u-boot patch).

@amazingfate when looking at /proc/cmdline I see androidboot.fwver=uboot-rmbian-05/20/2024 while with Radxa’s recent BSP images this contains a lot more info: androidboot.fwver=ddr-v1.16-9fffbe1e78,bl31-v1.45,uboot-17.09-26-5-04/26/2024. Would be great if Armbian images would also reference the BLOBs the image has been built with, don’t you think so?

I guess these androidboot args are for android os. I don’t know if there are any userspace applications would read them.

sbc-bench reports the contents since yesterday but since this could be misleading I’m already thinking about reverting this stuff. On boards with SPI NOR populated with a bootloader (Rock 5B for example) different BLOBs might be active than those the OS image has been built with.

Can you upload it as we can print it from a 3D printer?

1 Like