rockchip-rk3588: Bump edge kernel from 6.10 to 6.11-rc and current from 6.8 to 6.10

[efectn]

Description

• Update edge kernel to 6.11
• Update current kernel to 6.10
• Add Hantro VPU decoder back (H264 is not enabled)
• Refresh HDMI TX and RX patches from Collabora tree
• Disable HDMI-RX on OPi5+ by default and add an overlay in order to avoid interrupts
• Use green led as heartbeat in Orange Pi 5 Plus
• Add HDMI & VOP2 to Orange Pi 5 which is likely to have been removed
• Add bluetooth support to Khadas Edge 2

To Do

• Crypto, RNG and some other nodes seem to have been removed during rewrites. I will add them back.
• USB-C doesn't work on both boards as far as i've tested. This needs to be checked. (also not working with 6.10) works but not stable like it was

How Has This Been Tested?

• Orange Pi 5, Orange Pi 5 Plus and Khadas Edge 2 boots.
• HDMI works up to 1080p@120fps
• OPi5+ and OPi5 tested with 6.10 (current kernel)
• @ColorfulRhino: CM3588 NAS boots 6.11 fine without any visible errors in dmesg
• Tests with more boards.

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

[timsurber]

NanoPC CM3588 is now also included in mainline as rk3588-friendlyelec-cm3588-nas.dts, so I think we should use that.

[EvilOlaf]

Seems like a v2 hdmitx patches have been sent yesterday.
https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=875715
Not sure if this is already up-tp-date. If they are apologize. Kind a having a hard time to compare pr with mailing list...maybe it is just too early in the morning 😅

[efectn]

Seems like a v2 hdmitx patches have been sent yesterday. https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=875715 Not sure if this is already up-tp-date. If they are apologize. Kind a having a hard time to compare pr with mailing list...maybe it is just too early in the morning 😅

I've also derived them from Cristian's branch it should be up-to-date

[efectn]

NanoPC CM3588 is now also included in mainline as rk3588-friendlyelec-cm3588-nas.dts, so I think we should use that.

I will remove it and add a patch to enable HDMI on CM3588

[ColorfulRhino]

NanoPC CM3588 is now also included in mainline as rk3588-friendlyelec-cm3588-nas.dts, so I think we should use that.

I will remove it and add a patch to enable HDMI on CM3588

Yes it has been added to mainline 🎉 I'll do this in a separate PR though since CM3588 needs some other new changes as well. I'll update a bunch of stuff :)

[ColorfulRhino]

Overall: nice, thanks 👍
I've got two comments though:

1. Let's wait for ~rc3 (1.5 weeksfrom now) or at least rc2 before merging to have the first bugs ironed out.
2. EOL 6.8 current kernel should be bumped to 6.10 in this PR as well in a way that doesn't destroy git history, since it can just use the 6.10 patches we have now. I can have a look how the optimal approach would be to make git recognize most stuff as movbed or copied instead of deleted/newly added.

[igorpecovnik]

current kernel should be bumped to 6.10 in this PR as well in a way that doesn't destroy git history, since it can just use the 6.10 patches we have now.

Agree.

[EvilOlaf]

Builds and boots on 5+
Also bumped to rc2
https://paste.armbian.com/tiquseyopo

[EvilOlaf]

@efectn Hm I am confused. For me the green led already had the heartbeat trigger set before this change.

/ot
As for me I actually replaced it with the blue one since the green one is pretty annoying when its dark outside 😁

[EvilOlaf]

@igorpecovnik I suggest to late-merge this into 24.08 once ready.

[efectn]

@efectn Hm I am confused. For me the green led already had the heartbeat trigger set before this change.

/ot As for me I actually replaced it with the blue one since the green one is pretty annoying when its dark outside 😁

It's quite strange behavior since default-trigger is not defined for both LEDs; therefore, they both should be off by default. For example, blue LED does not have any default trigger because it's not defined by devicetree or at somewhere else.

[efectn]

Um does this apply for the rock 5b as well?

Yes it does
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts#L61

[EvilOlaf]

Alright. Something was messed up in my brain. Sorry for the noise. And thanks for your patience.

[ColorfulRhino]

Overall: nice, thanks 👍 I've got two comments though:

1. Let's wait for ~rc3 (1.5 weeksfrom now) or at least rc2 before merging to have the first bugs ironed out.

I've just updated it to rc2

2. EOL 6.8 current kernel should be bumped to 6.10 in this PR as well in a way that doesn't destroy git history, since it can just use the 6.10 patches we have now. I can have a look how the optimal approach would be to make git recognize most stuff as movbed or copied instead of deleted/newly added.

Done

Thanks, this works!

RC3 should be ready today or tomorrow probably.

[ColorfulRhino]

@efectn I tried to update to 6.11-rc3 but I can't push to this PR, likely because you want to merge this from a different account?

[efectn]

@efectn I tried to update to 6.11-rc3 but I can't push to this PR, likely because you want to merge this from a different account?

Yes it looks like. Can you send me your patch? I can apply it into the tree

[ColorfulRhino]

@efectn I tried to update to 6.11-rc3 but I can't push to this PR, likely because you want to merge this from a different account?

Yes it looks like. Can you send me your patch? I can apply it into the tree

Sure: commits are c7da0a5 and d3289df

[ColorfulRhino]

I haven't done any thorough testing like HDMi and stuff, but from looking through the commits, the PR looks good to me in its current state 👍

[ColorfulRhino]

• Add Hantro VPU decoder back (H264 is not enabled)

What's up with this though? I guess it did not make it for 6.11, does anyone know if this VPU stuff is in the pipeline for 6.12? @amazingfate

[amazingfate]

• Add Hantro VPU decoder back (H264 is not enabled)

What's up with this though? I guess it did not make it for 6.11, does anyone know if this VPU stuff is in the pipeline for 6.12? @amazingfate

This is a bit complicated. RK3588 has two h264 decoder: hantro g1 and rkvdec2, but userspace applications like gstreamer and chromium can't deal with two decoder with the same codec. We did a hack in armbian to disable h264 hantro vpu and use h264 decoder in rkvdec2 to make chromium work out of box. And at the moment hantro vpu patches are not at a good state to be upstreamed.

[ColorfulRhino]

This is a bit complicated. RK3588 has two h264 decoder: hantro g1 and rkvdec2, but userspace applications like gstreamer and chromium can't deal with two decoder with the same codec. We did a hack in armbian to disable h264 hantro vpu and use h264 decoder in rkvdec2 to make chromium work out of box. And at the moment hantro vpu patches are not at a good state to be upstreamed.

We should not stray too far from the upstream kernel in my opinion. If the Hantro G1 is hacked in and not in a good state (as in will not be upstreamed soon), we should remove it fully since it does not really provide any benefit. Its main benefit is/was H264 (the other codecs from Hantro G1 as far as I can see, VP8 and MPEG2 have no real relevance in 2024), but if rkvdec2 can do H264 in similar quality and is in a better patch state, we should only keep that one.

Opinions?

[amazingfate]

This is a bit complicated. RK3588 has two h264 decoder: hantro g1 and rkvdec2, but userspace applications like gstreamer and chromium can't deal with two decoder with the same codec. We did a hack in armbian to disable h264 hantro vpu and use h264 decoder in rkvdec2 to make chromium work out of box. And at the moment hantro vpu patches are not at a good state to be upstreamed.

We should not stray too far from the upstream kernel in my opinion. If the Hantro G1 is hacked in and not in a good state (as in will not be upstreamed soon), we should remove it fully since it does not really provide any benefit. Its main benefit is/was H264 (the other codecs from Hantro G1 as far as I can see, VP8 and MPEG2 have no real relevance in 2024), but if rkvdec2 can do H264 in similar quality and is in a better patch state, we should only keep that one.

Opinions?

Hantro g1 provides vp8, and I think it's worth keeping the patch.

[efectn]

I think the PR should be ready to merge. What do you think @amazingfate @ColorfulRhino

[amazingfate]

I tried to build kernel 6.11 serval days ago, but at that time there is no kernel shallow cache in ghcr. I'm fine with it if you guys have tested the kernel since this is bleeding edge.

[lanefu]

just did a build and working fine on my headless rock5b

https://paste.armbian.com/ohixoyiyeq

[rpardini]

at that time there is no kernel shallow cache in ghcr

That's... worrying. When there is no -rc, the shallow cache should carry torvald's master instead
I just checked https://github.com/armbian/shallow/actions and something broke -- thanks for alerting me to this

[ColorfulRhino]

Hantro g1 provides vp8, and I think it's worth keeping the patch.

Where is VP8 used these days? Sites like Youtube use VP9 and AV1 for ages. I have personally never noticed any VP8 encoded videos.

[rpardini]

the shallow cache should carry torvald's master instead

Fixed; it broke cos Torvalds pushed an arm64-uaccess branch together with his master branch and FETCH_HEAD defaulted to it. someone (@igorpecovnik ?) please merge armbian/shallow#3 there?