jock

You have to put the file in /lib/firmware/brcm directory, then reboot and see if it works

First of all, probably you're talking about the stock Android: you're in the wrong place. We don't discuss here about Android at all, we discuss about Armbian here. About the technicals, even the cheapest rockchip soc around (rk322x) is capable of driving 4k HDMI panels (but only up to 30fps) and decode 4K H.265 content (only up to 25fps AFAIR), but they are pushed to their limits. More newer and powerful socs (rk3328, rk3399, rk3528 and rk3566/68/88) should be capable of handle 60fps 4k HDMI panels and decoding 50/60fps content, but then come the optimization issues. Chinese manufacturers advertise what the soc is capable of, but the amount of data involved in 4k 60fps content to be decoded and displayed is huge and if pipeline is not perfectly optimized, you get stuttering and bad performance. Chinese manufacturers don't care at all about optimizations, because optimizing software is a lengthy process and thus costs a lot and they want profit, not costs.

Put an armbian image on a sdcard and boot from there

It's a linux shell command

Hmmm, what you describe seems a regression from latest u-boot upgrade to v2024.01, even though I did not notice any issue like that before; anyway you can easily trigger the boot from sdcard removing the bootloader from the emmc with dd if=/dev/zero of=/dev/mmcblk2 bs=32k seek=1 count=40 Once you do that, the board will boot multitool from sdcard

Nand options were not removed at all from latest multitool. Those options are just hidden if the NAND is not detected. You should check lsblk and dmesg to see if rknand device appears and maybe post dmesg log here too.

It should autodetect the device if it is properly working and enable the dtb overlay in /boot/armbianEnv.txt automatically; you should not need to select anything. You mileage may vary, though.

Thanks for your experience, did you try to run rk322x-config again and let it enable the proper overlay? realtek bluetooth is a bit quirky, especially on newer kernels

@helix ff510000.mmc is disabled in led-conf3 because led-conf3 is for MXQ-RK3328-D4 board, which accidentally has rk805 PMIC and fixes something. But clearly led-conf3 is not tailored for your board, hence not all the hardware works.

@helix afaik, no tool for that. phandles are the way how kernel navigates the device tree. BTW, you may wish to try to enable box-wlan-ap6330 or box-wlan-ap6334 device tree overlay in /boot/armbianEnv.txt and see if you advance in getting bluetooth: broadcom chips have the need for some bits in the device tree to load the driver and attach the communication "bus" (which is usually a simple UART port). Also they are very similar chips. the driver is usually capable of handling the detection of features despite you declare a different chip in device tree. You can see the source of the ap6330 overlay here And yes, you definitely need to enable the led-conf3 because the dtb declares that your board definitely has a rk805 PMIC: that's why the photo of the board is heavily suggested in the first page to get help.

Most of the patches are in the kernel mailing lists. ffmpeg patches have been taken from mainline LibreELEC project.

You should first try to disable xfce compositing, which is very taxing and pretty useless. Without composition, videos should be much smoother, but take note that rk3228 is very limited in terms of resources so windowed playback is acceptable perhaps up to 1080p25/1080p30, anything above won't work well and even 1080p may have some smoothness issues. 8bit/10bit should not matter though.

@helix hello, those "errors" are actually ok for brcmfmac driver. The clm blob is not always necessary and not available for some chips, the .bin file error is an attempt to look for a nvram file, but the driver will later look for other alternative nvram files and does not tell you that finally has found one.

Tested Debian Bookworm on Radxa Rockpi-E - RK3328: Systems boots HDMI N/A eMMC N/A sdcard ok USB 3.0 ok Gigabit Ethernet ok, throughput ok (> 900mbps) Fast Ethernet ok, throughput ok (> 90mbps) Wireless ok (rtl8821), throughtput satisfying but not at best (~30 mbps on 2.4ghz 802.11n network) Bluetooth untested Analog audio codec ok dmesg is clean

Tested Noble XFCE on ASUS Tinkerboard S - RK3288: System boots HDMI ok eMMC ok sdcard ok USB2.0 ok Ethernet ok, throughput ok (> 900mbps) Wireless ok (rtl8723bs), throughput ok (~70 mbps on 2.4ghz 802.11n network) Bluetooth ok, streamed same music from same smartphone as opi4 lts; some occasional hiccups but link is stable Analog audio codec ok dmesg is lamenting: ff540000.usb device "Waiting for Host Mode timed out", USB 2.0 host ports yet works fine ff580000.usb softreset failed, but USB OTG port is occupied by PSU SPI device is not found (there is no SPI device on my tinkerboard) mmc1 (wifi) incurs in an issue on first initialization, but succeeds on next attempt and wifi/bt seems to work pretty fine

Tested Noble XFCE on Orange Pi 4 LTS - RK3399: System boots HDMI ok eMMC ok Sdcard ok USB 2.0 and USB 3.0 ok Ethernet ok, throughtput ok (> 900mbps) Wireless ok, throughput ok (~80 mbps on 2.4ghz 802.11n network) Bluetooth ok, streamed some music from smartphone Analog Audio codec is fine dmesg is clean with no particular errors

Definitely, if you look at the kernel source code you can enable the codec Yes, it is. I think it is in the kernel mailing list, so it is something that is already floating around and eventually will be merged.

🤷‍♂️ perhaps; the branch is at an old period in time and has not been updated anymore, so anything could be...

Hello @primoitt , yes it has been deprecated. It wasn't developer anymore, now has been fully removed. You can find the latest iteration with the legacy kernel for rk322x family on this branch. After that, rk322x and rockchip familes have been merged and legacy kernels removed because old and unmaintained. The main reason to keep legacy was raw NAND support, but we at last we decided it does not worth the effort to keep it.

i perfectly understand, I also hate when an available piece of hardware cannot be used, but really lost a lot of time in wifi drivers and, especially realtek drivers, need constant care because they are overbloated software written by simians. When complied, any realtek driver is few megabytes large, while the average wifi driver is well below the 100kbytes. The device id you see in rk322x-config 024c:8723 is clearly declares that your chip is rtl8723as (for some other references: https://forum.libreelec.tv/thread/27091-no-wifi-at-mxq-pro-4k-5g/)

Hello! The problem is the missing driver for the rtl8723as. Actually, there is a driver floating around, but adapting and keeping it working on every kernel release require a lot of effort. I don't even have a board with such chip, so it is indeed very difficult, but it may become unworthy of the time spent because realtek drivers are very messy. You could find the source code and compile it yourself, or perhaps desoldering the wifi module and change the chip with another one is easier! It would be even easier to attach an USB wifi device. BTW, in the forum thread there is a success story with rlt8723as driver, you may want to search with forum tools or google.

Not really needed to do that for wear prevention: armbian is already optimized to write logs in a zram device (so they are kept in ram and compressed on the fly) and also swap space is by default a zswap device. Don't know, it could be possible if some pins are directly connected to gpios, but for what I know they are connected to another led driver chip which is surely missing on your board, so the answer is probably no. I tried msd on the usb2 port for both rk3318 and rk322x socs and it kinda works. The rockchip implementation of the dwc2 IP (the silicon behind the USB2 port) seems to be a bit buggy and the dwc2 driver also seems to be a bit buggy, so the whole thing is a bit buggy. Nonetheless it worked on my side, but had to make some patches for the kernel (see this) that you don't really need if you're running kernel >= 6.8 but definitely if < 6.8. As a note, audio gadget was totally out of reach. Did not try having two or more USB gagdets at the same time. From the uboot dwc2 driver I'm inspecting, I see #define MAX_ENDPOINT 16, but take it with a grain of salt. USB3 port seems to work a bit better. edit: dmesg tells that the 3318/3328 has 10 EPs, so I guess it is an accurate number

@McTurbo OrangPi official images use the vendor kernel 5.10 with various custom patches and drivers. Armbian does not offer vendor kernel anymore because after a while they become old and unmaintained.

AFAIK, to get fully working 4:4:4 modes, there is the need to import some "experimental" patches that are floating in the rockchip kernel mailing list. The patches have been tested a lot by libreelec users on various rockchip platform (32 bit rockchip device like rk322x and rk3288 already have them merge in), but have been judged "too complicated to maintain" for rockchip64 repository. You can see the last attempt here and the previous attempt here, useful to get the points of the discussion.

rkvdec does not technically "override" hantro h.264: hantro and rkvdec are two totally different devices and both are exposed by v4l2 framework to userspace. It's up to the user application to choose the preferred device. Ffmpeg, which is perhaps the most common user application around, has no way to choose the v4l2 device for h.264. The workaround to force ffmpeg to use rkvdec (yes, because it is more performant) was to avoid declaring hantro as capable of h.264, sto the only left h.264 decoder is rkvdec. edit: and yes, rkvdec is in the kernel staging directory, plus armbian has a patch to enable h.265 decoding too