danboid

Under Ubuntu when you install using BTRFS and Debian when you install to BTRFS using the Calamares live GUI installer, both installers create a subvolume called @home for the /home directory and another subvol called @ for the rest of the filesystem. This layout enables users to use timeshift to easily (and automatically with timeshift-autosnap-apt) create BTRFS snapshots and restore them using the command line or the timeshift GUI and restore their OS whilst optionally keeping users files stored under /home intact.
 
I would like to see the armbian installation script configure BTRFS in this same manner.

I'm going to have to try installing to the eMMC. I have noticed it offers about twice the read speed of using the SD card slot according to hdparm. I have got this working with Manjaro on my X96 Air amlogic TV box, eMMC boot. Good to hear it works and thats cool that you can even do it over the web in you're brave enough!
 
Back to my H10-play. I tried Android again and all 4 USB ports do work. Not sure what happened last time. The build quality of the H10-play is not up to the standard of the T95 MAX, as evidenced by the constant and very audible noise and distortion on the onboard audio jack when using the default Android rom. My T95 MAX runs at just under 50 degrees whilst I've not seen the H10 run any cooler than 62 degrees. Also, on the T95 MAX I am able to power a mechanical 2.5" USB 3 disk via its onboard USB 3 port but you cannot do that on the H10-play so I'd recommend people buy the T95 boxes in most cases unless you really want the ethernet blinkenlichts or the extra 2 USB 2 ports.
 
I recently bought a rockpi4c and its great now that I have 4K output working and it booting directly off nvme. Wifi and bluetooth work too under Manjaro, I just need to rebuild the kernel with the pcie-gen2 patch now to get full disk speed. I've also got the rpi4 and the jetson nano and I've not done any proper benchmarks yet but I'm confident it will beat both notably and it has MUCH better mainline kernel support than the nano.
 
I would buy the rockpi4b instead of the 4c if I was buying another. The 4c has an extra mini displayport but it uses mini HDMI whereas the 4b just has one normal HDMI output. Beware if buying a second hand 4b that it has the SPI chip because you need that to install u-boot to so you ca boot directly off nvme.

TX6 design summary and of course new release.
Today was the day I decided to promote the TX6 as a my main native ARM development center. This brought some improvements and I finally decided to open it. There were no screws, just plastic snaps.

It seems that the manufacturer tried to improve the thermal characteristics of this device. On the right side: a flat metal block and a plastic mass.
At first I removed them but to my surprise the temperatures were worse. So this thermal bridge helps somehow.
The next step was to drill a few holes at the bottom and turn the box upside down (which meant putting it back in its "right" position). I also included some new rubber feet on the "new" bottom.
The box is cooler now, but the idle CPU temperature remains the same (it's better under load and the temperature returns to normal very quickly when the load is gone). So probably the TX6 design is not as flawed as I thought and the high temperature must be for some other reason.



I've managed also to enable installation on the eMMC storage: the installer works now without errors and uboot's DTS was updated in bit different manner (from Aarch DTS patches).
The speed is not great:


Images are being uploaded:
https://github.com/awawa-dev/build/releases/tag/v2022.03.08

Thanks for the info @awawa. I'm currently trying to apply the guidelines provided by @MBB. I'll share if it works as well for my two models of TX6.

@Pic55 after creating a backup I tried to install on eMMC. But the system doesn't boot from eMMC, starting from SD is still working.
During installation using armbian-config there are some errors:
sed: can't read /mnt/nand-sata-install.yi7VMe/bootfs/boot/boot.cmd: No such file or directory sed: can't read /mnt/nand-sata-install.yi7VMe/bootfs/boot/boot.cmd: No such file or directory grep: /mnt/nand-sata-install.yi7VMe/bootfs/boot/armbianEnv.txt: No such file or directory /mnt/nand-sata-install.yi7VMe/bootfs is empty

No, I didn't install system on eMMC. I've got some other TV boxes that are tested for my HyperHDR project as Rpi 4 replacement. Rpi doesn't have eMMC and I want to provide them equal chances (and I don't want to break them if something with eMMC goes wrong , maybe later). BTW so far Rpi4 USB3.0 handling/bandwidth is no match for them...probably tvboxes' USB3.0 drivers are inferior. CPU/Thermal handling is very tricky on H6. For example: one of Armbian patches that should improve CPU's temps is introducing massive instability in fact (it can be observed in dmesg after some time). Despite CPU temps in valid range. So now I'm very cautious when it comes to modify related things.

Actually being able to temporarely run at 1.8ghz (with the on-demand governor) enable some use cases (eg in my case web navigation, for which the system goes 1.8ghz only for short period of time). And through armbian-config you can alway define the limits between which you wish the CPU to run (if you want to keep it below the 1.8 to stay safe). However, today the dbt is buggy : the frequency is there but due to the wrong voltage it's not available) And if you remove the 1.8Ghz (or even the 1.7) it's a bit a pity for the ones requiring it (knowing that it's possible ;-) On top some users could add a better coling system. But up to you, it was just to share (as I fixed my problem ;-)

According to linux-sunxi.org TX6 was designed for 1.5ghz. I think 1.7ghz is already too much due to very poor ventilation and I was rather considering downclocking Maybe some alternative solution could be possible like script to modifying DTB after the installation (decompiling DTB, changing voltage/max speed, compile it again).

@hexdumpyou were right, the problem was in the dbt and was due to a mistake in the power supply block: The regulator-vdd-cpu-gpu is set to 1.135V and the 1.8Ghz block (opp-1800000000) was requiring 1.16V. By changing that limit to 1.135V (opp-microvolt-speed0 = <0x115198 0x115198 0x124f80>;) the 1.8Ghz is now available (and seems to run well). @awawaas your build is the new reference for the TX6 maybe you can add the fix in the dtb ? It's not a major frequency improve but at least all the frequencies listed in the provided dtb are available.

The doc I posted a few days ago in this thread on building from mainline includes a patch to fix eMMC and everything is fully documented there.  I use it and it works well.  I find these boxes are far more responsive when running from eMMC vs SD. Plus, it frees up the SD slot for use as a removable storage device.  Or, if you install something like Balana Etcher, it can even flash it's own images from a URL.  We provide our products pre-flashed to eMMC so they are ready to plug in and use.  
 
With the patch, you can boot from SD and flash eMMC using armbian-config in the usual way (basically, take the first option all the way through the menus and it will start).

I have TX6 box with 8822BS wifi+bt too. I have patches for this wifi, meant to be upstreamed. Speed is probably not on par with out of tree driver and has locking issue (I never experienced it, but it was discovered during testing it on another wifi), but it generally works ok. Take a look here: https://github.com/jernejsk/linux-1/commits/rtw88-test2 (ignore first two patches). BT needs some more patches and FW extracted from Android image (I asked Realtek, but they are not interested in officially supporting BT on 8822BS version). I don't have those patches available anywhere currently.

SPDIF is already included in base H6 DTSI file (any board can easily enable it, if present) and it will be enabled for Tanix TX6 by default in 5.17

@awawa Great news you are switching to mainline.  It will be fantastic to have someone maintain a Tanix H6 build again!  THANK YOU FOR SHARING ALL YOUR WORK ON THIS!
 
On a somewhat related topic, I am working with a manufacturer in China to (hopefully) sell the Tanix-compatible T95 Mini under a new name to avoid confusion, with EMMC, preflashed with Armbian so ready-to-use out of the box.  If anyone is interested in such a product, please let me know.  @awawa's repo works flawlessly.
 
For anyone considering a Tanix-compatible box, I highly  recommend the T95 Mini (with EMMC - often these get shipped with NAND unless you check and they understand what you are even asking ).  The reason why we like the T95 Mini is it seems to run cooler than any other compatible model.  It is also really small and inexpensive.
 
Thanks again @awawa!

My repo is back. With new release of course Bump Kernel to new 5.15.25 and include all valid for us LibreElec patches after their review. https://github.com/awawa-dev/build/releases/tag/v2022.02.24
The fork is now linked to armbian:master and it is ahead by 1 commit that contains all my changes. It will be easy to refresh origin with future Armbian upstream changes.
Unfortunately for us tvboxes have a low priority for mainline development: few patches that are included in Armbian probably for other SCBs, prevent Tanix TX6 from booting or they are causing unstable behavior so I needed to exclude them. So that board needs to have its own patch repository (99% armbian patches included and most of LibreElec).

@danboid If that driver works then probably can be integrated in build script. My repo will be offline for few days: I want to switch fork to mainline Armbian and apply my changes to it. I will be much easier in future to track all the changes in official Armbian releases.

For rtl88x2bs you can try this solution but that external driver seems a bit unstable https://forum.armbian.com/topic/12162-single-armbian-image-for-rk-aml-aw-aarch64-armv8/?do=findComment&comment=97194 Probable safer choice is purchasing TX6 without a Bluetooth as support for rtl88x2bs if it happens, is currently really in bad shape (SDIO version).
 

In case anyone is interested in building from mainline Armbian, here is a doc describing the steps I used.  The goal with this was to change as little as possible and document all changes so they could be reproduced.  Hopefully nothing missing/wrong, but I'll recheck everything tomorrow.  
 
 
 
Tanix TX6 with Armbian.odt
 

Few differences I see:
- different drive strength for wifi (lower than TX6) - not that important
- slightly different eMMC settings (lower frequency, etc) - might be important
- different IR key codes (nothing surprising)
- it seems that slightly different LED display driver is used (can't be sure unless I see detailed PCB photo)
- T95 max has slightly higher DRAM frequency (672 MHz) vs. TX6 (666 MHz)
- different DRAM config, but it's unclear how much they influence stability

No, not really, only general instability (app crashes, kernel lockups, etc.). Note that Android has completely different display stack, so you can't compare it to X11. If you really want to prove it's driver issue, you would need to create BSP based image and test it there. But I never done that for 64-bit Allwinner SoCs, so I have no idea how hard it would be.
 
Strange, your DT blob has this:
 
awleds { device_type = "awleds"; compatible = "allwinner,fd6513_dev"; status = "okay"; leds_clk = <0x87 0x07 0x05 0x01 0xffffffff 0xffffffff 0x00>; leds_dat = <0x87 0x07 0x06 0x01 0xffffffff 0xffffffff 0x00>; phandle = <0x1bd>; }; which clearly indicates it should have FD6513 LED driver and thus display. Maybe it's one image for several box variants.

@danboid Haven't tried dis/reconnecting HDMI yet. MATE version will be uploaded.

New version for Tanix TX6 (Allwinner H6):
https://github.com/awawa-dev/build/releases/tag/v2022.02.17
 
Changelog:
Add support for OpenVfd LED clock (service is disabled on default) upgrade current branch to: 5.15.24 include 4k60 H6 fix from LibreElec update current(5.15) Armbian patches include drivers for RTL8822CS  
To enable LED clock service execute these commands:
 
sudo systemctl enable openvfd sudo systemctl start openvfd  

Great to see you got openvfd working awawa!
 
I have built and booted your 5.16 edge kernel on my T95 MAX. The good news is that ethernet and wifi are working but my HDMI reconnect problems are still present. Have you tried disconnecting and reconnecting your HDMI cable when running X (eg XFCE) on your TX6?
 
What H6 device(s) have you got Jernej?
 
Please could you add MATE as a second desktop option to your images please awawa?

I know about the changes, I'm the one who made them. However, everything works for me . Note that there are some issues with 5.17-rc releases due to some sunxi pinctrl driver bugs, which were resolved recently. Last patch is not applied yet.

@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.

@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.