bump rockchip64 edge to 6.13

[amazingfate]

Description

Borrowed work from #7560.
Patches are applied and kernel build fine.
Tested with rk3588 rock5b.

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

• ./compile.sh kernel BOARD=rock-3a BRANCH=edge DEB_COMPRESS=xz KERNEL_CONFIGURE=no KERNEL_GIT=shallow

Checklist:

Please delete options that are not relevant.

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[amazingfate]

Comparison with 6.12 kernel patches: amazingfate/build@9d7ab82...ad4586c

[EvilOlaf]

Tested with Rock 3A (rk3568) https://paste.next.armbian.com/ivuguqatos

[EvilOlaf]

Just tried with rc4 but did not build
https://paste.armbian.de/qekiwazuja

[amazingfate]

Tested with rk3328-roc-cc.

[amazingfate]

Now two hdmi ports of rock5b are supported:

$ ls -l /sys/class/drm/
total 0
lrwxrwxrwx 1 root root    0  1月  4  2000 card0 -> ../../devices/platform/display-subsystem/drm/card0
lrwxrwxrwx 1 root root    0  1月  4  2000 card0-HDMI-A-1 -> ../../devices/platform/display-subsystem/drm/card0/card0-HDMI-A-1
lrwxrwxrwx 1 root root    0  1月  4  2000 card0-HDMI-A-2 -> ../../devices/platform/display-subsystem/drm/card0/card0-HDMI-A-2
lrwxrwxrwx 1 root root    0 12月 25 14:14 card1 -> ../../devices/platform/fb000000.gpu/drm/card1
lrwxrwxrwx 1 root root    0 12月 25 14:14 renderD128 -> ../../devices/platform/fb000000.gpu/drm/renderD128
-r--r--r-- 1 root root 4096 12月 25 14:15 version

[EvilOlaf]

Should work with opi5+ the same way I guess?

[amazingfate]

Should work with opi5+ the same way I guess?

Yes, the board patch is similar.

[paolosabatino]

Checked a rk3318 tv box and RockPi-S (rk3308) and both of them work fine, dmesg is clean

[EvilOlaf]

Tested against T-Firefly ROC RK3399 PC Plus a.k.a. Station P1: https://paste.next.armbian.com/hodorenoni

Fun fact: When installing to eMMC armbian-install spit out an error about armbianEnv.txt file not found. It uses extlinux which has been installed successfully. So on the bottom line just cosmetical issue.

[paolosabatino]

Checked OrangePI 4 LTS (rk3399), boots and works fine. rkvdec driver though does not load because it is missing some resets in the device tree; probably something that could be addressed in the future with ease.

[rpardini]

Cherry picked, built OK, tested basics (not HDMI tested):

• NanoPCT6 ✅ https://paste.next.armbian.com/edihosipup
• CM3588-NAS ✅ https://paste.next.armbian.com/sutawisise

[efectn]

Tested with Orange Pi 5 Plus including HDMI1 and USB ports. LGTM

https://paste.next.armbian.com/zivazisoxu

[SuperKali]

I'm trying applying a patch for radxa rock 5 itx, if it works I push a commit, I'm compiling it :)

[amazingfate]

Checked OrangePI 4 LTS (rk3399), boots and works fine. rkvdec driver though does not load because it is missing some resets in the device tree; probably something that could be addressed in the future with ease.

There is a patch adding reset controls to driver and devicetree, and in 6.13 there is a patch merged changing devm_reset_control_array_get_exclusive used by our patch: https://lore.kernel.org/all/20240925-reset-get-deasserted-v2-1-b3601bbd0458@pengutronix.de/

I find that hantro driver is using devm_reset_control_array_get_optional_exclusive. After changing to it rkvdec driver is probed fine.

[SuperKali]

@amazingfate Question, do you happen to know if the configuration of the rock 5 itx hdmi side is different from all the others, I see that on the 8K port and directly connected, instead for the 4k port it is muxed with the display port.

[amazingfate]

@amazingfate Question, do you happen to know if the configuration of the rock 5 itx hdmi side is different from all the others, I see that on the 8K port and directly connected, instead for the 4k port it is muxed with the display port.

Yes, the other hdmi port is from dp.

[SuperKali]

the other hdmi port is from dp.

As I thought, the other problem is on the other hdmi port, even writing the patch doesn't work, do you think at least one port can be made to work?

[rpardini]

Let's merge this

[rpardini]

I've tried dropping the 0001-tools-disable-sched_ext_clean.patch (to investigate how it could be avoided across all families), but look and behold, it built and packaged without errors 🤔
Maybe it is not needed anymore?

[amazingfate]

I've tried dropping the 0001-tools-disable-sched_ext_clean.patch (to investigate how it could be avoided across all families), but look and behold, it built and packaged without errors 🤔 Maybe it is not needed anymore?

Yes, I added it when bumping to v6.12. Now it is not necessary for 6.13.

[amazingfate]

Wait, there is still error after deleting the patch: https://paste.next.armbian.com/rolezisafa

[rpardini]

Wait, there is still error after deleting the patch: paste.next.armbian.com/rolezisafa

Interesting, this is exactly what I was trying to reproduce. Somehow it doesn't happen for me. Thanks for the full debug logs, I will try to investigate this further -- same subject was mentioned in the sunxi 6.12 PR.

[rpardini]

Hmm. This rabbit hole is very deep, notice the error message on @amazingfate 's logs:

     DESCEND sched_ext
   Makefile:83: *** Cannot find a vmlinux for VMLINUX_BTF at any of "  ../../vmlinux /sys/kernel/btf/vmlinux /boot/vmlinux-6.1.84-vendor-rk35xx".  Stop.

Somehow Kbuild/Makefile is looking for the build host's kernel BTF sysfs image (/sys/kernel/btf/vmlinux) and the build host's image (/boot/vmlinux-6.1.84-vendor-rk35xx). I assume you don't have any of those (as the rk35xx vendor kernel is not BTF enabled yet), and thus it fails.

On my host (where I have a fully CO-RE BTF enabled kernel - standard Ubuntu one), /sys/kernel/btf/vmlinux actually exists (as sysfs is mounted on /sys) and it works.

I believe this is a bug upstream, but since 90% of distros are shipping BTF enabled (host) kernels these days, most people won't notice.

We've already a few hackfix for other Kbuild bugs, one of which I reported and got fixed upstream (torvalds/linux@a101482).

In this case, seems to me either @The-going's "pass a VMLINUX_BTF var to make clean", or simply creating a fake "../../vmlinux" could work-around the issue; that way we don't need to spread the sched_ext disablement patch across too many families.

What do you think?

Thanks again for helping me find this.

[rpardini]

Even deeper hole; seems upstream is aware of the issue, and have removed the sched_ext clean from the top-level Makefile to address it (torvalds/linux@eb4a3b6) -- except we're calling the tools/Makefile directly, not the top-level one. Phew.

[amazingfate]

Even deeper hole; seems upstream is aware of the issue, and have removed the sched_ext clean from the top-level Makefile to address it (torvalds/linux@eb4a3b6) -- except we're calling the tools/Makefile directly, not the top-level one. Phew.

I wonder if it is necessary to run make clean under tools.
After this patch we can build without 0001-tools-disable-sched_ext_clean.patch:

diff --git a/lib/functions/compilation/kernel-debs.sh b/lib/functions/compilation/kernel-debs.sh
index 13e8f177f..caa752548 100644
--- a/lib/functions/compilation/kernel-debs.sh
+++ b/lib/functions/compilation/kernel-debs.sh
@@ -447,7 +447,7 @@ function kernel_package_callback_linux_headers() {
        declare make_bitbucket="&> /dev/null"
        [[ "${DEBUG}" == "yes" ]] && make_bitbucket=""
        run_host_command_logged cd "${headers_target_dir}" "&&" make "ARCH=${SRC_ARCH}" "M=scripts" clean "${make_bitbucket}"
-       run_host_command_logged cd "${headers_target_dir}/tools" "&&" make "ARCH=${SRC_ARCH}" clean "${make_bitbucket}"
+       #run_host_command_logged cd "${headers_target_dir}/tools" "&&" make "ARCH=${SRC_ARCH}" clean "${make_bitbucket}"
 
        # Trim down on the tools dir a bit after cleaning.
        rm -rf "${headers_target_dir}/tools/perf" "${headers_target_dir}/tools/testing"

I think we can fix this make clean issue in another pr since all familes with 6.12 later kernel is related.

[rpardini]

I wonder if it is necessary to run make clean under tools.

I think so, otherwise we'd be shipping binaries built for the host into the headers package, which might be for a different architecture. The whole headers package is meant to be source-only and built in postinst.

I think we can fix this make clean issue in another pr since all familes with 6.12 later kernel is related.

Absolutely, yes. I say just merge the way it is! Thanks.