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

    Things work better on LE due to the OS being overall lighter and because Kodi setup with adjust-refresh and whitelists etc. requires less compute resources during playback than a desktop app under wayland that's forced to resample audio and video to run at the desktop rate of 1080@60Hz or 4K@60Hz.

    The buffer size issue is the main thing to focus on for VDPU346. The VP9 patches seem to work well and I'm coaching Abhi Sarma on kernel etiquette so hopefully a v1 series can be sent for review soon.

    The minor tearing/glitches that can be seen when the Kodi OSD is active are the result of refactoring in the ffmpeg patches (dealing with ffmpeg developer feedback/requirements) and additional work in Kodi is needed to get back to the previous state where there were no artefacts. More patch series need to be merged down, then some effort can go into investigating that.

    Test share images are updated with Linux 6.19-rc6 and a notable fix to gracefully handle uninitialised values during HEVC decoding which helps with 4K media files that spammed the system log with errors. I'm now able to play all the HEVC media in my test-file collection which includes a number of known-bad files. Playback of those sometimes takes 10-15 seconds to start, depending on the underlying kind of broken, but even those play which is great. That fix (the result of AI analysis of kernel splats) also pointed fingers to some related code that can be improved to not allow the uninitialised values in the first-place, so we should see some additional fixes on the mailing-list in the next week.

    At this point the only things I feel are missing from RK3588 are HDR and hardware deinterlacing. The former will eventually happen through work Collabora are doing. Nobody is handling the latter though.

    I'm back to buffer size AI guesswork and nagging Jonas to review old patches for older hardware so we can get closer to a unified kernel source for aarch64 boards.

    chewitt updated to the new nightly (r6s) and it booted to a large mouse cursor in the top left which disappeared into a black screen. Had to ssh in and systemctl start/restart kodi.service, which was preset: disabled (not by me).

    There is no underlying desktop environment in LibreELEC so if you saw a mouse cursor on-screen Kodi started. If the home screen did not then show, the kodi.log (hopefully a debug one) and/or the systemd journal might have clues. This is probably past-tense though and I've not seen anything similar; other than the Kodi database upgrade screen. NB: I'm not aware of anything in images that would result in kodi.service being disabled.

    Quote from chewitt

    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.

    Thanks for the detailed answer, it's appreciated. I understand and support your position, from a LE project perspective.

    From a "how do i get this device to do what i want" perspective, it sounds like i need to learn to build LE and add the driver in my image, to get it to get usable wifi? or add an external wifi adaptor, which is a lot simpler, a bit sad considering it has onboard wifi, and not as fun (probably type-2 fun though, lets' be honest). Or run Armbian / Radxa Debian and make it boot into Kodi.

    Quote from axel

    ...it sounds like i need to learn to build LE and add the driver in my image, to get it to get usable wifi?

    Thread

    Self-building an LE image with RTL8852CU support

    My Raspberry Pi 4 was getting terrible wifi reception and the cheapest way I could figure to improve it was to buy a cheap wifi adapter off of amazon.

    I bought an "AX5400M" wifi 6e usb adapter with external antennas, hooked it up and... nothing.

    lsusb showed the device with an ID of 0bda:c832 and dmesg showed it was being recognized as a wifi adapter, but it wasn't actually accessible.

    Some googling indicated this chipset is _very_ new and there is practically no support for it anywhere, but…
    Kermit_Protocol
    August 31, 2023 at 11:05 PM
    Quote from axel

    From a "how do i get this device to do what i want" perspective, it sounds like i need to learn to build LE and add the driver in my image, to get it to get usable wifi? or add an external wifi adaptor, which is a lot simpler, a bit sad considering it has onboard wifi, and not as fun (probably type-2 fun though, lets' be honest). Or run Armbian / Radxa Debian and make it boot into Kodi.

    Regarding this, my post will help with your image building LE I think.

    Post

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

    […]

    I made the aic8800 driver and firmware package using Radxa driver repo for my Radxa ZERO 3W confirmation.
    https://github.com/ShigeakiAsai/L…er-and-firmware
    It needs 2 commits. ( 6cb5a2a7e83535b1265a23d79124356956df6f4e and d9c5aa21eaea8dbdc3a984ddc964c52e81c2b6e2 )

    The firmware files were loaded and wifi was able to use.
    Just report only, I don't make pull request for this.
    Yasai-san
    September 22, 2025 at 12:42 PM

    But I don't create Pull requests for AIC8800 driver because I'm agree with chewitt and LibreELEC perspective.

    Quote from Yasai-san

    I don't create Pull requests for AIC8800 driver because I agree with chewitt and LibreELEC perspective.

    Yasai-san Just create a pull-request with "This PR is being submitted so information on how to add the AIC8800 driver package into a self-built image is more easily found. I support the project's wish to not add downstream drivers that have no visibility of being upstreamed and do not expect this to be merged" .. so we look less authoritarian when we close it without merging :)

    Quote from chewitt

    Yasai-san Just create a pull-request with "This PR is being submitted so information on how to add the AIC8800 driver package into a self-built image is more easily found. I support the project's wish to not add downstream drivers that have no visibility of being upstreamed and do not expect this to be merged" .. so we look less authoritarian when we close it without merging :)

    I made PR as https://github.com/LibreELEC/LibreELEC.tv/pull/10960
    Please close this PR. :)

    Quote from dale

    With latest build for rk3566, I got high cpu/gpu temperature (71C) and sometimes crash. Is it expected?

    High temps aren't expected unless doing something CPU intensive, e.g. software decoding. NB: CPU temp is reported, GPU is faked in the Kodi GUI (re)using CPU data. Most boards also benefit from heatsinks and cases that conduct heat. The 71ºC temp is higher than desirable but most boards can run a lot hotter than we're comfortable with so it's probably short of problem levels.

    Crashes (not heat related) are perhaps more expected given the current experimental state of images with 160+ patches. There are known issues with DRM buffer sizes that will probably show up with HEVC media and spam the system log with IOMMU page-fault reports. If those start showing the system ends up in a state that will ultimately need a reboot to recover from.

    NB: Put kodi in debug mode and then use "pastekodi" to share log URL's post-crash. Guessing at issues isn't our strength :)

    Quote from chewitt

    High temps aren't expected unless doing something CPU intensive, e.g. software decoding. NB: CPU temp is reported, GPU is faked in the Kodi GUI (re)using CPU data. Most boards also benefit from heatsinks and cases that conduct heat. The 71ºC temp is higher than desirable but most boards can run a lot hotter than we're comfortable with so it's probably short of problem levels.

    Crashes (not heat related) are perhaps more expected given the current experimental state of images with 160+ patches. There are known issues with DRM buffer sizes that will probably show up with HEVC media and spam the system log with IOMMU page-fault reports. If those start showing the system ends up in a state that will ultimately need a reboot to recover from.

    NB: Put kodi in debug mode and then use "pastekodi" to share log URL's post-crash. Guessing at issues isn't our strength :)

    Can you take a look at the log here? https://paste.libreelec.tv/legible-shrimp.log

    dale The kernel runs out of memory (OOM) and oomkiller stops kodi.bin to avoid resource starvation. I've not see anything similar, but the board samples I use are all 2GB minimum (most are 4GB/8GB) so I'm not going to see OOM conditions.

    Code
    CmaTotal:         524288 kB
CmaFree:          515660 kB

    Splat analysis from AI tools points out the kernel has 512MB CMA allocated, which might be too much for your 1GB board. This is set during kernel compile through the kernel defconfig https://github.com/chewitt/LibreE…ch64.conf#L8038 but it can be overriden with a kernel boot param in extlinux.conf, so you can add cma=256m and see if that prevents the crashes?