SteeMan

@robertoenr 
 
I have installed Armbian 20.10 Focal 5.9.7 in my OTT TV BOX X96 mini 1 + 8GB and it works well, only the wifi that does not work, I want to know if there is a more advanced kernel to install it on these equipment.
 
Equipment information:
- Amlogic S905W chipset
* Quad Core 1.2GHz 64bit Cortex-A53 Mali-450
* 1 GiB of DDR3 memory
- 8 GiB of eMMC flash
- 10/100Mbit Ethernet
- HDMI output up to 4K30P
- Model: X96 mini.
 
I would like to install one such as: Armbian 21.xx Focal 5.10.x, if some one knows please let me know.

Anyone else ever get just a blank screen? I’m trying to install onto a Trongle S3 box. I’ve tried a number of dtb’s but as it’s a relatively rear box nothing is definite. Tried to match them by spec but hoped it would at least register an output on my monitor. 

I get a no signal notification. 
 
I will be trying to tty the com port but this includes soldering so wanted to see if anyone else knew of a possible solution before I spent time doing this.

Let me add my limited knowledge here.  Note that the following comments only apply to amlogic CPUs.  The 'chainloading' of u-boots is designed to utilize the original u-boot that came on the device (stored in emmc) to start booting.  Then after the original u-boot has initialized everything, the secondary u-boot (the chain loaded one) is started to continue the process and load the linux kernel, ramdisk and dtb and launch the linux kernel.  This secondary chain loaded u-boot is stored in the /boot directory and named u-boot.ext.  Thus the installation step to rename the appropriate u-boot file to u-boot.ext (this file could on either SD, USB or emmc depending on where the installation is running from.
The reasons for doing things this way are to try to simplify things such that multiple different TV boxes can be supported.  Theoretically each TV box should have its own custom u-boot to fully boot correctly.  By using the existing manufacturer shipped u-boot we avoid having to build a hundred different u-boots for each device.  The problem is that these original u-boots are buggy and old so they don't support the latest u-boot functionality - like using hdmi output during the boot process.  The chain loaded u-boots are using recent u-boot source code and therefore are better.  Because the hard work of bringing the system up (memory, cpus, other devices) has already been done by the base u-boot, the chain loaded u-boot has a lot less to do and hopefully can be more generic and support multiple different boxes with one u-boot build (per CPU).

The fix for this would be on the armbian side (for the linux-image-current-meson64 package).  It is a one line fix in the postinst script.  I plat to submit a PR for this fix when I get a chance.

@ballerburg9005 I just wanted to add a few of my own thoughts to this thread.  Overall I can see both sides to the above discussion.  There are valid points made by everyone commenting.  While we all sometimes need to have 'grand visions' of the future we would like to work towards, we also have to deal with the reality of where we currently are.  I often think of a saying "crawl, walk, run".  While we all want to be running to the finish line of an Olympic race, we all start by crawling first.  As that relates to armbian and more specifically armbian on TV boxes, we are at the crawling stage.  There is a lot of work to be done to just get us walking.  That doesn't mean that crawling and walking in themselves aren't valid and productive stages (they are and you can use a lot of different TV boxes today to do a lot of productive stuff).
There is a lot of work to be done today to improve our crawling.  We need volunteers (like you) to pick up that work if we ever hope to get further along our path.  We need to build a community one volunteer at a time.  While visions are important, if we don't have people willing to do work today then we will never more forward.
If you hang around armbian for any extended period of time, you will learn that the single thing that most bothers the core maintainers of the project are people having grand visions or even small visions of what should be done but who don't contribute any time to help and expect others to do the work for them.
Whether intentional or not, that is how your post came across to Igor and Balbes and they reacted as they normally do to such posts.
If you want to run to the finish line with your vision, you need to start by crawling.  Spend time on these forums following the issues to build your knowledge.  Help support new users to allow others with the technical knowledge time to work on development and progress on our shared goals.  This all doesn't happen overnight.
I welcome your contributions to the efforts here, but starting off by getting into a disagreement with two of the core maintainers isn't likely the best way to have started.  Overtime you will realize we all share a lot of the same goals and can work together even through we have different personalities and sometimes have to overcome language/cultural differences.

@Scrooge69 Welcome to the armbian world and your first post in the forums.
I unfortunately don't have much information in response to your questions.  balbes150 who created the builds referenced in this thread has moved his focus to other projects (the StationPC M1 and P1 boxes).  I don't own a rk3328 based device so I have no personal experience with them.  If you look at the recent activity in this thread there isn't anyone actively engaged currently supporting boxes like the one you have.  The best I can recommend is to try using the images linked in the thread and try things out.  Since you are puttimg the images on an SD card it won't hurt your device to test and experiment.  (I wouldn't recommend installing anything onto your emmc memory however).

@ballerburg9005 I just wanted to add a few of my own thoughts to this thread.  Overall I can see both sides to the above discussion.  There are valid points made by everyone commenting.  While we all sometimes need to have 'grand visions' of the future we would like to work towards, we also have to deal with the reality of where we currently are.  I often think of a saying "crawl, walk, run".  While we all want to be running to the finish line of an Olympic race, we all start by crawling first.  As that relates to armbian and more specifically armbian on TV boxes, we are at the crawling stage.  There is a lot of work to be done to just get us walking.  That doesn't mean that crawling and walking in themselves aren't valid and productive stages (they are and you can use a lot of different TV boxes today to do a lot of productive stuff).
There is a lot of work to be done today to improve our crawling.  We need volunteers (like you) to pick up that work if we ever hope to get further along our path.  We need to build a community one volunteer at a time.  While visions are important, if we don't have people willing to do work today then we will never more forward.
If you hang around armbian for any extended period of time, you will learn that the single thing that most bothers the core maintainers of the project are people having grand visions or even small visions of what should be done but who don't contribute any time to help and expect others to do the work for them.
Whether intentional or not, that is how your post came across to Igor and Balbes and they reacted as they normally do to such posts.
If you want to run to the finish line with your vision, you need to start by crawling.  Spend time on these forums following the issues to build your knowledge.  Help support new users to allow others with the technical knowledge time to work on development and progress on our shared goals.  This all doesn't happen overnight.
I welcome your contributions to the efforts here, but starting off by getting into a disagreement with two of the core maintainers isn't likely the best way to have started.  Overtime you will realize we all share a lot of the same goals and can work together even through we have different personalities and sometimes have to overcome language/cultural differences.

No hardware decoding.  Please read: https://forum.armbian.com/topic/16407-please-read-first
You should not be expecting to use TV boxes running armbian for heavy desktop work i.e. video.

@ballerburg9005 I just wanted to add a few of my own thoughts to this thread.  Overall I can see both sides to the above discussion.  There are valid points made by everyone commenting.  While we all sometimes need to have 'grand visions' of the future we would like to work towards, we also have to deal with the reality of where we currently are.  I often think of a saying "crawl, walk, run".  While we all want to be running to the finish line of an Olympic race, we all start by crawling first.  As that relates to armbian and more specifically armbian on TV boxes, we are at the crawling stage.  There is a lot of work to be done to just get us walking.  That doesn't mean that crawling and walking in themselves aren't valid and productive stages (they are and you can use a lot of different TV boxes today to do a lot of productive stuff).
There is a lot of work to be done today to improve our crawling.  We need volunteers (like you) to pick up that work if we ever hope to get further along our path.  We need to build a community one volunteer at a time.  While visions are important, if we don't have people willing to do work today then we will never more forward.
If you hang around armbian for any extended period of time, you will learn that the single thing that most bothers the core maintainers of the project are people having grand visions or even small visions of what should be done but who don't contribute any time to help and expect others to do the work for them.
Whether intentional or not, that is how your post came across to Igor and Balbes and they reacted as they normally do to such posts.
If you want to run to the finish line with your vision, you need to start by crawling.  Spend time on these forums following the issues to build your knowledge.  Help support new users to allow others with the technical knowledge time to work on development and progress on our shared goals.  This all doesn't happen overnight.
I welcome your contributions to the efforts here, but starting off by getting into a disagreement with two of the core maintainers isn't likely the best way to have started.  Overtime you will realize we all share a lot of the same goals and can work together even through we have different personalities and sometimes have to overcome language/cultural differences.

This issue is specifically about an issue where 'sometimes' a box will fail to boot off of emmc (after having booted successfully previously).  The workaround is to boot once from SD card and then the emmc boot generally works fine again.
 
I am starting this thread as a central place to discuss this issue that has been reported by a few people that I know. @lgranie and @robertoenr both have reported this problem either recently or in the past and I see it myself frequently.
 
It would appear that something is getting set in the uboot environment that is causing the boots to fail and fixed/cleared by a boot from SD card.
I haven't had time to look at this and don't know when/if I will have time.  But I wanted to log this so others would know about the issue and perhaps someone might have time to dig into this.

I have begun to make some changes to the TV Box 'Club' area.
 
The overall goal is to provide more useful information to users and reduce the support workload of answering the same questions over and over again.
 
To that end there is now a FAQ forum on the menu.  While it is currently empty and just a place holder it should provide a centralized location for TV Box information over time.
 
The second new addition is the forum titled 'TV Boxes running Armbian'.  The idea here is to provide a maintained list of current information with links to the details for boxes reported by the community to be successfully running armbian.
 
Both of the two above forums will likely be strictly moderated to keep the information concise and on topic.  I don't want these to become mega threads (like some of the TV box threads tend to be).  Content that gets posted here that belongs elsewhere will be moved.
 
I'm still trying to figure out how the rest of the area should be organized.  There needs to be a place for newbies to ask questions and it would be nice if there was a place for developers to share information.  The problem is that the current mega threads for the Rockchip CSC builds do that in a single thread, vs using one or more forums for that.  Also I wonder if there should be different forums by CPU family (AML,RK,AW?) by developer build (Balbes vs Jock's CSC builds?).  Any suggestions on how others think things should be organized?
 
  

I have begun to make some changes to the TV Box 'Club' area.
 
The overall goal is to provide more useful information to users and reduce the support workload of answering the same questions over and over again.
 
To that end there is now a FAQ forum on the menu.  While it is currently empty and just a place holder it should provide a centralized location for TV Box information over time.
 
The second new addition is the forum titled 'TV Boxes running Armbian'.  The idea here is to provide a maintained list of current information with links to the details for boxes reported by the community to be successfully running armbian.
 
Both of the two above forums will likely be strictly moderated to keep the information concise and on topic.  I don't want these to become mega threads (like some of the TV box threads tend to be).  Content that gets posted here that belongs elsewhere will be moved.
 
I'm still trying to figure out how the rest of the area should be organized.  There needs to be a place for newbies to ask questions and it would be nice if there was a place for developers to share information.  The problem is that the current mega threads for the Rockchip CSC builds do that in a single thread, vs using one or more forums for that.  Also I wonder if there should be different forums by CPU family (AML,RK,AW?) by developer build (Balbes vs Jock's CSC builds?).  Any suggestions on how others think things should be organized?
 
  

We are currently at a breaking point where cheap Android TV boxes become powerful enough and viable enough to do the following while running Linux:
 
1.  Be a server: self-hosting data, fediverse, home NAS
2. Be a TV box: 1. web browser, 2. other multimedia options, 3. games
3.  Be a makeshift PC replacement (run office applications, photo editing, etc)
 
Concerning #1: If you have followed the news then you have witnessed that censorship is increasing and that the nature of it is most alarming. Over the next years, big tech and politics-driven manipulation of online information will only get worse, until the internet essentially devolves into a kind of TV program suitable for only silent, mindless and conformist consummation. In the wake of this happening, enough people are slowly waking up and realize: We can't just blindly put all our data and digital lives into the hands and dictatiorships of giant companies anymore. That is why we need to step back from those ill relationships and towards alternatives like the fediverse, that have already been worked on for the benefit of the greater good. As more and more ordinary and "technologically helpless" people are turning to the community for solutions, we should have all the answers. 
 
Concerning #2 & #3: Many people have smart TVs now. A lot of them aren't even running Android and they do not support any or proper web browsers in order to lock people into vendor schemes. But even on Android, many apps do only work in a makeshift shorthand manner, meant to be just barely enough to work with on a tiny phone when a PC is not available. Office doesn't work well and can't be used in a productive manner, most uncommon hardware addons like basic game controllers are not working for game emulation, if there are server apps they tend to be unreliable, there are not proper video/photo/music editors, etc. etc. This is absolutely not the case on desktop Linux distributions that run on x86 and ARM virtually all the same.
 
The TV box has evolved away from a dumb DVD player-alike thing with classic remote controls and is moving towards being a mini-PC with mini keyboard remote or full keyboard and mouse as standard, that people need for things they just can't practicably do well enough with their smartphones. In fact nowadays, most ordinary people rather primarily use their smartphones and do not even want to have a real PC around. Like described, Android performs well on smartphones, but the entire ecosystem has always been and will always be far too misfit for the TV environment to exhaust the true potential and benefit a TV box could have in people's lives.

Here is were Linux comes in, and this could turn the tide on Linux marketshare: We, the people from the Linux community, are not only providing a solution, with enduser-friendly server application environments like Yonohost or Docker, to the problem of big tech vs. our privacy, freedom and democracy. We also provide an operating system that fills an unfilled market nieche: the TV box as both a media center and mini-PC, a kind of "most things ordinary people often most need but nothing too serious" kind of solution. One that isn't controlled by big tech, and one that is born out of free choice and their choice for freedom. Never again has it been so convincing for people to switch to Linux by their own volition.
 
The Rasperry Pi or similar boards are all in all a good option here. But unfortunately they are neither advertized, nor sold nor priced in a manner that would appeal to and convince the average Joe to buy it. In fact I would rather buy the Rasperry Pi, if I was only buying it for myself: to have it easier.  But I am not thinking of myself here. I am thinking of the bigger picture and the greater good that would come from even lower cost.
 
Think of this: Before the Rasperry Pi existed, you could have simply used an old notebook or a thin client with GPIO card to do the same job. Yet in the very long era of thin clients, no one was thinking of all the great magical things you can do now with the Rasperry Pi. That is because back then they weren't magical at all at higher price points. When you run the Pi now, it consumes barely any power. Hosting your own data or controlling the doorbell, heating or hydroponic garden over wifi feels like a delight. You have so many awesome possibilites to enriche your life. But when you pay $10 for powering the Pi per month, like you would have paid for an old thin client, all those great things feel rather unpleasant. They aren't so advantageous or helpful anymore and leave a very bad aftertaste. A $30 TV box is about as capable as a Rasperry Pi and the Rasperry Pi is about as capable as some thin client from back in the day. The lower cost is all there was that made all the difference. And it is what opened up widespread use, large communities sourrunding it and so many benefits that just weren't really good benefits at all when the technology was more expensive.
 
That is how a $30 TV box running Linux will be cornerstone technology. And a thin client or Rasperry Pi kit for $100 sadly were not.
 
$30 will currently get you a 4GB/64GB Cortex-A55 with Mali 31 GPU. Those specs are far than enough.
 
Linux currently has (like it always had) 2% market share on desktops. Something needs to change, not to convince ourselves more that our own logic is sound, but to bring more ordinary "non tech" people in. who are not knowing the same things we do and make decisions based on different premises and imperatives. If we could push Linux up to only 15% market share, then most software companies that currently ignore Linux (like Adobe) would also develop for Linux to make more profit. At this point, Linux would snowball into widespread use because it had more advantages than using Windows. This wouldn't just be a great victory for software freedom and thus our freedom while using software, but it would also lay the foundation for a consciousness on digital freedoms and other cultural freedoms as well, where today only ignorance prevails.
 
What catches ordinary "non tech" people is also impression and convenience. Like a phone just resets and you can sell it, you can plop out your SD card into the next TV box and merely use the internal user-storage of Android for backup files. You can dual-boot Android, just try Linux out, no harm done. It comes fully assembled and doesn't look weird. Believe me to ordinary people who basically know nothing about technology, things like this are huge. Not only but foremost because they can easily imagine how to move forward with and treat it like other things they already have used before (like a phone or TV).
 
 
I didn't say it will be easy, just that this is how things are and could be. There are several problems to be solved and some are not easy to solve.
 
Like on PCs, Linux doesn't ship pre-installed on Android TV boxes and it needs to be distributed afterwards. Here I could imagine, that people could turn to local computer/Linux clubs to have it done for them for free. Or they could, worst-case, mail their box to someone in their country who will install Linux for them. It is probably the biggest hurde to get people to make this first step. But as people are now losing faith in big corporations, the return to community-driven options is only logical.
 
Then there is the technical side of things. And this is where we come in and I am asking for your help here: As I gathered, virtually all the cheap TV boxes with really good specs are (and always were) Amlogic devices. As you know there are hundreds of devices and they even often require reverse engineering, while the manufacturers don't play ball. So supporting Amlogic in general seems more like a fools errand. **However**, for us to support just one model every 2 years per generation is not: It absolutely is the smartest move we can make for everyone. We make the cheapest and fastest box work smoothly and as good as it gets, as a team effort. And this is the box we recommend as a community, that all people then can buy and profit from.
 
I believe so strongly in the value of this vision and the power and potential of all the converging events described, that I want to create a seperate website, which will serve two purposes: 1. to coordinate the project, provide a better dedicated space for knowledge and development. 2. To describe the idea to ordinary consumer-type people, so that they can easily understand what it is, what their options are in software and hardware and and what advantages they get.  There are many recent technologies from the fediverse and related, like Yunohost and docker, that even most tech-savvy people know nothing about and hence can't draw implications from. A dedicated site would quickly explain all those things, in a carefully thought-through manner to specific audiences, provide demos and tutorials and so forth and thus not be as convoluted and difficult to ingest as the post that you are reading right now on this forum.
 
From what I gathered, there isn't anything happening like that here or elsewhere at all. But admittedly, I haven't searched for it days on end either. I know of Balbes who seemed to be the one-man-army for Amlogic devices but now it seems he has quit? And SteeMan kind of took his place? I have been reading some on the Forum, and learned a few things about the general situation and gained insight to very very few scattered technical details. But there are thousands of pages on this-and-that sourrunding the topic from the last years. And it is totally impossible to work through all of it. This forum is about enduser support mostly, and no seperate dev forum seems to exist there are just bits and pieces here and there.
 
This is why it would be really really helpful if someone very experienced (like Balbes?) could write a crash course for other devs who have not worked much beyond the basics with TV box hardware.
 
This crash course should contain all the endpoints where dev support is needed, the technical nature of the problem, some details around it and maybe even a quick guide how to possibly tackle them. Of course this shouldn't be a lengthy tutorial, and only be as long as the person has time to spare. In essence it should just be the insights and pitfalls in the deciding details that someone with experience has gathered.
 
We could then expand on that crash course and work through all the issues. But let's first see how many people really jump on to this train, or if this will be a one man show. That would be kind of sad.
 
Personally I don't have much experience in hardware hacking and I can't desolder SMD parts or read EPROMs or anything like that (I suppose that isn't required, ever?; hopefully). I did work in IT most of my life, so I have all sorts dev exeperiences and am a Linux expert. I worked with microcontrollers and kernel drivers before, but not much. I dived a bit into uboot and drivers 2 years ago for my current box, but I still have to learn quite some with the hardware specifics. I have a ttl serial dongle of course. I am willing to learn whatever it takes.
 
As for the question of "which box?": Please make a recommendation. I believe the X96 max plus is the best candidate for last year and as a start.

@riocoles Please read https://forum.armbian.com/topic/16407-please-read-first
especially note the current status of amlogic cpus which is what your box contains.
 
Have you tried different dtb files?  You are using a dtb file that isn't part of the mainline kernel (thus it is a patch applied to mainline kernel).  It could be the case that due to changes in mainline over time that the patch hasn't been well maintained and no longer works correctly.  When dealing with TV boxes sometimes the best advise is to try all the relevant dtb files for your cpu to see which has the best support for the physical hardware in your specific box.
 

@alexx  If I understand you correctly, you are currently running with the OS installed on an external drive connected via USB (no sd card and the original android still installed on the internal emmc storage).  There isn't any reason you need to change that setup.  As a general rule of thumb, SSD better than emmc which is better than SD card, in terms of quality and durability of the storage.  So you should be fine running your current setup. 

As is stated here: https://forum.armbian.com/topic/16407-please-read-first
it shouldn't be an expectation that wifi is going to work with armbian on TV boxes.  I have about 8 boxes now and wifi doesn't work on any of them.  While there are exceptions, in general if you limit your expectations to using wired ethernet you can do some amazing things with these boxes.  Since you didn't even mention which box you are interested in, I can't guess if wifi has a remote possibility of working for you, but my guess is not.
 
There are only a couple of people currently engaged in volunteering their time to respond to users in the TV box forums.  So I choose to focus my limited resources on helping users who have a reasonable chance of success (i.e. their expectations are appropriate).  Otherwise I could spend all my time trying to help one user try to get wifi working on one poorly supported TV box type and likely be unsuccessful in the end.
 

As a new user, have you read:  https://forum.armbian.com/topic/16407-please-read-first
 
You haven't told us how you installed your system.  Lets start with some basics:  what build did you use?

Moved you post to the TV Box club.  You should read:  https://forum.armbian.com/topic/16407-please-read-first
Generally you are not going to find any Android TV boxes that will meet your needs with the armbian builds that you can install on them currently.  They were great for headless servers, or light desktop/browser use.  But you aren't going to find good video playback support currently in general and especially not at the price point you are looking at.  Just trying to set your expectations.  If you already had a box and wanted to experiment, I would say go ahead, but if you haven't yet bought something, you are likely going to be disappointed by the current state of armbian on TV boxes - the first clue to that state is that they aren't supported devices.

@hannah You have a lot to learn about armbian on TV boxes and dtbs and kernels.  I plan to write a longer response this weekend when I have more time, but for now the short answer to your most specific question: no audio over hdmi is that you need to use a different dtb file.  Your box is s905x3 based (i.e. the sm1 architecture).  You are using based on what you reported a dtb for the s905x2 (g12a).  While much is the same, some things are also different.  Now what you may find is that if you use one of the very few available sm1 dtbs (I use and have only tested meson-sm1-sei610.dtb - the sei610 is the reference board for the s905x3 chip) that other things you have working on your current install (like wifi) will probably no longer work.
I believe you have likely already read the following: https://forum.armbian.com/topic/16407-please-read-first
as it was referenced in the last thread you started.  The current state for armbian on TV boxes is limited especially for amlogic cpus.  There are many reasons for this and that deserves a longer explaination of how dtbs and kernels interact and the overall goals of the armbian project.  (and how they differ from other projects out there like coreelec you reference above).
 
But I have already spent an hour of my day (we are all volunteers around here) setting up a test system to verify that audio does indeed work on a TX3 X3 box (as I thought it did, but because I don't normally run desktop environments as the current state of support really isn't working well yet, I didn't have an environment I could quickly test).  What I did just do is downloaded a clean copy of the 2020-10-14 balbes build of focal 5.9.0 desktop, used the meson-sm1-sei610.dtb and the u-boot-s905x2-s922 uboot file copied to u-boot.ext, booted and played the test.mp4 file and had correctly working audio via hdmi.  I then changed the dtb to meson-g12a-x96-max.dtb, which I believe you are using, rebooted and had no audio.
 
What I don't understand is that if you have read the Please Read First post, why you would post four posts in this thread within a day, seemingly demanding support for the 2 or 3 volunteers around here that monitor this forum?  Especially when you are asking about things like bluetooth, wifi, etc on the amlogic platform that we say you shouldn't expect to work, and if they do you are lucky.

@hannah You have a lot to learn about armbian on TV boxes and dtbs and kernels.  I plan to write a longer response this weekend when I have more time, but for now the short answer to your most specific question: no audio over hdmi is that you need to use a different dtb file.  Your box is s905x3 based (i.e. the sm1 architecture).  You are using based on what you reported a dtb for the s905x2 (g12a).  While much is the same, some things are also different.  Now what you may find is that if you use one of the very few available sm1 dtbs (I use and have only tested meson-sm1-sei610.dtb - the sei610 is the reference board for the s905x3 chip) that other things you have working on your current install (like wifi) will probably no longer work.
I believe you have likely already read the following: https://forum.armbian.com/topic/16407-please-read-first
as it was referenced in the last thread you started.  The current state for armbian on TV boxes is limited especially for amlogic cpus.  There are many reasons for this and that deserves a longer explaination of how dtbs and kernels interact and the overall goals of the armbian project.  (and how they differ from other projects out there like coreelec you reference above).
 
But I have already spent an hour of my day (we are all volunteers around here) setting up a test system to verify that audio does indeed work on a TX3 X3 box (as I thought it did, but because I don't normally run desktop environments as the current state of support really isn't working well yet, I didn't have an environment I could quickly test).  What I did just do is downloaded a clean copy of the 2020-10-14 balbes build of focal 5.9.0 desktop, used the meson-sm1-sei610.dtb and the u-boot-s905x2-s922 uboot file copied to u-boot.ext, booted and played the test.mp4 file and had correctly working audio via hdmi.  I then changed the dtb to meson-g12a-x96-max.dtb, which I believe you are using, rebooted and had no audio.
 
What I don't understand is that if you have read the Please Read First post, why you would post four posts in this thread within a day, seemingly demanding support for the 2 or 3 volunteers around here that monitor this forum?  Especially when you are asking about things like bluetooth, wifi, etc on the amlogic platform that we say you shouldn't expect to work, and if they do you are lucky.

@horiatm welcome to armbian and the TV box club.  Since this is your first post, I want to point you to the 'Please Read First' post:  https://forum.armbian.com/topic/16407-please-read-first
 
 
I have never heard of your box before.  In doing some searching, I don't see anyone ever posting about it in the armbian forums either.  Actually I can't find much information at all about the box.  Therefore it is unlikely that anyone around here is going to own one or have any direct experience with it.  Therefore while we might be able to give you some general guidance, you are likely on your own trying to hack armbian onto your box.
 
If you are looking for help, more information would be helpful.  Like where are you downloading the images you are trying from?  What steps/instructions are you using to attempt to get this working.  Simply saying 'Tried to boot..' doesn't give us much to go on.  Things like what dtb's you have tried (and how) would be helpful.

Update: I located the stock firmware for this TX3 Mini 1.6 board in a vietnam webpage: https://tinhte.vn/thread/tong-hop-cac-ban-firmware-cua-android-tv-box-tx3-mini.3022766
As I read is the 2020-21 hardware stage for this box. And this is the unique firmware working on this box.
 
I've tried with Amlogic Burning Tool and works OK. Mega link to stock firmware (if anyone interest): https://mega.nz/file/TcID3SyB#9SPAqK2kslwuDQ9C9TMgEFfai4bPwZy-RNar3WSYw48
 
The bad news is that still can't boot from USB/SD (external media). No human way. I've tried pressing/non pressing the reset button while power on, pressing the remote menu button, disconnect all (including keyboard) with no success to boot Armbian, it always boot to Android Recovery. It's like the box can't boot from external media and the reset button function were changed to show the Android Recovery...
 
@Ngo Thang What DTB are you using? I've tried the "meson-gxl-s905w-p281.dtb" and the "meson-gxl-s905w-tx3-mini.dtb", but no way to start.
 
Aprecciate all help.

Hi, don't know if it might help, because I have a TX3 Mini with a 1.2 board,  but if yours can dualboot stock Android (Alice UX) and LibreELEC, like mine does, then perhaps they are similar enough.
On mine, pressing the reset button does nothing either, in order to boot from SD card I have to:
-boot on the stock Android first;
-open the upgrade & backup app;
-press on select an upgrade package;
At this point a menu will pop-up and after a brief search the app should find, on the SD card, an "aml_autoscript.zip" file, which I guess is a package the image creator has made in order to trick the upgrade app into thinking that the Armbian image is an upgrade package, but anyway, select it;
-press the upgrade button;
The app ask if you're sure, would you like to make a backup first, yada yada, click ok and it should reboot for the firmware upgrade;
On reboot, instead of the firmware upgrade that Android expected, you should have Armian booting, no need to press buttons or anything, just click reboot and wait to be prompted to input a username and password.
 
Since I have no wi-fi (my TX3 has the dreaded SV6051P SDiO Wi-Fi and BT chip) and since many around the forums claim that they fixed it by changing their dtb, I have tested several dtbs:
meson-gxl-s905w-tx3-mini.dtb
meson-gxl-s905x-p212.dtb
meson-gxl-s905w-p281.dtb
meson-gxl-s905x-nexbox-a95x.dtb
All of them worked, meaning that I could boot into Armbian no matter which one of them I used, but I noticed that audio through HDMI works on the s905w ones and not on the s905x ones (sometimes I had no HDMI audio on s905w either, just try reflashing the SD card if that happens).
None of them fixed the Wi-Fi, none of them had hw acceleration for videos (meaning that video playback relies on CPU and it sucks), no IR remote, no VFD, no audio from the AV jack, but that was to be expected.
 
Since we're on the subject, I wanted to ask SteeMan (the man who owns 4 TX3s, with different board revisions) if he managed to get the Wi-Fi to work on any of them and if yes, on which ones.

But anyway, yeah, let me know if that works.

Given that you do have general linux knowledge and rpi familiarity, here are my comments on your requests.
I have 4 TX3 mini's three of which I run armbian on and one that I use the original android on.  I will mention that just because a box is labeled TX3 mini, doesn't mean the internals are the same.  The manufactures put identical external branding on boards that may be significantly different.  For example all TX3 minis claim they have emmc storage in them.  But only two of my TX3 minis have emmc storage, the other two come with nand storage (cheaper to manufacture that way).  Since mainline linux doesn't support nand I can only install armbian on internal storage on two of my boxes.
 
From the above linked post you need to download an image file from any of the download locations.  The file you are looking for is the arm-64 version from October 14th 2020.  These are the last versions from balbes150 to support Amlogic cpus.  So be warned that when and if you get this running on your TX3 mini box, there is currently no path to get anything newer than this Oct 14 build with 5.9.0 kernel.  You will get updates from your chosen distribution (debian or ubuntu) just no kernel updates, unless someone else in the community picks up the ball and begins building/maintaining amlogic kernels.
 
In the downloads directory you will find builds for debian (buster and bullseye) and ubuntu (bionic and focal), along with both a desktop and non-desktop version of each.
 
Once you download your chosen build (for example  https://users.armbian.com/balbes150/arm-64/Armbian_20.10_Arm-64_focal_current_5.9.0.img.xz - ubuntu focal non-desktop build)
You need to burn the image to an SD card.  Generally balenaEtcher is recommended (however I have only ever used dd on linux to create my sd cards, so I have no familiarity with that tool)
 
Once you have the SD card with your chosen build, then you need to edit the boot configuration file on the SD card.  In the BOOT partition of the SD card there will be a file /boot/extlinux/extlinux.conf, that you need to edit. (In earlier builds this was done in the /boot/uEnv.txt file, so a lot of comments in these threads talk about that file, but in the latest builds it was changed to the extlinux.conf file)
 
Your extlinux.conf file should look like:
LABEL Armbian
LINUX /zImage
INITRD /uInitrd
# aml s9xxx
#FDT /dtb/amlogic/meson-gxbb-p200.dtb
FDT /dtb/amlogic/meson-gxl-s905w-tx3-mini.dtb
#FDT /dtb/amlogic/meson-gxm-q200.dtb
#FDT /dtb/amlogic/meson-g12a-x96-max.dtb
#FDT /dtb/amlogic/meson-g12b-odroid-n2.dtb
APPEND root=LABEL=ROOTFS rootflags=data=writeback rw console=ttyAML0,115200n8 console=tty0 no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0
 
Basically you need to have the correct dtb for your box and the correct boot command for your box, along with the top three environment variables set.  *Everything* else needs to either be deleted or commented out.  This is a common mistake where people uncomment out what they need, but leave other lines in the file not uncommented and thus they fail to boot.  The extlinux.conf file above is directly from my TX3 mini box.  Note that if you were using a different box than a TX3 mini, you would attempt to use different dtb files until you found the one that works the best for you boxes hardware (there are a bunch of dtb files in /boot/dtb/... to try depending on your cpu architecture and hardward).
 
Next you need to copy the correct uboot for your box.  This is needed for amlogic cpus (other cpus have different uboot stuff to do).  For your TX3mini you need to copy u-boot-s905x-s912 to u-boot.ext (note I say copy not move).
 
Once you have your SD card prepared, on an Amlogic box you need to enable multiboot.  There are different ways documented to do this, but for your TX3 mini box, you should use the toothpick method.  At the back of the audio/video jack connector is a hidden reset button.  By pressing that button with a toothpick or other such pointed device you can enable multiboot.  What you need to do is have the box unpluged, have your prepared sd card inserted, then press and hold the button while inserting the power connector.  Then after a bit of time you can release the button.  (I don't know exactly how long you need to hold the button after power is applied, but if it doesn't work the first time try again holding for longer or shorter times).
 
You should now be booting into armbian/linux.
 
If you want at this point, you can copy the installation to emmc (assuming your box has emmc).  You do this by running the appropriate shell script in /root, which for your case is /root/install-aml.sh.  Note that it is recommended that you make a backup of emmc first (use the ddbr tool that should be installed on your sd card).  Also be prepared if anything goes horribly wrong with your emmc install to reinstall the armbian firmware using the Amlogic USB Burning Tool to unbrick your device.  It is pretty easy to find TX3mini android firmwares on the internet and you can generally recover a bricked box using the Amlogic tool and an original firmware file.
 
Finally, I have written this from memory and haven't been actually doing these steps as I am writing, so there might be something I forgot to say, so I make no promises that this is completely accurate, but I think it is.
 
Also, don't expect that all parts of your TX3mini box will work.  You should have a working boot, working wired ethernet and working hdmi.  Don't expect things like wifi, bluetooth, infrared remote, box display to work.  The experimental armbian for these boxes is enough to get a basic server running and a light graphical display, but don't expect full functionality.
 

Given that you do have general linux knowledge and rpi familiarity, here are my comments on your requests.
I have 4 TX3 mini's three of which I run armbian on and one that I use the original android on.  I will mention that just because a box is labeled TX3 mini, doesn't mean the internals are the same.  The manufactures put identical external branding on boards that may be significantly different.  For example all TX3 minis claim they have emmc storage in them.  But only two of my TX3 minis have emmc storage, the other two come with nand storage (cheaper to manufacture that way).  Since mainline linux doesn't support nand I can only install armbian on internal storage on two of my boxes.
 
From the above linked post you need to download an image file from any of the download locations.  The file you are looking for is the arm-64 version from October 14th 2020.  These are the last versions from balbes150 to support Amlogic cpus.  So be warned that when and if you get this running on your TX3 mini box, there is currently no path to get anything newer than this Oct 14 build with 5.9.0 kernel.  You will get updates from your chosen distribution (debian or ubuntu) just no kernel updates, unless someone else in the community picks up the ball and begins building/maintaining amlogic kernels.
 
In the downloads directory you will find builds for debian (buster and bullseye) and ubuntu (bionic and focal), along with both a desktop and non-desktop version of each.
 
Once you download your chosen build (for example  https://users.armbian.com/balbes150/arm-64/Armbian_20.10_Arm-64_focal_current_5.9.0.img.xz - ubuntu focal non-desktop build)
You need to burn the image to an SD card.  Generally balenaEtcher is recommended (however I have only ever used dd on linux to create my sd cards, so I have no familiarity with that tool)
 
Once you have the SD card with your chosen build, then you need to edit the boot configuration file on the SD card.  In the BOOT partition of the SD card there will be a file /boot/extlinux/extlinux.conf, that you need to edit. (In earlier builds this was done in the /boot/uEnv.txt file, so a lot of comments in these threads talk about that file, but in the latest builds it was changed to the extlinux.conf file)
 
Your extlinux.conf file should look like:
LABEL Armbian
LINUX /zImage
INITRD /uInitrd
# aml s9xxx
#FDT /dtb/amlogic/meson-gxbb-p200.dtb
FDT /dtb/amlogic/meson-gxl-s905w-tx3-mini.dtb
#FDT /dtb/amlogic/meson-gxm-q200.dtb
#FDT /dtb/amlogic/meson-g12a-x96-max.dtb
#FDT /dtb/amlogic/meson-g12b-odroid-n2.dtb
APPEND root=LABEL=ROOTFS rootflags=data=writeback rw console=ttyAML0,115200n8 console=tty0 no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0
 
Basically you need to have the correct dtb for your box and the correct boot command for your box, along with the top three environment variables set.  *Everything* else needs to either be deleted or commented out.  This is a common mistake where people uncomment out what they need, but leave other lines in the file not uncommented and thus they fail to boot.  The extlinux.conf file above is directly from my TX3 mini box.  Note that if you were using a different box than a TX3 mini, you would attempt to use different dtb files until you found the one that works the best for you boxes hardware (there are a bunch of dtb files in /boot/dtb/... to try depending on your cpu architecture and hardward).
 
Next you need to copy the correct uboot for your box.  This is needed for amlogic cpus (other cpus have different uboot stuff to do).  For your TX3mini you need to copy u-boot-s905x-s912 to u-boot.ext (note I say copy not move).
 
Once you have your SD card prepared, on an Amlogic box you need to enable multiboot.  There are different ways documented to do this, but for your TX3 mini box, you should use the toothpick method.  At the back of the audio/video jack connector is a hidden reset button.  By pressing that button with a toothpick or other such pointed device you can enable multiboot.  What you need to do is have the box unpluged, have your prepared sd card inserted, then press and hold the button while inserting the power connector.  Then after a bit of time you can release the button.  (I don't know exactly how long you need to hold the button after power is applied, but if it doesn't work the first time try again holding for longer or shorter times).
 
You should now be booting into armbian/linux.
 
If you want at this point, you can copy the installation to emmc (assuming your box has emmc).  You do this by running the appropriate shell script in /root, which for your case is /root/install-aml.sh.  Note that it is recommended that you make a backup of emmc first (use the ddbr tool that should be installed on your sd card).  Also be prepared if anything goes horribly wrong with your emmc install to reinstall the armbian firmware using the Amlogic USB Burning Tool to unbrick your device.  It is pretty easy to find TX3mini android firmwares on the internet and you can generally recover a bricked box using the Amlogic tool and an original firmware file.
 
Finally, I have written this from memory and haven't been actually doing these steps as I am writing, so there might be something I forgot to say, so I make no promises that this is completely accurate, but I think it is.
 
Also, don't expect that all parts of your TX3mini box will work.  You should have a working boot, working wired ethernet and working hdmi.  Don't expect things like wifi, bluetooth, infrared remote, box display to work.  The experimental armbian for these boxes is enough to get a basic server running and a light graphical display, but don't expect full functionality.