LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    The RK3588, RK3567, RK356X images in my test share have been updated to use Linux 6.19.0 and HDR is now working on RK3588 and hopefully RK3576 too (limited tested on RK3588, no testing on RK3576 yet). I'm finding the output a little dark compared to the family daily-driver RPi5 board, but different hardware will always give different results, and most users won't have multiple devices wired up to the TV for comparisons; meaning you can tweak TV settings/profiles to get things as you like.

    I did some new tests and these are my findings:

    Rock64 (RK3328):

    • LE Add-ons gave error msg "Could not connect to repo" (too old image?)
    • BBB 1080p: AVC or HEVC including 10-bit -> perfect
    • BBB 4K: almost perfect, just a couple of minor display problems ('shocks')
    • 'Costa Rica' 4K: 8-bit -> works reasonably, including HDR, but also several 'shocks'
      10-bit: quite a lot of artifacts, including green lines
      Probably expected as those files are likely encoded above the RK3328's specs
    • Jellyfin: AVC/HEVC-8bit/HEVC-10bit @30M all played fine
    • Bo Burnham and Elementary: subtitles didn't work and several artifacts on 10-bit variants; 8-bit was quite a bit better

    RockPro64 (RK3399):

    • On bootup, my TV (I think) reported "Invalid format" ?!? That also happened on my own Sway system (with 6.19-rc7+media-patches kernel). On LE the display seemed fine afterwards, but on my own system, the right ~1/3th of the screen had some white/gray 'overlay', obscuring most of what would be shown there.
    • LE Add-ons gave error msg "Could not connect to repo"
    • HDMI audio did NOT work on LE ... but did work on my own Sway system, but not exactly flawless either. I did not test analog audio with LE, but it hasn't been working on my own system for quite a while. Apparently known to several people ...
      Several errors reported in dmesg wrt audio on my own system (for quite a while); didn't check on LE.
      FTR: The HDMI cable is not a/the problem as it works/worked fine with all my other tests
    • Tried BT audio which technically worked, but audio was delayed by 1-2 secs and of very poor quality. May be caused by the WiFi+BT adapter though? (I have nothing to compare its performance with yet)
    • 'Costa Rica' 4K: pretty good including HDR, but small 'shocks'. It seems my HEVC 10-bit variant played perfectly \o/
    • Jellyfin: AVC/HEVC-8bit/HEVC-10bit @30M all played fine (AV1 in 'slow motion' though)
    • Bo Burnham and Elementary: subtitles worked, but sometimes resulted in minor artifacts ... but only with 10-bit files. The 8-bit variants played without artifacts

    Quartz64-B (RK3566):

    • LE Add-ons worked just fine (installed System Tools successfully)
    • BBB 1080p: AVC or HEVC including 10-bit -> perfect
    • BBB 4K: Several display issues like hickups ... and then a black screen (again/still) with rk_iommu page faults.
      vop2_isr ~386K callbacks suppressed
      [drm] *ERROR* POST_BUF_EMPTY irq err at vp0
      rkvdev fdf80200.video-codec: Frame processing timed out!
      last msg was printed only once, the others MANY times
      No return to visible list of files when stopping playback; reboot was only remedy
    • Jellyfin: All played fine, but no playback (at all) with AV1 (I know HWDEC doesn't support AV1 on RK3568) ... but LE still indicated it was playing 'something'
    • Elementary: Subtitles worked on 8-bit file ... but also resulted in black screen. Looks like subtitles cause the problem as without it, it played fine.

    HTH

    RK3288/RK3328/RK3399 depend on a different kernel patchset which I am still trying to encourage (re)work on from knaerzche and Kwiboo. I'm not really able to judge the state of things and I don't have working test hardware. I'm not suprised there are issues, and I don't plan to do much about it for now.

    RK356X is expected to have issues with page faults as there's been zero development on fixing buffer sizes. As I don't really code, I plan to have Claude AI investigate that problem, but first I need to prepare all the relevant source materials for the prompt, and then I'll need to have enough tokens/time to let it work on the issue. AV1 isn't supported on the hardware.

    Quote from chewitt

    treedav I've picked the Armbian patch that Yasai-san flagged, and pushed an updated image to my test share. On reboot the card should now be detected, but firmware will be missing. Check the system log for errors and filenames.

    See https://wiki.libreelec.tv/how-to/add-firmware for instructions on manually adding firmware. This repo has firmware files with a blind guess at the needed filenames: https://github.com/chewitt/brcmfm…re/tree/ap6275p

    https://forum.armbian.com/topic/36744-or…dComment-214649 suggests this might not be enough, but best to try. If it does work I can send the patch upstream and add the firmware to our collection. Please share the journal log, e.g. journalctl | paste and share the URL.

    LibreElec noob checking in here. I am looking to upgrade my streaming box on my TV with LibreElec, and the RK3588 on the Orange Pi 5 family is great on paper for hardware video decoding. My idea is to have H265/AV1 HDR 10-bit files stream from my local Jellyfin server over Wifi without any transcoding for quality reasons.

    Was anyone able to get the Wifi on the 5B to work? My other question -- on the Orange Pi 5 Plus, with the M.2 slot for a Wifi card, would any card with kernel support (e.g. Intel AX200) be recognized automatically by LibreElec, or would I need to build my own custom version of LibreElec? Just trying to figure out what I'm getting into before buying. Also open to any other SBC (H265/AV1 HDR 10-bit hwdec + wifi) recommendations.

    Thanks for all the hard work!

    > AV1 isn't supported on the hardware

    I know. But with RockPro64 it then tried CPU based decoding, which is exactly what I'd expect. Therefor on RockPro64 I did get normal video output, but as said in 'slow motion' (i.e. the CPU wasn't fast enough).

    Displaying an error like "format not supported" (and then return to file list) would've made sense to me too.

    What doesn't make sense to me is what it actually did.

    I don't have the knowledge/skills to do that.

    I (probably) should've left out that sentence. What I wanted to point out is that I don't understand why there is (completely) different behavior based on SoC (or board) ... which may indicate some bug in the kernel or somewhere else in the display pipeline. I don't have the knowledge/skills to do that either, but hopefully someone on the LE team does.

    Edited once, last by diederik (February 14, 2026 at 1:17 PM).