jock

@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

@im_chc those source code files are irrelevant for the boot issue: the rk322x has a SPI bus where the board maker can connect anything other than a flash memory. Those drivers handle the low level communications along that bus, but whatever is connected to that (a flash memory, a wifi devices, a led strip, a led panel driver, or whatever...). You need a loader (specifically, the miniloader), which is engaged before uboot and the kernel, which should support reading from the SPI to load u-boot. You also will need u-boot and kernel compiled to read and write to the SPI flash of course, but the first step is the miniloader.

@im_chc AFAIK the loader firmwares around do not support anything else than sdcard and emmc, but I may wrong: I have never seen a rk322x device with SPI flash memory, so I can't bet on my affirmation. Perhaps you should have a look to the rockchip repository on github or search around to see if there is a rk322x loader for SPI memories.

@ThaisTaki Hello! I did not remove any particular driver or feature from earlier versions. Perhaps you were using the older vendor kernel 4.4 in the previous installation? In such case, it is not supported anymore, so some device may have lose support. Also notice that, depending on your board (I can't read the signature/silkprint on that from the photo), you may have to run rk3318-config twice to enable the correct driver.

Hello! First of all, multitool creates a 1 to 1 image of the content of the eMMC; no bits are changed and nothing is rearranged in any way. What you get in the backup is the exact content of the eMMC, some of those partitions are raw partitions that does not contain a filesystem, but rather just raw data. For example the uboot and trust partitions normally contain binary data, so you won't be able to mount them in any way because they are not filesystems. You could inspect with a hex editor though.

@Ikesankom sorry, I misunderstood your issue, which is not related to the rest of the thread. It looks like the kernel does not enumerate the partitions of the USB drive, I just tested the bootloader which is not related at all with your issue. It is weird though, because I have an rk3288 tvbox which boots from an external hard drive with ext4 partitions without issues. Could you please post the results of the suggested commands cat /proc/modules and ls /dev/sd* ?

@astrosky @tERBO this may help you getting hardware decoded videos, but don't expect your browser work with them. Mixing hardware video decoding into browsers compositors is not an easy task.

@Ikesankom I did a quick test jiggling with bootloader to try and test multiple cases with both sdcard and emmc. I found a little "bug": there is no "alias" for the mmc devices in the device tree, so sometimes at boot the emmc is mmcblk0 and sdcard il mmcblk2, sometimes they get swapped. Anyway, despite this bug, the installer never broke the existing bootloader, at most it could miss the right device (I should check the logic behind, as it is not so easy guess what is the booting device) if you have both emmc and sdcard plugged. It's not a big deal though: the bootloader has got no real updates in a while since it works fine and the important thing is that the script does not destroy anymore the existing bootloader 😁 Anyway, if the board is remotely installed and controls something important, and you want extra-safety, you can do apt-mark hold linux-u-boot-tinkerboard-current and prevent bootloader upgrades

@Ikesankom hello, no I didn't test it yet. Actually, I have been busy with other issues and totally forgot to test for the upgrade path. If you have a bit of patience I may give it a shot in the next few days, probably tomorrow.

@A9 they are not errors, just missing firmware files for various wifi devices that you don't really need