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

  • The kernel is something that moves forwards continuously and relentlessly so the adage "If you stand still, you're actually moving backwards" applies in a big way and because (for good reasons) people became inactive for a while a whole heap of WIP changes got parked for a while. I don't think there's a single series, it's more a case of "a little bit of everything" as the kernel evolved.

    Im picking up what you're putting down. As opposed to the windows way of doing things where operating systems are just stacked on top of one another forever. Where your windows 2000 program will still run through 7 shims, and if you dive too many layers deep in the menus you'll end up in a program with an unresizable tiny window from when monitors were 480p, because why would anyone ever need to resize a window 😂.


    I was just curious, I know there was an effort or push to overhaul and standardize the requirements for manipulating graphics around kms and drm to help make things less of a wild wild west. Probably pretty helpful in the long run for projects supporting wide range of devices, although painful in the short term. Especially with manufacturers of sbcs that like to play the hype release abandon cycle on repeat.

    I was helping Moonlight-qt project who lost thier HDR support because setting 1 property on 1 connector instead of atomically, the kernel just said no after a certain version. I think those changes started around 3.19 but ran parallel and weren't enforced until well into the 6.x versions. I was just curious if the rock chip HDMI was a casualty of that same standardization effort with kernel graphics coming to completion.

  • Hi, sorry to revive and old thread. I have skimmed this thread and I was wondering if there are currently RK3588 images available. The links I found in the thread are no longer there. I would like to try out LibreElec on my Radxa Rock 5B.

    I also apologise if I'm asking a silly question or if I missed a rule or guideline. I would appreciate it if you could point me in the right direction.

    TIA!

  • Hi, sorry to revive and old thread. I have skimmed this thread and I was wondering if there are currently RK3588 images available. The links I found in the thread are no longer there. I would like to try out LibreElec on my Radxa Rock 5B.

    I also apologise if I'm asking a silly question or if I missed a rule or guideline. I would appreciate it if you could point me in the right direction.

    TIA!

    https://test.libreelec.tv/13.0/Rockchip/rock-5b/
    you can find the latest nightly in this. :)

  • Nightly seems to work like a charm. Installed on my NVMe by flashing it. Came up, rebooted. Did some basic config (via keyboard / mouse / monitor), hooked it up to my TV and used the remote for the rest. Video and audio works (I'm using a soundbar). Decoding and transcoding works as well. Just had to get used to indexing of Kodi (it is more strict than Jellyfin), but I can deal with that.


    Thanks for all the work to get this running on RK3588!

  • hello ,


    it might have been answered already, but is there already av1 decode support on rk3576/rk3588, or is the userbase too small fro quick progress? might have pickedup a rock pi5a,but now it seem the train is bit gone for awhile; but for libreelec also a 4gb variant could suffice?

  • AV1 is supported upstream on RK3588 but not RK3576; the latter has a different (all new) IP block and nobody wrote drivers yet.

    And the train is indeed a little quiet. Curating a working image still requires a large number of patches and as some of the in-flight series have iterated/progressed the number of conflicts between things has gone up, and resolving and figuring out how to solve those problems requires a level of effort that I don't have time and motivation for at the moment. Things are at the stage where the easy option is just leaving things as-is until more of the major bits are merged upstream and the overall patch count reduces to a more manageable level. That probably doesn't play well with the likely timeline for K22/LE13 though. Catch22.

    LE runs happily on 2GB boards unless you're planning to run flatpak things or other services in the background. 4GB is fine.

  • I've pushed revised RK3288/RK3328/RK3399/ RK356X/RK3576/RK3588 images to my test share. The main change is a kernel bump to Linux 7.2 with the latest usable iterations of the many patch series that go into current images. Of particular note: older Rockchip hardware is now using the same kernel as newer hardware since Kwiboo has been reworking old bit-rotten patches that broke and reworked patches are slowly being upstreamed.

    However !!! WARNING !!! .. I'm on vacation with zero access to hardware so the images are compile tested only, and a few large G&T's have assisted some of the patch wrangling. What could possibly go wrong? :D

    I'd advise taking a backup of KERNEL/SYSTEM before updating in case I messed things up and you need to roll back. I've not kept up with patches since Linux 6.19 so I'm half expecting some feature differences somewhere if I've missed things. Reports of success or failure (or feature completeness etc.) are appreciated.

  • Kernel 7.3 have improvements for gpu at arm64 systems.

    [GIT PULL] DRM Rust changes for v7.3-rc1 - Danilo Krummrich


  • I've pushed revised RK3288/RK3328/RK3399/ RK356X/RK3576/RK3588 images to my test share. The main change is a kernel bump to Linux 7.2 with the latest usable iterations of the many patch series that go into current images. Of particular note: older Rockchip hardware is now using the same kernel as newer hardware since Kwiboo has been reworking old bit-rotten patches that broke and reworked patches are slowly being upstreamed.

    However !!! WARNING !!! .. I'm on vacation with zero access to hardware so the images are compile tested only, and a few large G&T's have assisted some of the patch wrangling. What could possibly go wrong? :D

    I'd advise taking a backup of KERNEL/SYSTEM before updating in case I messed things up and you need to roll back. I've not kept up with patches since Linux 6.19 so I'm half expecting some feature differences somewhere if I've missed things. Reports of success or failure (or feature completeness etc.) are appreciated.

    Thanks for the images.

    I updated from the latest nightly build using the .tar file on my Orange Pi 5 and the update process went smoothly.

    YouTube playback was as flawless as it usually is.

    When I turned my attention to a list of test files, some of which are common files available on the web I found that some would not play at all, one would seem to play with great delays between frames and some that would result in a black screen, where my TV would lose signal, only to regain it once the file playing in the background finished and returned to the GUI, allowing the file to be played successfully on a repeat play.

    So fair to say that that there is some regression but it is not a bad thing to see where we are with the new kernel right now.

    Having followed the many updates from collabora in recent months that seem to be bringing the whole picture together more, especially as more and more go upstream, the future might have some light ahead for the RK3588.

    In terms of where things stand right now though, experience has taught me that sometimes a fresh install is the way to go, so I will create a fresh one and repeat my testing to see what the state of play is.

    I would be disappointed to hear any response from you whilst you are knocking back your few large G&T's in your paradise holiday location.

    So enjoy the booze, the other consumables, the relaxation and continue again on the flip side.

  • Kernel 7.3 have improvements for gpu at arm64 systems.

    None of that is relevant to a device currently running a development images with 7.2-rc6/rc7 kernel. Even when 7.3 ships it will make zero real-world difference to any of the devices that LE supports. These changes are the coding equivalent of rearranging deckchairs.

  • Quartz64-B (RK3566):

    • 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

    Earlier today a patch was posted with mentioned POST_BUF_EMPTY:
    [PATCH] drm/rockchip: vop2: Scale the AXI clock to the bandwidth the mode needs - Igor Paunovic

    No idea if it can help with that, but figured I'd mention it.

  • diederik I currently distrust anything from that contributor as a result of conversations over the RK3588 VP9 driver submission. All of their comments complete with inaccuracies were being generated through some AI tool and they bullied the main author into adding them as Co-Developer on the series despite their contributions being little more than minor fixups found through testing, and one "very important fix" patch that was quickly proven to be irrelevant under maintainer review. The patch you've flagged is worded less aggressively than previous things but that's more likely to be evolution in the AI tooling than human influence.