SteeMan

You should be following the instructions in this thread:
https://forum.armbian.com/topic/26978-csc-armbian-for-rk3318rk3328-tv-box-boards
 
And if you have any questions or issues you should post them there.

@MrK I think you owe @Gunjan Gupta an apology.  There is no need for such language when people are volunteering their time and efforts, or ever for that matter.
 
@MrK you are in the wrong forum.  Changes such as you are proposing should be done at the Linux kernel level.
 
@MrK I am not sure the following comments are worth posting. But if it helps you, I would recommend that you learn to work with others in a team environment.  You will get more things done and with better results.  If you had been working for me I would have fired you for behaving this way. It is just too disruptive.

GPT is something the Armbian build framwork supports, not currently the default, but here is a list of boards that use it:
grep -i gpt *
armsom-sige7.csc:IMAGE_PARTITION_TABLE="gpt"
armsom-w3.csc:IMAGE_PARTITION_TABLE="gpt"
bananapir2pro.csc:IMAGE_PARTITION_TABLE="gpt"
fxblox-rk1.wip:IMAGE_PARTITION_TABLE="gpt"
hinlink-h28k.csc:IMAGE_PARTITION_TABLE="gpt"
hinlink-h88k.csc:IMAGE_PARTITION_TABLE="gpt"
hinlink-ht2.csc:IMAGE_PARTITION_TABLE="gpt"
indiedroid-nova.csc:declare -g IMAGE_PARTITION_TABLE="gpt"
jp-tvbox-3566.tvb:IMAGE_PARTITION_TABLE="gpt"
khadas-edge2.conf:declare -g IMAGE_PARTITION_TABLE="gpt"
mangopi-m28k.csc:IMAGE_PARTITION_TABLE="gpt"
mixtile-blade3.wip:declare -g IMAGE_PARTITION_TABLE="gpt"
nanopct6.wip:IMAGE_PARTITION_TABLE="gpt"
nanopi-r5c.csc:IMAGE_PARTITION_TABLE="gpt"
nanopi-r5s.wip:IMAGE_PARTITION_TABLE="gpt"
nanopi-r6s.conf:IMAGE_PARTITION_TABLE="gpt"
odroidm1.conf:IMAGE_PARTITION_TABLE="gpt"
orangepi3b.csc:IMAGE_PARTITION_TABLE="gpt"
orangepi5.conf:IMAGE_PARTITION_TABLE="gpt"
orangepi5-plus.conf:IMAGE_PARTITION_TABLE="gpt"
panther-x2.csc:IMAGE_PARTITION_TABLE="gpt"
quartz64a.csc:IMAGE_PARTITION_TABLE="gpt"
quartz64b.csc:IMAGE_PARTITION_TABLE="gpt"
radxa-e25.wip:IMAGE_PARTITION_TABLE="gpt"
rock-3a.conf:IMAGE_PARTITION_TABLE="gpt"
rock-5a.wip:IMAGE_PARTITION_TABLE="gpt"
rock-5b.conf:IMAGE_PARTITION_TABLE="gpt"
rock-5-cmio.csc:IMAGE_PARTITION_TABLE="gpt"
station-m2.csc:IMAGE_PARTITION_TABLE="gpt"
station-m3.csc:IMAGE_PARTITION_TABLE="gpt"
station-p2.csc:IMAGE_PARTITION_TABLE="gpt"
xiaomi-elish.conf:IMAGE_PARTITION_TABLE="gpt"

Moved to Community Maintained Allwinner.
 
@krrmbn Note that this is not an Armbian supported board.  It is community maintained.

I just want to add a few comments to this whole dtb overlay discussion.
 
First I want to thank all of you involved in this discussion.  You all have different view points and I think are tackling a very difficult problem to which there is no perfect solution.  What comes out of this discussion should be applied to the other soc families as well, as they all suffer from some form of this issue as there is no standard in place that works for all use cases well.  From what I have seen, good minds are thinking this through and I expect a good result to follow.
 
The reason I am commenting at all, is because in my role as forum moderator, the basic question: "How do I enable feature x on my board" is one of, if not the most commonly asked question by end users of the forum.  And when the answer is 'just write a dtb overlay', you have lost 95% of those users as they do not have the skills/knowledge to do that.  The status of the dtb overlay's across Armbian supported and community maintained boards is poor.  There is no standardization from family to family or board to board.  And no testing of what does exist to ensure that it works.  Now I'm not saying that all of this needs to be solved in what comes out of this design discussion.  I'm just saying from my perspective as a moderator that this is an area that can use some attention, and in doing so, please try to make the end result usable by the typical end user of an sbc, trying to do common things.  I realize also that I'm saying this when I only use these boards as servers and don't personally need any of the functionality the overlays provide.  But as a forum moderator, I see the mismatch between what is being done and some common use cases that end users are looking for.

I just want to add a few comments to this whole dtb overlay discussion.
 
First I want to thank all of you involved in this discussion.  You all have different view points and I think are tackling a very difficult problem to which there is no perfect solution.  What comes out of this discussion should be applied to the other soc families as well, as they all suffer from some form of this issue as there is no standard in place that works for all use cases well.  From what I have seen, good minds are thinking this through and I expect a good result to follow.
 
The reason I am commenting at all, is because in my role as forum moderator, the basic question: "How do I enable feature x on my board" is one of, if not the most commonly asked question by end users of the forum.  And when the answer is 'just write a dtb overlay', you have lost 95% of those users as they do not have the skills/knowledge to do that.  The status of the dtb overlay's across Armbian supported and community maintained boards is poor.  There is no standardization from family to family or board to board.  And no testing of what does exist to ensure that it works.  Now I'm not saying that all of this needs to be solved in what comes out of this design discussion.  I'm just saying from my perspective as a moderator that this is an area that can use some attention, and in doing so, please try to make the end result usable by the typical end user of an sbc, trying to do common things.  I realize also that I'm saying this when I only use these boards as servers and don't personally need any of the functionality the overlays provide.  But as a forum moderator, I see the mismatch between what is being done and some common use cases that end users are looking for.

here is some 2 cents comments, if you are meaning NPUs like these:
 
https://github.com/rockchip-linux/rknpu2
 
- hardware interfaces are kept as trade secrets and not published anywhere
 
1st the hardware interfaces are practically undocumented, what they provide is mostly an 'sdk' with some binary blobs
it practically means there is *no way* to use the NPU as those binary blobs in turn depend on device drivers which again are binary blobs (no source)
and there is no hardware documentation any where about the technical details, registers etc. 
if that at least those are published, one could possibly start coding something to test things on the NPU.
 
then that for things like ethos-n78
https://www.arm.com/products/silicon-ip-cpu/ethos/ethos-n78
you can find some info here
https://developer.arm.com/Processors/Ethos-N78
but that it seemed the real SOCs with that chip is no where to be seen let alone any boards found with them.
 
- IO / cpu scheduling 
 
cpu frequency scaling / governors are well documented
https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
https://docs.kernel.org/scheduler/schedutil.html
https://www.kernel.org/doc/html/latest/scheduler/
and for 'simple' ARM (or RISC V) chips, any sort of 'elaborate' scheduling are probably going to just burn more cpu cycles with little to gain.
but that nevertheless the source codes and the documentations are there so that one can try to develop your own governor if you prefer.
and that the elaborate 'advanced' schedutil governor is already there in the kernel, likely in Armbian as well.
Hence, one can proceed to improve that if one deem that the state-of-the-art currently isn't adequate.
 
and if one wants to do some manual scheduling there is the plain old "nice" command
https://www.scaler.com/topics/linux-nice/
 
----
well my thoughts, scheduling and NPU are 2 unrelated issues, it is possible to handle 'elaborate' scheduling without an NPU, this is currently the state-of-the-art from the 'lowly' ARM boards that we are running, to top tier high core count Intel Xeon / AMD Epyc processors and running all that loads ranging from amazon, google, chatgpt etc, no issues.
 
The other thing being the NPUs itself, currently many SOC IP owners, held their hardware interfaces as *trade secrets* and refused to release them.
You would need to jump that hoop to even use the NPU without any documentation, or else use their proprietary binary blob software, which won't work outside their proprietary binary blob distributions.
 
This withheld *trade secret* about the NPU is the biggest pitfall / trap to those buying those boards with those SOCs and wanting to use the NPU. you get *no support*, *no help*, *no nothing* after you buy the board which purportedly has the NPU. practically *useless*. don't even bother to try it for any 'test' 'AI' stuff, you may at best get a *binary blob demo* and that's it (and it is not anywhere close to even using it for any practical purpose, let alone scheduling).
 
And much more than that, using an NPU practically means that your neural network model must be *quantized*, if you know what that means. All those small NPU hardware normally handles like 8 bit integers, 16 bit integers or at best 16 bit floats. This practically means that you would need to spend a lot of effort to *convert* even ordinary neural networks into the *quantized* form that can be processed by the NPU, if you can't convert that it is  unusable. Even if you managed to convert that there is a risk of lost of precision, e.g. if you convert a 32 bit float down to an 8 bit int, you may practically be quantizing a number space of 4 billion numbers (actually more) to 256 quantized levels. that is the extreme of the information loss, and at the end of the day, if it even works, you may simply get *wrong* results, and again it is practically *useless*.
 

That is because this board is not supported, and you were posting in the supported boards section of the forum. 

Known Issue: https://forum.armbian.com/topic/30245-cant-boot-with-2305-or-later-builds-on-s905x2-g12a-or-s905x3-sm1
 

Also the contribute/PR process as documented in the Armbian Docs:  https://docs.armbian.com/Process_Contribute

Hi,
 
You are posting on the Armbian forum.
The images you refer to are not Armbian images.
The people of Armbian don't like their forum be polluted with non-Armbian support request. I think that is quite understandable, don't you?
 
That being said, this answer is also true for Armbian tvbox, so maybe the answer is allowed: 
 
All those tvboxes are different, even if they look the same or even have the same 'model name' from the outside.
Especially the wifi modules are a lottery. So you have to be lucky to get a standard supported wifi module. And otherwise you'll have to learn a lot, google a lot to get wifi working. That's the 'fun' of tinkering with those cheap boxes. If you want a working wifi and don't want to learn all that... you are better of buying a well supported SBC instead.
 
Some pointers that might be helpful:
decompile the dtb and look if the aml_wifi gpio's for power are the same gpios as in the DTB you use for mainline linux (sdio-pwrseq node)  sometimes it can help to lower the max-frequency property for the sdio node run ( vendev=( $( cat /sys/bus/mmc/devices/mmc2:*/{vendor,device} ) ) && echo "wifi SDIO ID: ${vendev[0]}:${vendev[1]}" )  to get the driver vendor ID and device ID. If that doesn't work, previous two points are probably not ok. (Or wifi is not on SDIO bus, but is not very likely) (alternatively) open the box, look for the wifi markings and search google for the linux driver source and compile that driver Have fun!
 

There is no such cpu.  Can you specify the cpu you have?  There are many different versions of boxes labeled tx3 mini, so you need to be specific.  Pictures of the motherboard would also be helpful.

You need to find the correct Android firmware for your device and reinstall it according to the instructions for that firmware (usually USB burning tool)

You should not advise to buy shit, they are cheaper because:
* they are made of scrap parts, that often break after very short usage (see the emmc in the rk3318 thread)
* they have no kind of warranty
* the power supply is a joke, made of cheap components and very lousy - switching power supplies are one of the thing the more they weight the better; confront with a quality 5V/2A power supply and see the difference
* the HDMI cable is crap quality, often not capable to transfer CEC or collects any kind of interference at 1080p/4K
* the case is a bit of plastic, with little to no design for heat dissipation - right now I have a rk322x board here withing its case that reaches 97°C while simply installing a package with apt...
* many sorts of limitations to keep them as cheap as possible: no sd card UHS mode, no real shutdown/suspend, USB ports have limited power: be prepared to have headaches if you try to attach something that requires just a tiny bit more power like an external hard drive.
* wifi is a lottery and clearly tells you the general quality: you can find freshly made boards with wifi chips discontinued years ago!
 
Most of all: they have absolutely no software support; if you are able to run armbian on your tv boxes it is because some people within armbian and other projects spent their time for the fun of making it.
Tv box makers don't care at all, they just need to sell their cheap shit to make some profit. Some (not all) SBC makers at least in some way provide support, but tv box makers are mostly parasitic and should not be endorsed.
 
Now that you stated that about 20 pcs of different tv boxes run armbian, may I also ask you what you did in change for that for armbian? Because tv box makers obviously did nothing for armbian, still keeping up the servers infrastructure and the general maintenance cost real money to real people, and who pays that?

@Ya_super_grafiti dts/dtb files are specific to the linux kernel.  Armbian focuses on mainline linux kernels and others out there use vendor kernels (which usually are a ported android based kernels from ancient sources).  The differences between vendor kernels and mainline linux are usually significant preventing direct reuse of a dts/dtb from one to the other.  If you know how dtb's work and have the hardware specs, you could port the dts into mainline, but that is expert level work.

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.
 
 

Just because someone (dietpi) forks Armbian, doesn't give credit to armbian, and doesn't contribute back to Armbian, doesn't mean that Armbian can then support their end users.  We have no idea what dietpi has done to their code after forking off of armbian, so we again can't help you.  Complain to those that can/should be providing you support.  We can't.  Of course you always have the option to install a genuine Armbian build.  That doesn't mean that this will get magically fixed, but at least we will not completely ignore your request.

I agree that this branding is confusing for end users.

What build are you using?  What instructions are you following? List the steps you have performed.

Armbian team have no plan/resources/budget to do this, but if someone sacrifices his time and polish this feature as expected, we will pay with respect and review the work. Every code that is sent our way is liability and that is not something we are accepting open handed. If adding this feature won't represent much burden for maintainers, we will merge it. Making PR from your side is just one part and is small if you are not going to keep it in good shape for another several months / years.
 

The same goes for half of elderly single board computers that we are keeping alive. Its only in users interest, a little in ours. We only have costs with maintaining, while HW vendors wants from you to buy new stuff ...  We already have severe problems with cost management as you expect we do everything for free, and where we receive absolutely no help from vendors or anyone. This is for us nothing but a waste of time. I hope you do understand this - maintaining is hard work and doesn't pay off in any way. And its a lot more code to maintain then people who will do it. You have to step up.

Topic moved and appropriate tag added.

Topic moved and appropriate tag added.

That would not be an armbian image then if it didn't come from official Armbian sources.  So this isn't really the place to discuss non-armbian builds.

That would not be an armbian image then if it didn't come from official Armbian sources.  So this isn't really the place to discuss non-armbian builds.

Armbian now has a community supported build target for amlogic TV Boxes (aml-s9xx-box).  You can now build your own builds directly with the Armbian build system.
 
This is now an opportunity for members of the community to move the support for amlogic TV boxes forward within the Armbian framework.  If you are not familiar with the Armbian build system check out the Armbian developer documentation.  If you have idea on how you would like to see things evolve/change please use this forum to share your thoughts and ideas and submit PRs for any code changes you would like to see.
 
I am currently testing this code against the four different amlogic based boxes I own, but would appreciate others testing as well.  Once I have completed my testing, I will be updating the FAQ amlogic install instructions with this information.