KY69

Beware that there are different hardware versions of this same box. I myself have two X96 Max boxes, with two different hardware versions, both bought just days apart from each other. It has been a few weeks since I had the chance to play with them, but from what I recall, one of them worked OOTB with Armbian 20.10 5.9.0 and the expected dtb (x96max). The other one is instead more similar to the X96 Max+. It came with an 8822CS wifi chip (same as the Max+) instead of the AP6356SA that came on the first one. The "original" version of the X96 Max does work ethernet @ Gbit speed and WiFi OOTB with the 201014 image. The second one I do not recall now if I ended up managing to use either of the (onboard) network interfaces or if I simply plugged a USB wifi dongle at the time. I had but a couple hours at most with them. I plan to play again with them soon, I will let you know more details once I have the chance to check. Bottom line, first of all check what hardware you got inside your box!

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

Today I had the pleasure of benchmarking an ARM64 server.
This server has been made available for Armbian to test native ARM64 image building.
I knew nothing about the server. Nobody told me any details.
So everything was an adventure for me to find out. I got SSH access, so my research began.

A lscpu informed me it had 32-cores all clocked at 3.3Ghz. 
 
cat /proc/cpuinfo confirmed these 32-cores
 
Checking on what kernel we're on. Ubuntu Focal 5.4.0-52-generic. 
And how much memory. 128GB RAM.

So first thing I wanted to know, how does one core perform with 7-zip benchmark?
The record I had seen until now was from the A73 cores from the Odroid N2+ clocked at 2.4Ghz. 2504MIPS decompression.
So :
taskset -c 31 7z b
 
This beats the Odroid N2+ its A73 cores clocked at 2.4Ghz. 2763 vs 2504MIPS decompression. 
This also tells me these cores do not perform as good per clock as a high performance core. 
While doing the single core benchmark I checked the sensors to know the wattage and temperature.
 
CPU power is about 20W for a single core tasks. 
Without a load the CPU consumes between 10W-15W. So in total it consumes a bit more than 20W in idle.
Temperature never went under 49C even after +5 minutes in idle. 
 
Of course, the next thing to do is an all-core 7zip benchmark. 
This gives an amazing result. Way higher than anything I had ever seen on ARM.
 
85975MIPS decompression. This is amazing.
Best I had seen was 11000MIPS of the Odroid N2+. So this server does 8 x better than the N2+. 
Tho, I must say. 7zip does bad with unequal clusers. The N2+ has a great difference in cluster frequencies. So it performs worse then expected here. 

The wattage went a lot higher, up to 110W. And the temperature rose quickly up to 75C in seconds.
 
To test the internet connection I downloaded an Armbian image multiple times. Sometimes it was as low as 3MB/s. 
Highest average speed I've seen was 12.5MB/s
 
Next test. BMW Blender render benchmark. 
Here the fastest I had ever seen was by the Khadas VIM3. That did it in 42m51s.
I haven't done this yet with the N2+ in Armbian. In Odroid's Ubuntu it was a little slower. I expect it to be a little faster than the VIM3 in Armbian Bionic. 
This is a tile based test. So every core gets its own task, until all tiles are done. 

Well, this ARM64 server did this in 8m27s. 
5 x faster compared to the Khadas VIM3. 

For this the wattage didn't go over 85W. But the temperature did rise to 83C. So it started to throttle. 

@lanefu already had done SBC-Bench on it when it was free. So this I didn't have to do myself.
http://ix.io/2Dcc
Here we see a lot. For example the CPUMiner did : 81.0kH/s 
The Odroid N2+                                                         : 14 kH/s         5.7 x less 
RK3399 does a maximum of                                     : 10.23kH/s     8 x less
Odroid C2 clocked at 1.75Ghz                                   : 4.65kH/s       17 x less

So this server clearly can move a lot of bits around. 
Now, what is this server? Ask google if nobody else tells me. "32 core ARM server 3.3Ghz"
First answer : https://www.theregister.com/2018/09/18/ampere_shipping/
That looks like it is this CPU. But still I can't find the exact name. 
2nd answer : https://www.servethehome.com/ampere-32-core-64-bit-arm-chip-x-gene-3-ip/
So this is the Ampere 32-core 64-bit from X-Gene 3 IP.

Here the wikichip : https://en.wikichip.org/wiki/apm/x-gene/apm883832-x3?fbclid=IwAR0ljCQ61DY8Zwh_VyZd0fQH43dmPUTJA-CGLiQKYqU2fWwszFm1CPjH6Zo

This supports up to 1TB RAM. 8 channels @ 2666Mhz. With a maximum memory bandwidth of 158.95 GiB/s.
42 lanes of PCIe Gen 3, with 8 controllers
– x16 or two x8/x4
– x16 or two x8/x4
– x8 or two x4
– Two x1

4 x SATA Gen 3 ports, 2 x USB2. And a TDP of 125W TDP.

For me this is just an awesome thing to behold. I use ARM for almost everything.
The NanoPi M4V2 is my main desktop computer.
It isn't as powerful as my PC, but does the task for 10 x less power consumption, while being completely silent.

But when I need a big CPU, it isn't enough.
Even the more powerful Odroid N2+ isn't powerful enough to render long, +20minutes 1440p video's for example for my Youtube channel.
So then i need to use my x86/amd64 PC. 

Today I have seen and tasted the future. 
While this doesn't use the most modern Cortex/clusters. And it is only 16nm.
So there is still a lot of room for improvements in performance and lower power consumption. 

ARM for desktop is possible, and ARM servers for big datacenters is possible(AWS). I have seen the future, I loved every second of it. 

Here benchmarks compared to my SBCs

 

Greetings, NicoD

Technically Balbes never supported the s905x3. But it is true that he is now ending support of all amlogic cpus.  I already make my own kernel builds, and since I own a few different amlogic based boxes, I have an interest in seeing support continue in some form.  I have asked balbes in another thread if he would tag his public github repositories with a tag that corresponds to his last build supporting amlogic, which then can be a starting point for continued support by the community if there is enough interest.

I totally agree with @balbes150.
In my opinion, what he's doing is absolutely great.
Maybe it's easy to forget @balbes150 is doing this for free, and maybe we don't know how many hours he's spending on doing this (I bet some of them, everyday).
 
Thank you, Mr. @balbes150: I think you should be paid by ATVs manufacturers, because, thanks to your work, and only in my case, they have sold 3 Amlogic ATVs (to me); and I had never bought them because of Android: It's your Armbian, the reason
 
To be sincere, I'm happier with my ATV boxes, running @balbes150 Armbian,  than I am with my Raspberrys, covered by tons of dust in this very moment.

Glad to read I seem to have created something useful.
 
My box is a scishion ai one alike one, MXQ pro max labeled box. The board is labeled TX-RX4B-V02.
 
My workflow:
Used adb to read the device tree directory from the box running android. Converted to android.dts file using dtc. For armbian used the ...box.dtb because the device could boot using that one. Converted dtb to dts using the "sorted" option of dtc for comparison (a). Converted dtb to dts without the "sorted" option for optimization (b). Used a merge utility (meld) to compare (a) against android.dts Put the found differences into (b), used dtc to compile. Too easy
 
Now, compare and merge... Using dtc to decompile a dtb to text format means there is no symbolic info - names as found in the kernel sources .dts(i) files 
and rockchip documentation are not available. Its just like reading and trying to understand a compiled app from a debugger listing without symbols.
Reading the kernel documentation regarding the device tree mechanism turned out to be very helpful.
 
I think this kind of workflow is suitable for proof of concept. It is really not suitable for anything else.
 
Its very easy to make mistakes. Easy to detect if the device refuses to boot, but there are many more possibilities.
 
Reading things like ... "did not work... suddenly did... then stopped to work again...":
This can mean pin settings (called pad nowadays, ok) might be wrong.
Reset or chip enable signals of peripheral chips are wired to soc gpios. If the mapping of those gpios to driver functions is wrong - anything can (and will) happen.
 
Regarding dram settings
These numbers count in pico seconds. And a pico second is a dammed short time. The right values depend on used chips and pcb layout and must be
set very carefully. Just using the values suitable for one board with an other... might work - or not - or temporary.
 
Regarding the wifi chip
The soc pads wired to the 8723 on my pcb differ from the standard ones and an other mmc peripheral of the soc is used for sdio connection. 
It might well be, that other pcb's are wired the same way and that 8723bs and 8723cs are mostly compatible.

 

https://yadi.sk/d/pHxaRAs-tZiei/5.41/mali-6/5.41.1_KODI-17.6

It probably already works for the box you linked, but if I may suggest, this one already works for sure, it costs just a few dollars more (4/16 model), and has twice the amount of RAM. I wouldn't think twice:
 
www.aliexpress.com/item/A5X-Max-4GB-32GB-Smart-Android-7-1-TV-Box-KD-RK3328-Quad-Core-5G-WiFi/32841541783.html

That problem was cured by not keeping the package info in compressed form as far as I'm concerned.  You have to change something in a config file then delete the lists and apt-get update again.  It's 10-20 times as fast now.
 
If you have to live without Synaptic try apt search.

I remember I had similar problems a few months ago when I tried installing Armbian on my TX3 mini for the first time. I did some tests back then and if I recall correctly mounting any Linux partition (extX) on Android seemed to be changing the file system to use SElinux permissions, which prevented Armbian from even reaching the first login prompt. I had the same problem even after having everything running and simply mounting the SD card or HDD on Android, it simply messed everything up, and changing all permissions back was time consuming, so I simply do NOT mount any linux filesystem when running Android on the box. Actually I never even boot Android, I bought the box specifically to run Armbian, sadly I haven't had time to play with it for over a month now.
But the symptom was as you described, I prepared the SD card, updated the box to multiboot (via Android, so it mounted the linux filesystem on the SD card and messed it up right there), and no matter what dtb file I used it would halt somewhere like what you showed. After rewriting the SD card and not mounting it on Android (I already had multiboot), Armbian booted out of the box, but it took me some time to figure that out. After I had the system working I booted Android and inserted the SD card, and I was again not able to fully boot Armbian due to SElinux permissions on certain system files (actually all over the filesystem, but fixing the permissions to a few system files made the system bootable again. Afterwards I still had to fix the whole filesystem nonetheless). I tried a few things after I had the system running from an HDD, and simply mounting this HDD on Android was enough to "update" the file permissions and make Armbian unbootable again. In summary, at least with my TX3 mini, I cannot mount any media with Armbian partitions on Android. I believe my box has Android 7.1 from March/2018.
In fewer words, your problem is probably not with the Android Update app, but with Android itself whenever it mounts the extX partition(s). Hope this helps somehow.

Updated images kernel 3.14 and 4.18.
 
Add dtb for p281 (S905W).
 
Please note that installation in eMMC, a system with kernel 4.18, is possible only when using u-boot-2018 and formatting the eMMC in normal disk mode.