willmore

And updated wifi driver with fixed MAC address is coming later on to beta repository. 

Igor added in the meantime the device to the build system with our usual 'conservative' approaches (downclocking DRAM for example on those small boards with 16-bit DRAM config since we don't want to fry them).
 
So let's test with an Armbian Xenial arm64 now (64-bit kernel 4.13.13, max cpufreq limited to 1008 MHz and clocking DRAM at 408 MHz): https://pastebin.com/2iYbFRhD
 
Test BSP Armbian std memcpy MB/s: 887.9 634.8 std memset MB/s: 2037.9 1553.0 7z comp 22: 1288 1234 7z comp 23: 1344 1279 7z decomp 22: 3296 3329 7z decomp 23: 3215 3317 sysbench 648 (s): 14.4798 14.1447 sysbench 816 (s): 11.4151 11.2191 sysbench 1008 (s): 9.2395 9.0787 openssl speed aes: identical The way lower DRAM clockspeed ruins tinymembench numbers (and would most probably affect graphical applications that depend on memory bandwidth) but with tests that are affected by lower memory bandwidth and higher latency (like 7-zip) the difference is negligible (in fact with our kernel/settings 7-zip is finishing the first time not being oom killed). Debug output here: http://sprunge.us/KHCM
 
So once we rebased the whole stuff to 4.14 within the next weeks, then allow H5 to clock up to 1200 MHz some more performance improvements will follow.

To prepare next steps I booted with vendor OS image once (obviously no tuning at all for this board, it seems that's generic Allwinner H5 BSP stuff already used for Orange Pi PC 2 before, at least this is /boot/orangepi/OrangePiH5orangepi.dtb being decompiled).
 
Performance results here: https://pastebin.com/TZhEPrqs (64-bit kernel 3.10.65, settings limiting cpufreq to 1008 MHz and clocking DRAM at 624 MHz)
 
Then I thought I take FriendlyELEC's Xenial image for their NEO Plus 2 (since same voltage regulation, switching between 1.1V and 1.3V toggled by PL06 pin) but to no avail. IIRC they implement some board detection logic and I ended up with no cpufreq support but running at 816 MHz, DRAM clocked at 672 MHz: https://pastebin.com/8wEaPiUp (quick note wrt iperf3 tests: with Armbian IRQ affinitiy settings numbers improve from 844/922 Mbits/sec to 895/940 Mbits/sec so once we have voltage regulation configured correctly on this board and can exceed 816 MHz cpufreq full GbE saturation will be possible)
 
With BSP kernel and without heatsink this thing idles at 55°C according to sysfs so it now wears a heatsink (and all tests above were made with a fan running in parallel). 

Just created the wiki page for the device: http://linux-sunxi.org/Orange_Pi_Zero_Plus

Got some nice feedback from JMicron explaining firmware versions.
0.1.x is for self-powered SATA HDD/SSD device 0.2.x is for bus-powered SATA HDD/SSD device  0.4.x is for self-powered SATA HDD/SSD/ODD device application (ODD --> optical disk) $higher-number.x means custom firmware (enclosure maker) I only asked for the firmware revisions of a couple of devices I've access to so not all possible variations are listed above (eg. 0.3.x or 0.5.x could mean 'bus-powered HDD/SSD/ODD device). But at least this explains a lot already.
 
When comparing 0.1.0.5 on ODROID HC1 and 0.4.0.5 with ROCK64 SATA cable the firmware revision (x.x.0.5) is the same while the ROCK64 cable firmware should also deal with optical drives. And the 0.2.x firmware being meant for bus-powered vs. self-powered suddenly explains the different behaviour I observed wrt JMS chip being present on the USB bus or not depending on whether there's a SATA drive connected or not (different consumption in different modes).
 
Anyway that needs some more understanding and testing but at least we don't need to be concerned about one JMS578 device (ODROID HC1) having a horribly outdated firmware 0.1.0.5 while ROCK64 SATA cable has a way higher (0.4.0.5) since FW revision is actually the same.
 
JMicron is still busy testing with a newer firmware revision solving the HDD spindown issues, once I get news or something to test I'll update this thread.

Just a little bit: https://forum.armbian.com/topic/4921-orange-pi-zero-plus-h5-chip/?do=findComment&comment=43667 (but with UAS active also CPU utilization slightly decreases so it's good anyway)
 

Little update on the NAS Expansion board: the first time I had this thing in my hands and gave it a try with mainline kernel I was surprised why the JMS578 chips on the board did not allow to use UAS. It looked always like this (lsusb -t):
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M With no other JMS578 device around I experienced this and since I'm currently testing with Orange Pi Zero Plus (still no UAS) and In the meantime JMicron provided us with a firmware update tool.... I thought I take the slightly higher JMS578 firmware revision from ROCK64 SATA cable (0.4.0.5) and update the NAS Expansion board (0.4.0.4) with:
root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -v Bridge Firmware Version: v0.4.0.4 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -v Bridge Firmware Version: v0.4.0.5 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -b ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.5.bin Backup the ROM code sucessfully. Open File Error!! root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -f ./JMSv0.4.0.5.bin -b ./JMSv0.4.0.4.bin Update Firmware file name: ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.4.bin Backup the ROM code sucessfully. Programming & Compare Success!! Success!
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 480M Please keep in mind that you need to update both JMS578 of course. I won't upload the newer firmware yet since thanks to Pine's TL Lim I'm in direct contact to JMicron now and it's about fixing another JMS578 firmware issue.

Wrapped in a warm hat is one of my TV boxes (Tronsmart Vega S96) .
Run test for a couple of hours. Here is the result at the end of the second hour. Such a conclusion in the console, no change for end hours, so stopped the test.
 
 

Someone said my name?  Sorry it took me a while to run this, but they offer a 100MHz clock speed and that takes a very long time to run--especially with one thread.  I have a high degree of confidence that there is no throttling as IIRC, I tested this setup with cpuburn and got no throttling.  I can't imagine this being more demanding than that!
 
Here's the data:
num-threads=4
100: execution time (avg/stddev): 99.4764/0.02 250: execution time (avg/stddev): 37.7647/0.01 500: execution time (avg/stddev): 18.6581/0.00 1000: execution time (avg/stddev): 9.2395/0.00 1296: execution time (avg/stddev): 7.1300/0.00 1536: execution time (avg/stddev): 6.0117/0.00 1656: execution time (avg/stddev): 5.5794/0.01 1680: execution time (avg/stddev): 5.4853/0.00 1752: execution time (avg/stddev): 5.2694/0.01 num-threads=1
 
100: execution time (avg/stddev): 369.1851/0.00 250: execution time (avg/stddev): 146.8992/0.00 500: execution time (avg/stddev): 73.3360/0.00 1000: execution time (avg/stddev): 36.6221/0.00 1296: execution time (avg/stddev): 28.2551/0.00 1536: execution time (avg/stddev): 24.4123/0.00 1656: execution time (avg/stddev): 22.0989/0.00 1680: execution time (avg/stddev): 21.7828/0.00 1752: execution time (avg/stddev): 21.3559/0.00  

Sadly, a working MALI won't help with kodi/xbmc performance, as it's purely a OpenGL ES device and nothing else. For media playback, you need a working CedarX driver, which is a completely separate thing. Luckily it's being worked on in the form of Cedrus project.

We have search feature: "mali mainline" would give you something useful. I merged it with an existing topic.
https://www.armbian.com/search_gcse/
 

To develop, test and debug dependencies and finally implement this feature cost/would cost roughly 5.000 (depend from which perspective you look) volunteering working hours from experts in the field. I am always happy when we receive a donation since it is a rear event. Sometimes people donate a box of beer which makes my wife angry and sometimes pcs of hardware.

Donations are like love. Unconditional.

TL;DR: The small H2+/H3 boards unlike their bigger siblings are all prone to overheating due to smaller PCB size (on the larger boards the PCB's groundplane acts somewhat as a large heatsink dissipating heat away from the SoC). Due to mainline kernel settings not being optimized currently all these boards are slower under constant load compared to legacy kernel. This should change but won't unless someone is looking into it and spends some time on this.
 
Two areas that deal with this overheating tendency or are somewhat related are
 
thermal protection / throttling: use the thermal sensor(s) inside the SoC to downclock various engines if specific tresholds are exceeded DVFS (dynamic voltage frequency scaling). All the small boards have either no voltage regulation (NanoPi NEO2) or a primitive one only switching between 1.1V and 1.3V  
With sun8i legacy kernel Armbian and linux-sunxi community members spent a lot of time and efforts on improving thermal/throttling performance. Read through the following as a reference please: https://github.com/armbian/build/issues/298
 
The result of our optimizations was a lot of better performance compared to Allwinner's defaults (that targeted only Android and preferred higher single thread performance over overall better performance, with Allwinner settings on an overheating system you could end up with just one or two active CPU cores pretty easily). Now with mainline kernel situation for the larger H3 boards is ok-ish (those boards have an I2C adjustable voltage regulator, voltage switching works fine grained, overheating isn't much of an issue anyway and performance is almost as good as with legacy kernel). But situation with the smaller boards needs some attention.
 
If we run the cheapest boards currently with mainline kernel then we're talking about these settings:
 
max cpufreq 1008 MHz (at 1.3V), next lower cpufreq 816 MHz at 1.1V, then 624/480/312/240/120 MHz defined 4 thermal trip points defined starting at 65"C with throttling, then using 75° and 90°C and shutting board down when 105°C are reached.  
With Armbian and using legacy kernel it's the following instead:
 
max cpufreq is 1200 MHz, then 1008 MHz still at 1.3V, at 912 MHz we switch to 1.1V and below are a few other cpufreqs available between 816 MHz and 1344 MHz Armbian's legacy kernel provides cpufreq steps every 48 MHz (allowing for fine grained throttling) On the small boards we use twice as much thermal trip points as mainline settings and our strategy is to switch to 912MHz@1.1V pretty early once throttling occurs  
These differences result in both lower 'normal' performance (since mainline kernel limits also single threaded tasks to 1GHz instead of 1.2GHz) and also 'full load' performance since DVFS/THS/throttling settings are not optimal and once the board reaches the first thermal trip point throttling is not that efficient compared to legacy.
 
It's easy to test: grab an OPi Zero, NanoPi Duo or any of the other H2+/H3 boards with primitive voltage regulation, then grab an Armbian OS image with legacy kernel (3.4.113 using fex settings) and one with mainline kernel. Execute on both
 
sudo rpimonitor -r (installs RPi-Monitor so you can enjoy nice graphs when connecting with a web browser to port 8888 of your machine) sudo rpimonitor -p (installs cpuminer which is a great tool to heatup your board and also to measure 'thermal performance' since spitting out khash/s values in benchmark mode minerd --benchmark (this is the actual benchmark running)  
With mainline kernel performance is lower. Expected result: same performance. What to do? Improve mainline settings.
 
BTW: Mainline settings currently are as they are since these were the values megi started with last year. Once numbers exist they're only dealt with copy&paste any more.

Yes
 
But we (and Icenowy in her branch) reverted that removal.
"Unstable bindings" doesn't mean that something isn't working or is unstable, it just means that DT maintainers are not happy with the way DT represents the hardware.
Today the 7th iteration of the attempt to resolve this was posted: https://groups.google.com/forum/#!topic/linux-sunxi/jxF_AIJP0VA

Or so  https://en.wikipedia.org/wiki/BogoMips#Timer-based_delays
 
Edit: sun8i legacy kernel is a 3.4 kernel so we have there high BogoMIPS values, starting with 3.6 on ARM the meaning is something different, now no DVFS so 'next' is a lot slower than 'default' and even if DVFS will work soon those small H3 board with mainline kernel will still be slower compared to before since 
 

NEXT stable. Made from a recent mainline stable base. We have currently 100+ patches on top and few more are expected to make those little boards usable with a modern kernel. Just hundreds of working hours and we are done  

I have one Orange Pi Zero which had Wi-Fi working in the beginning and after some days Wi-Fi stopped working. I'm always surprised that hardware that cheap as an Orange Pi Zero works in the first place. I remember the last thing I did before realizing that I had broken Wi-Fi on my Zero was taking a nap (you remember the last thing you did was trying out another kernel). But I don't think me taking a nap is related to hardware becoming broken.

It's not our decision to put this chip on board, we don't sell boards, we only try to make them usable. We already wasted an enormous amount of our extremely scarce time on this piece of crap and got nowhere. We decided to drop support - you can find the reason on this forum if you do some search.
 
Forget about that there is a WiFi chip on board.
 
As I already told you - just about any other chip works O.K. also in AP mode. RPi has very similar Wifi chip which you can find in Opi Zero 2+, Neo Air, Banana PRO, ... it works just fine, more than 1mbit at a distance of 10m.
 
 
Time from people who are willing to help you might cost way more.

So, 8-12$ (depends if you calculate the price for an orange pi with or without shipping) is expensive? I do some testings with the opi pc+ in AP mode, but to be  honest I like the 'connecting sbc to access point wired, and connect nodes normally to this ap' approach more. It's less load on my SBC and capabilities of my AP are better (throughput, which is of no interest in your case but ping seems also to be better).
 
Just have a look with the google search engine here if you find something that fulfills your needs. It's a bit out of my knowledge cause my sbcs are mostly wired.  
https://www.armbian.com/search_gcse/

Just about any board has better wireless chip than Orange Pi Zero but don't expect router class experiences on any other since you won't find them. Get something with RT5572, RT3572, RT3070, AR9271, ... first two will go up to 300mbps at 5Ghz, while last two up to 150mbps at 2.4. Access point mode of course.
 
With something like this: http://www.ebay.de/itm/ALFA-Networks-AWUS052NH-2-4-5-GHz-USB-WLAN-Adapter-300-MBit-Ralink-RT3572- you could have (very good) router class experience. Long range and presumably a lot more clients than on those on board el cheapo wifi chips.
 

I think all Armbian supported boards that have wifi chip can operate in access point mode. The question is a quality/speed/distance and max. client count. All this is fairly limited.

If only any wifi were so simple...
 
 
https://github.com/fifteenhex/xradio
is an example of someone working on this.  The readme excerpt below came from there:
Also: The xr819 chip/firmware drops tons and tons of frames with FCS errors and this makes performance horrible at best. Most people have lost interest in having anything to do with the xr819 because of people being idiots and demanding that issues that are incredibly hard to fix without documentation be fixed because they spent $8 on a board and somehow people that got exactly zero of their $8 are responsible. Moral of the story: If you're going to post nasty things on the interwebs and demand people fix stuff because reasons at least have a bunch of packet dumps etc and have some idea about what you're talking about.  

When you started with a freshly burned SD-Card running mainline something like this should appear within your first login.

 
If you did it via armbian-config, something like this appears:

or this (if you moved to nightly):

And if you had a brief look on armbian download page you would see something like this:

and this:

 
I can't repeat your experiment, booted a 4.11.7 image (wifi was visible, cause not deactivated on this image), followed by booting a 3.4.113 image and wifi worked, without any issues (no long-term test!!).. So it might be hard to figure out why wifi on your board is broken now. If you look around here, you'll see that wifi on this board is somehow questionable (just an example, you'll find multiple threads about this issue).
A personal opinion: Using a older nightly with 4.11.7 just cause wifi wasn't deactivated by default isn't really smart (you got maybe wifi, but cause you've to freeze kernel and board upgrades, you'll miss all the improvements on board support). It seems that the wifi driver for XR819 is in such a bad shape that nobody wants (or is able) to work on it. If I would need wifi on one of my opi0, I'd go for a usb wifi stick. If I would need wifi permanently, I'd go for another board with better wifi support.
 

Stretch is possible, but kernel for this board is not quite ready. We are working round the clock to finish this in planned due in 1-2 months.
 
Current status: 
HDMI DRM driver, CEC, HDMI audio, I2S (requires overlays)
Missing features: DVFS, THS U-boot is most likely broken

Which is not possible with all Mali GPUs Allwinner used till H6.

So we (or rather Maxime/Free-electrons) got r6p2 Mali400 armhf blobs with a good license. No arm64, no mali450 (?), so I wouldn't call this "closed"

No, at least this seems to be fixed. In any case overlays functionality affects stable branches too, so it's not "development, not supported", so thanks for the bug report.