The ROCK 4SE (MT53E512M32D4NQ) is dual-rank, 4Gb per channel. It boots without the patch, and also works fine with it.
Correction: on the ROCK 4SE (MT53E512M32D4NQ), rkbin reports MR8=0x10 and CS=1, so it is single-rank, 8Gb per channel (same as the 4C+). It boots without the patch, but 180ns is out of spec. With the patch it uses 280ns and boots fine.
I found why mainline U-Boot fails to boot on the ROCK 4C+ V1.41 (D2): the LPDDR4 tRFCab is too short (180ns). JEDEC requires 280ns for 8Gb-per-channel devices.
The fix does two things:
- Sets the initial tRFCab to 380ns.
- Reads the density from MR8 and selects the tRFCab according to JEDEC.
With this, LibreELEC/Kodi boots at 800MHz with mainline U-Boot (no rkbin).
Branch: ShigeakiAsai/LibreELEC.tv at rk3399-lpddr4-fix-trfc-from-mr8
Patch: LibreELEC.tv/projects/Rockchip/devices/RK3399/patches/u-boot/0001-ram-rk3399-select-LPDDR4-tRFC-from-MR8.patch at rk3399-lpddr4-fix-trfc-from-mr8 · ShigeakiAsai/LibreELEC.tv
It is based on an older master, because current master cannot build RK3399 until #11904 is merged.
Requests:
- I don’t have a D1 version of the ROCK 4C+.
It would be great if someone could test it.
- The ROCK 4SE may have the same issue.
I have ordered one and will test it.
I will open a PR after #11904 is merged, and I also plan to send the patch to U-Boot upstream.
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.
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).
I did quick check on x96-mate clone board and fixed some obvious issues. Now basic H616 support should work.
Please test:
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:
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
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
Please wait to fix, or disable CONFIG_KASAN on your kernel config and build image.
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.)
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:
CodePKG_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
(Sorry, this is compilation check only)
Note.
as you know, I do not actively support this.
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?
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.
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.
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.
