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?