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

    I've pushed Rockhip images based on the RK356X/RK3576/RK3588 enablement PR: https://github.com/LibreELEC/LibreELEC.tv/pull/10420 to my test share.

    Download here: https://chewitt.libreelec.tv/testing/

    Images are versioned 12.90.1 in premature preparation for an LE13 alpha1 release. Don't get too excited at the version; there are no timescales and it's just a number. I use static versioning because it makes download URL's predicatable vs. having random githashes in filenames. If I push updated images to my test share the date/time of the image changes, not the version number.

    Images are experimental "minimum viable product" not "finished product" state with 15+ different kernel patchsets (some merged, most are in-flight). There is huge scope for bugs and issues. You should expect to find some problems.

    Media capabilities: H264 and HEVC should work. 4K modes should work, but there is no HDR and I don’t expect this to be added in the short-term. VP9 is software decoded at 1080p but hardware decoded at 4K (which is a bug as it should be software decoded) so 4K currently fails. AV1 is software decoded; the kernel driver exists but the corresponding FFMpeg hwaccel has not been written yet.

    CEC should work although I never test this myself as too many identical devices are connected to the AVR and it gets confused.

    HDMI audio is limited to PCM output. There is no pass-through and I have no idea what is missing or needed to enable that.

    Feedback on issues related to distro packaging and specific boards (boot issues, missing hardware etc.) is useful. Feedback that includes fixes is particularly welcomed. If you want to be a "tester" posting "H264 working, HEVC working" levels of detail each time I post an update please keep quiet. The core image has already been through basic sanity testing and we have general knowledge of what works (and media capabilities are still very much work-in-progress) so that kind of feedback is noise and quickly becomes annoying. Of course, if you have technical knowledge on kernel and codec development we are keen to have your meaningful feedback!

    p.s. If for any reason you need to share a log file, please use the built-in paste function or upload to pastebin.com and then share the URL generated. If you attach files to your post do not expect me to look at them.

    Enjoy :)

    Tested for a few hours on my Orange Pi 5 8Gb board.

    Works beautifully for the vast amount of 100+ files that threw at it.

    VP9 4K does not seem to work correctly. It attempts to play but does not switch to the video playing in the background and as I move my mouse I get a mouse trail. I am able to assess the play button to stop play, so no locking up. With VP9 still on the Collabora list for resolution, I therefore expect this not to work, so not a fault right now.

    No hardware acceleration on AV1, which I partially expect based upon comments made on another thread where whilst Collabora have reported AV1 as complete, this turns out to not to be the case.

    Everything else plays perfectly in line with the 'basic sanity testing' stated by the OP.

    But I can add that I could not find a file outside of VP9 or AV1 that did not play as hoped, including some high bitrate files at up to 400MBps.

    YouTube plays perfectly, subject to the VP9 and AV1 caveats mentioned above.

    Nice to see CEC present and working.

    One note regarding the OP5 that I know is not a direct focus of LibreELEC, which is active on some distros like Armbian but not on others, is the USB-C port, where I sometimes have my mouse, keyboard and controller plugged in via a hub, is inactive. Just for note to other OP5 users so that they can know what to expect from the start. A feature no doubt to come when code is pushed to mainline in future Linux kernel releases.

    In short, amazing work that I could not really want more from right now.

    No lockups, restarts or erratic behaviour so far.

    It will become a daily driver already.

    Only faults and improvements to be posted from now on as per the OP's requirements.

    :)

    Edited 2 times, last by ozarks (August 28, 2025 at 6:23 PM).

    ozarks I've updated the first post with info on media capabilities; VP9 is known and possibly a partial leak of RK3399 capabilities to the newer SOC, it's been flagged to Collabora. Regarding OPi5 and USB-C, if you can point me to patches on a mailing list I can pick them, but I don't think I see anything for that board. Or if you can figure out the patch (there is maybe prior art for the Rock5 boards) I can send the patch upstream on your behalf.

    I have asked the question over at Armbian and piecing together what I have previously read about the USB-C, which I am hoping will be a universal kind of fix for all RK3588 boards.

    I have noted recent entries on the Collarora to do list regarding eDP, USB-C link and the latest entry for DisplayPort controller, which seem linked to me but will seek more clarification on what the defined meanings are in order to identify what I think may be a patch before sinking sending you on a wild goose chase.

    That there are other ports to provide the necessary USB I/O connectivity means that use and testing can proceed pro-actively.

    On Radxa ROCK 5C (RK3588S) - Not ROCK 5C Lite (RK3582)

    Display is shown with 1027 x 768 size on Full HD display.
    Splash logo screen and kodi both are shown this size.

    By dmesg, "i2c read error" and "i2c read timed out" are several times logged.


    I'm sorry just report only.
    I can't find any good information for this.

    Works fine on the NanoPi-R6C except for audio ( no audio device detected )

    Its very very very smooth, it hardly breaks a sweat. From the 8 cores playing a random MKV@1080p@x265, 7 are idling 0-2%, one of them jumps between 25%-40% and its a different core each time (a bit like whack-a-mole with one mole) .

    CEC is detected, but in my work env i have no TV ;(

    SMB works, NFS works

    Booted right out of the box ^^

    Except for the audio this is one hell of a job guys :thumbup:


    Thanks


    edit: I found out that only 4GB of the 8GB memory is recognized

    afaik the R6C came in two models: 4GB-no_flash and 8GB-32gb_flash

    Edited once, last by Elicity (August 29, 2025 at 9:39 PM).

    Elicity

    > Works fine on the NanoPi-R6C except for audio ( no audio device detected )
    NanoPi-R6C/R6S HDMI audio will be added in near future.
    Update patch file is exist.

    > only 4GB of the 8GB memory is recognized
    This is suppressed boot parameter of /extlinux/extlinux.conf in now.
    By previous versions readme.md (projects/Rockchip/devices/RK356X/README.md),

    Code
    * ram is limited to ~4gb with `mem=3838M` (memory range `0x00200000` - `0xefffffff`)
 - there is an issue with importing decoded video frames into display stack
 - old work-in-progress patches broke display stack for older socs

    RK3588 and RK3576 are same as RK356X
    I don't know this has been updated or not, sorry.

    Yasai-san

    Quote from Yasai-san

    NanoPi-R6C/R6S HDMI audio will be added in near future.
    Update patch file is exist.

    That is very nice to know.

    Quote from Yasai-san

    I don't know this has been updated or not, sorry.

    Don't be, I'm happy as it is now, it was unexpected to see things go as fast as they do. I think we get a fully working RK3588/s kernel in Linux 6.18 late December. Most likely small issues and quirks like these will be solved a bit later.

    I don't even know if I would benefit from the extra RAM if its available /shrug

    Thank you for your time :saint:

    edit:

    Quote from Yasai-san

    Update patch file is exist.

    Is it this one: https://lkml.org/lkml/2025/8/7/872 ?

    Patch: https://lkml.org/lkml/diff/2025/8/7/872/1

    Edited 2 times, last by Elicity (August 30, 2025 at 6:35 AM).

    Elicity

    > Is it this one: https://lkml.org/lkml/2025/8/7/872 ?
    > Patch: https://lkml.org/lkml/diff/2025/8/7/872/1
    Yes!
    I did confirm this patch locally, HDMI audio is working on my R6C/S.

    And this is known chewitt.

    Rockchip: add support for RK3588, RK3576, and RK356X devices by chewitt · Pull Request #10420 · LibreELEC/LibreELEC.tv
    This supersedes #7864 which has been waiting for numerous upstream dependencies to reach mythical "minimum viable product" state for LibreELEC use.…
    github.com


    This is merged latest version(12c4579bd9) ^^

    Quote from chewitt

    Elicity I've picked the patches for R6C. If you update using the RK3588 .tar file in my test share HDMI audio should work now?

    YES it does!

    Yahoo, it works like a charm. OMG this amazing, I've played around with it for a couple of hours now. Watched an entire movie just to see how it would hold up and from this short exposure I can say: its been working great.

    There is one hick-up playing videos on my Samsung TV where it jerks the screen every 10 seconds or so. Setting "PRIME RENDERING" to "EGL" solved this issue. (I did not experience this on my test monitor earlier, so ymmv)

    Very impressive guys :thumbup:

    Quote from Elicity

    Setting "PRIME RENDERING" to "EGL" solved this issue

    EGL rendering is always a workaround not a solution, as it's not as efficient as DRMPRIME rendering. Interesting to know that it has impact though. DRMPRIME is the correct configuration to be using (in the long-term).

    Quote from kelv

    Initial boot of 12.90.1 on the rock-4c-plus looked good however no sound devices were picked up by alsa (13.0-nightly has functional sound).

    Please put Kodi in debug mode then reboot and run "pastekodi" and share the URL so I can check for issues.

    Quote from PANiCnz

    For a RK3399 board how do these images differ from the standard nightly's? More or less features? or much the same?

    Either way will give it a go on a Rock 4C+.

    There should be no real-world difference as we're still using the same overly-large kernel/u-boot/ffmpeg patchsets. To long-term reduce maintenance effort I've merged all the kernel configs though, so it's possible there are some missing drivers.