jock

They can't, because some boards like the "old" nvram and some others want the newer

@stroma first page, one of the last paragraphs...

Too vague, please provide logs via serial adapter and photos of the board.

@SuperMaximus don't do full-upgrade until the driver is enabled in mainline armbian. I'm going to do merge the config bits right now, but I don't know when the next kernel update will be upstreamed to armbian repository. Could take days, or weeks. Perhaps @Igor may give a hint about. edit: yet consider that your board is not officially supported, because it is a Tinkerboard S R2.0; I'm not aware about the differences from the regular Tinkerboard S Rev 1.01. Support is best effort.

@Vittorio Mori Hardware video decoding is available since kernel 5.10 on armbian, thanks to libreelec patches, but the userland part is a bit worrysome. You can try with this, but it is a very old post and very old binaries that probably don't work on recent kernel because it is more than one year old. The problem is that ffmpeg never really stabilized the v4l2-request kernel api, thus you have to compile the libreelec patches version and then supply the static libraries to mpv to gain hardware video decoding via v4l2-request. I don't know if recent ffmpeg 6.0 release include working support for v4l2-request or there is the need to still use the libreelec patched version.

@SuperMaximus You have to wait a bit for the kernel config selection menu to appear, armbian has to patch the kernel and compile uboot first, then it will appear.

@SuperMaximus I attach the patch to the message, perhaps git does not like copy-paste from the forum due to space/tabs mismatch disable-vidconsole.patch edit: 8723ds is disabled in the current 6.1 kernel, perhaps it got disabled during the transition from 5.15. You can enable it by yourself choosing to show the kernel config initial compilation menus, and then finding the driver in the following tree: │ -> Device Drivers │ -> Network device support (NETDEVICES [=y]) │ -> Wireless LAN (WLAN [=y]) │ (1) -> Realtek 8723D SDIO or SPI WiFi (RTL8723DS [=n])

@SuperMaximus asus does not provide any specific info about the wifi chip, you don't provide logs nor details. It is very hard to do support this way and looks like a waste of time.

@SuperMaximus Well I just checked my Tinkerboard S which is rev. 1.01 and has a rtl8723bs wifi chipset that is working perfectly fine. Could you please verify your wifi chipset on your board?

@SuperMaximus A couple of questions: why do you say Tinkerboard S has no wlan0 in kernel 6.1? It was working last time I checked out (although with some incomprehensible performance drops) are you on legacy master branch or current main branch of armbian? also, whatever you have in your userpatches directory is only yours, since the directory is in armbian .gitignore and not committed into the repository 🤷‍♂️

@SuperMaximus Perhaps this is what you want: diff --git a/include/configs/tinker_rk3288.h b/include/configs/tinker_rk3288.h index bde7d72e6d..64c0781359 100644 --- a/include/configs/tinker_rk3288.h +++ b/include/configs/tinker_rk3288.h @@ -8,8 +8,8 @@ #define ROCKCHIP_DEVICE_SETTINGS \ "stdin=serial,usbkbd\0" \ - "stdout=serial,vidconsole\0" \ - "stderr=serial,vidconsole\0" + "stdout=serial\0" \ + "stderr=serial\0" #include <configs/rk3288_common.h>

Not a wise thing to do though

@SuperMaximus probably you can disable the vop nodes in the device tree and there will be no video output. Another way could be to disable the video output in the u-boot configuration/header files (ie: remove vidconsole)

@stroma Hello, thanks for the photos, they will be useful at least to have an idea of the issue. Anyway did you try the experimental image with kernel 5.19.15 and libreelec patches? They have several HDMI/DRM fixes, perhaps they fix your case. Since the LE patches are not mainlined into armbian, you should then not upgrade the kernel. I quickly looked back and @Seth described similar issues you have had with his two boards.

Hmmm that's odd, I applied the same "fix" @ilmich applied on libreelec but it didn't work. The serial log output could have been very handy here; we will think about what could be wrong and maybe some other idea may pop up.

@rafaeldavid I actually don't remember what exactly we discussed about the last time, but surely R29 boards have this long-time HDMI issue I could not inspect because have no such board and noone provided one to study. For the clock issue, I don't remember if I suggested you to use the cpu-stability (both with 1.2 or 1.4 ghz max frequency) overlay and see if it makes any difference. What I could guess about is that there are some board whose power regulation design in "slow" to bring up voltage in time for the frequency change, so random crashes happens. The overlay will raise the lowest voltage from 0.900v to 1.100v, so the gap with max voltage (1.35v) is shorter. I have a board with such kind of issue right here, and that overlay made it work flawlessy.

Perhaps @Seth can give some advice.

To debug the problem, it is better to paste the link coming from armbianmonitor -u ; also photos of the board are very useful to identify which board you have. Also this is the reference thread for rk3318 boxes

@ochentay4 I set up a multitool image with the same fix proposed by @ilmich on his libreelec image. This fresh build is totally untested, but you can download a copy from here and test by yourself. Perhaps this solves @n3o problem too.

@arcube101 Hi, this kind of problems usually is in the wifi firmware/nvram ballpark, except for on kind of software issue I experienced: check if wpasupplicant debian package is correctly installed in your system: that package was removed as a dependency from network manager in upstream packages, thus was not included anymore in the base armbian images. Installing it manually may solve the problem. Other than that, I have seen such kind of refusal when the crystal reference clock was set to a wrong frequency, but AFAIK on realtek chips you really can't se the reference frequency via driver option or nvram. Try the first suggestion and see if it works.

@moussa854 Hello, from the logs you posted it looks to me that the eth0 interface seems to be DOWN: ### ip addr: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet XXX.XXX.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 56:9e:45:d9:4d:b8 brd ff:ff:ff:ff:ff:ff

🥳🥳🥳

No, I mean the serial output logs. If you don't know what I'm talking about, read the rest of the thread or search with google.

Inference in which sense? An opencl load of some sort?