jock

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

@lucky62 looking with elixir, it turns out that the function was already deprecated in 6.6: https://elixir.bootlin.com/linux/v6.6.27/source/drivers/gpio/gpiolib.c#L1022 You could copy the body of the deprecated function in place of gpiochip_find About of_get_named_gpio_flags you should see if you can afford to use the suggested function

@PLaume Hello! Well, a power loss is a power loss... you won't know what will be gone when the cache is not flushed. I read from the eMCP the code "JY941" or "JY94I", but according to micron part decoder (https://www.micron.com/sales-support/design-tools/fbga-parts-decoder), that chip does not exist. Perhaps it is a fake chinese chip with "micron" printed on it with unknown reliability? About the errors, the hdmi "error" is rather an information and does not affect any feature. The ssv6200 error instead says that the wifi chip does not work because the driver only support ssv6051p chip and not the ssv6256p your board has.

@astrosky I can't recommend you an image you can just install and everything works... tvboxes have this little problem about the changing hardware and that's not so easy. I have repeated dozen of times that tvboxes are not the way to go, buy an SBC if you need reliability. About 6.6.25 kernel, now I understand that you repeated the procedure starting from 6.6.23 image and this time the board rebooted fine but still without HDMI, am I right?

@astrosky mmmh, pretty weird that it broke your setup, it is a quite standard 6.6 kernel, also it does not touch the bootloader. Did you perhaps alter a device tree and changed it in /boot/armbianEnv.txt? because the /boot/dtb directory is replaced when the new dtb package gets installed.

@Hqnicolas thanks for the instructions, but I already have a backup of my box I had taken with multitool. The problem that is puzzling me is why the box does not boot from sdcard when the emmc is empty, something which is absolutely normal for other rockchip devices.

i have one of those boards, the silkprint on the PCB says RK3528_DDR3, that's the one I used to bring up the mutltool for rk3528. A major "problem" I have it is that the board does not boot from sdcard when the eMMC is blanked. I had no time to understand what is the reason behind. Though it should boot when a bootloader is available in eMMC.

Hello, for anyone who is having difficulties with HDMI, I made an experimental 6.6.25 kernel with a very small number of patches from LibreELEC project available here. I can't test by myself because the rk3318 board I have was already working with my monitor, yet the patched kernel did no harm on my setup. If there are some successful reports, the patches will be merged into armbian and hopefully the HDMI issues will be fixed once and for all. Thanks!