Bump Rockchip Vendor to rkr6.1

[HeyMeco]

Description

This PR switches to the latest rockchip vendor kernel release 6.1-rkr6.1 from rkr5.1
Now we need some people to test if their usecases still work.
I went ahead and made sure it compiles correctly and runs on RK3588 but haven't tested much further

How Has This Been Tested?

Boot:

• RK3588 (Rock-5B-Plus)
• RK3576
• RK3566/68
• RK3528

Mali:

• Valhall
• Bifrost

Panfrost/Panthor:

• Valhall
• Bifrost

Video Processing:

• MPP / Jellyfin

Acknowledgement

• @hbiyik for figuring out the kernel config collisions and also having a rebase effort I could take as a base (and then add the few commits since then on top)
  • See: Rebase Armbian rkr5.1 on rockchip rkr6.1 linux-rockchip#389 (comment)

[coderabbitai]

Walkthrough

• Vendor kernel branch bumped from rk-6.1-rkr5.1 to rk-6.1-rkr6.1 in rk35xx and rk3588 family configs.
• Kernel config updates for rk35xx vendor: enabled RT group scheduling, netfilter/NFT additions (e.g., NETFILTER_NETLINK_HOOK, NF_CONNTRACK_ZONES, NFT_REJECT_NETDEV, NOTRACK, EMATCH IPT), ZRAM writeback/memory tracking, persistent/encrypted keys, KEY_DH operations.
• Removed options include LTE_RM310, TOUCHSCREEN_FTS, and COMPASS_AK8975.
• No public API/exported declarations changed.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• Switch from rkr5 to rkr5.1 #8089 — Adjusts the same vendor KERNELBRANCH variables in rk35xx and rk3588 family configs.
• board configs sync - netfilter-modules + make oldconfig #8678 — Changes overlapping kernel config symbols (netfilter/NFT, ZRAM writeback/memory tracking, persistent/encrypted keys).
• Beagle kernel config improvements #8295 — Modifies kernel configs with similar option sets (RT group scheduling, NF_CONNTRACK/zones, keyrings, ZRAM features).

Suggested labels

Ready to merge, size/medium, Patches

Suggested reviewers

• rpardini
• krachlatte
• paolosabatino
• igorpecovnik
• amazingfate
• lanefu

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title succinctly captures the primary update of bumping the Rockchip vendor kernel to version rkr6.1 and directly reflects the core change made in this pull request without including extraneous details.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.
Description Check	✅ Passed	The pull request description explains that the Rockchip vendor kernel release is being updated from rkr5.1 to 6.1-rkr6.1 and outlines compilation and runtime testing results on RK3588, directly reflecting the changes in the configuration files. It lists which platforms have been tested and which require further verification, providing relevant context for reviewers. It also acknowledges the contributor who resolved kernel config collisions and links to upstream discussion for clarity. Therefore the description is clearly related to the changeset and provides appropriate information.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[EvilOlaf]

once merged default repo should be switched at linux-rockchip.

[EvilOlaf]

rock-3a: https://paste.armbian.com/isoyojisuj seems ok. Got a few pcie errors but can also be because m.2 slot was empty.

[nyanmisaka]

Based on armbian/linux-rockchip@e54469c, I guess Mali Valhall needs these changes?

-CONFIG_MALI_BIFROST=y
-CONFIG_MALI_PLATFORM_NAME="rk"
-CONFIG_MALI_CSF_SUPPORT=y
-CONFIG_MALI_BIFROST_EXPERT=y
-CONFIG_MALI_BIFROST_DEBUG=y

+CONFIG_MALI_VALHALL=y
+CONFIG_MALI_VALHALL_PLATFORM_NAME="rk"
+CONFIG_MALI_VALHALL_EXPERT=y
+CONFIG_MALI_VALHALL_DEBUG=y

[HeyMeco]

Based on armbian/linux-rockchip@e54469c, I guess Mali Valhall needs these changes?

-CONFIG_MALI_BIFROST=y
-CONFIG_MALI_PLATFORM_NAME="rk"
-CONFIG_MALI_CSF_SUPPORT=y
-CONFIG_MALI_BIFROST_EXPERT=y
-CONFIG_MALI_BIFROST_DEBUG=y

+CONFIG_MALI_VALHALL=y
+CONFIG_MALI_VALHALL_PLATFORM_NAME="rk"
+CONFIG_MALI_VALHALL_EXPERT=y
+CONFIG_MALI_VALHALL_DEBUG=y

Yeah true, I need to add that change for RK3588 (mali valhall) since they split the driver to bifrost and valhall. I think the Bifrost flag is still needed for RK3568/RK3576/… builds

[nyanmisaka]

Yeah true, I need to add that change for RK3588 (mali valhall) since they split the driver to bifrost and valhall. I think the Bifrost flag is still needed for RK3568/RK3576/… builds

CONFIG_MALI_CSF_SUPPORT=y will only allow mali KMD to support CSF based gpus. Not sure after the split. In addition, armbian/linux-rockchip@28d212b + armbian/linux-rockchip@28d212b enable panfrost KMD but break mali KMD compatibility. So in fact libmali is currently unusable on rk3576. Not sure about the rk356x. So actually it doesn't hurt to delete those Bifrost-only configs.

[ginkage]

Good point about CONFIG_MALI_VALHALL stuff, I'll test this later today with my libmali-driven 5A.

[ginkage]

...and, it worked, with a small caveat:

[   20.625663] W : [File] : drivers/gpu/arm/valhall/platform/rk/mali_kbase_config_rk.c; [Line] : 143; [Func] : kbase_platform_rk_init(); power-off-delay-ms not available.

(probably a missing entry in the dts). But, it's just a warning, should be safe to ignore.

[EvilOlaf]

Getting lots of rockchip-dmc errors in dmesg: https://paste.armbian.com/ewuvisawes
Reverted back to .115: https://paste.armbian.com/enixukefor

[HeyMeco]

Getting lots of rockchip-dmc errors in dmesg: https://paste.armbian.com/ewuvisawes

do you have some uptime info? Or did they come rather quickly?

[EvilOlaf]

Just a few seconds uptime and then sent armbianmonitor in both cases.

[HeyMeco]

@EvilOlaf

Only the rockchip dmc debug driver seems to have gotten any relevant changes. I will keep monitoring on my devices for similar behavior.

I looked at:

• drivers/devfreq/rockchip_dmc.c
• drivers/soc/rockchip/rockchip_dmc_debug.c

[hbiyik]

@EvilOlaf @HeyMeco

Get wrong frequency, Request 528000000, Current 2112000000

DMC frequencies are handled via ATF (bl31) and dts is only used for voltage lookup.

Rk3588 dts has a default dvfs table for dmc, and it is supposed to go 528Mhz when idling.
https://github.com/armbian/linux-rockchip/blob/a4a4a884e1dd8a17a184d64cc562bef16d00d71f/arch/arm64/boot/dts/rockchip/rk3588s.dtsi#L2303-L2314

But to go 528Mhz your ATF should provide 528Mhz first. If it does not you get the above error message.

Overall how dvfs works rokchip bsp is quite bullshit, so the error message should be quite harmless. I think the question is why your ATF does not provide 528Mhz. If i am right, this issue should be gone when you update your full bootlader (you need to change the ATF (bl31) blob)

to verify my theory i have a tool to communciate with ATF
https://github.com/hbiyik/smccc

here is a short how to use, and below gives the desired 528Mhz, i guess in your case it should not be there, and should be there when you update your atf.

[alarm@tv smcc]$ cd module
[alarm@tv module]$ make
make -C /lib/modules/6.1.118-rockchip/build M=/home/alarm/remfs/home/boogie/src/smcc/module modules
  CC [M]  /home/alarm/remfs/home/boogie/src/smcc/module/smccc.o
  MODPOST /home/alarm/remfs/home/boogie/src/smcc/module/Module.symvers
  CC [M]  /home/alarm/remfs/home/boogie/src/smcc/module/smccc.mod.o
  LD [M]  /home/alarm/remfs/home/boogie/src/smcc/module/smccc.ko
[alarm@tv module]$ sudo insmod ./smccc.ko 
[alarm@tv module]$ cd ..
[alarm@tv smcc]$ cd pysmccc/
[alarm@tv pysmccc]$ sudo ./rktune mem getclocks
     INFO | 0) 528Mhz
     INFO | 1) 1068Mhz
     INFO | 2) 1560Mhz
     INFO | 3) 2112Mhz
     INFO | 4) 0Mhz
     INFO | 5) 0Mhz

[SuperKali]

Will test soon on RK3576

[EvilOlaf]

test@orangepi5-plus:~/smccc/pysmccc$ sudo python3.12 rktune mem getclocks
     INFO | 0) 528Mhz
     INFO | 1) 1068Mhz
     INFO | 2) 1560Mhz
     INFO | 3) 2112Mhz
     INFO | 4) 0Mhz
     INFO | 5) 0Mhz
test@orangepi5-plus:~/smccc/pysmccc$ uname -a
Linux orangepi5-plus 6.1.115-vendor-rk35xx #1 SMP Mon Sep  1 17:12:42 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

test@orangepi5-plus:~/smccc/pysmccc$ sudo python3.12 rktune mem getclocks
     INFO | 0) 528Mhz
     INFO | 1) 1068Mhz
     INFO | 2) 1560Mhz
     INFO | 3) 2112Mhz
     INFO | 4) 0Mhz
     INFO | 5) 0Mhz
test@orangepi5-plus:~/smccc/pysmccc$ uname -a
Linux orangepi5-plus 6.1.118-vendor-rk35xx #1 SMP Sun Oct  5 21:19:02 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

Looks the same. Did not do anything to the boot loader

[hqnicolas]

Testing mali bifrost on rk3566

[hbiyik]

test@orangepi5-plus:~/smccc/pysmccc$ sudo python3.12 rktune mem getclocks
     INFO | 0) 528Mhz
     INFO | 1) 1068Mhz
     INFO | 2) 1560Mhz
     INFO | 3) 2112Mhz
     INFO | 4) 0Mhz
     INFO | 5) 0Mhz
test@orangepi5-plus:~/smccc/pysmccc$ uname -a
Linux orangepi5-plus 6.1.115-vendor-rk35xx #1 SMP Mon Sep  1 17:12:42 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

test@orangepi5-plus:~/smccc/pysmccc$ sudo python3.12 rktune mem getclocks
     INFO | 0) 528Mhz
     INFO | 1) 1068Mhz
     INFO | 2) 1560Mhz
     INFO | 3) 2112Mhz
     INFO | 4) 0Mhz
     INFO | 5) 0Mhz
test@orangepi5-plus:~/smccc/pysmccc$ uname -a
Linux orangepi5-plus 6.1.118-vendor-rk35xx #1 SMP Sun Oct  5 21:19:02 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

Looks the same. Did not do anything to the boot loader

Ok then my theory did not hold up

[hqnicolas]

Testing mali bifrost on rk3566
performance is 20% below expectations for this mali bifrost

[nyanmisaka]

Testing mali bifrost on rk3566
performance is 20% below expectations for this mali bifrost

It's actually Mesa Panfrost, which has nothing to do with bifrost/libmali closed source driver.

[hqnicolas]

bifrost/libmali closed source driver.

Can you share your resusts?

[EvilOlaf]

What's the status? Should we just wing it or discard the version bump?

[ginkage]

I'd like to proceed with merging, but we probably need separate config files for rk3588 (due to VALHALL entries) and the rest of it. That said, we can also do the bump for rk3588 only.

[HeyMeco]

I'm currently trying to think of a way to implement something like a "USE_LINUX_CONFIG=defconfig,rk3588.conf" for the kernel build system. That would be beneficial for other families too. When that is done we can update this pr to make use of that and merge?

I can open up a GitHub task if anyone else can assist or provide feedback

[igorpecovnik]

I'm currently trying to think of a way to implement

This is already implemented on userpatches level - if kernel config exists there (userparches/linux-xyz.config), it pulls it from there. Here we need to decide - going forward now. Or a bit later. Having another vendor sub-kernel here is not a viable option.

Since we are about to push out a new release, I would vote to wait.

[HeyMeco]

Since we are about to push out a new release, I would vote to wait.

I agree that we can push this for the first 2026 release.

Regarding the user patch option: The thing here is that as far as I know we don’t have any support for split kernel configs and that is something (imo) we should implement as more and more vendors use that and it would make it easier for us to maintain certain families in the future as vendor config changes would be covered automatically.

[igorpecovnik]

as vendor config changes would be covered automatically

Useful, but probably not worth implementing for vendor kernels. I agree there will be a few changes here and there, but changes should pop-up here #8782 so they are integrated. Rare event.

[rpardini]

The thing here is that as far as I know we don’t have any support for split kernel configs and that is something (imo) we should implement as more and more vendors use that and it would make it easier for us to maintain certain families in the future as vendor config changes would be covered automatically.

Yeah. There were a few cases (in mainline, at least; see CONFIG_MFD_RK808) that certain Kbuild changes required a change to arm64_defconfig (in the kernel sources) which didn't make it through to Armbian, as we don't really take upstream defconfig in any way. Given the existence (and growth) of armbian-kernel.sh, the efforts with automated .config rewrites, etc, I'd like to experiment with a different way, maybe taking a given kernel source's defconfig + multiple sets of changes instead of a versioned .config + changes.

That way we could say eg for rockchip64-edge "take upstream arm64_defconfig, disable all ARCH_* except ARCH_ROCKCHIP, enable default set of USB drivers, enable default set of NICs, ..."