armbian
Bump Rockchip Vendor to rkr6.1
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:
- [X] RK3588 (Rock-5B-Plus)
- [ ] RK3576
- [x] 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: https://github.com/armbian/linux-rockchip/pull/389#issuecomment-3268057704
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
- armbian/build#8089 — Adjusts the same vendor KERNELBRANCH variables in rk35xx and rk3588 family configs.
- armbian/build#8678 — Changes overlapping kernel config symbols (netfilter/NFT, ZRAM writeback/memory tracking, persistent/encrypted keys).
- armbian/build#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.
Comment @coderabbitai help to get the list of available commands and usage tips.
![coderabbitai[bot] avatar](https://avatars.githubusercontent.com/in/347564?v=4 "Published by a pub.dev verified publisher"){kind=small}
rock-3a: https://paste.armbian.com/isoyojisuj seems ok. Got a few pcie errors but can also be because m.2 slot was empty.
Based on https://github.com/armbian/linux-rockchip/commit/e54469c723f07d3885deea31d2d6f10473661293, 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
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
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, https://github.com/armbian/linux-rockchip/commit/28d212b790bb4d38d2366e070703096fedc9c3eb + https://github.com/armbian/linux-rockchip/commit/28d212b790bb4d38d2366e070703096fedc9c3eb 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.
Good point about CONFIG_MALI_VALHALL stuff, I'll test this later today with my libmali-driven 5A.
...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.
Getting lots of rockchip-dmc errors in dmesg: https://paste.armbian.com/ewuvisawes Reverted back to .115: https://paste.armbian.com/enixukefor
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
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
@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
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
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/Linuxtest@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/LinuxLooks the same. Did not do anything to the boot loader
Ok then my theory did not hold up
Testing mali bifrost on rk3566 performance is 20% below expectations for this mali bifrost
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.
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.
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
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.
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.
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 https://github.com/armbian/build/pull/8782 so they are integrated. Rare event.
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, ..."
