Avinash Ga

What I would love to see is someone joining our development efforts to provide all the stuff outlined by @rellla in this installation log http://linux-sunxi.org/User:Rellla/Armbian to be integrated into our build system.
 
A dev joining in willing to dig a bit deeper into Debian packaging so that all the aforementioned stuff could be integrated as Armbian .debs into our repository so we could provide upgrades the usual way (apt-get update/upgrade) and also real upgrades from CLI/server OS images to desktop images would be possible (if one tries to upgrade a server image now then most probably all stuff needed to get HW acceleration for media playback will be missing afterwards).
 
As far as I understand everything needed for A10, A20 and H3 boards is already in place so the missing step is 'just' integrating all these packages into our build system so at least users of the most popular sunxi boards could benefit from.
 
And at least to me the Orange Pi Plus 2E we're talking here about to be able to give away for free to devs wanting to join in (a big thank you to Xunlong!) would be the perfect board for this purpose due to 2 GB DRAM, pretty fast 16 GB eMMC, superiour PCB heat dissipation allowing high clockspeeds without much or any throttling occuring, Gbit Ethernet and onboard WiFi being not that bad according to first testers. Or am I'm overseeing something?

[Ended]   Be active, creative, helpful and you can get a powerful board in return. First give away batch is starting 11.6.2016  
It's not often that you can work on a software project that actually brings joy and helps people. Armbian is one of those project. It is a system that helps one build a kernel or boot images for several ARM development boards. 
 
It's in common interest that we improve level of support and to relieve most active people. Our crew needs an upgrade:
we need more coders, kernel hackers, UX designers to find and solve problems. If you are one of them, join our forum, join project at Github. we need properly built, packed and supported desktop with major functions: video acceleration/fbturbo, libump, mali, etc. we need to put together much better documentation. We need to fine tune MkDocs documentation tools For those who are willing to claim a task or help others to understand "how do I do this in Armbian" we prepared a dozen of boards as a small reward. It's a Xunlong Orange PI+ 2E, which design was improved based on requests from our community. It's H3 based quad core with 2G RAM, 16G eMMC, Gigabit LAN, WIFI and 3x USB.     There might be just enough boards for everyone who are willing to do some public service work. Claim your projects at this topic and each weekend we will discuss and select up to 15 people who will get the board, starting with 11.6., ... until we run out of boards. One will be notified by email and expect an answer within 48 hours, if not, board goes to somebody else.   Boards were donated and will be sent directly from Xunlong Co., Shenzhen, China.     1st batch is going to: Kriston, lanefu, vlad59, martinayotte, jeanrhum, Gravelrash, xcasex, naibmra, Xer0, madilabs, wha, @lex, WereCatf   naibmra - Bulgaria - kernel testing, try hooking to kernelci.org, docs - mid July wha - USA - 50unattended-upgrades, issue #337 - June Kriston - USA - documentation rework - July, August Xer0 - Germany - media build - July, August lanefu - USA - issue tracking improvements between forum and github - 22 June, July madilabs - Martinique - Packaging for desktop video acceleration - June xcasex - Sweden - desktop packaging - July, August jeanrhum - France - documentation and debian packaging - July martinayotte - Canada - maintain/fix DTS entries for some devices such I2C/SPI/W1 - ASAP vlad59 - France - Nanopi M1 testing and documentation Gravelrash - UK - Prepare HOWTO's & package "armbian-gc2035-fswebcam package" - June   2nd batch is going to: dimag0g, R2D2_C3PO, miked, 0x0, sysitos, jmcneill    dimag0g - France -  Packaging of OpenGL wrapper library - end of July R2D2_C3PO - Germany - Improved SD-Card partitioning - end of August miked - Canada - build system recension - end of August 0x0 - Russian Federation - Redesign site and documentation WIP + add some changes to graphics in distro. - end of July sysitos - Germany - replace/rework ramlog for systemd - end of August jmcneill - Canada - (Armbian is helping porting Freebsd)    Users were notified and were requested to provide: project name, due date and their shipping address

@Skygod: I don't know how different M1+ is from M2, of which Hosteiner mentioned it works fine. If there is a difference, it would be cool to see it it works on the M1+ as well!
 
@Holsteiner: The Docker version in this image is probably by far not latest, but will probably work fine, which is good to see!
 
Performance of Docker? Like charm :-) See this is docker daemon without any containers:
$ ps -p 1277 -o %cpu,%mem,cmd %CPU %MEM CMD  1.1  2.8 /usr/bin/docker daemon -H fd:// --storage-driver=overlay -D Let's start 20 webservers (https://hub.docker.com/r/hypriot/rpi-busybox-httpd/), i.e. starting 20 containers, and check again:
%CPU %MEM CMD  6.5  3.4 /usr/bin/docker daemon -H fd:// --storage-driver=overlay -D Note, that this is just the Docker daemon as "container manager" instance!
 
For each container, Docker starts 4 processes. Please do not ask me why. Let's rather have a look at CPU and RAM:
With 20 webservers running, CPU usage in total and average is about 4%. Before starting these 20 containers, it was a bit more than 2% in average.
RAM usage is 162 MB. Before starting the 20 containers, it was 46 MB.
 
So in general, only the Docker daemon is put on top. For containers, Docker's footprint is about the same as if you run apps natively. For this test, I used HypriotOS (http://blog.hypriot.com/) on a Raspberry Pi 2 B.
You also can define how much CPU and RAM a container is allowed to have at max, and also in relation to other containers. Docker offers many options to make sure you are in control about available resources.
 
And, BTW, with some tweaking, it's possible to start 2500 containers on a single Raspberry Pi with Docker :-) -> https://blog.docker.com/2015/10/raspberry-pi-dockercon-challenge-winner/
 
@September: I can see that several containers are running, which shows that Docker works well, awesome! Thanks for your feedback! Yeah, we are not sure yet how much work it is, but we at least try to get together...

I am skipping / postponing Pine64 so it's up to community & maker - our project is open and anyone can start supporting it. arm64 was already brought in and tested with Odroid C2 so initial work was already done. I am aware that having a good Linux support is critical for those boards but can't do much about. Linux is a community project per se while Pine64 ...

Hi all , i register to see advances in the h3 support. Im happy to see that my orange pi pc will be vanilla kernel support.
Thanks for your work!
PD: Sorry for me english.

Of course. Some of these crappy onboard WiFi 'solutions' do even lead to stability problems (see Lamobo R1). And the very same vendor (SinoVoip or 'Team BPi' how they call themselves) now has a board in stock with non-functional WiFi where you have to desolder a resistor to be able to use WiFi reliably: http://linux-sunxi.org/Banana_Pi_M3#Wi-Fi (but users don't care and buy this crap because of onboard WiFi and the slowest USB-to-SATA bridge in the world)
 
Users don't care. The WiFi was already there when they bought their board, it's obviously crap but they want to use it anyway even if they have to place their board 2m next to the router.
 
An Orange Pi PC Plus with eMMC and WiFi is announced for $5-$6 more. The problem with onboard eMMC and an additional SD card on Allwinner boards is that the SD card will normally preferred when available at boot by the SoC. But the best location for the rootfs (and user homedirs when a desktop image is used) is the eMMC since random I/O is often magnitudes faster. But this would require bootloader on SD card and rootfs on eMMC which is already possible with Armbian after some tweaking but might become a future installation option.

4.5, hopefully. We wait for Ethernet support to become stable.

It might be time for some release line. Let's put together what was done in past few month, need to be done, was forgotten and it's worth mentioning. I sure missed stuff out ... so just add it.
 
IMAGES / KERNEL:
- all 3.10+ kernels are Docker ready
- added Odroid C2 CLI and desktop, kernel upgraded to 3.14.65
- Udoo Neo wireless works
- legacy kernel for Allwinner boards was upgraded to 3.4.111
- legacy kernel for iMx6 boards was upgraded to 3.14.65
- vanilla images comes with kernel 4.4.6
- Clearfog comes with 3.10.101 and 4.4.6
- added Armbianmonitor which knows ....
- fixes for SPDIF / I2S audio driver in legacy kernel
- added USB camera section
- added fix for slow SD cards
- changed first boot procedure and force user creation
- all A10/A20/H3 comes with HW acccelerated video playback in desktop build
- Bluetooth on Cubietruck works well, both kernels
- verbose / no verbose boot works almost on all boards
- added wifi radar to desktop
- desktop jessie only
- enabled I2S on sun8i
 
BUILD SCRIPT:
- Added Belink X2 as WIP target (H3 based media player)
- Added Odroid C1 as WIP target
- introducted CLI_TARGET per board
- prepared FEL boot
- prepared Xenial target
- GCC 5 support for vanilla and allwinner legacy
 
BUGS:
- Udoo Neo reboots takes a while, 1min+
- C1 does not boot
https://github.com/igorpecovnik/lib/issues
 
NEED TO BE FIXED IN THIS RELEASE:
- vanilla build for H3 with working EMAC / GMAC
- nand installer for H3 eMMC
 
DUE DATE: 30.4.2016
 
------------
Copy paste / add and remove this text. Just add to the topic

That means that boot loader is patched / prepared and we did a manual boot. For installer we need to create / adjust scripts and make few tests. This is scheduled for next release - in 2-3 weeks. This info is valuable for users who knows how to do it manually.
 
http://forum.armbian.com/index.php/topic/881-prepare-v51-v201604/

Please have a look at https://github.com/igorpecovnik/lib/issues/219  for possible workarounds and solutions. Feedback welcomed.

CPU or HDD ? or Outside ? might be a good idea to be a bit specific

If you use the most recent image for H3 boards then the SoC temperature is available as /etc/armbianmonitor/datasources/soctemp otherwise have a look into /sys/class/thermal/thermal_zone1/temp
 
And you can also do monitoring by starting 'armbianmonitor -m' which shows relevant system parameters including CPU clockspeeds and temperature. Looks then like this: https://github.com/longsleep/build-pine64-image/pull/3#issuecomment-194980231

It's important to believe blindly in numbers! At least when you try to be mislead as much as possible!
 
Yesterday Michael Larabel from Phoronix fired up his usual set of passive benchmarking tests for the new Raspberry Pi 3 and he still uses rather questionable results for other boards to compare with (he claims that it would be sufficient to use a board with 'factory settings', run a set of synthetic benchmarks, don't analyse the results or even think about whether they could be wrong and treat the results as the truth)
 

 
RPi 3 is 4 times faster than OPi PC and 6 times faster than OPi Plus? Really?
 
If you just try to think about these graphs for a second it's obvious that there must be something wrong: Testing Orange Pi PC and Plus individually already makes no sense at all (same SoC, same settings --> same performance results to be expected) and publishing results that vary that much is alarming: either your benchmark must be wrong or the conditions or the tester. If you just think a second it's obvious that Orange Pi PC and Plus have to be faster than Banana Pi M2 (also an Allwinner ARMv7 SoC clocked a bit slower) and that you should drop any results if you experience a difference of more than 10% between both boards that must perform identical.
 
So I took our Armbian 5.05 release candidate and tested 2 of Phoronix' benchmarks on an H3 based Orange Pi (and then stopped this waste of time):
 
C-Ray: 340 with Armbian vs. 1425 according to Phoronix. Using Armbian increased the performance by over 400% (if you're dumb enough to rely on 'benchmarking gone wrong')
John the Ripper: 558 with Armbian vs. 315 according to Phoronix. Using Armbian increased the performance by 77% (if you're dumb enough to rely on 'benchmarking gone wrong')
 
Confusing! Why is Armbian way faster?! And why does choosing Armbian speeds up your Orange Pi in one case over 4 times and in the other case just by 77%? Let's have a closer look:
 
How does Armbian differ:
We are able to use 1.3GHz as CPU clockspeed (might speed things up) For reliability reasons we clock the DRAM lower (might slow things down) Most importantly: We don't use braindead thermal throttling settings (and I used a heatsink/fan) And the latter is the most important issue that Michael Larabel seems to miss at all when he uses the 'benchmark' results he collected sometimes ago to compare between different hardware. It's 2016 now! Each and every more recent SoC is a throttling candidate. This has to be taken into account if you want to benchmark a SoC or a board. If you ignore this your results are plain bullshit (just like Michael's).
 
When he tried to 'benchmark' Orange Pi PC and Plus he obviously ran into the problem that the vendor's budget cooling settings favoured killing CPU cores instead of thermal throttling so he obviously ended up with just one active CPU core left after some time of testing. And while this was an important finding (OS images for Orange Pis all crap more or less back then and negatively influencing performance) it's also important that this is nothing the hardware has to be blamed for.
 
The very same board running with Armbian performs more than four times faster! Think about. So obviously the benchmarks Phoronix recommends do not test the hardware but something else instead.
 
To be clear: the Phoronix test suite is fantastic when used correctly. That means ACTIVE BENCHMARKING and not collecting meaningless numbers and then relying on these worthless numbers to draw the wrong conclusions. When using the Phoronix test suite correctly you can identify performance bottlenecks and boundary conditions that affect performance easily (wrong cpufreq governor, killed CPU cores, thermal throttling, wrong settings, whatever). And also what to do to increase performance (tweaking compiler/scheduler settings, constantly trying out to optimise things until it works better).
 
The worst thing you could do with the Phoronix test suite is to collect numbers without meaning (passive benchmarking) and then use them to draw the wrong conclusions (that's what most of Phoronix' users including the author of the test suite do all the times).
 
Back to the origin again: We started with the Raspberry Pi 3 and 'benchmarking gone wrong' the Phoronix way. You really should take the numbers Michael/Phoronix published with a grain of salt since he neither mentioned whether throttling happened nor he commented on the consequences for the RPi 3 if the RPi foundation understands that it's necessary to provide a Raspbian version that is ARMv8 optimised.
 
The RPi foundation claimed the new RPi 3 would outperform the RPi 2 by 50% using questionable sysbench results. If they would've optimised their Raspbian code base for ARMv8 they could claim the RPi 3 would be at least 15 times faster. Why? Because benchmarks are always wrong and using sysbench (that calculates prime numbers) can't be used any more to compare between different ARM architectures (or architectures in general): http://forum.odroid.com/viewtopic.php?f=136&t=19158(I'm really curious whether Phoronix gets that when 'benchmarking' ODROID C2)
 
TL;DR: Benchmarking is fine as long as you use it to optimise software and to rule out insufficient hardware. When used wrong it's misleading (unfortunately that happens most of the time)

Might not happen that soon. While we're preparing the new 64-bit architecture (which will take some time) the current state of Linux on A64 permits building OS images for end users
 
BTW: Since people started to take the silly sysbench result above (3.25 seconds on Pine64 vs. 49 on RPi 3 -- only possible conclusion: forget about this 'benchmark' from now on) to compare with the ODROID-C2 I simply unlocked the higher CPU frequencies and measured again: now 2.8 seconds or ~15% better -- all just by modifying thermal throttling behaviour). It should be obvious that any kind of benchmarking for A64 now is plain nonsense. The aforementioned tests are only suited to demonstrate how misleading this sort of pseudo benchmarking is.

Wondeful. Soon i will be getting my pine64 boards. I am eager to try armbian supported image on it.