Image | Radxa ROCK 5C / Radxa ROCK 5C Lite

[isarrider]

I just got my Radxa 5C Lites...
(cheap but with A76 cores)
Would be awesome to use them with DietPi...

[isarrider]

Update: works with the DietPi_ROCK5A-ARMv8-Trixie Image
I only changed fdtfile=rockchip/rk3588s-rock-5c.dtb from fdtfile=rockchip/rk3588s-rock-5a.dtb in the dietpiEnv.txt

[isarrider]

but after trying after apt install linux-image-edge-rockchip-rk3588, the system wont come up again...

[isarrider]

but this only happend when going to Kernel 6.8... Never before, and not since going to 6.8..

[MichaIng]

Okay, so a mainline Linux issue in this case.

[isarrider]

yap - will see what happens when I try other Rock5Cs....

[isarrider]

You'd need to install the related DTB package as well:

apt install linux-image-edge-rockchip-rk3588 linux-dtb-edge-rockchip-rk3588

However, I would recommend the legacy-rk35xx or vendor-rk35xx instead.

Why btw - much of rk3588 and so this derivate is going to mainline already...?

[MichaIng]

We are not going to mainline Linux. This is just an option. Our RK3588 images are all shipped with linux-image-legacy-rk35xx/linux-dtb-legacy-rk35xx instead. I aim to migrate to the vendor branch (based on Rockchip Linux 6.1 sources), but last time I tested it, I still faced issues, like a udev-worker loop causing constant 5% CPU load.

[isarrider]

I dont see any 5% CPU load on my 5B and 5C with 6.8, but ok - thought you had some insights why legacy or vendor is the way... ;)

[MichaIng]

A bunch of hardware features, including GPU support, won't work with mainline Linux yet. But it has been a while I tested it. Essential is that onboard WiFi/Ethernet, in case NVMe SSDs and M.2 WiFi modules etc work. I see, the ROCK 5C comes with eMMC slot only, no M.2, so those things should be easy to test.

Would be fine for me to go with mainline Linux for this new SBC, but we cannot migrate other RK3588 SBCs when this breaks too many features for users.

[isarrider]

actually I think it is totally ok when we document somewhere how to switch to edge - that way everybody can pick and legacy is standard...?
(In my case for example UART needs a newer one) - shall I do a PR somewhere to document this?

[MichaIng]

Since we do not support this SBC yet, not sure where to document it. In general, I am no fans of "supporting" (which is somehow implied when we document how to switch) multiple kernel branches. Our scripts and parts of the setup depend on kernel branch used, e.g. some used sysfs nodes for udev rules and such may change, overlays we apply (rarely but there are cases) do not exist anymore and such. We are too small to properly monitor and have code which correctly handles all kernel branches. Of course we could document it with a "not supported" note, but I prefer to just tell it users directly when being asked, so we can discuss right there how it works, and in case also which parts of DietPi setup/udev rules it broke.

Hence I would just implement it with the one kernel branch we found to be most suitable, and I will migrate other RK3588 SBCs to vendor and/or mainline/edge when the respective issues have been solved/all relevant hardware features are supported, which then implies changes in some scripts and configs here and there.

A particular issue with edge kernel is also that it is not bound to LTS, changes rapidly and is mostly untested. So general no great production basis. current is mainline Linux as well, but the LTS kernel (Linux 6.6) might not support this SBC (well) yet. Armbian just added that branch for some RK3588 SBCs very recently. We'll see how it works, at least a reason to test it again by times.