arox

Yes, we promote Ubuntu with a reason - Ubuntu Xenial has more recent and polished package base with less troubles than Debian Jessie. In desktop area we ran into enough troubles which lead to abandoning support for Debian desktop versions, while server remain fully supported. If there are no download options, you need to build it on your own.
 
When Debian moves to Stretch, we plan to follow and situation will most likely turn in favour of Debian.

Now that I've done builds for NanoPiM1Plus2 and BananaPiM2Plus, along with the previous series OPiZeroPlus-H3/OPiZeroPlus-H5/OPiWin/OPiPrime, and that all of those boards has the same symptoms of missing AP6212 (+/- some have mmc-sdio appear, some not), I've continue my search for hints.
To my discovery, I found the following quote in http://linux-sunxi.org/Sinovoip_Banana_Pi_M2%2B
I hope that is not true any more ...

H2+/H3/H5 boards overview (2017/03 update)
 
Since it has been a while since this topic has been updated and a lot of new boards have been released in the meantime it's time for a new overview.
 
I'll add also H2+ and H5 based boards since in the meantime we learned that those SoCs are pin-to-pin compatible and recently vendors started to simply exchange H3 with H5 on some PCB (and vice versa in at least one occurence). From a software point of view H5 is quite different (using 64-bit Cortex-A53 CPU cores and ARMv8 instruction set, some early boot stages are also totally different compared to Cortex-A7/ARMv7 used in H3 and H2+) and it should also be noted that Armbian currently only provides OS images based on mainline kernel for H5 boards (so please forget about HW accelerated video decoding or 3D for now or maybe ever since none of the developers is in the mood to deal with Allwinner's BSP/legacy kernel for H5 (regarding 'BSP' just look above in post #2).
 
While software support for H5 is currently somewhat different hardware features are pretty much the same as with H3 (still 3 to 4 real USB2 host ports and one USB2 OTG port: a simple register setting can switch the Micro USB port's PHY between the so called 'musb' controller used for OTG and a real EHCI/OHCI controller pair: with mainline kernel it will soon be possible to switch OTG to a real 4th USB2 host port with full feature set that still has not to share bandwidth with any of the other USB ports).
 
CPU performance with H5 compared to H3 is slightly higher at the same clockspeed but some workloads that benefit from either 64-bit or ARMv8 instruction set are significantly faster (eg. software making use of NEON instructions might perform almost twice as fast and the best example is the stupid 'sysbench' CPU pseudo benchmark which shows over 10 times better scores on the same hardware when compiled with ARMv8 settings).
 
In the following list I will also introduce some subjective 'categories' to deal better with the huge amount of boards we can use in the meantime:
NAS category: these are the H3/H5 boards with Gigabit Ethernet IoT category: these are the small and cheap boards best suited for low consumption 'General purpose' category: all the other H3 devices, these are also those you should look for if you want a cheap device to run with X11, OpenELEC, RetrOrangePi or Lakka since they all feature HDMI and full legacy kernel support As already said the differentiation is subjective and partially misleading since new boards like NanoPi NEO 2 featuring Gigabit Ethernet are also that inexpensive, small and energy efficient that they could serve both as NAS and IoT nodes (actually you can somewhat control behaviour since GbE vs. Fast Ethernet makes a pretty huge difference in consumption so it's up to you). Boards that might fit in multiple categories are listed more than once to make comparisons more simple if you're only interested in a specific device category:
 
NAS category (only due to Gigabit Ethernet available):
Banana Pi M2+: H3, 1GB DRAM, 8GB slow eMMC, 1+2 USB ports useable, Wi-Fi/BT Banana Pi M2+ EDU: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable NanoPi M1 Plus: H3, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi M1 Plus 2: H5, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+2+2 USB ports useable, Wi-Fi OrangePi PC 2: H5, 1GB DRAM, no eMMC, 1+3 USB ports useable OrangePi PC Prime: H5, 2GB DRAM, 1+3 USB ports useable, Wi-Fi/BT OrangePi Plus: H3, 1GB DRAM, 8GB eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2: H3, 2GB DRAM, 16GB fast eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2E: H3, 2GB DRAM, 16GB fast eMMC, 1+3 USB ports useable, Wi-Fi IoT category (cheap, small, energy efficient, most of them headless):
NanoPi Air: H3, 512MB DRAM, 8GB slow eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet NanoPi NEO: H3, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Fast Ethernet NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Gigabit Ethernet NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Gigabit Ethernet OrangePi Zero: H2+, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI OrangePi Zero Plus 2: H5, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI General purpose (HDMI and full legacy kernel support: video/3D HW accelerated):
Beelink X2: H3, 1GB DRAM, 8GB slow eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet NanoPi M1: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi Lite: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable, Wi-Fi, no Ethernet OrangePi One: H3, 512MB DRAM, no eMMC, 1+1 USB ports useable, Fast Ethernet OrangePi PC: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi PC Plus: H3, 1GB DRAM, 8GB fast eMMC, 1+3 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet pcDuino Nano 4: See above, it's just an OEM version of NanoPi M1 done for Linksprite Some important notes:
The following boards are listed in more than 1 category due to advanced feature mix: NanoPi NEO 2, NanoPi NEO Plus 2 and OrangePi Zero Plus 2 H3/H5 CE/FCC certifications: Please check individually and don't trust in logos silkscreened on the PCB, even if it looks like 'CE' it might mean 'China Export' instead IO bandwidth: H2+/H3/H5 SoC features 3+1 USB2 ports but on a few boards an internal USB hub is used so while these expose more USB receptacles some ports have to share bandwidth. Also on these boards a buggy/slow GL830 USB-to-SATA bridge is used. Search for 'hub' above to identify them. eMMC: shows most of the times higher random IO performance compared to 'the average SD card', but some vendors use pretty slow eMMC on their boards (Xunlong being the exception with OPi PC Plus, Plus, Plus 2, Plus 2E and Zero Plus 2). Please do not overestimate eMMC -- there's no need to choose crappy/slow SD cards and if you follow the usual recommendations difference in performance varies not that much (for example eMMC on most boards shows pretty low sequential write speeds that will be easily outperformed by any good SD card and differences in random IO don't have to be that huge, simply watch out for SD cards showing A1 or even A2 logo) USB ports: Some of the IoT devices have two of the SoC's USB host ports available on a pin header to be used with soldering or combined with various Docks, HATs or 'Expansion boards' (search for '1+1+2' above). On OPi One/Lite the unexposed USB host ports are available at pretty tiny solder pads so only usable with a lot of soldering experience Wi-Fi/BT: all boards providing both Wi-Fi and BT rely on Ampak's AP6212 so performance is identical, the Wi-Fi only boards either rely on RTL8189ETV/8189FTV (slightly better Wi-Fi performance than AP6212) or Allwinner's XR819 (so expect low Wi-Fi performance with OPi Zero or NEO Plus 2 since implementation is low-end and currently driver sucks) Yeah, each vendor's naming scheme totally sucks. Partially there are rules involved (the 'Plus' then means eMMC with Xunlong or GBit Ethernet with FriendlyELEC... mostly) but please don't trust in and check always individually!  
And now another few words on a different technical detail affecting both performance and thermal behaviour of the various boards: Voltage regulation / DVFS. TL;DR: the SoC can be fed with a variable voltage (VDD_CPUX), the lower the voltage the lower the temperature (less problems with heat/overheating), the higher the voltage the higher the maximum CPU clockspeed. So the best idea is to adjust this dynamically (low voltage/clockspeed when idle and only increasing both when needed). There are 3 variants to implement this: not at all, primitive or advanced (using a voltage regulator that's able to adjust VDD_CPUX in 20mV steps)
Only 3 devices implement no voltage regulation at all: Banana Pi M2+/EDU (frying the SoC constantly at 1.3V therefore prone to overheating), Beelink X2 (no idea) and NEO 2 (only 1.1V therefore limited to 1008MHz cpufreq max since above instabilities might occur).  Some boards use SY8106A I2C accessible voltage regulator where we can use fine grained voltage settings (Armbian fine-tuned these for every board so far to achieve max performance). This applies only to the following Xunlong boards: OPi PC, PC Plus, PC 2, PC 3, Plus, Plus 2 and Plus 2E. All other boards implement a simple two voltage scheme and are able to switch between 1.1V (up to 912MHz possible with H2+/H3 or 1008MHz with H5) or 1.3V (1.2GHz max with H2+/H3 and 1.25GHz with H5) And finally to add some stupid rankings: the cheapest board is from Xunlong (Orange Pi Zero: $7), the fastest is from Xunlong (Orange Pi PC 2 for $20) and the one with best feature set and onboard peripherals is also from Xunlong (Orange Pi Plus 2E: $35). And that's only due to OrangePi PC 3 Prime still not being released at the time of this writing (since otherwise regarding both performance and features this specific Xunlong board... )
 
Hope that helps
 
Edit: OPi 3 is now known as OPi Prime and (almost) nothing has changed compared to the leaked pictures back from last August.
 

Just a note, on modern installations you don't ever manually configure the /etc/resolv.conf it is automatically maintained by other services. Plain openvpn installation don't do dns push lines unless you tweak them from the server side, the network manager plugin which is part of the gnome packages does this automatically while restarting whole networking.
 
We have some amazon to datacenter bridges and even my soc installations are connected to datacenter network services by openvpn client. Most of the problems started when ubuntu started using network manager on desktop images but dns push routes took a lot off man hours to get them right. Currenlty I add manually the hostnames and don't rely on dns lookups.
 

In my experience, wifi has always be unreliable and a waste of power. I think there is some nonsense with wifi : you cannot have middle range and high bandwidth networks on an overcrowded frequency. What we need is what bluetooth should become : LE/AMP/mesh. LE stand for low energy : having the capacity to transmit small messages or rest in standby with very little power. AMP is the possibility to dynamically open a high bandwidth channel when needed. Mesh is the possibility to have a micro network of redundant nodes and links with short range / low power transmission, instead of interfering with others transmissions in wide areas as with wifi.
 
Unfortunately, the specification for that has been more or less released. Which means that current implementation is a mess. In first versions, BT was supposed to be cheap (but reliable) technology for specific use cases ("profiles"). Now, adding LE/AMP/Mesh simply mean multiply complexity by 4.
 
Nevertheless, at present you should be able to do wifi in ad hoc mode and use obex with bt ? I never tried wifi ad hoc and obex since bluez4. What are the problems ?

LM2596 should be right for the job - it can cope with such loads and they are dirt cheap.
 
https://www.aliexpress.com/wholesale?SearchText=LM2596

Just saw your input, sorry I was at work. Today, I've tried both 1.9.2 and the 1.9.3 which are very recent versions released in this last 2 days, and I can confirm 1.9.3 fixed the issue on ARMBian Debian.
 
The changelog has a line like this:
 
 
I don't know if this was the reason, however one of the fixes pushed to release from 1.9.2 to 1.9.3 fixed it on ARMBian Debian (I wiped the SD card 2 times to double check).
 
This thread can be marked as solved :-)
 
Thanks for your time!

Do you have this in your kernel .config ?
 
CONFIG_UNIX98_PTYS=y

SINOVOIP which design Banana PI is a special case : it is the most distributed arm manufacturer. You (I in France) can purchase a board in many local sites. So their "costumers feedback" would be the best place to complain about the price, hardware and software bugs, and lack of support.
 
The BPI M1 was worse the price, the other boards ... . So with the "m2 ultra", you just got a little more power for twice the price. Their marketing strategy and business model is not much encouraging to invest time or money both for users or for developers !

I think response to broadcast ping may have been disable (for security reason ?). I didn't manage to use it for a long time.
 
Please don't back up people that try to port "blue screen" technology on linux. I have seen the funniest things on network with appletalk 3 level physical/logical/service paradigm (access to wrong printer) and Microsoft abuse of layer 3 broadcast helpers (broadcast storm propagated threw the WAN). Microsoft programmers are not bad : bad choices are made upstream to offer functionality with little concern to security.
 
Automatic configuration of address is of no use : you have to choose a unique name anyway. You could as well use a fixed well known local ip address and force user to change it a first connection - as it is done for root password.

https://www.reichelt.de/Bluetooth/LOGILINK-BT0015A/3/index.html?ACTION=3&GROUPID=5844&ARTICLE=170030&OFFSET=16&SID=96WDwXhKwQATMAAHrYxKs8aa7eb3331164bb14def41b33191fbf3&LANGUAGE=EN
 
I used this one this a RPI. I just have ported my a2dp server on bluez5/pulseaudio/nanopi air (internal BT chip)
 
- compatibility depends on bluez (and btusb kernel module) and not on board or distro, if customers report it works with "linux" or "ubuntu", then you will be able to have it working.
- better use a class I dongle if you want a good range - but you will anyway hardly reach more than a few meters because a2dp device are generally class II
- even better use a nanopi air : with eMMC and internal BT chip, you get the same price than an $8 board with crappy SD card and crappy dongle. Without antenna (not provided) this board is unusable, but with an IPX cheap antenna you get as good a range than with class I dongle for that usage.
- be aware that with bluez5, you need pulseaudio, you can only use one BT sink at a time and you need workarounds to handle bugs in (pulse, bluez, dbus), workarounds that may depend on device specific profile connection management.

Well, I eventually got it working :
 
- first I also forgot to signal I had change : "ControllerMode = bredr" in /etc/bluetooth/main.conf (not sure it is necessary)
- second in /etc/init.d/ap6212-bluetooth, in hciattach command the serial speed is at 115200 and fex/uboot param don't seem to be relevant. I had to put it at 1500000, otherwise the daemon drops furiously samples.
- and the major problem :
 
The sink is by default connected to the headset profile at 8KHz mono (and it seems it doesn't work). You need to change it :
 
- pactl set-card-profile <num> a2dp_sink
 
<num> has to be retrieve with : pactl list cards (and it changes constantly !)
 
But there is there also a bug : the next time the daemon will fail to reconnect the (recorded) profile and you will need to reset the "headset" profile, reconnect and reset a2dp : pactl set-card-profile <num> headset_head_unit + stop/start the device + pactl set-card-profile <num> a2dp_sink
 
(The web is full of advises on people that explain that in normal mode with graphical interface, they need to alternate between profiles and restart the device before they can connect a2dp)
 
I will now look if I manage to get the AVRCP profile connected threw uinput in order to read next/back commands.
 
I end my comments here as it seems nobody is interested in BT on armbian.
 
PS: second device, other problem ...
 
It seems this one does not have his audio profile automatically connected. So if the device fail to be recognized by pulse or if it refuses to switch profile (with set-card-profile), try a connect <addr> with bluetoothctl ...
 
PS2: workaround
 
It seems profile selection bug is well knows (but not corrected in pulseaudio 8). After many tests, I think that the better solution is to NOT load the "module-card-restore" module. Otherwise, this module will reset the ad2p profile and bluez module fall in bugs and race conditions. So the workaround become :
- disable module module-card-restore
- monitor dbus events
- on base [device] connection event, force connection by bluetoothctl connect, in order to connect audio profile (if device does not do that itself)
- on audio [media] connection event, switch profile to a2dp
- on [transport active] event start playback
 
There are other bug that may need to be handled, but with the method described above, I can get a fast clean working server.
 
Of course I think that this is only relevant for one version of (pulse, bluetooth, dbus)

2,5$ - https://www.aliexpress.com/item/HLK-PM03-AC-DC-220V-to-3-3V-Step-Down-Buck-Power-Supply-Module-Intelligent-Household/32586663935.html
I don't use crap $2 esp8266 - https://www.aliexpress.com/item/D1-mini-V2-Mini-NodeMcu-4M-bytes-Lua-WIFI-Internet-of-Things-development-board-based-ESP8266/32529101036.htmlD1_mini best choice IMHO.
And don't think about money - I can eat in restaurant for 100$, but it give me less fun, than building my devices, it's a hobby.

If you rotate 90degrees the heatsink and bolt it again, you will see that it has proper opennings for pin soldering..   
 
Christos

"If no data went trough for certain boards, than either tester failed to test or it does not boot at all."
 
If no data is auto-submitted, it indicates that network is not fully configured - not that the board doesn't boot. Or that it does not pass threw the firewall as in my case anyway ... In any case, you should explicitly ask permission for reporting.

Well the board survived ... I am know trying to survive to debian and systemd : a mistake in /etc/network/interfaces and the system hang at boot ...

That is of course the first question I asked myself. Nevertheless, the card was purchased at a reliable supplier and anyway there is no way at my disposal to check that.
 
The fact is that I have over 30 years experience in system but was not prepared to face such a stupid problem : hardware pretending doing the job but not doing anything. I suspected the image, the fs options and the card reader before the card itself when I noticed that files created on fs disappeared after unmount/remount !
 
Anyway, I will now check /etc/os-release after flashing a card ...

"Is it possible to have the same problem with udev?"
 
I don't know and don't want to know - udev is a system configuration subsystem : a user shouldn't have to fiddle with multiple cryptic configuration files to configure his applications. If it doesn't work out of the box, it is bugs !

Well ...
 
- you dont provide a usage manual for your script.
- raw archives need a full understanding of partitions and filesystems !
- when you copy and compress a fs, you loose some crucial information : the size of partition needed to restore it. You need to store that somehow because you will end up with archives which you dont know why you have done it, and that require long and tedious operation to restore or simply identify.
- it is always much more difficult to restore and manage archives than to make archives ...

"everyone uses the tools he used already last century"
 
Well tools are only part of the problems. In particular when people dont know if or why they need it. (And in that case tools tend to become the problem)

Its not just a question of stability. When you browse the web, you want to be able to display every pages. The browser has to implement most of the moronic standards in use to format and style pages and execute javascript code. And even then, if the browser respects standards, you will only have a usable browser if websites test their pages against that browser.
 
So, you have firefox or chromium. I never could use chromium because of memory leaks (the tabs where killed). You have to do with firefox :
 
- use the card with the fastest CPU and huge heatsink (mulicore not usable with ff - 2 cores usable for sys/net/io/display AND js)
- go in preference and "about:config" to disable all that is not needed
- install extension to filter pubs and sniffing js (uBlock, disconnect, noscript ...) or use some frontend proxy like privoxy.
- assure you have fast disk io for .mozilla and .cache
- forget about video and perhaps remove pluggins or block them
- compile it from source with optimization and disable what you can
- wait for a multi-threaded stable version
 
Edited on a BPI M1 (A20 2x1 GHz 1Go DDR3) - web filtered against js abuse. Quiet usable (but I browse youtube with another machine : atom 1.6 GHz and ff compiled with gentoo)

I dont care for functionalities that make software unusable. Browsers are designed for use on 3 GHz multicore processors, and so are also web pages with "experience improving" sniffing javascript abuses.
 
So I use a privoxy/polipo front-end to purge pages and I disbled local cache. (At least, you should use local filter extensions). Firefox DBs are another problem : I donnot want firefox were out my SD card or even use a costly SD card just for "improving my experience". I dont save work files in local but on an NFS server.
 
I approve at 110% tkaiser's advice on using eMMC. But in the meantime, I currently use an A20/bpi1 as desktop and deported home and firefox gigacache on NFS, which is a bottleneck (even with no document cache). The ideal solution would be to use a ram FS, but what would be the best solution ?

Well, if you look at this topic, it explains how to generate your own kernel and modules. You should be able to enable batman in config. No reason it should not work.
 
http://docs.armbian.com/Developer-Guide_Build-Preparation/
 
There are numerous modules available in kernel. I dont know on which criteria they are enabled or disabled (@igor, @zador).
 
I would like to test mesh networks with bluetooth, but my experience with bt since it is "maintained" by opendesktop.org folks dont give me much hope, so I would rather wait.

Have you make a "sync" after dd ?
 
I see also sometimes recommendations to wipe the cards (dd if=/dev/zero of=/dev/sdX) before copying an image. I never do this, as I never found a justification to do it. But I also sometimes copy images that will not boot ...

setenv bootargs "console=tty0 root=/dev/mmcblk0p1 rootwait"
 
If it is what you entered in fex, you forgot the S (ttyS0 and not tty0)