Unofficial LE for RK356x RK3328\RK3399 RK3588(s) RK3576

    Quote from Protx

    Armbian have a dts file/patch for their "edge" 6.18 kernel

    From the amount of /delete-node/ and /*commented*/ items in the file I'd guess it either forward-ports a device-tree file that was originally written for the vendor kernel or is a hand-rolled attempt from an inexperienced developer. It probably works(ish) but six months has elapsed since it was created so (as normal for Armbian patches) the author clearly has no intention of trying to submit support for the board upstream, and that's probably because this dts is too much of a hatchet job to be accepted.

    https://github.com/armbian/build/pull/8348 <= The "VPU (Unable to test due to lack of VAAPI support)" comment is amusing :)

    The Armbian PR also confirms the board needs an out-of-tree Ethernet driver to work. For both board and Ethernet support I'll be happy to cherry-pick patches submitted to kernel mailing lists, or items from known kernel contributors (who are trusted to follow-through on upstreaming them) but that's my minimum threshold.

    I've pushed updated images for RK356X, RK3576, RK3588 to my test share. These are now using Linux 6.18.1, and the v4l2_request patches currently being upstreamed to FFmpeg not the patches LE has used in recent years. FFMpeg devs have requested a few things to be moved around in code to align with their standards and this has surfaced an issue where Kodi shows visual glitches in video when OSD objects like vol up/down, navigation bars, etc. are overlaid on the screen. We have already figured out roughly what the underlying issue is, but it might take a while to come up with a proper fix. On the upside, the latest patches add FFMpeg support for the hantro AV1 hardware decode IP block on RK3588.

    Two steps forwards, one step backwards :)

    I've pushed updated images with some initial WIP support for VP9 hardware decode on RK3588 (limited to Profile 0 = 1080p). The codec driver has literally been found hiding in plain sight on GitHub earlier today; the work of a Computer Science undergraduate who has been working on Android images for recent RK boards. I am yet to chat with the author about his plans, but there are code and reddit comments about wanting to add 4K support and upstream which sound positive.

    NB: If the driver matures a little more it should be reasonably simple to extend support to RK3566 and RK3568, but RK3576 uses a newer IP block that is "similar but different" enough to need a separate driver.

    Kwiboo has given me (and thus you) some patches to test that fix the glitching/tearing issues introduced with the latest ffmpeg changes so RK356X/RK3576/RK3588 images in my test share have been updated to include them. Go forth and report issues :)

    NB: I've also extended VP9 hardware decode (up to 1080p) to RK356X as the patch was indeed trivial. However i'm not in the same location as an RK3566 or RK3568 board at the moment, so let me know if it works?

    Quote from chewitt

    Kwiboo has given me (and thus you) some patches to test that fix the glitching/tearing issues introduced with the latest ffmpeg changes so RK356X/RK3576/RK3588 images in my test share have been updated to include them. Go forth and report issues :)

    NB: I've also extended VP9 hardware decode (up to 1080p) to RK356X as the patch was indeed trivial. However i'm not in the same location as an RK3566 or RK3568 board at the moment, so let me know if it works?

    The glitching/tearing mitigation patches appear to be working really well on the r6s rk3588s. Using the YT add-on, vp9 playback does occasionally produce a static green video output, and sometimes seeking forward/backward or restarting playback results in expected video output.

    The work-in-progress VP9 driver implementation is loosly based on the older 'rkvdec' IP block for RK3399 boards which was limited to 'Profile 0' media (8-bit, YUV420, up-to 1080p). The driver has been extended to work with 4K media, but needs further work to support 'Profile 2' (10-bit) and the DRM layer on RK3588/RK3576 does not support YUV422 yet. The driver author also needs a little coaching on how to run the 'fluster' tests that are used to score conformance and capabilities. It's a promising start though.

    Updated images in my test share now run Linux 6.18.2 and after some collaborative VP9 fiddling with the driver author this morning all the YUV420 8-bit/10-bit VP9 test media I have now plays fine on RK3588 (no more green screens) although whether we managed to correctly enable 'Profile 2' support in the driver is anyone's guess. On RK356X I'm seeing some IOMMU page-fault issues with 10-bit HEVC media. There's also an issue on RK356X where fractional rates (23.976/29.97/59.94) are not showing up in the kernel DRM layer. That can be worked-around by disabling adjust-refresh and allowing Kodi to run at 60Hz. Both of those will need some looking into. And i've not tested with RK3576 for a while, something still to find time for.