It works for me. didn't work means no useful information to me.
Announcing the ROCK 5C: Power, Performance, and Versatility for Just $30
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?
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
Hi there, I have a couple of question now that I received my board.
Is there an ETA for an android image availability ?
Is armbian handling hardware acceleration and if so is it openGL only or is vulkan available ?
Thanks
You might want to read from here on: https://github.com/geerlingguy/sbc-reviews/issues/41#issuecomment-2116230813
Thanks for the pointer, my understanding is that a guy built his own kernel that has openGL support. I’m not familliar with kernel building though so not sure I can do much with this 
OpenGL ES more likely (but I’ve not really any idea about all this GUI/GPU/desktop stuff). And more importantly the same guy said that hopefully all (t)his work will be included in next Armbian release.
Welcome to Linux on ARM 
I mean, “that guy” did build his own kernel, but the OpenGL support comes from the driver side.
We already have the highly performant GLES drivers, thanks to Mali blobs, and can use e.g. gl4es for OpenGL (that won’t work to run something like GNOME, but can still run some games pretty well).
You can also go with Panfork for both OpenGL and GLES, with somewhat lower performance (we’re talking 2-3x slower). Or combine Panfork with blobs, to e.g. run GNOME with Panfork, and your games with blobs (that’s what you see happening in the screenshot, malirun being the script that allows that (also note that I’m running glmark2-es2 there).
Now, in the upcoming Armbian release there will also be a new kernel driver, Panthor, which is a bit faster (~7% or so faster) and better than Panfork, and also runs both OpenGL and GLES, but can’t be used together with Mali blobs.
1 Like
I notice that the stable armbian images are available
First I flashed Armbian_24.5.1_Rock-5c_noble_vendor_6.1.43.img.xz wich doesn’t work. I see some searching for btrfs file system … and kernel panic at the end.
Armbian_24.5.1_Rock-5c_noble_edge_6.8.10.img.xz is working well and ssh comes up as usual.
Would be nice to use the vendor kernel (6.1.43) instead of the bleeding edge (6.8.10) one.
Edit:
OCR a screenshot from. First boot with Armbian_24.5.1_Rock-5c_noble_vendor_6.1.43.img.xz
Welcome to Armbian 24.5.1 noble!
[ OK ] Created slice system-modprobe.slice Slice/system/modprobe.
[ OK ] Created slice system-serial\x2dgetty.slice Slice /system/serial-getty.
[ OK ] Created slice user.slice User and Session Slice.
[ OK ] Started systemd-ask-password-wall.path Forward Password Requests to Wall Directory Watch.
[ OK ] Set up automount proc-sys-fs-binfmt_misc.automount Arbitrary Executable File Formats File Se
Expecting device dev-ttyFIQ0.device /dev/ttyFIQ0.
[ OK ] Reached target integritysetup.target Local Integrity Protected Volumes.
[ OK ] Reached target slices.target Slice Units.
[ OK ] Reached target swap.target - Swaps.
[ OK ] Reached target time-set.target System Time Set.
[ OK ] Reached target veritysetup.target Local Verity Protected Volumes.
[ OK] Listening on rpcbind.socket RPCbind Server Activation Socket.
[ OK ] Listening on syslog.socket Syslog Socket.
[ OK ] Listening on systemd-fsckd.socket fsck to fsckd communication Socket.
[ OK ] Listening on systemd-initctl.socket initctl Compatibility Named Pipe.
[ OK ] Listening on systemd-journald-dev-log.socket - Journal Socket (/dev/log).
[ OK ] Listening on systemd-journald.socket Journal Socket.
[ OK ] Listening on systemd-udevd-control.socket udev Control Socket.
[ OK ] Listening on systemd-udevd-kernel.socket udev Kernel Socket.
Mounting dey-hugepages.mount Huge Pages File System...
Mounting dey-mqueue.mount POSIX Message Queue File System...
Mounting sys-kernel-debug.mount Kernel Debug File System...
Mounting sys-kernel-tracing.mount Kernel Trace File System...
Starting fake-hwclock-load.service Restore the current clock...
Starting keyboard-setup, service Set the console keyboard layout...
Starting kmod-static-nodes, service Create List of Static Device Nodes...
Starting modprobe@configfs, service Load Kernel Module configfs...
Starting modprobe@dm_mod, service Load Kernel Module dm_mod... [43.282597] systemd[1]: Caught <SEGV> from PID -1444467920.
[ 43.286703] systemd[1]: Caught <SEGV>, core dump failed (child 393, code killed, status=11/SEGV).
[ 43.290634] systemd[1]: Freezing execution.
I tested armbian stable too, wifi and bluetooth are not working yet and I experience regular crashes from chromium.
Hi @GinKage,
I was wondering if you had the ability to make progress on your image. I’m interested in using my rock c as a retro console.
Thanks
My image is basically the same Armbian, with only a few tweaks. I did have trouble with WiFi and Bluetooth though, so I built the kernel module from sources. You can try installing these on your system and see if that helps:
aic8800-firmware_3.0 git20240116.ec460377-8_arm64.zip (1.2 MB)
aic8800-usb-dkms_3.0 git20240116.ec460377-8_all.zip (3.4 MB)