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

    I tried the (awesome) build on my Radxa Rock 5 ITX board. Install was flawless... Overall performance is pretty nice. On my 4K TV set - the GUI runs buttery smooth (at 4K60!)...

    However, I noticed some wonky things, besides the known ones (no passthrough, no HDR)...

    - Audio drops out irregularly while watching (48khz and 192khz content)

    - 192KHz Audio is not played "cleanly" - you can hear a popping/hissing/clicking

    - Dropped frames even though the video is decoded via hardware - is there something I can do about or is this known?

    - Video HDMI timings are odd - the OSD of my AVR (Marantz Cinema 70) is not shown - I only had this with a pc where I altered HDMI timings... - Running ARMbian (with vendor kernel and closed source Mali Valhall or open source panfrost driver) the OSD is shown perfectly


    If needed, I can send the sample file that I use(d) for testing audio things (it has different audio tracks, stereo, 5.1, 7.1, 16bit, 24bit, 48khz,192khz)

    Question:

    hw decoding of h264 and HEVC work fine - so are the hw decoding bits from here - that are sent upstream (https://gitlab.collabora.com/hardware-enabl…nline-status.md) already in there?


    thanks!

    I've noticed occasional audio dropouts during movies, but there are no traces of anything in Kodi or ffmpeg logs and the event is not reproducable, e.g. rewind media and the event does not reoccur at the same point. I have no idea how to reproduce or debug this so it's something I need to flag to upstream devs. I have a hunch (based on similar issues with Amlogic hardware) that this is related to unstable clocks, but I have no way to prove that and I have low expectations of an easy find or fix.

    I've not experimented much with 192KHz audio. If you have some structured test media that you can share, send me a download link; email to chewitt@ our domain or Kodi domain.

    I've not seen dropped frames in videos other than some known-bad test media with exotic/problem encodings, but playback is sensitive to using correct modes so I would strongly advise everyone to use adjust-refresh and the general config outlined in this wiki article: https://wiki.libreelec.tv/configuration/4k-hdr

    The kernel DRM layer is using HDMI 2.0/2.1 mode timings which are standards and both LE and Armbian are broadly using the same versions of mesa/panfrost, although this is only relevant for rendering the Kodi GUI an has nothing to do with HDMI modes and DRM connector timings. The one possible difference between LE and Armbian is that I have a bunch of in-flight patch series that enable deep-colour and HDMI 2.1 capabilities in the kernel and Armbian probably doesn't. That's all going to be merged upstream at some point though, and it's still the AVR's responsibility to generate its own OSD and overlay this onto the HDMI signal sent to the TV so if it can pass HDMI video/audio but not show its own OSD that sounds like an AVR bug. FWIW, the OSD of my 2018-ish Marantz AVR shows up fine on the rare occasions I display it.

    There are lots of in-flight patch series required for the image. All current hardware decode ones are included.

    Quote from chewitt

    Papaya5595 I've updated the RK3588 images in my test share to include newer iwlwifi firmware.

    Thanks for the quick response. The new image no longer outputs video to my display but instead repeatedly flashes "HDMI 1 No Signal" which I interpret as difficulty completing a handshake.

    Also noticed that the naming convention for the new image changed from "LibreELEC-RK3588.aarch64-12.90.1-rock-5b.img.gz" to "LibreELEC-ARMv8.aarch64-12.90.1-rock-5b.img.gz".

    I updated https://chewitt.libreelec.tv/testing/LibreE…-rock-5b.img.gz first before starting some work on an ARMv8 image that might become the future of support. We build too many images that are essentially the same aside for some compile time optimisation that doesn't make a huge different to performance. Consolidating to a single image will save a ton of CI time when building nightlies and releases.

    Add video=HDMI-A-1:1920x1080M@60D to kernel boot params in extlinux.conf and see if that helps?

    chewitt Could you update the image for the following devices? Rock64, RockPro64, Quartz64-A, Quartz64-B, NanoPi R5S. Then I'll do my best to do a test run with them shortly.
    I realize it may not be strictly needed for non-RK356x devices, but I prefer to have them all in the (exact) same software state.

    Quote from chewitt

    swever the images include the latest rtw88/rtw8821a_fw.bin firmware from the upstream linux-firmware repo and nothing has changed with that in the last few months. If you have files in /storage/.config/firmware/rtw88 these override the lastest upstream files so I would suggest removing them and using upstream firmware. If that doesn't fix something; clean boot then "journalctl | paste" and share the log URL so we can look for error messages etc.

    I deleted the firmware directory and the latest image (1/11/2026, 11:05:07 PM) makes the wifi dongle work again! Thanks!

    I just tried out the LibreELEC-RK356X.aarch64-12.90.1-radxa-zero-3.img.gz image on a newly bought Zero 3W, and it booted fine however, no wifi card appears to be detected, nor bluetooth.

    Is this to be expected?

    I'd edit my previous message, but can't apparently.

    I just checked by booting Radxa's official Debian image, and wifi and bluetooth work fine.

    Also, i got worried they'd sent me the wrong board as LE was only reporting 4GB of RAM, instead of 8. But no, there are 8 gig, htop and free -m confirm it. So it appears that's another issue with the LE image, it only reports 4GB of RAM out of 8GB.

    axel I forget exactly what the issue is, but IOMMU errors are seen with RAM sizes over 4GB so LE currently and intentionally sets mem=3838M in kernel boot params to sidestep the problem. You are free to remove that param and see the full 8GB, but expect other issues. NB: LE runs in under 1GB so it has zero functional impact on Kodi use.

    Quote from axel

    Zero 3W, and it booted fine however, no wifi card appears to be detected, nor bluetooth

    I can see that device-tree defines the module, but I can't see anything in documentation that states which Broadcom chipset is being used. It's probably something new(er) that we don't have firmware for, but as you didn't share the system log .. that's only a blind guess and could be wrong. In short .. no idea /shrug

    I will try to get a log, I was a bit lazy the other night as there was no immediate way of SSHing into the device.

    Or I currently have the Radxa Debian SD inside: with some minimum help I can confirm what firmware and kernel module are being loaded.

    axel I've spoken to Radxa about the AIC8800 wireless chip a couple of months ago as it's also fitted to one the boards I've been using to test. Radxa have no plans to upstream the driver as this would require a large effort, i.e. complete rewrite as the current quality of driver code would never be accepted into the kernel, and after years of working to rid our codebase of the maintenance burden of downstream (mostly Realtek) drivers we have no desire to add technical dept in the form of another vendor driver that has no plan to be upstreamed. I've shared our surprise/annoyance and position, and have strongly suggested they stick to using Broadcom, Qualcomm, Realtek (now upstream) chips in future iterations of current boards and future board designs so distros can avoid the need for crap drivers. I'm not sure LibreELEC's opinion will carry much commercial weight with them, but from our side, there's no action to be taken.

    Quote from diederik

    chewitt Could you update the image for the following devices? Rock64, RockPro64, Quartz64-A, Quartz64-B, NanoPi R5S. Then I'll do my best to do a test run with them shortly.

    Chewitt should have already seen it, but for completeness, I wrote a test report here:
    Re: [PATCH v3 0/3] media: rockchip: rkvdec: add support for the VDPU346 variant - Diederik de Haas

    I was a bit surprised that it was so easy to break it. My testing was only while connected to my 4K TV ... and maybe 4K input files also made it break faster?
    That's next to a 4K HDR video file (sort of) working, which was surprising and really cool :D

    I've read the feedback. I'm still experimenting with AI tools to see if they can bridge the gap in my rather lightweight coding skills or we have to resort to nagging Collabora folks to take over (or cap the current driver at 1080p to get an initial merge).

    HDR works, 8-bit only? (HDR is better when 10-bit but it's not mandatory) as RK3566/68 use the older Rockchip HDMI IP which has more colour support upstream. The newer one used with RK3588 etc. is still missing some infoframe handling IIRC.

    btw, Jonas believes https://github.com/torvalds/linux…2fdfc001d044bee might have resolved the "wiotlb buffer is full" IOMMU issue that requires RAM to be capped under 4GB. I'm going to remove the cap on my boards and see if I still get a load of weird errors. Please do the same on your LE images.

    My message may not have come across correctly then? I think both Detlev's v8 as your patch set are ready to be merged.
    There do need to come additional fixes ... somewhere (ffmpeg, mpv, RK356x SoC support, board support, etc) and possibly in multiple places. To make it even better!

    To me the issues I found (only) with LibreELEC indicate some issue on the LE side? And thus not with Detlev's and your patch set. Otherwise I should've gotten the errors also outside LE ... which was not the case. OTOH, I also got the feeling that it worked better on LE because it did its (decoding) work better ... which in turn showed there were actual issues. Again, dunno where. But those can be worked on in subsequent patch series?

    I actually tried both 8-bit and 10-bit ... and I thought HDR needed 10-bit? Both worked though.