awawa

@jernej I've included needed changes to Tanix DTS (5.15.24). I tried to run your python script unfortunately without a success. Am I missing something? Logs attached.
logs.txt

Had better luck using OpenVfd. The watch is working. But currently really have no idea how to include it in the build scripts.

You don't need to wait so long, just pick mentioned DT lines.

@danboid I like @jernej solution so I think we will wait until 5.17 and not use openvfd. There are already struggles with ofenvfd in the rk3318 / 3328 thread and it is not so easy to make it work properly and to include in my build. But @danboid there is a task for you if you want Recent changes brought: legacy(5.10 without further support), current(5.15) and new edge version (5.16). Can you build & test 5.16? I tested it, but only to make sure it boots up and there are no errors in dmesg.  I've included H6 4K60 patch  from LibreElec for edge (5.16). If it works I include it to current. Also RTL8822CS driver is included now in default builds.

@danboidif you prefer, we can continue our discussion here.
 
Note, mesa has nothing to do with HDMI plug detection. GPU is distinct core from display engine (that's why you have two dri cards present). I would say it's X11 issue, but then, I have no experience with it on H6.
 
Regarding LED driver - you might make it work with above repo, but then there is easier way, at least if you have some python programming knowledge. I recently added a node for LED display in DT and it will debut with kernel 5.17:
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix.dtsi#L32-L38
 
Once you have that in DT, together with enabled i2c-gpio and i2c-dev drivers, you can play with LED display as much as you want. For example, with python script using python-periphery library:
 
from periphery import I2C i2c = I2C("/dev/i2c-0") # adjust path as needed msgs = [I2C.Message([0x03], flags=I2C._I2C_M_IGNORE_NAK)] i2c.transfer(0x24, msgs) # enable display msgs = [I2C.Message([0xff, 0x67, 0x63, 0x63, 0x47], flags=I2C._I2C_M_IGNORE_NAK)] i2c.transfer(0x33, msgs) # set LEDs i2c.close()  
Note, that ignore NAK flag is important. FD650 LED driver is not exactly your standard I2C device.

Thanks awawa!
 
I have installed the latest build on my T95 MAX and the cedrus stuff actually does seem happier with the v4l2-request patched ffmpeg now but I haven't worked out the correct ffmpeg or ffplay command to get them to display the video so not much use as is. mpv is the same as with the previous kernel. - software decoding only.

New build has just released and images are uploading. I've included now almost all new Kernel patches from official Armbian (a lot of changes for cedrus, sound mixer and media components): only these related to DTB/DTS and causing TX6 instability are excluded but they are not related to your subject. So @danboid in my opinion you can treat it almost as generic Armbian release in your straggling with accelerated ffmpeg. Can't help much more than that. Previous releases were primary targeting vanilla mainline Kernel using just few old balbes150 patches till I figured out where are the problems with current Armbian patches. Now I know why support for that board will probably never reach even Armbian's CSC level. I don't have a plan for sid release.

I think that's the last build for Tanix TX6 H6 till next major Kernel upgrade appears as everything seems OK now.
https://github.com/awawa-dev/build/releases/tag/v2022.02.14

On my Tanix TX6 temperatures in idle are around 60C using 5.15. With moderate load while capturing&processing 1280x720x60fps video stream from USB3.0 grabber in HyperHDR it's around 80C and rarely hit 85C for a moment (throttling point which reduces CPU frequency, without it the stories are telling and the chip can go up to 120C). On 5.10 handling USB3.0 took more CPU resources. Unfortunately using official Armbian patches for 5.15 causing my device not to boot: heavily modified DTS is broken and that also affects LibreElec releases. I've not installed the system on eMMC because with TV boxes I've always preferred safer approach with SD cards.

@danboid I've got something even better Support for 5.15 kernels, with kernel sources and headers packages this time.
 
There is a nasty bug (or let's rather say: something incompatible with TX6) introduced with the mainstream kernel 5.15 sunxi that completely breaks eMMC, introduces I/O instability and causes high CPU usage as sideeffect: FIXED.

Release (Tanix TX6, Allwinner H6, AC200/XR819 network cards):
https://github.com/awawa-dev/build/releases/tag/v2022.02.12

After the non-working DTS patch for Tanix TX6 XRadio XR819 was recently finally removed from balbes150 git repo and there is no outlook to bring back support for working TX6's wifi, I decided to create an alternative CLI release for my TX6 server with a priority for XR819 & AC200 network cards.
 
After many, many tries with the official Armbian repository  I gave up on them: apparently they are missing some magic from balbes150's versions So I had to back in time in armbian-tv repo, merge some new stuff like latest kernel 5.10.*, remove some patches (including some custom cedrus patches, don't need them for CLI but they can be included back after the revision) that had conflicts with newer kernel, provide new patches and some improvement for kernel configuration, DTB wifi section and for XR819. None of XRadio XR819 drivers without the patch is compatible with current AArch64 crosscompiling and probably that's why it was removed even from the latest official Armbian AArch64 releases.
 
Works stable with fast SD card access and CPU governor: I tried also 5.15 and 5.16 kernels using mainstream Armbian versions but there are some problems with slower SD access (initial partition resizing took x5 longer than usually) and/or with the CPU governor (CPU was staying at 1.7GHz all the time). I have not observed it using 5.10.99 Bullseye CLI build based on armbian-tv. Will try to provide fully working 5.15 if possible. I'm thinking also about CPU downclocking because that box is really hot on default settings. Feel free to improve it further. Sources are available of course.
 
Tested configuration: current (5.10.99), Debian Bullseye, server. Enjoy!
https://github.com/awawa-dev/build/releases/tag/v2022.02.10

After the non-working DTS patch for Tanix TX6 XRadio XR819 was recently finally removed from balbes150 git repo and there is no outlook to bring back support for working TX6's wifi, I decided to create an alternative CLI release for my TX6 server with a priority for XR819 & AC200 network cards.
 
After many, many tries with the official Armbian repository  I gave up on them: apparently they are missing some magic from balbes150's versions So I had to back in time in armbian-tv repo, merge some new stuff like latest kernel 5.10.*, remove some patches (including some custom cedrus patches, don't need them for CLI but they can be included back after the revision) that had conflicts with newer kernel, provide new patches and some improvement for kernel configuration, DTB wifi section and for XR819. None of XRadio XR819 drivers without the patch is compatible with current AArch64 crosscompiling and probably that's why it was removed even from the latest official Armbian AArch64 releases.
 
Works stable with fast SD card access and CPU governor: I tried also 5.15 and 5.16 kernels using mainstream Armbian versions but there are some problems with slower SD access (initial partition resizing took x5 longer than usually) and/or with the CPU governor (CPU was staying at 1.7GHz all the time). I have not observed it using 5.10.99 Bullseye CLI build based on armbian-tv. Will try to provide fully working 5.15 if possible. I'm thinking also about CPU downclocking because that box is really hot on default settings. Feel free to improve it further. Sources are available of course.
 
Tested configuration: current (5.10.99), Debian Bullseye, server. Enjoy!
https://github.com/awawa-dev/build/releases/tag/v2022.02.10

@awawa @markst I updated the images and deb packages with latest kernel compilation (5.15.23) and with bcm43342 patch in.
Obviously I can't test it, but if you have the chance to give it a shot and give a fallback it will be appreciated

Yes, it would be great  Of course you can link the tutorial.
Following your advice, I was probably able to locate this bluetooth file (Attached, can't test it because I'm fighting with Tanix TX6 right now ...really bad experience compared to support for rk3318).
You can find binary wifi drivers in my article.
I attach also source of patch that is necessary for the kernel (kernel\drivers\net\wireless\broadcom\brcm80211\brcmfmac\). I tried to keep it as simply as possible avoiding inserting defines in other files.
BCM43342.hcd sdio.c.patch

Multitool update!
 
Hello! I'm pleased to announce that multitool finally got network and SSH access, and now can be used on headless systems!
 
The latest release will retrieve an IP from the network DHCP server automatically, so you can consult your local network router to discover what IP the box got.
SSH access can be obtained logging in as root user; no password is requested.
Example with IP 192.168.1.18:
paolo@predatorg:~$ ssh root@192.168.1.18 Welcome to Multitool SSH session! root@multitool:~#  
 
Link-local access:
 
Multitool will also, by default, listen to link-local 169.254.120.120/16 address. This is useful if you have no DHCP server or have troubles retrieving the IP address.
Note that to access such private IP you need to set a network interface of your PC on the same subnet, or also use a virtual interface.
 
Here there is an example using ip assigning address 169.254.89.32/16 to virtual interface eth0:1 (address can be changed at your pleasure, interface must be the same interface you use to access the box, ie: wlan0, enp0s25, or whatever):
ip addr add 169.254.89.32/16 brd + dev eth0 label eth0:1  
or if you prefer old but good ifconfig:
ifconfig eth0:1 169.254.89.32/16  
then the multitool is accessible to 169.254.120.120:
paolo@predatorg:~$ ssh root@169.254.120.120 Welcome to Multitool SSH session! root@multitool:~#  
Of course link-local access won't work if you have multiple devices running multitool on the same network, since all of them will conflict because they have the same IP; in such case use the IP provided by DHCP.