Posts by Yasai-san

For anyone with a ROCK 4C+ V1.41 that does not boot with the rock-4c-plus image: booting with the rkbin 666MHz DDR blob (legacy boot chain) works on my board with current LE master. Details and the commit are here: RE: LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

Hi chewitt, two RK3399 boot issues I found and fixed on real boards while working on Lakka (which shares the LE Rockchip bootloader setup):
1. NanoPi M4 2GB The 2GB variant uses DDR3 (Samsung K4B4G1646E-BCMA) instead of the LPDDR3 on the 4GB model, so the nanopi-m4 image stops in TPL with "sdram_init: LPDDR3 - 933MHz failed!". Adding a nanopi-m4-2gb entry using the upstream nanopi-m4-2gb-rk3399_defconfig fixes it. Tested on LE master (U-Boot 2026.07). PR: https://github.com/LibreELEC/LibreELEC.tv/pull/11832
2. ROCK 4C+ (V1.41 with different LPDDR4) Same issue as https://forum.libreelec.tv/thread/29774/ : with the mainline TPL there is no UART output at all (confirmed with the current LE master rock-4c-plus image). It boots with the legacy chain (rkbin DDR blob + miniloader + trust, mainline U-Boot proper) using rk3399_ddr_666MHz_v1.30.bin, matching Radxa's statement that the RK3399-T needs the RAM at 666MHz. I added it as a separate "rock-4c-plus-ddr666" board so existing rock-4c-plus users are unaffected. The DDR blob is selected in rkbin/package.mk, next to the RK3328 frequency override. Tested on LE master: boots to Kodi on cold boot and reboot, 4GB RAM. Commit: https://github.com/ShigeakiAsai/L…65eb17339d1cc5e Is this approach acceptable for a PR, or would you prefer something else (e.g. mainline SPL with CONFIG_ROCKCHIP_EXTERNAL_TPL)?

jernej Thanks for the update! With the AXP313A ramp delay fix, my Orange Pi Zero3 runs fine with your latest image: no freezes, and H.264/H.265 videos played for 5 minutes without issues.

Quote from jernej

Please provide DT patch and I'll incorporate it into PR.

I also fixed deinterlacing, the only remaining issue I could find for H616. I'll push it later with your fix.

Thanks! Here is the patch. It's the same change I tested with a local build of the PR head: the unpatched build oopses or hangs within a minute, and with this patch it stays stable with schedutil (37664 frequency transitions).

Quote from jernej

I did quick check on x96-mate clone board and fixed some obvious issues. Now basic H616 support should work.

Please test:

Images: https://jernej.libreelec.tv/images/h616/

PR: https://github.com/LibreELEC/LibreELEC.tv/pull/11799

Thanks for the H616 work! I tested on an Orange Pi Zero3 (H618, 4 GiB, AXP313A). Display, HDMI audio and Panfrost work fine, but with cpufreq enabled the board is unstable:

• Your test image hangs within about a minute of boot: RCU stall with CPU3 not responding even to NMIs, i2c-0: mv64xxx: I2C bus locked (the AXP313A bus), and an Ethernet TX timeout just before.
• A local build of the PR head oopses 14 s into boot on CPU3, inside zstd decompression for squashfs, with obviously corrupted register values (e.g. lr : 0xebfa28af2645a26c), which looks like the CPU computing garbage rather than a software bug.

Booting with cpufreq.off=1 is stable, and so is pinning the CPU at its top OPP (1.416 GHz on this chip), so the problem is frequency switching rather than the OPP voltages.

The AXP313A regulator ops have no set_ramp_delay and the driver declares no ramp delay, so the regulator core assumes the new CPU voltage is reached instantly and raises the clock right away. Adding a ramp delay to the CPU rail in the Zero3 DT fixes it:

reg_dcdc2: dcdc2 {
        ...
        regulator-name = "vdd-cpu";
+       regulator-ramp-delay = <2500>;
};

With that, the same local build runs stable with the default schedutil governor: 37,664 frequency transitions without a single hang or oops. 2500 uV/us is the value the H6 boards use for their CPU rail.

I can share the patch and full UART logs if useful.

Thanks
Asai, Shigeaki

Quote from mjholtkamp

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.

This boot fail is known issue

Post

RE: Official LE13 Test Images for Amlogic (Kodi-22)

It looks like CONFIG_KASAN=y snuck into a kernel defconfig and this increases the KERNEL size to a point where standard vendor u-boot configurations (as used with Android STBs) will fail to load the kernel and fault. This is nothing to do with RAM size.

I have a large list of changes to work on and current progress is rather slow, so I will update images at some point soon, but to avoid breaking promises I'm not going to give a timeline on when.

chewitt

April 9, 2026 at 10:44 AM

Please wait to fix, or disable CONFIG_KASAN on your kernel config and build image.

Quote

Out of curiosity Yasai-san are you also having issues?

I don't use the Radxa Zero 3W now.
So I have no informarion for this issue sorry.

I've confirmed the issue with the odroid-xu4 boot failure.

It occurs starting with the following image:
- LibreELEC-Exynos.arm-13.0-nightly-20250730-ecfa284-odroid-xu4.img.gz

And it has been fixed in the following image:
- LibreELEC-Exynos.arm-13.0-nightly-20251223-941298b-odroid-xu4.img.gz

If my testing method is correct, both(boot fail and performance) problems appeared since v6.16.
- 81e3bc35c1e59d75693062b45b05adae32210fe5 is booted
- 821d827dba93b3ffe14ac40dfb7dbc33935b6eca is not booted

- 821d827dba93b3ffe14ac40dfb7dbc33935b6eca + 2 fix commits
(098bfdb6b51d06adf6285b63e21b71078ae1d497 + 0b4b7ecca0daabe90b39f7171c78c5a4840a41e1) is booted but wrong performance

This topic is talked for the boot fail issue.
I think performance issue will talk on new topic better.
(Similar performance issue is also happened on Lakka.)

Quote from axel

Yasai-san I've managed to build an image of LE13 for RK356X for my Radxa Zero 3 thanks to your work. Many thanks!

I rebased on master, and tried to bump the aic8800 driver from the radxa-pkg/aic8800 repo from 4.0~ to 5.0~, but it failed to build. ie:

Code

PKG_VERSION="5.0+git20260123.5f7be68d-4"
PKG_SHA256="58c4c1ee085fac7971e9972dba99c5e3207e1ea0991c3f957bd9200f6ec8fbe7"

Two questions:

• Did you pick 4.0+git20250410.b99ca8b6-5 specifically, or was it just the latest when worked on this?
• How did you figure out the right targets in projects/Rockchip/packages/aic8800/package.mk?
  • When trying to build 5.0+git20260123.5f7be68d-4 i had to comment out the pre_make_target for linux 6.12 as that build patch is missing and it then failed anyway with another error.

Hello axel

> Did you pick 4.0+git20250410.b99ca8b6-5 specifically, or was it just the latest when worked on this?
I used the latest version at that time.
This is reason.

> When trying to build 5.0+git20260123.5f7be68d-4 i had to comment out the pre_make_target for linux 6.12 as that build patch is missing and it then failed anyway with another error.
I also confirmed this build failure.
a) Radxa aic8800 repo removed linux 6.12 patch file by version up.
fix: update patchset · radxa-pkg/aic8800@89f865b
-> it needs to remove this patch apply from package.mk
b) (after a) compile error is shown about vfree
-> Radxa aic8800 repo has patch file for this compile error.
aic8800/debian/patches/fix-vmalloc-not-include.patch at main · radxa-pkg/aic8800
it needs to add this patch apply to package.mk

Please check my following commit

aic8800: bump version to 5.0+git20260123.5f7be68d-4 · ShigeakiAsai/LibreELEC.tv@2bb9159

github.com

(Sorry, this is compilation check only)

Note.
as you know, I do not actively support this.

Quote from chewitt

It looks like CONFIG_KASAN=y snuck into a kernel defconfig and this increases the KERNEL size to a point where standard vendor u-boot configurations (as used with Android STBs) will fail to load the kernel and fault. This is nothing to do with RAM size.

I have a large list of changes to work on and current progress is rather slow, so I will update images at some point soon, but to avoid breaking promises I'm not going to give a timeline on when.

Thank you very much for this information.
My bananapi-m5 was able to boot with "CONFIG_KASAN" kernelconfig disabled. (using attached patch)

I can't boot nightly LE13 build image (since 20260211-4871898) on my bananapi-m5.
I want to report about this.
May I create new thread? or keep to report here?

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 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.

RadxaNaoki
I found your latest rock5c update in mainline linux contribution.
Many thanks!

About HDMI audio, rock5a is also needed patch I think.
Could you please make it?

chewitt  RadxaNaoki
I was able to get HDMI audio on my rock5c with above RadxaNaoki's patch.
Many thanks!

But still logged "fde80000.hdmi: i2c read timed out" in journalctl log.
> LibreELEC kernel: dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out

rock5c's kodi also doesn't show rk3588-es8316 audio device after apply patch.
but "aplay -L" shows "rk3588es8316".
> LibreELEC:~ # aplay -L
> null
> Discard all samples (playback) or generate zero samples (capture)
> default:CARD=hdmi0
> hdmi0, fddf0000.i2s-i2s-hifi i2s-hifi-0
> Default Audio Device
> sysdefault:CARD=hdmi0
> hdmi0, fddf0000.i2s-i2s-hifi i2s-hifi-0
> Default Audio Device
> default:CARD=rk3588es8316
> rk3588-es8316, fe470000.i2s-ES8316 HiFi ES8316 HiFi-0
> Default Audio Device
> sysdefault:CARD=rk3588es8316
> rk3588-es8316, fe470000.i2s-ES8316 HiFi ES8316 HiFi-0
> Default Audio Device
> LibreELEC:~ #

Please let me know if "pastekodi" is needed.

chewitt
I tested your 20251107 image on my rock5a.
HDMI audio device was not shown.
Log hrer: https://paste.libreelec.tv/advanced-snake.log

BTW, I got HDMI audio device on my rock5a with attached DT patch.
rockchip-9999-add_enable_rock5a_hdmiaudio.patch.txt please remove ".txt" from file name
But this patch has a problem that lost rk3588-es8316 device \when patch is enabled.

And I couldn't confirm it on my rock 5c because my rock 5c has same problem with gnarlsnishi

Quote from leo kalmaev

hi, I tried your image for rock5b, it didn't load, there's only a black background on the screen.

My ROCK 5B was able to start LibreELEC with 20251021-3f3aa0f nightly image via mSD.
LibreELEC-RK3588.aarch64-13.0-nightly-20251021-3f3aa0f-rock-5b.img

My ROCK 5B has no eMMC and no nvme SSD.
Dose your ROCK 5B have eMMC or nvme SSD?