What’s the difference between stable release and rolling release you said?
Announcing the ROCK 5C: Power, Performance, and Versatility for Just $30
rolling release is 24.5.0-trunk.xxx current stable is 24.2
https://docs.armbian.com/Process_Release-Model/
P.S. I think 3W/E and 5C support comes with final 24.5
Yes, for the stable image you said you have wait for the release date.
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
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:
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/
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?