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

    oke, update - I just tested the latest build (21/02/2026) and audio passthrough of at least Dolby Digital works fine (dts untested); however, with my UHD bd rip streamed from a smb share, I had some severe frame dropping. Multiple frames at a time...

    I will retest with some more time, with passthrough enabled and without...

    What I also noticed, was pcm output seems wrong in regard to channel mapping. The center channel was played by the right channel speaker.

    I've pushed updated RK3588/RK3576 images that appear to have HBR formats "working" to some level now, although I hear some glitches on a few files that could be underruns or some kind of DP/HDMI bandwidth issue.

    I don't see channel mapping issues with speaker-test -D hw:hdmi0,DEV=0 -c 6 on a Rock 5B board. Channel mapping was an issue in the past, but Kwiboo spotted the problem some weeks ago and a fix was submitted upstream.

    If you see issues with SMB shares perhaps experiment with different SMB chunk size values in the Kodi SMB client settings. I see no issues with 50GB+ sized ISO rips (other than start being slower) so that sounds more like an environment or media problem.

    Quote from chewitt

    DeViLRuNNeR-dev there are now 200+ patches in my Rockchip 6.19.y kernel branch so I can't put my finger on specific things that make PCM output work on that hardware. I do know that working multi-channel PCM output is not a new thing for LE images, it's been around for a few months now.

    Commit d39e2d1 kinda describes what I am seeing in mainline/upstream kernels. How would one ask for these to be included in current-rockchip64 kernel builds?

    Hello ,I tested the new build own (21/02/2026) for Khadas Edge2 from chewitt github and audio passthrough works fine.

    The built-in Wi-Fi module AP6275P was not being recognized before I made the following changes to the file.

    LibreELEC.tv/projects/Rockchip/linux/linux.aarch64.conf at rockchip · chewitt/LibreELEC.tv
    Just enough OS for KODI. Contribute to chewitt/LibreELEC.tv development by creating an account on GitHub.
    github.com

    + CONFIG_PCIEASPM_DEFAULT=y

    + CONFIG_BRCMFMAC_PROTO_MSGBUF=y

    +CONFIG_BRCMFMAC_PCIE=y

    and then copy firmware.tar.gz from this post RE: Unofficial LE for RK356x RK3328\RK3399 RK3588(s) RK3576

    Can you confirm if this is the correct way to do it, or should I use another method.

    So far, I have not been able to boot correctly new builds from chewitt github on internal eMMC of the Khadas Edge2.

    The only working option so far is to first install latest version from hеre https://yadi.sk/d/8vNYuuxynz1L0w

    on the eMMC, and then manually replace the SYSTEM, KERNEL, and DTB files.

    It seems that the official versions of U-Boot currently do not support installation from eMMC for this model.

    Is there any other solution for this, or do we simply need to wait for it to be developed in the future?

    f1gogata If you have been running Oleg's older RK images I have no understanding of how the board is booting or what u-boot versions are installed, but you probably need to a) erase the vendor u-boot that Khadas oocrap installed to SPI flash, as this has boot priority over the emmc device, and b) ensure an LE image has been written to emmc using dd to ensure u-boot 2026.01 is present on emmc to boot the device once SPI flash has been erased.

    To erase SPI flash, run dd if=/dev/zero of=/dev/mtdblock0 bs=1M from any Linux OS that boots.

    To write LE to emmc, boot an LE image from SD card or USB stick (so emmc is not in-use) then transfter a current LE13 image over to the /storage partition and use emmctool to write the image to emmc.

    Quote from DeViLRuNNeR-dev

    Commit d39e2d1 kinda describes what I am seeing in mainline/upstream kernels. How would one ask for these to be included in current-rockchip64 kernel builds?

    The same change is present in the rockchip-6.19.y branch: https://github.com/chewitt/linux/…9847573205c326a used in my test images and the same will be in LE13 nightlies. If you want to have the same fix in some Armbian release (we have no rockchip64 kernel builds) go ask their devs to copy the patch from my tree.

    Quote from f1gogata

    The built-in Wi-Fi module AP6275P was not being recognized before I made the following changes to the file

    I've picked the same changes to the next images I push to my test share (might be a few days as investigating a boot issue with Linux 7.0-rc1 at the moment). If you share a boot log showing which firmware files are being used these can also be added.

    Quote from chewitt

    I've picked the same changes to the next images I push to my test share (might be a few days as investigating a boot issue with Linux 7.0-rc1 at the moment). If you share a boot log showing which firmware files are being used these can also be added.

    Thank you for your response.

    Here is boot log from terminal -

    External Content pastebin.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    https://paste.libreelec.tv/pure-mink.log