Posts by Yasai-san

Quote from chewitt

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.

GitHub - ShigeakiAsai/LibreELEC.tv at Add-Aicsemi-aic8800-WiFi-driver-and-firmware

Just enough OS for KODI. Contribute to ShigeakiAsai/LibreELEC.tv development by creating an account on GitHub.

github.com

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.

Quote from chewitt

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:

LtPurpie's comment on "Orange pi 3B won't boot"

Explore this conversation and more from the OrangePI community

www.reddit.com

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.

Quote from chewitt

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

Quote from Yasai-san

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)

Quote from Yasai-san

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.

Merge tag 'v2025.07-rc5' into next · u-boot/u-boot@184e7d0

Prepare v2025.07-rc5 With this merge, tighten up the LTO_FLAGS removal we added to not trigger on ARMv7 (which is Thumb-2 and should be fine).

github.com

This commit was merge commit, I will investigate more.

Quote from chewitt

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.

Quote from chewitt

Code

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

Quote from chewitt

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.

Quote from chewitt

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.

firmware/ap6275p at master · orangepi-xunlong/firmware

Orange Pi specific firmware. Contribute to orangepi-xunlong/firmware development by creating an account on GitHub.

github.com

the orangepi-xunlong github - firmware repo has ap6275p firmware files.
These may be able to use.

Note.
This device seems pcie device not sdio.

Quote from chewitt

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.

build/patch/kernel/archive/rockchip64-6.16/rk3588-1072-arm64-dts-rockchip-add-AP6275P-wifi-to-Orange-Pi-5B.patch at main · armbian/build

Armbian Linux build framework generates custom Debian or Ubuntu image for x86, aarch64, riscv64 & armhf - armbian/build

github.com

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.

Rockchip: add support for RK3588, RK3576, and RK356X devices by chewitt · Pull Request #10420 · LibreELEC/LibreELEC.tv

This supersedes #7864 which has been waiting for numerous upstream dependencies to reach mythical "minimum viable product" state for LibreELEC use.…

github.com

This is merged latest version(12c4579bd9)

Elicity

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

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

Quote

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

Display More

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.