Thank you very much good information
I will try "git bisect"and I wiil report.
progress:
I was able to get the commit for this RK3588 boot failure with "git bisect" maybe , many thanks.
This commit was merge commit, I will investigate more.
RK3588 boards should be usable without the additional patches that LE is using (which are mostly for 3576 support) so clone u-boot sources and start a git bisect to track success/failure, but use the githashes (and no patches) in the LE buildsystem. No matter how large the number of commits difference between the start points is, bisect will find the breaking commit within 8-10 moves, and if the rest of the LE image is static this is probably no more than an hour of effort. NB: I normally edit scripts/uboot_helper so I don't waste time building images for hardware that I won't be testing with.
Thank you very much good information
I will try "git bisect" and I wiil report.
CodeU-Boot SPL board init U-Boot SPL 2017.09-orangepi (Aug 30 2024 - 22:09:16)Yasai-san all three boards are trying to boot a prehistoric vendor u-boot, e.g. ^
I'd guess they have it installed to SPI flash, so erase that and the boards should find upstream u-boot on the SD card and boot.
I got to know the RK3588 device boot failed reason a little.
In past chewitt development version, these devices were booted.
I temporary changed(reverted) u-boot version from 2025.10-rc3 to 2025.07, it is worked again.
This boot fail happenes from u-boot 2025.10-rc1 after.
I can't find yet which commit affects it because v2025.10-rc1 has 1025 commits from 2025.07.
BTW the u-boot has new tag 2025.10-rc4 already.
But I didn't try to shift yet sorry.
Yasai-san please see https://github.com/LibreELEC/LibreELEC.tv/pull/10495 which the patch descriptions show also touches on some RK3588 boards. I pushed updated images to my share about 30 mins ago.
Thanks pushed.
But, these images were same result.
I'd wait nightly image coming and test them.
chewitt
Could you please test the latest image on your RK3588 device?
RK3588S devices were able to boot on the latest image. (NanoPi R6C, NanoPi R6S, OrangePi 5, ROCK 5A, ROCK 5C)
But, RK3588 devices weren't able to boot. (ArmSom Sige7, OrangePi 5 Max, OrangePi 5 Plus)
In my RK3588 cases, it restarts on u-boot phase (OrangePi 5 Max, OrangePi 5 Plus) or it stops on u-boot phase (ArmSom Sige7).
I don't know what the cause is because I don't understand it well enough.
NB:
OrangePi 5 Max device with OrangePi 5 image was able to boot.
OrangePi 5 device with OrangePi 5 Max image wasn't able to boot.
- it restarts on u-boot phase.
So both image may had something difference or not.
treedav I've picked the Armbian patch that Yasai-san flagged, and pushed an updated image to my test share. On reboot the card should now be detected, but firmware will be missing. Check the system log for errors and filenames.
See https://wiki.libreelec.tv/how-to/add-firmware for instructions on manually adding firmware. This repo has firmware files with a blind guess at the needed filenames: https://github.com/chewitt/brcmfm…re/tree/ap6275p
https://forum.armbian.com/topic/36744-or…dComment-214649 suggests this might not be enough, but best to try. If it does work I can send the patch upstream and add the firmware to our collection. Please share the journal log, e.g. journalctl | paste and share the URL.
the orangepi-xunlong github - firmware repo has ap6275p firmware files.
These may be able to use.
Note.
This device seems pcie device not sdio.
Run "journalctl | paste" after boot and share the URL generated so we can see which device-tree is being used, and assuming it's one where WiFi/BT are described, what chipset is being used and what firmware might be needed.
Latest orange pi 5b device tree had no wifi/BT description. (linux v6.17-rc4)
https://github.com/torvalds/linux…orangepi-5b.dts (add)
https://github.com/torvalds/linux…orangepi-5.dtsi (add)
By Orange Pi 5B User Manual, it has AP6275P device.
> WIFI+BT Onboard WI-FI6+BT 5.0 module (AP6275P), supports BLE
Armbian has patch file for orange pi 5b wifi. I can't find about BT patch.
Sorry I have no orange pi 5b. (I have orange pi 5 and orange pi 5 Max)
Just information.
ASUS tinker board S R2.0 (RK3228) is working good.
image: LibreELEC-RK3288.arm-12.90.1-tinker.img.gz
HDMI display(FullHD)/audio OK, KODI is shown, H264/H265 video is played.
I use the following sample video.
https://kodi.wiki/view/Samples - 4K (UltraHD) & HDR Formats -
7. HDR 10-bit HEVC 59.94fps (MP4, Camp by Sony)
Note.
I will test with ROC-RK3328-CC when it arrived on middle Sep.
Elicity
> Is it this one: https://lkml.org/lkml/2025/8/7/872 ?
> Patch: https://lkml.org/lkml/diff/2025/8/7/872/1
Yes!
I did confirm this patch locally, HDMI audio is working on my R6C/S.
And this is known chewitt.
This is merged latest version(12c4579bd9) 
> Works fine on the NanoPi-R6C except for audio ( no audio device detected )
NanoPi-R6C/R6S HDMI audio will be added in near future.
Update patch file is exist.
> only 4GB of the 8GB memory is recognized
This is suppressed boot parameter of /extlinux/extlinux.conf in now.
By previous versions readme.md (projects/Rockchip/devices/RK356X/README.md),
* ram is limited to ~4gb with `mem=3838M` (memory range `0x00200000` - `0xefffffff`)
- there is an issue with importing decoded video frames into display stack
- old work-in-progress patches broke display stack for older socsRK3588 and RK3576 are same as RK356X
I don't know this has been updated or not, sorry.
On Radxa ROCK 5C (RK3588S) - Not ROCK 5C Lite (RK3582)
Display is shown with 1027 x 768 size on Full HD display.
Splash logo screen and kodi both are shown this size.
By dmesg, "i2c read error" and "i2c read timed out" are several times logged.
grep -i i2c /storage/logfiles/rock5c-dmesg.log
[ 0.066093] /i2c@fec90000/audio-codec@11: Fixed dependency cycle(s) with /i2s@fe470000
[ 0.184302] dwhdmiqp-rockchip fde80000.hdmi: registered DesignWare HDMI QP I2C bus driver
[ 0.185054] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
[ 0.185855] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
[ 0.186658] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
[ 0.187448] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
[ 0.188237] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
[ 0.189026] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
[ 0.266051] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
[ 0.266978] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
[ 0.286834] i2c_dev: i2c /dev entries driver
[ 0.289605] /i2s@fe470000: Fixed dependency cycle(s) with /i2c@fec90000/audio-codec@11
[ 0.289636] /i2c@fec90000/audio-codec@11: Fixed dependency cycle(s) with /i2s@fe470000
[ 0.372812] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 0.476079] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 0.582648] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 0.685980] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 0.789433] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 0.892825] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 0.996105] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 1.099448] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 1.202722] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 1.309330] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 1.415990] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 1.519314] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 1.622666] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 1.729329] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 1.836082] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 1.942703] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 2.046023] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 2.152662] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 2.262691] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 2.365989] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 2.469350] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 2.572776] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 2.676065] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 2.779393] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 2.882669] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 2.986100] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 3.089376] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 3.192722] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 3.296060] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 7.199448] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 7.302789] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 7.406110] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 7.509439] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 7.612777] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 7.716098] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 7.819383] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 7.922773] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 8.026106] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 8.129383] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 8.232773] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 8.336058] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 8.439381] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 8.542771] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 8.646121] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 8.749435] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 8.852715] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 8.956097] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 9.059436] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
[ 9.162774] dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
I'm sorry just report only.
I can't find any good information for this.
By mainline linux device tree, Orange Pi 3B has 2 HW revisions V1.1 and V2.1.
I met the ethernet problem on my V2.1 revision device when V1.1 dtb file was used.
But, it was able to use the ethernet when V2.1 dtb file is used.
Please check your HW revision and your dtb file I hope.
HW revision is printed in board.
If you want to boot LE with microSD on Banana Pi M5/M2Pro,
please read the following BPI wiki before do it.
Erase EMMC for SDcard Bootup
If Android is remained in eMMC, LE with microSD is not able to boot.
Like I was
I confirmed the PR#10024-LE13/PR#10025-LE12 on Odroid XU4 night build.
Both have no panic(?) log. It seems to good.
LE13 image : LibreELEC-Exynos.arm-13.0-nightly-20250502-098deba-odroid-xu4.img.gz
This is PR#10024-LE13 boot log.LE13-disable-CONFIG_PROVE_LOCKING-bootlog-XU4.log
This is PR#10024-LE13 all log.LE13-disable-CONFIG_PROVE_LOCKING-log-2025-05-02-11.18.14.zip
LE12 image : LibreELEC-Exynos.arm-12.0-nightly-20250501-8fe8900-odroid-xu4.img.gz
This is PR#10025-LE12 boot log.LE12-disable-CONFIG_PROVE_LOCKING-bootlog-XU4.log
This is PR#10025-LE12 all log.LE12-disable-CONFIG_PROVE_LOCKING-log-2025-05-02-11.06.47.zip
Thanks!
ASAI, Shigeaki
I will confirm your #10024-LE13 / #10025-LE12 on next nightly build.
Many thanks!
panic was not shown in boot log when # CONFIG_PROVE_LOCKING is not set on LE12.
It seems to fix.
Coule you please check my test result?
my modification is not-set-CONFIG_PROVE_LOCKING-in-kernelconfig.txt
bootlog is LE12-bootlog-(not-set-CONFIG_PROVE_LOCKING).log
all log is LE12(not-set-CONFIG_PROVE_LOCKING)log-2025-05-01-09.02.46.zip
P.S.
Lakka-v6.x is same, there was no panic.
I also confirmed the fix boot fail problem on Odroid XU4 LE12 night build.
- LibreELEC-Exynos.arm-12.0-nightly-20250501-18f208b-odroid-xu4.img.gz
This is boot log.LE12-fixed-bootlog-XU4.log
This is all log.LE12-log-2025-05-01-05.55.20.zip
LE12 boot log has something panic information.
But this is another problem and LE13 has no panic info.
So, I change this post to "resolve".
Thanks a lot!
ASAI, Shigeaki