Pic55

Hi @deltasig68 yes. Actually the issue was due to some kernel flags not set when the OS image was generated. I managed to have it working by recompiling the OS (following the Quadra / Inovato procedure by @MBB: https://forum.inovato.com/post/building-armbian-from-source-12449428?pid=1334457271) and once the few build issues fixed, I recompiled changing the following kernel flags (taken from a libreelec forum) :
 
CONFIG_CEC_CORE=y
CONFIG_CEC_NOTIFIER=y
CONFIG_CEC_PIN=y
CONFIG_MEDIA_CEC_SUPPORT=y
CONFIG_USB_PULSE8_CEC=m
CONFIG_USB_RAINSHADOW_CEC=m
 
Then you can use the cec protocol with cec-ctl (apt-get install v4l-utils). I haven't completed my tests but it seems to work fine. Please notice that the above is valid on a T95 / Quadra box (H6 based). And double check that your HDMI cable support the protocol (not all do).

For background, this is part of our project to bring an Armbian-based TV Box to market.  See our home page at https://www.inovato.com.

For anyone wanting to build from mainline, we have posted an article with our patches.  These include AC200 Ethernet and XR819 wifi support in kernel 5.15.y.  For edge builds, AC200 Ethernet is supported.  To support the XR819, we'll have to create more patches for the changes in kernel 5.19.  The link is https://www.inovato.com/article/building-armbian.

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

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.

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 ;-)

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

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
 

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

Welcome to the world of Armbian on TV Boxes!
 
TV Boxes are not officially supported by the Armbian project.  This "TV Box" sub forum is for users interested in experimenting with Armbian on TV Boxes.
 
Overall you will be best served if you set your expectations low as to what you might be able to accomplish with your TV Box and Armbian.  Specifically you should think of your TV Box as a potential linux server - *not* as a desktop replacement.
 
Feel free to post and ask questions in the TV Box forums if you are interested.  But realize this is a peer-to-peer forum so you may or may not get an answer.  Don't expect or demand support as there are only a handful of people that participate in these forums and they are all donating their time.
 
Search is your friend.  There is a lot of historic information stored on this site.  Your question has likely already been asked previously.  However, a lot has changed over time and therefore be prepared for a lot of the information you find by searching the forums to be outdated and in some cases just plain wrong.  Even though that may be the case, please search the forums first before posting a question.  It shows you are willing to invest the time to do your part and makes those of us who volunteer our time to answering questions more likely to want to help you.
 
 
Amlogic (S9xx) based TV Boxes
1. There is a community build for Amlogic based s9xx TV Boxes - The key being community - so please contribute to make improvements
2. A single developer (@balbes150) had worked years on getting things to the state they are.
3. As of October 14th, 2020 balbes150 removed support for Amlogic CPUs, so that is the last active build from him
4. Expectations should be set low (i.e. don't expect anything to work) but if you do get the box to boot, get HDMI and wired ethernet to work, you are doing good.
5. You really shouldn't expect things like Wi-Fi, bluetooth, remote control, etc. to work.
6. There is a very small number of people on this forum/club that are able to provide any guidance.
7. Most likely no one on this forum owns your specific box and therefore generally can only provide vague guideance.
8. If you get this working on your box, it will likely only be useful for server type tasks, maybe a little light graphical desktop usage, but do not expect video playback, etc.
 
RockChip (rk3399, rk3328, rk3288, rk3228, etc) based TV Boxes
These are probably the best supported TV boxes currently.  They have the most active developers.  Feel free to post in the Rockchip TV Box sub forums your questions.
 
Allwinner (H6, H616, H313) based TV Boxes
There is no ongoing effort to support Allwinner based boxes.  Occasionally a developer will respond to a question, but in general if this is what you have, you will be expected to do a lot of work on your own, so you better be comfortable doing development for these type of boards.  You aren't likely to find anything that you can just install and have work.
 
Other Comments
The official recommendation from the Armbian project would be to not use TV Boxes and use officially supported SBCs. Taking this approach will likely result in an easier time, less hassle, better support and likely a more fully functioning device.
 
There are reasons you may choose to want to use unsupported Armbian on TV boxes, for example here are some of my ( @SteeMan ) reasons:
 
1) It is a challenge and therefore a learning opportunity.  I would never have learnt to build my own linux kernels from source if I was still exclusively using x86 hardware.  If you want a challenge you will find it here.
 
2) Price vs specs.  The Android TV boxes are built to be cheap consumer devices.  They are produced in larger quantities which drives down the per unit price.  You will generally not be able to get the same level of hardware for the same price with a standard SBC.  But that cheapness comes with - no support by the manufacturers and potentially sub-standard components.  If the manufacturers goal is to sell the lowest price box they are likely cutting corners somewhere to make that happen.
 
3) emmc is standard.  TV boxes always come with internal storage while most SBCs do not.  Again from a price/performance standpoint having internal emmc storage vs running off an SD card is a plus.  emmc storage *should* be faster and more durable than storage on an sd card.  The caveats here being that this is one of the areas that the manufacturers may cut corners.  For example I have two TX3 mini boxes that are supposed to have 16GB of emmc memory (like the other TX3 mini boxes I have), but they were instead manufactured with cheaper nand memory for which there is no mainline kernel support.  There is no visible difference between the identically packaged boxes that had emmc vs those that came with nand, other than opening the case and looking at the physical chips on the boards.
 
4) cases come standard.  TV boxes always come with cases, whereas for SBCs that is an extra cost.  For my uses having a case is a big improvement vs not having one.  A downside if that these cases are not necessarily well designed to provide adequate cooling.  So depending on your use case, overheating might be a problem.
 
5) While I own both SBCs and TV boxes, I personally find the TV boxes work best for my needs (running server based software) and I enjoy the challenge of getting them running and keeping them running with the great underlying work that the Armbian project is doing to build on top of.
 
If you have the correct expectations (set your expectations low) are looking to learn and are up for a challenge these are fun things to work with.  And I look forward to working with you on these forums.