pfeerick

even more blunt
If you klick download - you will see the landing page first, before you can chose your SBC with something like this:
 
Getting started:
Many users waste hours because of bad POWER SOURCE  (a little picture of a barrel jack would be great here)
Many users waste hours because of bad SDcard (make sure you have two (2) or read our introduction and test) (little pic SDcard)
Legacy kernel - optimal for multimedia and desktop usage scenarios
Mainline kernel - optimal for headless server usage
 
Continue to download page..
 
 
another idea to get the message over and just one place to maintain

... or ADSL to fiber and you are protected against storm

I mean that outside links should not contain exact kernel and release versions, they should look like
http://image.armbian.com/betaimages/Armbian_Nightly_Orangepizero_Ubuntu_xenial_default.7z
or
http://armbian.com/download?type=nightly&board=orangepizero&release=xenial&kernel=default
that should get HTTP 302 redirect to actual image file Armbian_5.24.161208_Orangepizero_Ubuntu_xenial_3.4.113.7z
 
 
Meaning of "legacy" or "vanilla" depends on board family/SoC and it needs to be stated on the download page (like it was before, but it should be shorter)
I don't have a better word to replace "legacy", but "vanilla" should probably be changed to "mainline"
For example in case of sun4i/sun7i it would be good to have at least this:
Legacy kernel - optimal for multimedia and desktop usage scenarios Mainline kernel - optimal for headless server usage See "Status matrix" for detailed comparison and we could have a table (I'm assuming Markdown tables are supported) that would show that currently HDMI audio, VE accelerated video decoding, DRM video driver and Mali are not available on mainline
 
Maybe nightly tab should also have "buttons" instead of links for consistency, and images buttons/links should be on top and repository info/instructions should be lower

Always do a verify since otherwise you never know when your hardware and/or dd failed. The following might require an
apt-get install gddrescue p7zip first. And then given we're talking about an SD card available as /dev/sda it's just:
root@ubuntu:~# cat /proc/partitions major minor #blocks name 179 0 3887104 mmcblk0 179 1 3686400 mmcblk0p1 8 0 500224 sda 8 1 1024 sda1 root@ubuntu:~# md5sum /dev/sda 19d9508a47b1469dc5570c2e8507112c /dev/sda root@ubuntu:~# ddrescue /dev/sda SD-card.img SD-card.log GNU ddrescue 1.19 Press Ctrl-C to interrupt rescued: 512229 kB, errsize: 0 B, current rate: 7798 kB/s ipos: 512163 kB, errors: 0, average rate: 7214 kB/s opos: 512163 kB, run time: 1.18 m, successful read: 0 s ago Finished root@ubuntu:~# md5sum SD-card.img 19d9508a47b1469dc5570c2e8507112c SD-card.img root@ubuntu:~# 7zr a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on SD-card-19d9508a47b1469dc5570c2e8507112c.7z SD-card.img 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs) Scanning Creating archive SD-card-19d9508a47b1469dc5570c2e8507112c.7z Compressing SD-card.img Everything is Ok root@ubuntu:~# ls -al SD-card-19d9508a47b1469dc5570c2e8507112c.7z -rw-r--r-- 1 root root 192350156 Dec 8 11:35 SD-card-19d9508a47b1469dc5570c2e8507112c.7z So you end up with a verified and compressed card image. And since MD5 hash is incuded in filename you could also check integrity after unpacking again.
 
TL;DR: Do not use dd to either write OS images (use Etcher!) or read from devices (use GNU ddrescue!). Using dd is ALWAYS wrong. Verify reading and writing stuff. And in case you plan to do anything that should serve as backup then TEST it afterwards.

BTW: This also prevents me contributing to any documentation in the meantime. Since writing documentation that is not accessible afterwards doesn't make any sense.
 
We still fail horribly to look at Armbian from the outside. We know that the average users hates to read stuff (instructions, documentation, whatever). He gets a new toy and wants it up and running. Or he gets annoyed by the vendor offerings and wants to try out an Armbian image.
 
Eg. a Pine64 user has been told to try out Armbian to make use of the LCD (nightly image!). Most probably the journey is like this:
Arriving at https://www.armbian.com (text, images, nothing he's interested in except of the next link) https://www.armbian.com/download/ -- aha, spotted Pine64 https://www.armbian.com/pine64/ -- aha, 'legacy' and 'vanilla' (WTF?!) and 'Jessie/Xenial server', so let's try out vanilla (sounds nice) and of course Jessie since that's what I know from Raspbian and the featured Lenny-builds from pine64.pro Let's take that crappy 4GB SD card flying around and use WinDiskimager since this tool ensures that I don't get notified when burning fails Ok, Armbian is crap, doesn't even boot, back to Jessie from pine64.pro One week later: Let's try out this Armbian stuff again since I realized that the crappy SD card I used is really broken So let's burn Armbian Jessie (5.20) again, this time it boots but there's no HDMI output (vanilla!) and no way to activate the LCD as described in their 'Hardware info' tab (there they're talking about 5.21, 5.24 and 5.25 but they only provide 5.20. WTF?!) Ok, Armbian sucks, back to the pine64.pro offerings @Igor: Currently no one who is not an Armbian developer or is guided by responsible guys like @pfeerick is able to find the nightly build for Pine64 and can benefit from all the great stuff we include. It's simply unaccessible and really a mess. And it won't change unless we start to look at this here from the outside.
 
I second Zador's suggestion: there have to be maximum 3 sentences that outline the most important stuff directly. Users start to read the fine print later if at all. When they want to download an image they need just a little information but that has to be easily accessible.
 
Also I think it would be a great idea to not link to an image with static version information (Armbian_5.20_Pine64_Debian_jessie_3.10.102.7z) but to a symlink that always resolves to latest version (Armbian_stable_Pine64_Debian_jessie_legacy.7z). Currently people link to OS images below http://http://image.armbian.com that get outdated automagically with Armbian improving. That's bad.
 
And as soon as Etcher 1.0 is released we should completely switch to .etch format (download checksum integrated, using Etcher guaranteed, no more hassles with broken download/burning processes. Saves our users and us a lot of time and frustration).

Small update on Pine64 running with mainline kernel: https://github.com/igorpecovnik/lib/issues/546#issuecomment-264862192
 
@apritzel was so kind to provide a nice tool to poke memory values on some Allwinner boards (so anyone with an OPi PC 2 in his hands could start to determine perfect tx-delay/rx-delay values to max out Gigabit Ethernet on this board). My results with 2/0 and 3/0 combination on Pine64 were rather good given that I only slightly overclock A64 with 864 MHz (with mainline kernel we still have no PMIC support and therefore also no cpufreq and dvfs scaling so by default A64 will be clocked with just 480 MHz -- when using Armbian's build system we clock A64 with 816 MHz since this is a sane value given that VDD_CPUX without active PMIC support is set to 1.1V).
 
In other words: Looks promising to already do server tasks with mainline kernel. With Armbian CPU cores clock at the upper maximum already, USB2 throughput is impressive high with UASP capable disk enclosures and Gigabit Ethernet performance is also almost perfect (900/940 Mbits/sec). 

http://wiki.pine64.org/index.php/Pine_A64_Software_Release#Armbian_Linux_Image
 
How moronic is that? A wiki linking to static OS images instead of our download/info page? So every time we update the OS image (and that's EVERY NIGHT at the moment) it's ensured that Pine64 users only get access to more outdated stuff. Those guys responsible for this wiki still try very hard to provide most shitty user experience ever for Pain64 users. Unbelievable.

Strange. While Armbian provides extensive documentation and a beta image where everything should work out of the box since weeks... meanwhile in Pine64 land people waste time and struggle with our build system and other people even provide 'customized' Armbian images bundled with wrong instructions: http://forum.pine64.org/showthread.php?tid=1183&pid=22923#pid22923
 
Seems the out of control moderator (Marcus H...) did a really great job constantly deleting every post mentioning Armbian
 
@pfeerick: wouldn't it be a good idea to make users over there aware of https://docs.armbian.com/board_details/pine64/ ?

The image was made for this contest ONLY!
 
Designed by: AntwanDesign
tronCube.zip

Armbian - Universal Operating System, therefore the universe reference with a slight hint of a PCB design backlighting the earth from the right...
It is a custom designed image, all required resolutions provided.
 
The image was made for this contest ONLY!
 
Designed by: AntwanDesign
AntwanDesign - ArmbianWallpaperPack.zip

For you to get the idea why you won't receive any more comments from me: I'll remain quiet from now on since it's a waste of time.
 
We're talking here not about the hobbyists point of view but professional use cases. If I want to roll out a few hundred OPi Zero a pre-populated SPI NOR flash with u-boot able to boot from network makes a huge difference regarding TCO!
 
Is it really that hard to understand why a device specific boot loader that's
 
a) already there
can boot from everywhere (SD card, USB stick, USB disk, SATA on A10/A20/R40 devices, network)
c) can boot device agnostic (universal!) OS images
d) while assisting the inexperienced
 
is simply a great idea? As long as the vendor's increase in costs is marginal and doesn't hurt.

@nz1
Never intended to insult, it is just a metaphor to get the idea of how easy it is to be distracted from the very few that make a lot of noise and forget the many thousands that are happy and quiet..

Fully agree. By the end of 2017 we should simply stop supporting new sunxi hardware that lacks SPI flash and fade out support for devices from those vendors being too ignorant.
 
It will take some time but as soon as board vendors (collaborating with linux-sunxi community) start to ship their devices with pre-populated SPI NOR flash this will be the best user experience improvement EVER. Just do a quick check of the SD card and inform user that he should return to the mall and buy a better card since the one he's using is insanely slow crap. Do some fancy cpuburn stuff to prevent any 'insufficient power supply' issues by simply deadlocking the board until the user gets the idea to replace the crappy phone charger lying around with a proper PSU. Implement netbooting by default, provide device agnostic Armbian images from then on...
 
Seriously: hardware vendors using Allwinner SoCs who save the 4 Cent to solder 16 Mb flash to their boards should be avoided beginning with January the 1st 2017. Boards with eMMC being the exception since there identical stuff could be stored on eMMC boot partition(s). Lets make this the test case for board support or not!

You already mentioned 'board without FEL button' -- lets make this the 2nd requirement. IMO it doesn't matter that much what the board vendor thinks when releasing new hardware. But if he does not invest the 4 Cent for 16 Mb SPI NOR flash and the 1 Cent for the FEL button then we skip this hardware design.
 
It's a classic chicken-egg problem that can only be solved by convincing hardware vendors to put both components on their boards. If starting to communicate with linux-sunxi community is part of the process... even better (though I have to admit that I really like Xunlong's communication 'style': Me and maybe others suggested implementing PoE, all answers were either non-existent or negative and then Xunlong simply delivers months later -- great. Same with SPI flash now or with OPi Plus 2E back then)
 
First and most important step is that hardware vendors start to invest the additional 5 Cent to put both SPI NOR flash and a FEL button on their boards. Then it's up to us (mostly linux-sunxi community) to demonstrate what could live inside the flash and how this could improve user experience. And then we'll see.
 
C'mon, it's just 5 Cents for them and if we can help vendors making this decision we should do. Really, simply let us stop supporting sunxi hardware that lacks this starting with 2017. Either eMMC or SPI NOR flash as a prerequisit isn't that much of a requirement?

It isn't necessary that there exists some consensus regarding stuff like this especially given that 'linux-sunxi' community isn't an 'entity'. IMO it's just expressing the need for these two 'features' worth 5 Cent per board for new hardware designs and being consequent with regard to supporting boards or not.
No FEL button but eMMC? Sorry, no Armbian support. No eMMC and also no SPI NOR flash? The same People will buy the hardware anyway and might even be happy with vendor software offers since they don't care about certain issues or are clueless. Who cares?
 
And it's not about supporting more boards but dropping support for boards from vendors that remain ignorant. Lets focus on hardware that is fun to play with and that's worth to get support. We waste so much time on support issues that could be simply avoided if hardware vendors would start to cooperate (really, all those 'SD card imaging gone wrong' stuff won't be an issue any more)

Regarding situation today I agree. Am talking about 2017 and huge improvements of the stuff living inside this SPI NOR flash.
 
A bootloader that is able to implement PXE will already ease deployment of sunxi devices a lot in certain environments. If board vendors start to cooperate (requires getting in touch) then why shouldn't be a bootloader also be able to detect/search for a Linux/Android image that meets certain requirements and boot it from wherever it is accessible?
 
Android for Allwinner devices doesn't have to rely on shitty partition schemes as implemented now and stuff like that. Jon Smirl and Kamil TrzciÅ„ski did a big step forward here and maybe even hardware vendors will get the idea that they don't have to rely on this braindead stuff from Allwinner if it's about Android. No one, really no one needs this '15 partitions for no reason Allwinner BSP stuff'. We just have to teach hardware vendors to stay away from this crap.
 
It's a community thing. It's huge but worth the efforts. But the first step is rather simple: Spend those 5 Cent per board and solder the stuff that's needed to your devices

Pinebook announced: https://www.pine64.org/?page_id=3707
 
Armbian support can be added easily since it's just different DRAM type and two different screen resolutions (hopefully we're able to distinguish between them prior to loading kernel): http://www.cnx-software.com/2016/11/24/pinebook-arm-linux-laptop-powered-by-allwinner-a64-processor-to-sell-for-89-and-up/#comment-536419
 
Edit: Both screen sizes use the same laughable 1280x720 1376x768. So in case displays are compatible a single set of settings (DRAM, LCD settings) is ok for both variants. I'm assuming that trackpad drivers are already available in BSP or will be provided soon.

apt-get install armbian-firmware-full  ... should solve a problem at least with firmware.
 
Sorry, can't recommend you any rock solid USB wifi adapter. The problem is usually a combination with a driver ... I am not aware how is the quality of a driver, which is a part of a Pain64 kernel ... but you can always try an alternative solution: https://docs.armbian.com/User-Guide_Advanced-Features/#how-to-build-a-wireless-driver
 
Someone may argue this but I think good WiFi chips are rare goods and usually PCI-based - Atheros / Broadcomm / Intel. They are installed into (solid / good) routers, APs and they can easily cost way more than an ARM board. Even those sometimes refuse to work out of the box

Yesterday he had also a great day, banned one account, censored a whole thread away and in two other threads important information:
here he deleted the last post mentioning that there's now also an Armbian Desktop image available (beta) And in this thread he deleted posts containing the following information: Firefox works without any problems on Armbian, that's simply since we install the armhf version by default on the desktop image since the arm64 version shows problems (this 'trick' can of course also be used to cure even the most crappy OS images for Pine64: on the broken Debian images from Pine wiki it's just 'apt-get purge firefox && apt-get install firefox:armhf' and those steps in between) Chromium with our Armbian desktop image is just a simple 'apt-get install chromium', there's really no need to install .deb packages from linaro or somewhere else. Using Chromium with '--disable-seccomp-filter-sandbox' is a bad idea, it would be better to address the problem (kernel fix needed?) If one wants to use '--disable-seccomp-filter-sandbox' though this can be added to all 'Exec' occurences in /usr/share/applications/chromium-browser.desktop So he managed to make Pain64 land great again, instead of informing people that there is software available that doesn't suck they (Pine Inc folks and their beloved premium moderator) ensure that no one knows, that people still use outdated, smelly and broken OS images containing numerous serious flaws and that nothing will change. Users are not informed that there are working 3rd party OS images existent in the meantime and users aren't tought how to use Firefox if they want since one person is allowed what he does best all the time: censoring everything he doesn't understand.

Well, I stand corrected since yesterday I bootet in Zador's new and shiny Pine64 desktop image... on Orange Pi PC 2: https://forum.armbian.com/index.php/topic/1762-new-oranges-with-h5-and-h2/?p=19663
 
This is far away from 'full Armbian support' but at least it demonstrates what's already available: 2D desktop acceleration already works by transplanting the userland/rootfs from our Pine64 image to OPi PC 2. Video acceleration didn't work for me even after increasing CMA but maybe it's just another simple tweak. Please remember that all that was needed to get HW accelerated video decoding with Pine64 was this commit (since all the work was already done for H3 by jemk before and A64 is pretty close to H3... it seems it's the same with H5 again).
 
Regarding 3D acceleration some bits can be read above (most probably redistributable 64-bit Mali450 blobs available). But to get OPi PC 2 fully up and running other stuff is more important: Getting voltage regulation to work to be able to use higher CPU clockspeeds and of course patching the BSP kernel a lot (I would assume we can most if not all stuff for A64 re-use also for H5 now).
 
Since I've been asked via PM how to fiddle around with some missing bits with Pine64 and BSP kernel like battery calibration: Probably the best way to start with device tree stuff is searching online for 'device tree for dummies' (not kidding, this is a good reading from a Free Electrons fellow and freely available!) and then you simply have to remember that Pine64 is nothing special at all but just another device using just another Allwinner SoC from the A series. Only differences: Now it's 64-bit and now DT has to be used where fex files have been used before.
 
We have several battery calibration related threads in the forum (all dealing with A20/AX209 but that shouldn't matter), simply read this, check linux-sunxi wiki for parameters if in doubt (not that much has changed regarding Allwinner specific bits) and ask back in 'Other boards' forum if you don't succeed.
 
The best base for such experiments is our new Pine64 desktop (beta) image: http://image.armbian.com/betaimages/ since Armbian ships with the stuff needed (git, gcc, dtc, whatever) and also Armbian is the only Linux offer for Pine64 so far that makes dealing with hardware/DT stuff as easy as with ayufan's Android 7.0 now. By setting/replacing DT contents from within u-boot -- just check boot script and documentation.

Ssssh! You weren't supposed to tell everyone... now they'll all be doing it so they can use their crappy glow in the dark microUSB cables!!! :-P

H5 just booted, Zador's changes were a simple switch to enable GUI stuff not only for 32-bit sunxi platforms but 64-bit too. As soon as H5 support is in a better shape we have to make a decision how to deal with this platform (that's mostly just a matter of naming schemes) but if/when H5 gets a proper HDMI driver we'll provide a desktop image too since 2D and video acceleration seem similar/solvable.
 
In fact with OPi PC 2 the situation now is much better than with Pine64 9 months ago since
it seems H5 is pretty close to H3 and A64 so software efforts can be reused Some progress has been made regarding HDMI driver just recently (EDID support so maybe no more just a few fixed resolutions supported but nearly everything every display out there is able to announce/display) OPi PC 2 is not broken by design regarding powering and led, this was/is Pine64's biggest problem from a support point of view. So many 'Pine64 is DOA' cases were just people connecting crappy phone chargers to Pine64's Micro USB port that led to insufficient power and the only led on Pine64 is just a power and not a custom led. This is way better now with OPi PC 2 since there the crappy Micro USB connecter can not be used to power the board at all and we have 2 custom leds on the PCB that can be used for feedback. Pine64 is a support nightmare, Orange Pi's aren't. It seems there are Mali blobs for H5's Mali450 floating around so in case these are re-distributable OPi PC 2 will get also 3D acceleration from the beginning (not that important or important at all, but there was some moronic 'the Mali' hype generated over at Pine64 forum) But please don't expect 'H5 desktop experience' in 2016. It all depends on linux-sunxi community now and if Armbian team learned a bit from the past we can H5 support make a test case how we improve with delegating testing efforts. Currently core team wastes too much time/nerves on testing but also failed to get more users into.

I enabled building accelerated video decoding related stuff for arm64 sunxi configuration (which currently includes only Pine64). Works for me, so we may provide beta desktop images (but we need to provide related packages first).

Awesome - I spent the whole morning reading this thread (and it killed my morning - which is a good thing!).
 
I learned more reading this whole 4 page thread - than in five months hanging around the Pine64 forum - I call that "moderator" a couple of nasty names - Pompous Princess - or Merkin777...  Can't believe the amount of bullshit information that "A" hole has steered me wrong with!
 
Thanks for all the insiteful info from contributors on this forum and this thread!

I'm sorry... I have stop you there... I'm having trouble not bursting out laughing... nope... I did... you've just summed up what I've been shaking my head over for past few months... 
 
lol... settings matter, ignorance hurts... so true... so true... 
 
ok, that makes sense... I'd gathered from what you'd said before that cqufreq played a big part here (which is understandable in the world of ARM, since its all on the one chip, rather than across different chips like on a x86 platform...). It would be interesting to see what they stuffed up in the debian distro though that still bottlenecks the download speed to 9MB/s instead of pushing it up to the 23MB/s that armbian proves the board is easily capable of doing. Don't think I can be really bothered finding out for them since the simple solution is 'use Armbian'... it is well supported and works! 
 
So, I should add iostat 5 to my video display/log/whatever... wildo... more stats the better... harder to argue against documented empirical evidence! 
 
So the iozone results... is that indicating 32.9MB/s write and 33.8MB/s read for 4kb blocks? thus meaning there is something still blocking for network downloads (if at 23MB/s)... which seems understandable since the Pine64 didn't really seem to throttle up for that side...
 
Oh, if you want a real hoot... I initially tried the vanilla image before realising the error of my ways... and since I couldn't seem to mount the usb drive... I instead shared out a folder of the microSD... and got a whopping 3MB/s up and down... needless to say, I decided that wasn't very practical
 
btw, is the wireless module supported (yet? or likely to be?)... Or am I just a bit too slow on working out how to enable it?