Infrastructure needed for releasing new kernels for Armbian for TV Boxes

[SteeMan]

I am starting a new thread as this discussion doesn't belong in the "Single Armbian image for RK + AML + AW" thread.

 

The end user need is that users (I think this is especially true of TV box users) think of Armbian for TV boxes like a standard linux distribution.  What this means is that they expect to receive security updates and critical bug fixes.  They are after all trying to run home servers and desktops on this platform.  And for the most part they get these fixes from the upstream distributions (ubuntu or debian).  However they don't get fixes for the linux kernel.  The question "how do I get kernel updates?" gets asked quite frequently in the TV box sub-forum (and if users aren't asking that question they probably assume they are getting updates through apt and don't realize they are not, or don't care at all about security).

 

@balbes150 has been working on building linux-image .deb files for the TV box builds, and I think with today's patches he has that working (i've looked at the code, but haven't tested that yet).  He has also been experimenting with deploying these kernel images via apt.armbian.com.  As was just discussed in IRC @igor correctly points out that the Armbian TV box work is a fork of Armbian and not supported.  But if we are using armbian infrastructure to deploy TV box kernel builds that line is certainly blurred.

 

There are a whole lot of release management questions and support issues that need to be worked out before this is all going to work smoothly.   And I think it is better for this to be planned and discussed so that everyone agrees to the strategy and supports it.

 

At the end of the day, my personal desire is to be able to install an "Armbian TV box release" of for example Ubuntu 18.04 on an LTS kernel (i.e. 5.4) and to have apt install all security and critical bug fixes for both the kernel and other packages for a couple of years without giving the box much thought (like I would with any other server linux distribution) - the fact that I want to do this (and hopefully can someday) on a sub $50 box that originally ran android is the incredible value that this project brings to the world.

 

So how should we deploy kernel images for Armbian TV Box builds?

 

 

[jock]

Speaking personally, my efforts in supporting tvboxes in armbian basically starts from treating them like other SBCs. From my point of view they are just boards like any other.

This is not entirely true because SBCs have specifications, the components are always the same or at least compatible, and they usually received some quality assurance - with some clamorous exceptions. Tv boxes wildy change hardware for the same commercially named product, which makes supporting them a nightname. But forgetting for a moment the confusion around tv boxes hardware, what you ask is not so far away in my opinion, and does not require changes to armbian ecosystem.

On the contrary: it requires changes to the user expectation. The user expects that she burns the image on a sdcard, put the sdcard in the box and everything just works.

Currently for many images proposed in this forum section, it is so. It just works, but has its constraints: the system lives outside the armbian ecosystem, so don't expect to get the all the armbian ecosystem gifts and goodies, kernel updates on top of that.

 

Technically speaking, armbian puts together several parts which are expected to work with each other. The focus is on mainline u-boot and kernels, and proprietary blobs and kernels are kept as last resource.

 

To make tv box images work out of the box, you have to sacrifice the first step of openness: you need to exploit the proprietary bootloader already installed on your tvbox, specifically u-boot. Proprietary bootloades wants proprietary ways to load the kernel, device tree binary, root filesystems, and so on... So it happens that when you upgrade the kernel someone should take care of converting the kernel and other parts to make them compatible with the proprietary bootloader. But should armbian people take care about the proprietary u-boot installed on your tv box? I would say no, they absolutely have not to. And that is even more true if you think that mainline u-boot just flattens all those differences between proprietary software, so why keep using the proprietary bootloader?

 

My personal approach is draconian and requires a bit more work for the user: first step is erase your tvbox internal memory. After this, the tvbox ceases from being a tvbox and turns it into an SBC with internal flash memory. Without the constraint of the proprietary bootloader all the updates can be supplied - kernel updates included - without any change to the existing armbian code and ecosystem. You will notice that also the standard armbian-config tool will be able to install the system on the internal flash without requiring special scripts or procedures.

 

In my opinion this is the way to go if you don't just want toy installations on tv boxes.

[hexdump]

@jock - that approach with erasing the emmc might work quite well for some boxes, but not for others: i have an rk3318 box where i was not able to get mainline u-boot+atf running at all and was relying on the first stage of the original bootloader ... there are allwinner boxes where mainline u-boot is not able to get the memory timing right - the only option there is to build a hacked non-redistributable u-boot using an allwinner blob and on amlogic it is even more complex: here u-boot uses binary blobs for the memory timing etc. which are often specific to a certain box, so that you'll have to first extract the original boot blocks from the box, extract those sections from it and and build a mainline u-boot with them following the for sure not trivial build procedure for the amlogic u-boot - it can be done if one is used to doing such things but i think it will fail as a generic solution for everyone ...

 

best wishes - hexdump

[balbes150]

12 hours ago, jock said:

Speaking personally, my efforts in supporting tvboxes in armbian basically starts from treating them like other SBCs. From my point of view they are just boards like any other.

This is not entirely true because SBCs have specifications, the components are always the same or at least compatible, and they usually received some quality assurance - with some clamorous exceptions. Tv boxes wildy change hardware for the same commercially named product, which makes supporting them a nightname. But forgetting for a moment the confusion around tv boxes hardware, what you ask is not so far away in my opinion, and does not require changes to armbian ecosystem.

On the contrary: it requires changes to the user expectation. The user expects that she burns the image on a sdcard, put the sdcard in the box and everything just works.

Currently for many images proposed in this forum section, it is so. It just works, but has its constraints: the system lives outside the armbian ecosystem, so don't expect to get the all the armbian ecosystem gifts and goodies, kernel updates on top of that.

 

Technically speaking, armbian puts together several parts which are expected to work with each other. The focus is on mainline u-boot and kernels, and proprietary blobs and kernels are kept as last resource.

 

To make tv box images work out of the box, you have to sacrifice the first step of openness: you need to exploit the proprietary bootloader already installed on your tvbox, specifically u-boot. Proprietary bootloades wants proprietary ways to load the kernel, device tree binary, root filesystems, and so on... So it happens that when you upgrade the kernel someone should take care of converting the kernel and other parts to make them compatible with the proprietary bootloader. But should armbian people take care about the proprietary u-boot installed on your tv box? I would say no, they absolutely have not to. And that is even more true if you think that mainline u-boot just flattens all those differences between proprietary software, so why keep using the proprietary bootloader?

 

My personal approach is draconian and requires a bit more work for the user: first step is erase your tvbox internal memory. After this, the tvbox ceases from being a tvbox and turns it into an SBC with internal flash memory. Without the constraint of the proprietary bootloader all the updates can be supplied - kernel updates included - without any change to the existing armbian code and ecosystem. You will notice that also the standard armbian-config tool will be able to install the system on the internal flash without requiring special scripts or procedures.

 

In my opinion this is the way to go if you don't just want toy installations on tv boxes.

I will not waste time on a detailed description, but almost everything written is incorrect and erroneous.

 

 

 

[jock]

@hexdump

But that's exactly the point I want to highlight: those little differences and customizations of some unlucky boards make thinking about a framework hard and maintaining it even harder.

 

[fabiobassa]

@balbes150
followed you in my first approach to run "linux" on an old amlogic 805 with only 512 ( 384... ) mega of ram
and the following you in the project of "one armbian for different platforms"

But this answer
 

Quote

I will not waste time on a detailed description, but almost everything written is incorrect and erroneous.

leaves me a bit puzzled. 
Nobody here is wasting time or wanting others waste time, but some form of explication of this arguments could be usefull

 

[xlogik]

Hi Guys,

I'm no developer but I figured is throw a couple ideas out there!

Would it be possible to retool this Android based installer to Install Linux?

https://github.com/amarullz/AROMA-Installer it maybe something worth looking into.

It would allow the Dev to release one installer and give the user a straight forward way of installing updates/upgrades. (See XDA Link below)

https://forum.xda-developers.com/showthread.php?t=1461712

 

It may also be possible to write a USB/SD boot script that scans the android file system during boot-up and downloads the necessary files to the

USB/SD and then continues the installation via a "net-install".  Any additional updates/upgrades like the kernel (if needed) would have to be pulled from the internet via a script pointing to the vendor's proprietary blobs.

Edited April 10, 2020 by xlogik

[xlogik]

On 4/4/2020 at 6:59 PM, jock said:

Speaking personally, my efforts in supporting tvboxes in armbian basically starts from treating them like other SBCs. From my point of view they are just boards like any other.

This is not entirely true because SBCs have specifications, the components are always the same or at least compatible, and they usually received some quality assurance - with some clamorous exceptions. Tv boxes wildy change hardware for the same commercially named product, which makes supporting them a nightname. But forgetting for a moment the confusion around tv boxes hardware, what you ask is not so far away in my opinion, and does not require changes to armbian ecosystem.

On the contrary: it requires changes to the user expectation. The user expects that she burns the image on a sdcard, put the sdcard in the box and everything just works.

Currently for many images proposed in this forum section, it is so. It just works, but has its constraints: the system lives outside the armbian ecosystem, so don't expect to get the all the armbian ecosystem gifts and goodies, kernel updates on top of that.

 

Technically speaking, armbian puts together several parts which are expected to work with each other. The focus is on mainline u-boot and kernels, and proprietary blobs and kernels are kept as last resource.

 

To make tv box images work out of the box, you have to sacrifice the first step of openness: you need to exploit the proprietary bootloader already installed on your tvbox, specifically u-boot. Proprietary bootloades wants proprietary ways to load the kernel, device tree binary, root filesystems, and so on... So it happens that when you upgrade the kernel someone should take care of converting the kernel and other parts to make them compatible with the proprietary bootloader. But should armbian people take care about the proprietary u-boot installed on your tv box? I would say no, they absolutely have not to. And that is even more true if you think that mainline u-boot just flattens all those differences between proprietary software, so why keep using the proprietary bootloader?

 

My personal approach is draconian and requires a bit more work for the user: first step is erase your tvbox internal memory. After this, the tvbox ceases from being a tvbox and turns it into an SBC with internal flash memory. Without the constraint of the proprietary bootloader all the updates can be supplied - kernel updates included - without any change to the existing armbian code and ecosystem. You will notice that also the standard armbian-config tool will be able to install the system on the internal flash without requiring special scripts or procedures.

 

In my opinion this is the way to go if you don't just want toy installations on tv boxes.

 

Jock,

Would the "draconian" method work with a T95max+ an Amlogic S905X3 device? If so what steps are needed?

[Igor]

On 4/4/2020 at 6:08 PM, SteeMan said:

As was just discussed in IRC @igor correctly points out that the Armbian TV box work is a fork of Armbian and not supported.  But if we are using armbian infrastructure to deploy TV box kernel builds that line is certainly blurred.

It is fine to use technical resources - they are dirt cheap compared to our time, but you can't hook on "armbian" if anything doesn't work or if you want support / ask questions. Official Armbian or unofficial: https://github.com/armbian/build#support

 

We also have boards that we don't support even images exists and you can build an image. I agree that the line is blurred but from my POW the only concern is lower quality of support on the TV boxes side since hacking advance development - not changing boot loaders, which prevents making standards.

 

We have too many boards and too little time.

 

Anyway, support for free software is never granted, so I don't know why we are making this difference important? Sometimes users ideas, due to not knowing how things are, are translated to projects worth millions and which we will certainly just ignore. Which is why we pointed out what we consider under https://docs.armbian.com/#what-is-supported

 

Branches should come together at some point, to lower maintenance costs. We tried once, but its insane lot of work. Perhaps once we merge more families together, this will finally become possible. Maintenance is still the biggest cost on those projects. And its those few developers private cost!

 

On 4/5/2020 at 12:59 AM, jock said:

SBCs have specifications, the components are always the same or at least compatible, and they usually received some quality assurance - with some clamorous exceptions.

 

This and serious lack of resources - we don't accept new boards because:

 

- there are just a few people that have fun playing with them. Fun is absolutely needed.

- we can't hire help. End user donations only covers servers electricity.

- i have no desire to do anything with those boxes but I am fine to share technical resources - Repository, perhaps once even download if things are made in some automated fashion and doesn't put a pressure to the main stream or any maintenance resource.

 

5 hours ago, xlogik said:

I'm no developer but I figured is throw a couple ideas out there!

First thing to do when installing a Linux is to wipe out Android and never look back  Only thing you need here is a boot loader for which you don't have sources and vendor never updates. The rest is easy to change, but the problem is that its different and no Android tool can make this easier.

 

My 2c.

[jock]

1 hour ago, xlogik said:

 

Jock,

Would the "draconian" method work with a T95max+ an Amlogic S905X3 device? If so what steps are needed?

 

That's a question I can't answer for sure, since I don't own any S905X3 devices. My experience on amlogic is limited to S905 soc and I can confirm that the "draconian" approach works: once you erase the eMMC (or ground the clock pin of the eMMC chip), it will try boot from the sdcard.

Most probably nothing changed with later chips, since this seems to be the common behaviour among various chips and vendors too, so my answer can be "probably yes"

 

[balbes150]

7 hours ago, Igor said:

not changing boot loaders, which prevents making standards.

Consider u-boot as a BIOS on a PC and everything falls into place, you do not need to interfere with its operation. No one in the field of development of Debian|Ubuntu and other distributions for PC does not develop BIOS for PC, this is a direct task of the manufacturer, who knows all the features of their hardware. Similarly to u-boot for TV boxes, let the manufacturer deal with it, our task is to add to it the minimum means of starting any system absolutely and, if possible, installing the system in internal memory (eMMC). The main u-boot will never be able to work fully on all TV boxes.

 

7 hours ago, jock said:

Most probably nothing changed with later chips, since this seems to be the common behaviour among various chips and vendors too, so my answer can be "probably yes"

Stupid advice, kill your device and then hope that you do not have to restore it in complex steps (which can not be performed, even experienced users, not to mention ordinary users). It is not difficult to erase the u-boot, but if you try to write a wrong (not working u-boot) to eMMC, you will get a hard-to-recover brick. So my advice is never to listen to such idiotic advice and be very careful with u-boot.

[xlogik]

2 hours ago, balbes150 said:

Consider u-boot as a BIOS on a PC and everything falls into place, you do not need to interfere with its operation. No one in the field of development of Debian|Ubuntu and other distributions for PC does not develop BIOS for PC, this is a direct task of the manufacturer, who knows all the features of their hardware. Similarly to u-boot for TV boxes, let the manufacturer deal with it, our task is to add to it the minimum means of starting any system absolutely and, if possible, installing the system in internal memory (eMMC). The main u-boot will never be able to work fully on all TV boxes.

 

Stupid advice, kill your device and then hope that you do not have to restore it in complex steps (which can not be performed, even experienced users, not to mention ordinary users). It is not difficult to erase the u-boot, but if you try to write a wrong (not working u-boot) to eMMC, you will get a hard-to-recover brick. So my advice is never to listen to such idiotic advice and be very careful with u-boot.

Okay,

Considering Balbes150 is a well known and has various Armbian builds on the forum, 

I figure I'd play it safe and follow one of the guides posted. 

 

Thanks Fellas!

[jock]

46 minutes ago, xlogik said:

Okay,

Considering Balbes150 is a well known and has various Armbian builds on the forum, 

I figure I'd play it safe and follow one of the guides posted. 

 

Thanks Fellas!

Your board, your rules

[xlogik]

2 hours ago, jock said:

Your board, your rules

This is true and rules made to be broken but only after carefully plotting the most efficient way of not getting burned! 

Since I'm fairly new to how this ecosystem is configured, I figured instead of wasting cash on a possible paper weight I might as well,

take the long route learn inner workings and then take the calculated risk.... I do see that you are very active on the forum also,

so I'm sure you to will be playing a unbeknownst role in my understanding of Armbian on Android based Tv Boxes !

 

[Nuno Cruz]

I would like to get more information about this. My linux skills aren't good as a dotnet dev, I have a spare tv box (s10 s912), and unfortunately I was not able to install just copying one of the provide dtb files, (well it boot with khadas vim2 but PCU temperature is to high for me 60degr).
I believe there's many beginners around that could do more steps, like unpack the original firmware, copy images from running android or get device firmware information or files and use this to make needed customization due different hardware, devices etc. 
The scenario of just the right dtb file would work maybe 90% of times is good enough, but still optimist and the problem is when it doesn't work, we end up without guidance. I'm not sure how much of the queries in theses forum are about people stuck when the dtb, device support is not enough to get armbian running well, but it could mininize a place with more details, alternatives to help when the easy path doesn't work. 
   

[lu4t]

First thing to do when installing a Linux is to wipe out Android and never look back  Only thing you need here is a boot loader for which you don't have sources and vendor never updates. The rest is easy to change, but the problem is that its different and no Android tool can make this easier.
 
My 2c.

Before wiping Android, maybe it’s worth taking advantage of the dtbs embedded.
I know this is not a politically correct topic on this forum, but I believe that if we take the approach Android has for dealing with multiple DTs at boot time is interesting:
https://source.android.com/devices/architecture/dto/multiple

2 cents more


Enviado desde mi iPhone utilizando Tapatalk

[Igor]

4 hours ago, lu4t said:

maybe it’s worth taking advantage of the dtbs embedded.

Yeah. Let's assume we already have them 

[lu4t]

19 hours ago, Igor said:

Yeah. Let's assume we already have them 

So, if we can reuse dtbs embedded on the native Android version, I guess we could think of mix and matching and produce a "generic" DT for Armbian. Again, I am not saying this is a simple task, I am just saying that Technically speaking if feasible and might be something that would facilitate massive adoption of Armbian.

I am looking at this as a way to push adoption, which at the end will return this effort to the community. It's true that the ammount of work on the TO DO must be overwhealming, depending on the criteria followed to assign priorities to each pending task, this could be a nice to have feature in the future...

[SteeMan]

40 minutes ago, lu4t said:

So, if we can reuse dtbs embedded on the native Android version, I guess we could think of mix and matching and produce a "generic" DT for Armbian. Again, I am not saying this is a simple task, I am just saying that Technically speaking if feasible and might be something that would facilitate massive adoption of Armbian.

I am looking at this as a way to push adoption, which at the end will return this effort to the community. It's true that the ammount of work on the TO DO must be overwhealming, depending on the criteria followed to assign priorities to each pending task, this could be a nice to have feature in the future...

Are you willing to take on this task and do this work?  I would say it is clear that the current maintainers here do not see this as a good investment of their time.  This is open source, and the best way to get something you need in open source is to step up and do the work and then contribute it back to the community.

 

A couple of additional thoughts on your request:

1) From what I have observed and know of the state of android on these TV boxes is that the dtb's from android are fairly worthless in helping getting things working under mainline kernels with armbian.  Everyone assumes this is not the case, but I haven't seen anything to indicate otherwise.  The gulf between ancient android based kernels and drivers (without source code in most cases) and modern mainline kernels is vast.

2) You are making an assumption that "pushing adoption" is a good thing.  The way things currently stand, there are not sufficient people on these forums with the desire and knowledge to provide end user support for the existing new users much less a larger quantity of new users in the future.  What is needed now is people willing to answer the basic questions that new users post here, and to work on high quality documentation and tutorials (and maintain them as things change), so that the core developers can be relieved of the burden of providing this information so that they can spend more time moving the project forward.

[lu4t]

6 minutes ago, SteeMan said:

Are you willing to take on this task and do this work?  I would say it is clear that the current maintainers here do not see this as a good investment of their time.  This is open source, and the best way to get something you need in open source is to step up and do the work and then contribute it back to the community.

I am willing to, and will be happy to share it with the commutity. 100% agree with you on the OS principles. As the say goes: I will put my money where my mouth is

 

8 minutes ago, SteeMan said:

A couple of additional thoughts on your request:
 

I am not requesting anything; I was just sharing my interest on a new work track, that I will personally join, just in case anyone shares same interests. That said: 100% agreed with your 2 comments too.

[Nuno Cruz]

2 hours ago, lu4t said:

So, if we can reuse dtbs embedded on the native Android version, I guess we could think of mix and matching and produce a "generic" DT for Armbian. Again, I am not saying this is a simple task, I am just saying that Technically speaking if feasible and might be something that would facilitate massive adoption of Armbian.

I am looking at this as a way to push adoption, which at the end will return this effort to the community. It's true that the ammount of work on the TO DO must be overwhealming, depending on the criteria followed to assign priorities to each pending task, this could be a nice to have feature in the future...

 

I already tried this, doesn't work, seems to be incompatible with the kernel, and decompile the dtb to information seems very hard to know what can be used. maybe a database with know nodes on original android that can be transformed to compatible armbian kernel ones. I'm a beginner I endup quiting to compile a working dtb for me tv box. I had one booting then I found the CPU on 60dgr, to much pain to me. 

[balbes150]

On 4/12/2020 at 7:15 PM, lu4t said:

So, if we can reuse dtbs embedded on the native Android version,

1. This is not possible in principle, because Android uses a kernel that is not compatible with normal Linux.

2. Using multi-DTB, a useless option that is only needed for TV box manufacturers (which would create problems for firmware theft). It is useless and creates unnecessary problems and difficulties for normal Linux.

3. Creating a universal DTB is a waste of time, it will not work properly.

 

 

[lu4t]

7 hours ago, balbes150 said:

1. This is not possible in principle, because Android uses a kernel that is not compatible with normal Linux.

2. Using multi-DTB, a useless option that is only needed for TV box manufacturers (which would create problems for firmware theft). It is useless and creates unnecessary problems and difficulties for normal Linux.

3. Creating a universal DTB is a waste of time, it will not work properly.

 

 

 

May be u"niversal DTB", or "multi-DTB," are not the right terms. The fact is, using a way to abstract the kernel (whichever it is) from dtbs, would isolate the complexity of each other.

Some distros (Android, Raspbian,...) use the term "Device Tree Overlay," which I guess is a better term, more descriptive than the former two. The idea behind it is esencially finding a way to isolate the kernel plumbing off the hw.

My suggestion is esencialy copying this strategy. Unless armbian kernel is way different on its design (I bet it's not the case) do not see why it wont work.

 

[SteeMan]

12 minutes ago, lu4t said:

 

May be u"niversal DTB", or "multi-DTB," are not the right terms. The fact is, using a way to abstract the kernel (whichever it is) from dtbs, would isolate the complexity of each other.

Some distros (Android, Raspbian,...) use the term "Device Tree Overlay," which I guess is a better term, more descriptive than the former two. The idea behind it is esencially finding a way to isolate the kernel plumbing off the hw.

My suggestion is esencialy copying this strategy. Unless armbian kernel is way different on its design (I bet it's not the case) do not see why it wont work.

 

What you describe can theoretically be accomplished today through the use of device tree include files (.dtsi).  And if you look at the source code, you will see that this mechanism is already used extensively to overlay board specific items on top of base CPU specifications.  Adding an additional layer on top doesn't provide additional functionality that couldn't be accomplished today.

 

Howerver, the scope of the problem is much bigger in the armbian world than in the Android and Raspbian world.  In both Android and Raspbian the base hardware is more constrained (i.e. the models of Raspberry Pi are a relatively small number with a small set of well known cpus, etc).  In the TV box world of armbian, you have three different primary CPU manufacturers (Amlogic, Rockchip, Allwinner) each with a wide variety of different cpu architectures.  Then you have many, many manufacturers that are putting together boards with all manner of third party chips for memory, nand, wifi, ethernet, bluetooth (and for most of them there is no source code available).  And since the goal of these manufacturers is to produce the cheapest tv box possible, they are likely using components that are inexpensive and thus not well supported.  Combine those hundreds of different devices with the fact that there is no upstream support from the board manufacturers and component makers to support their products (not even providing source code for others to do it) and you have a massive undertaking.  Then consider that there are only a handful of developers within armbian capable of working at this level of the code and you have a problem that isn't solvable today.

 

[lu4t]

1 minute ago, SteeMan said:

What you describe can theoretically be accomplished today through the use of device tree include files (.dtsi).  And if you look at the source code, you will see that this mechanism is already used extensively to overlay board specific items on top of base CPU specifications.  Adding an additional layer on top doesn't provide additional functionality that couldn't be accomplished today.

 

Howerver, the scope of the problem is much bigger in the armbian world than in the Android and Raspbian world.  In both Android and Raspbian the base hardware is more constrained (i.e. the models of Raspberry Pi are a relatively small number with a small set of well known cpus, etc).  In the TV box world of armbian, you have three different primary CPU manufacturers (Amlogic, Rockchip, Allwinner) each with a wide variety of different cpu architectures.  Then you have many, many manufacturers that are putting together boards with all manner of third party chips for memory, nand, wifi, ethernet, bluetooth (and for most of them there is no source code available).  And since the goal of these manufacturers is to produce the cheapest tv box possible, they are likely using components that are inexpensive and thus not well supported.  Combine those hundreds of different devices with the fact that there is no upstream support from the board manufacturers and component makers to support their products (not even providing source code for others to do it) and you have a massive undertaking.  Then consider that there are only a handful of developers within armbian capable of working at this level of the code and you have a problem that isn't solvable today.

 

I understand the complexity, and the fact that there's a huge number of combinations.... I am not saying this is just a copy-paste exercise. As many Leaders on the forum already said: chances of this working are almost none.

The first comment I did about this topic was just saying:

1.- let's reuse Android dtbs, which are already included on the Android boxes.

2.- Even though it's not possible to reuse those dtbs out of the box, cause they are compiled for a different kernel, we should be able to decompile them to dts. (this dts is the hw manufacturer description of their own hw; and for boxes manufactures, this files are a description of the mix and match exercise they did to build and compile Android for their boxes).

3.- If we could use a DT Overlay approach on Armbian (which is already existing today -sort of-, but we don't call it that way yet), we could then call the dts compiled into dtbs for Armbian Kernel, and that can be consumed by Armbian natively (through the DT Overlay -same as Raspbian does-).

Again, this is just an idea which I believe could make life easier and drive adoption. There's work to do, I am willing to work os this, and happy to join forces with anyone who believes on this vision to push it. 

[SteeMan]

2 hours ago, lu4t said:

1.- let's reuse Android dtbs, which are already included on the Android boxes.

2.- Even though it's not possible to reuse those dtbs out of the box, cause they are compiled for a different kernel, we should be able to decompile them to dts. (this dts is the hw manufacturer description of their own hw; and for boxes manufactures, this files are a description of the mix and match exercise they did to build and compile Android for their boxes).

I think this is the core of the misunderstanding of the complexity of the issue.  Both of your points 1 and 2 are based on a false understanding of the environment.

The underlying problem with your understanding of the problem is your statement "this dts is the hw manufacturer description of their own hw".  It is much more complex than that in reality.  The dts is essentially descriptive code that ties the hw, driver, and kernel together.  Any of those three things changing will have an impact on the contents of the dts.  So even though the hardware is the same, the driver software and kernels are not.  So the dts needs to be modified to correspond to the expectations of the target driver software and target kernel.  Unfortunately often the original driver software source code isn't available and android kernels are significantly different than mainline kernels.  So usually there isn't any use in having the original android dts in trying to support a particular box under armbian with mainline kernels.

[Nuno Cruz]

I think that these tv boxes have many diferences, sometimes one model has 1-2gb ddr3 other has 3gb ddr4, cpus, ethernet, wifi, hdmi etc.  can also require a specific dtb configurations and drivers to work properly.  
I have a s10 tv box with s912 3gb ddr4, and for a weeks I'm trying to run this, I was able to install armbian using the khadas vim2 dtb, but is missing something from the original firmware to have a reasonable linux server. on android with graphic interface GPU working it run at 30-40degrs, with vim2 dtb it goes to 75 with the minimal server running, no GUI. 
We should have a way to discover and produce a build and/or dtb, and is not only for optimization, is beacuse some people don't find a working dtb to their, in my case I have but is not enough. the optimization on this box was based on android and some information may be extract be do some reverse engeering. I' not asking to do this and distribute the artifact online, is missing some guidance to beginnners to do the bit on their on boxes.