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.
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
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?
The initial dev samples of the Zero3W had a Broadcom WiFi5 chip. The release versions were 'upgraded' to WiFi6 with an AIC8800 chip that has no drivers in the upstream kernel, which is probably why the WiFi/BT nodes required to use a driver that doesn't exist have not been added to the device-tree file.
Radxa have an AIC8800 driver in their repo: https://github.com/radxa-pkg/aic8800 but LE has no interest to add downstream vendor drivers to codebase unless there is a visible/known plan to upstream them (so we can drop them once upstream).
I made the aic8800 driver and firmware package using Radxa driver repo for my Radxa ZERO 3W confirmation.
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.
OrangePi 3B is booting vendor u-boot (2017.09-orangepi) so you need to erase that from SPI or wherever it's been stored.
OrangePi 3B was booted after erase SPI thanks!
I used this method for erase SPI:
My Rock3C boot failure was incompatible case trouble, not HDMI cable.
Currently my Rock3C without case is working correctly.
I'm sorry my bad environment.
Yasai-san Focus on reporting non-working devices (working ones are not interesting). Provide UART log output because it shows where the problem is. Your list is confusing because it shows Odroid-M1 in both working and not-tested. It shows Quartz64-A in both working and non-working.
NB: Rock3C, Rock4D, Rock5B are all working fine (tested by me).
Thank you comment. I fixed/edit mis-writing in my post.I will get UART log that is not working later. Attached boot UART log files.
My Rock3C is able to start kernel, but it stops before partition resizing.
When this time, HDMI cable Insert/remove start again.
This is not the case with other RK356X devices.
I'll try using a different HDMI cable just to be sure.(I will buy new HDMI cable later.)
chewitt u-boot v2025.10-rc4 version quick boot test result.
[[RK356X]]
Working:
- NanoPi R5C
- NanoPi R5S
- ODROID-M1(with SPI recovery SW on)
- Quartz64-A
- radxa zero 3e
- radxa zero 3w (but no wifi - driver is not included)
- radxa ROCK 3A
- radxa ROCK 3B
NOT working:
- OrangePi 3B(HW v2.1: not boot, OrangePi splash is shown)
- Quartz64-B (show black screen, I dont know linux started or not)
- radxa ROCK 3C (show black screen, but linux might be started)
NOT test
- ODROID-M1S (I have no this device)
[[RK3576]]
NOT test
- ROC-RK3576-PC (I have no this device)
- radxa ROCK 4D (I have no this device)
[[RK3588]]
will report
progress:
I was able to get the commit for this RK3588 boot failure with "git bisect" maybe , many thanks.
https://github.com/u-boot/u-boot/…6149ce96a4d1037
This commit was merge commit, I will investigate more.
I was able to boot on my Orange Pi 5 Max with the u-boot v2025.10-rc1 that there were needed 8 commits revert.
But, I feel something strange. I'll take a short break. (I'll try chewitt u-boot 2025.10-rc4 version)
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.
