What I see is that it’s available for:
and can be compiled with their respective SD-Fuse_RK3XXX
for example RK3568 NanoPI R5S:
git clone https://github.com/friendlyarm/kernel-rockchip --depth 1 -b nanopi6-v6.1.y kernel-rk3568
KERNEL_SRC=$PWD/kernel-rk3568 ./build-kernel.sh friendlycore-focal-arm64
@MichaIng is there any way for me to provide you the compiled kernel deb / headers deb?
Many thanks for the info.
I actually aim to use Armbian’s kernel builds for our new NanoPi 5/6 series images. For R5S/R5C, it will use mainline Linux, for 6 series it is based on the vendor kernel, but still 5.10.160: Index of /armbian/pool/main/l/linux-dtb-legacy-rk35xx/
Here 5.10 is hardcoded: https://github.com/armbian/build/blob/bd242072c17839285109eb0f98d185d08811ec7c/config/sources/families/rockchip-rk3588.conf
There is no 6.1 branch from Rockchip themselves, which is what Armbian’s “legacy” kernel repo is based on: Branches · rockchip-linux/kernel · GitHub
So I wonder whether FriendlyELEC based their 6.1 branch on mainline Linux 
. I will think about this after some other required image/kernel work for other SBCs.
Apparently Rockchip doesn’t keep their GitHub updated anymore but you can find the official 6.1 branch over on Gitlab: Files · develop-6.1 · RK3588_Linux / rk / kernel · GitLab
Personally I think there’s two ways to go either fully mainline (but there’s issues with complete support for HW accelerations)
Or with the vendor kernel which seems to have active (enough) development and full HW accelerations. I was also able to compile it on modern Ubuntu Jammy LTS but I do need to test it a bit more
If anybody wants to test for pyavitz/debian-image-builder here is a built image:
In how far is this “official”? I do not see any hint that this user/orga is Rockchip itself or any vendor .
Okay just checked what the person who linked me to it said. It’s a mirror maintained by Radxa and Rockchip’s Roadmap is 6.1 release for Q4 2023 by Rockchip roadmap reveals RK3576 and RK3506 IoT processors, Linux 6.1 SDK - CNX Software
So I wonder whether FriendlyELEC based their 6.1 branch on mainline Linux
It doesn’t seem like it’s mainline it also uses Rockchip weird partition table so I couldn’t build a booting image with mainline image builder efforts.
At least Friendlyelec provides clean debian images now so making them DietPi is a breeze.
Then again for DietPi either going full mainline (with 6.6 LTS coming up) would probably be the very best way to go (but don’t forget mainline U-Boot then too). But to have full (confirmed) working support Friendlyelec’s 6.1 branch might be the smarter option
@MichaIng I was looking at DietPi/.update/patches at 6a4b6e0486ffe363f6f75fda6f6d3718ac6aa627 · MichaIng/DietPi · GitHub
to understand how to upgrade the kernel on a running system and have some questions. Couldn’t I just build the Kernel myself as a deb, dpkg -i install it and Update initramfs pointing to the new kernel?
If I understand it correctly you just dd’d everything besides rootfs and updated firmware (where did that firmware.deb come from?).
FriendlyElec’s 6.1 is based on rk/develop-6.1 (not really published publicly but technically released and available on Rockchips SDK) so they didn’t brew up something on their own.
Since we are talking about our NanoPi R5S/R6S images, replacing the bootloader is mandatory to make it use any kernel from the rootfs. When this is done, you can also use e.g. the kernel builds from Armbian (and their U-Boot builds as well), who also offer some based in mainline Linux, running very well at least on R5S/RK356x.
I want to test removing the first 7 partitions from our images, so that the rootfs is the only left one, and then flashing the Armbian U-Boot. If this works, then probably the rootfs/partition can additionally be expanded to use the leading 140 MiB which the 7 bootloader/kernel/config partitions did previously use.
I’ll start working on this once I’m done with some RPi 5 image generation and testing.
Yeah that makes way more sense. As long as we stay with Armbian Legacy and go from the separate partitions to the way all other sbc‘s do it. By then maybe the public Rockchip 6.1 SDK is in a good state