reverend_t

The challenge with the Neo2 is that there are two hardware versions, so by default Armbian can't enable the regulator that is present only in the new 1.1 version of the board.  However I made a patch that I use for my Neo2 v1.1 board that adds support for the MP2143DJ regulator to the DT - see https://github.com/5kft/build/blob/master/patch/kernel/sunxi-next/sunxi-next-h5-nanopi-neo2-fix-leds-add-regulator.patch (this also corrects the LED names for the board).
 
In order to enable the higher clock rate, you'll also have to update the "sun50i-h5.dtsi" DT include.  I updated both this and the associated cooling-map in this patch:  https://github.com/5kft/build/blob/master/patch/kernel/sunxi-next/update-H5-board-config-support.patch (search for "sun50i-h5.dtsi" in this file).  You can extract just the patch for this file and ignore the other file patches I made.
 
Note that if you make these changes in your DT, then you'll also need to edit "/etc/default/cpufrequtils" on your Armbian board and change MAX_SPEED value to 1296000.  This way the board will run at a maximum of 1.3GHz via cpufrequtils.  With these changes thermal cooling works very well for me - the board auto-clocks down when it gets too hot, etc.
 
Unfortunately my Neo2's H5 is unstable at anything faster than 1.3GHz as the v1.1 regulator is restricted to 1.3v output maximum, so you can't overvolt.
 
I've been running my Neo2 using this for months using this configuration and it's been working great.  It's really a neat little board!
 
In any case, I hope this info might be useful - good luck!

Hmmm, I've never thought that e/n/i is particularly complicated. Like most of GNU/Linux it's a powerful tool, possible to get wrong but it's also a solid part of the Linux learning experience. Isn't that also what Armbian is at least partially about? Even Netplan, which is slated to replace ifupdown in 18.04, is largely based on e/n/i (state your desired outcome) principles rather than NM (coddle you from any chance of mishap) principles.
 
And the fact that boards like the Orange Pi Zeroes, etc, open up the world of Linux to more people is something to be celebrated, surely?
 
However, if this is the way things ust be then there's a couple of issues/suggestions:
 
1. The "standard" Ubuntu/Debian way of disabling Network Manager appears to be broken (at least in H3 5.35 Dev):
$ sudo systemctl stop NetworkManager.service $ sudo systemctl disable NetworkManager.service Following these (man page) commands good ol' Network Manager is somehow re-enabled on the next boot. I had to take slightly more drastic step of:
mv /lib/systemd/system/NetworkManager.service /lib/systemd/system/NetworkManager.service.BAK after the previous steps to actually slay the vampire. I don't know whether this is due to Armbian's integration of NM into its basic tools or what.
 
 
2. The description in /e/n/i needs to be more balanced
 
It sounds like it was written by someone fuming at the ears. It should, of course, emphasise the benefits of NM but should also point out that for any vaguely interesting routing set up (say you want to play with LXD and create neat bridges, VLANs or whatever) then it should contain clear and working instructions on how to disable NM (since the standard Debian way doesn't seem to work). Maybe even better would be to add into armbianconfig. I'll investigate if I have time!  

well, thank god u r not the only dev
 
// sent from mobile phone //

I've been super fascinated with the DSA stuff since my espressobin first exposed me to it's existence.      The thing I don't quite grok with DSA is if I'm trying to do any layer 3 stuff on the switch ports,  such as inter vlan routing is whether or not I'm always limited by the RGMII or whatever link the DSA chip is using to connect to the SoC.    
 
You have described a pretty ideal board.   A DSA with a cheap 4 core SoC is enough horsepower to brute force doing all sorts of cool network stuff without being so reliant on hardware offloading like on my EdgeRouter Lite.     Now that VyOS has ported their build over to supporting Jessie, I've been hoping to eventually rig up a VyOS installer armbian similar to the OMV userpatches installer.    

What a wasted opportunity. Even an H5 sitting behind a 3 port switch chip would have been fantastic (as long as the switch was booted in the sane deny all connections mode) as the switch could have taken easy care of switching packets on the same VLAN and brought in the SOC to handle inter VLAN stuff (Netgate's horrifically overpriced sg-1000 is essentially this).
 
(At some point I'm really hoping someone combines an RK3328 with an ax88179 and a decent switch chip so that we can have a genuine dual nic gigabit routing device)

There's nothing unstable about the OPi0 on Armbian stable, at all

Please be careful with such (wrong) conclusions, better try not to do 'reviews' based on nightly images and also try to be a bit more precise when you post about stuff (for OPi Zero you mixed legacy and mainline kernel and again: nightly images are for testing and reporting back in a constructive way to developers and distro maintainers and not for productive use or even basing 'reviews' on it).
 
I used my OPi Zero for days with a Ralink dongle in 5Ghz band and of course everything worked perfectly (using legacy kernel, my last tries with nightly builds weren't that great). Why should Linux fail with such a setup? It's either crappy drivers or what's more likely: power or SD card issues (and using 'same cables' doesn't help here since contact resistance might be different and consumption behaviour due to different settings).
 
Unfortunately all those small boards use Micro USB for powering but they also allow to be powered through GPIO pins which is the first thing that should be done in case 'stability' seems to be a problem (for obvious reasons!).

I do search and watch them deliberately. They are valuable source of feedback, they provide different perspective, gives 3rd party opportunity to learn something .... and make me feel good.  

One of the beauty of our build tools is, that we take care for this pain and match proper compiler (or patch) per any source involved in the process.
 
https://github.com/igorpecovnik/lib

Great that you were able to resolve the issue and especially that you shared solution/knowledge!
 
Please don't expect too much from legacy kernel here. This is an ancient 3.4 kernel from Allwinner that is known to have several networking issues. Also please be aware that problems on layer 3 (routing) might not even exist when the problem is solved at the appropriate layer (that would be 2 --> bridging). I did some tests with 3.4.113 and bridging that went well but in case you're running in problems it would be worth a try to test out the nightly builds with dev kernel to know whether the problem is solveable with mainline kernel (then it's just having some patience since OS images based on mainline kernel receive no end user support ATM)

Please don't confuse legacy vs mainline, @spock talks about the mainline, where DVFS was (or is) broken and needs more testing.

Ok, guys ! I found my hardware issue : I've been caught myself with an SDCard that becames crappy !
 
For the xradio issue, I don't know if it was also related, but I've created image with Zador stuff, although I had to tweak a bit the DT, and it is now working fine.
 
@Zador, the tweak needed is related to the fact that PL7 was already defined in PiOne, but due was slipped into pio instead of r_pio (same issue found few weeks ago for PiPC https://github.com/igorpecovnik/lib/commit/31c3133cf65af66197b0e78f92eae835615a90b1 )
I will commit this fix in few minutes along some removal in PiZero since we can reuse the PL7 from PiOne, simply by using same names.
 
EDIT : here is the first fix : https://github.com/igorpecovnik/lib/commit/5fff38add9873b50bc71d540573e4294bc97c10d, and here the redundancy cleanup : https://github.com/igorpecovnik/lib/commit/fdaadb42d7587371a7cb7f1184ade5915cd77924#diff-ef59beeea2dd85451fb9bf2905fb7ebf and https://github.com/igorpecovnik/lib/commit/369d3928e7154ac12c34f0e2bc4ce0e24636cb4e#diff-ef59beeea2dd85451fb9bf2905fb7ebf