tkaiser

Welcome here! Just looked through your commits and it's really great seeing MTK become commited to open source in the meantime and how far you already got!
 
MT7623 hardware features sound great (is there something like the 'MT7623N Datasheet for Development Board' available for MT7623A too?) and I'm really looking forward to devices based on MT7623N/MT7623A from reputable board makers hopefully soon.
 
Wrt Banana Pi R2 unfortunately it's challenging. You chose to cooperate with a partner here who has a horrible history: not releasing sources, not releasing schematics (timely), providing insufficient/incorrect information (no one right in his mind would call this abstruse copy&paste mess 'technical documentation'), advertising their products with wrong specs (numbers too high), not supporting their own products responsibly, not cooperating with open source community (even ignoring every try to help, see their reluctance to merge pull requests above who would fix tons of security issues on another device, or fix stability issues and so on) and most importantly their inability to even realize these problems (an unbelievable high level of ignorance, that's most probably their main problem).
 
This could all be problems of the past but as you can see clearly it's not. All of the above still applies, Sinovoip fails at unbelievable low levels and just recently they crossed a red line and censored in their forum posts they found to be 'useless' (eg. the only one analyzing R2's boot log and giving some hints). In the meantime they stepped a bit back and reverted their censorship partially but the whole situation is still a mess and just inacceptable. Almost all parts of open source community simple gave up on them and only a few people still try hard to help them (even if they're too ignorant to realize this).
 
You know better than anyone else that MTK has not the best reputation in open source circles based on the past (no sources available, NDA required and so on). And while I highly appreciate MTK opening themselves now and becoming part of the open source world all your efforts are at risk! Soon your first open source dedicated board will available. The board maker you cooperate here has obviously no clues what people want to do later with your device (otherwise they would test network and storage performance and so on and focus on reasonable use cases and not moronically try to use this board as a 'Desktop Linux' thingie). And all of the above listed problems unfortunately still apply in 2017, it's only needed to read through this thread: http://forum.banana-pi.org/t/banana-pi-bpi-r2-open-source-smart-router-with-mtk-7623n-design/2697 (at the time of this writing still 11 posts of mine censored/hidden).
 
Soon all of the above will also be associated with MTK and your open source efforts if you don't step in now. I already fear the first R2 reviews appearing in the wild (since software/support situation will be as horrible as it was all the times in the past with SinoVoip). Please try to escalate this problem with a manager, let representatives get in touch with responsible people at SinoVoip (is Foxconn/Nora Lee also involved?). I think it's really necessary that your partner wakes up and ensures that the problems outlined above get addressed. Otherwise I fear that your whole 'dev board' and open source engagement will fail with the first device since without situation improving R2 starting to sell will just be the same fiasco as with R1 back then (but this time all those people talking about 'If you want open source avoid MTK' will simply move into 'told you so!' mode and blame Mediatek instead of your hardware partner here suffering still so badly from the same problems they had already 2.5 years ago -- most notably ignorance) 
 

I would call the price/performance not good but simply awesome today given we get ultra performant cards like the 32GB SanDisk Ultra A1 for as low as 12 bucks currently: https://www.amazon.com/Sandisk-Ultra-Micro-UHS-I-Adapter/dp/B073JWXGNT/ (I got mine 2 weeks ago for 13€ at a local shop though). And the A1 logo is important since cards compliant to A1 performance class perform magnitudes faster with random IO and small blocksizes (which pretty much describes the majority of IO happening with Linux on our boards).
 
As can be seen in my '2018 A1 SD card performance update' the random IO performance at small blocksizes is magnitudes better compared to an average/old/slow/bad SD card with low capacity:
average 4GB card SanDisk Ultra A1 1K read 1854 3171 4K read 1595 2791 16K read 603 1777 1K write 32 456 4K write 35 843 16K write 2 548 With pretty common writes at 4K block size the A1 SanDisk shows 843 vs. 35 IOPS (IO operations per second) and with 16K writes it's 548 vs. 2 IOPS. So that's over 20 or even 250 times faster (I don't know the reason but so far all average SD cards I tested with up to 8 GB capacity show this same weird 16KB random write bottleneck -- even those normal SanDisk Ultra with just 8GB). This might be one of the reasons why 'common knowledge' amongst SBC users seems to be trying to prevent writing to SD card at all. Since the majority doesn't take care which SD cards they use, test them wrongly (looking at irrelevant sequential transfer speeds instead of random IO and IOPS) and chose therefore pretty crappy ones.
 
BTW: the smallest A1 rated cards available start with 16GB capacity. But for obvious reasons I would better buy those with 32GB or even 64GB: price/performance ratio is much better and it should be common knowledge that buying larger cards 'than needed' leads to SD cards wearing out later.
 

The nice dashboard screenshot above is used by @Fourdee to explain why DietPi is superiour to Armbian: 'With #DietPi, logs and DietPi scripts are mounted to RAM , this reduces SD card write operations vastly' -- while I don't understand the purpose to 'mount scripts to RAM' of course the idea to cache logs into RAM is great! That's why Armbian does it since 2014 already.
 
While the above 'proof' is somewhat questionable (watching a 5 min period in a dashboard and once there's activity in one graph taking a screenshot with numbers without meaning) let's look into what makes DietPi that superiour compared to Armbian since it's always a great idea to improve even if that means taking over other project's USPs.
 
For whatever reasons DietPi dropped support for all Orange and Banana Pis recently (seems this started with a conversation between @Igor and @Fourdee on Twitter, then continued here and ended up there) so I had to take another board to do a direct comparison. The only boards that are supported by both projects are now Pine64, Rock64, Tinkerboard, some NanoPi and the ODROIDs. I chose Rock64 mostly to ensure that we use same kernel and almost same settings (Armbian's philosophy is to fix as much as possible upstream so our usual performance fixes went into ayufan's Rock64 build scripts DietPi in this case is relying on by accident so even DietPi users can continue to benefit from our work  )
 
I took latest official DietPi image for Rock64 and the first surprise was the rootfs being pretty small and entirely full so no way to proceed:
/dev/mmcblk1p7 466M 453M 0 100% / For whatever reasons DietPi chose to overtake ayufan's partition layout (for users new to DietPi: this is always just someone else's Debian image processed manually and by some scripts until it becames 'DietPi') but their 'dietpi-drive_manager' responsible to resize the rootfs seems not to be able to cope with this (I wanted to report it to DietPi but there's already a report that gets ignored and it seems I can't comment there).
 
Edit: Ah, it seems @Fourdee blocked me from helping them entirely. I wanted to assist DietPi folks over at https://github.com/Fourdee/DietPi/issues/1550 but can't point them to fix the thermal issues they're running into again or why it's a bit weird to reintroduce the 'rootmydevice' issue again or why the new Allwinner BSP code is not such a great idea due to non-existing dvfs/thermal support  
 
Fortunately our scripts below /usr/local/sbin/ were not deleted by DietPi so I simply called /usr/local/sbin/resize_rootfs.sh which instantly resized the rootfs partition and was then able to continue. For whatever reasons it took 3 whole reboots to get DietPi upgraded to their latest version v6.2 but then I was able to do so some measurements:
 
I then downloaded our Rock64 nightly image (based on Ubuntu Xenial but that doesn't matter that much -- as we all know the userland stuff is close to irrelevant since kernel and settings matter) and did the same thing. But no reboot needed since for whatever reasons DietPi remained on pretty outdated 4.4.77 kernel so I chose to not update Armbian's kernel to our 4.4.115 but to remain at 4.4.77 too:
 
Let's look at the results leaving aside the various performance and security issues DietPi suffers from since not relevant if we want to look at stuff where DietPi outperforms Armbian. First 'idle behaviour':
DietPi Armbian DRAM used: 39 MB (2%) 44 MB (2%) processes: 120 134 cpufreq lowest: 97.5% 99.8% cpufreq highest: 2.0% 0.1% idle temp: 46°C 43.5°C %idle percent: 99.95% 99.98% So we're talking more or less about identical numbers. 'Used' memory after booting is 2% of the available 2GB (anyone thinking 'free' RAM would be desirable on Linux... please try to educate yourself: https://www.linuxatemyram.com), the count of processes reported by ps is almost the same, cpufreq behaviour, %idle percentage and temperatures are also the same (DietPi temperature readout is somewhat flawed since their 'cpu' tool affects system behaviour negatively).
 
Even if Armbian ships with almost twice as much packages installed by default the process count doesn't differ that much (and idling processes really don't hurt anyway) and used memory after booting also doesn't differ significantly. But this 'boot and sit there in idle' use case isn't that relevant anyway and in situations when RAM is really needed I would assume Armbian users are in a much better position since we ship with zram active allowed to use half of the physical DRAM (see here for a brief introduction to zram).
 
So far I don't see that much advantages (none to be honest) but most probably I missed something?
 
Anyway: let's continue focussing on storage utilization and 'use':
DietPi Armbian size img.7z: 104 MB 223 MB (x 2.1) size img: 668 MB 1.6 GB (x 2.5) rootfs size: 457 MB 1.2 GB (x 2.7) packages: 229 436 (x 1.9) commit interval: 5 s 600 s kB_wrtn: 156 KB 448 KB (x 2.9) kB_read: 1008 KB 5912 KB (x 5.9) So both compressed and uncompressed image sizes are much larger with Armbian, same goes for used space on the rootfs which is understandable given that Armbian does not try to be as minimalistic as possible (see the count of pre-installed packages). I don't think going minimalistic is something desirable though we could think about removing development related packages from default installations as @zador.blood.stained suggested already. Maybe it's worth to adjust the rootfs partition size calculation to use slightly less so the uncompressed image size can be a little bit smaller?
 
Anyway: for people being concerned about smallest image size possible even without leaving out packages from default install simply building an own image and then switching from ext4 to btrfs does the job since reducing image size to around ~60% (one of Armbian's advantages is that our images are not hand-crafted unique 'gems' but the fully automated result of our build system so everyone on this earth can simply build his own Armbian images suiting his own needs).
 
And besides that I really see no benefit in trying to get the rootfs size smaller since we surely don't want to start to encourage users to write Armbian images to old and crappy SD cards with less than 4GB size (though I already consider 4GB cards nothing anyone should use these days since almost all those cards are insanely slow). Let's better continue to educate our users about the importance to choose good and reliable SD cards!
 
Now looking at the last 3 lines above. I executed an 'iostat -y 3600' to query the kernel about the total amount of data read and written at the block device layer. within one whole hour With DietPi/Stretch 156KB/1008KB (write/read) were reported and with Armbian/Xenial 448KB/5912KB (write/read). All numbers are too low for further investigations though something is worth a look: that's the default rootfs 'commit interval.' DietPi seems to use ext4 defaults (sync every 5 seconds to SD card) while in Armbian we choose a somewhat high 10 minute value (commit=600).
 
So while with Armbian and 448 KB written in one hour almost three times as much data has been written at the block device layer it might be possible that the 156 KB written by the DietPi installation caused more wear at the flash layer below due to a phenomenon called Write Amplification (TL;DR version: writes at the flash layer happen at 'page sizes', usually 8K, and by using a high commit interval somewhat larger data chunks will be written only every few minutes which can result in significantly less page writes at the flash layer compared to writing every few seconds smaller chunks of data. Adding to the problem once a card is 'full' now we're talking about much higher Write Amplification since now not just pages are written but usually whole Erase Blocks are affected that are much larger. So please choose your SD card wisely and always use a much larger capacity than needed since there's no TRIM with SD cards in Linux!)
 
It would need a lot of more detailled analysis about this write behaviour but IMO it's not worth the efforts and Armbian's 10 min commit interval does a great job reducing further SD card wearout (anyone with too much spare time? Grab 'iostat 5' and 'iotop -o -b -d5 -q -t -k | grep -v Total' and start to analyse what's happening at the block device and application layer forgetting about the filesystem layer in between!)
 
So where's some room for improvement when comparing our defaults with DietPi's?
 
Maybe removing development related packages from default package list? Maybe tuning rootfs partition creation to use slightly less space? Mostly unrelated but an issue: improving our log2ram behaviour as already discussed?

Nope. Netdata is awesome. All I tried to explain is why 'armbianmonitor -r' was an attempt to generate insights about SBC behavior 3 years ago and why netdata is not sufficient for this purpose. Once you look at results the data collection approach completely changes system behavior --> useless for this use case.
 
 
IMO you should take care of cpufreq scaling on this class of devices and if netdata should generate insights and not just fancy graphs you might want to explore EAS.

Blender test. Checking the relevance of SETTINGS instead of focusing on irrelevant hardware details like DDR3 vs. DDR4:
RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=1000: 1:15:31 RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:06:59 RockPro64, Ubuntu Cosmic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:01:11  
That's 8:30 minutes difference due to switching from CONFIG_HZ=1000 to CONFIG_HZ=250. Check %sys vs. %user below (iostat 60 output). And why is Cosmic faster than Bionic if it's exactly same Blender version? Since Cosmic (18.10) uses GCC 8.2 while Bionic (18.04) uses GCC 7.3 to build the packages. So by switching from default SoC vendor kernel settings to something better and by letting modern compilers do their job we get almost 25% performance 'for free'.
 

There's a lot more. I just updated my post above with GCC 8.2 results. When Blender is built with a more recent compiler rendering gets faster (this is one of the many reasons why this Phoronix stuff is so bad -- Michael Larabel doesn't educate his users about such basics but throws a bunch of meaningless numbers and graphs at them to create the impression benchmarking would be something magic).
 
And if you build Blender from source with appropriate compiler flags (not those ultra conservative distro defaults, especially not with 'stable' distros like Debian and Ubuntu) then it will be even faster.
 
 
Very unlikely. And performance is already known, check sbc-results for PineH64 (board vendors don't matter, it's only about the SoC in question). And of course settings matter. If you use one of those crappy Xunlong images there's no need to test further since they're known for using crappy Allwinner defaults that suck.

Blender test. Checking the relevance of SETTINGS instead of focusing on irrelevant hardware details like DDR3 vs. DDR4:
RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=1000: 1:15:31 RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:06:59 RockPro64, Ubuntu Cosmic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:01:11  
That's 8:30 minutes difference due to switching from CONFIG_HZ=1000 to CONFIG_HZ=250. Check %sys vs. %user below (iostat 60 output). And why is Cosmic faster than Bionic if it's exactly same Blender version? Since Cosmic (18.10) uses GCC 8.2 while Bionic (18.04) uses GCC 7.3 to build the packages. So by switching from default SoC vendor kernel settings to something better and by letting modern compilers do their job we get almost 25% performance 'for free'.
 

'Around for a long time'? The point is not since when settings exist but what the defaults are and why people interested in maximum performance should care about such settings. This was the context:
 
 
And by looking at both tinymembench and Blender scores it should be pretty obvious that this makes a difference for workloads that utilize CPU cores fully... just to explain why comparing RK3399 and S922X benchmark scores doesn't make that much sense as long as such essential stuff is not also considered.
 
@NicoD: I explained in my former post how to check for such settings, simply check the spoiler.

Blender test. Checking the relevance of SETTINGS instead of focusing on irrelevant hardware details like DDR3 vs. DDR4:
RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=1000: 1:15:31 RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:06:59 RockPro64, Ubuntu Cosmic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:01:11  
That's 8:30 minutes difference due to switching from CONFIG_HZ=1000 to CONFIG_HZ=250. Check %sys vs. %user below (iostat 60 output). And why is Cosmic faster than Bionic if it's exactly same Blender version? Since Cosmic (18.10) uses GCC 8.2 while Bionic (18.04) uses GCC 7.3 to build the packages. So by switching from default SoC vendor kernel settings to something better and by letting modern compilers do their job we get almost 25% performance 'for free'.
 

Same with S922X, simply check @rooted's sbc-bench results (where even the cpufreq OPP are checked and confirmed). The problem is not thermal but reliability/undervoltage due to the firmware running on the Cortex-M3 controlling DVFS which can be clearly seen by running the most heavy load called cpuminer. 
 
Quoting myself: ''Overclocked' executions with both CPU clusters set to 2.0 GHz showed reliability issues most probably due to DVFS undervoltage (cpuminer quit almost immediately here while it ran only 50 seconds there -- this tool since being a load generator checking for data corruption can also be used for reliability testing but I would prefer our StabilityTester instead)'
 
I already suggested to Justin and Dongjin to take our StabilityTester approach to provide N2 users with an easy way to check for undervoltage/instabilities since a lot of those users will activate the 'overclocking' settings (most probably these are undervolting settings at the same time based on results) and then end up with silent data corruption and/or crashes (all the great results of trying to get laughable 7%-8% performance gain almost nobody is able to notice).
 
 
Simply do a web search for CONFIG_HZ

Since the last round of Moronix madness didn't include a single RK3399 device I decided to give two rounds of silly kitchen-sink benchmarking a try using the 'reputable' Phoronix Test Suite:
 
https://www.cnx-software.com/2019/02/13/odroid-n2-amlogic-s922x-sbc/#comment-560987
 
For those thinking the N2 results would be better when running bare metal... I doubt it since of course I checked with sbc-bench first:
here's running sbc-bench on 'ODROID Bench' inside a container: http://ix.io/1BEM and there's the results Dongjin (@tobetter) shared with me few days ago (look at the timestamp, Hardkernel tested already weeks ago so they were pretty clear about which benchmark results to publish and which not): http://ix.io/1BsF The ODROID-N1 numbers are representative for each and every RK3399 device out there running at 2.0/1.5GHz with CONFIG_HZ=250. Scores might improve once Rockchip provides new DRAM initialization BLOBs especially on those boards using LPDDR4.

Funny place here...
 
All the RK3399 'benchmark' results collected so far were done with CONFIG_HZ=1000 (good for a responsive UI in Android and Linux, not so good for normal computing or server tasks) while everywhere around CONFIG_HZ=250 is the default. Is this affecting Blender or not? Anyone tested so far (latest ayufan images switched to CONFIG_HZ=250)? Anyone into Active Benchmarking instead of just firing up the next round of kitchen-sink benchmarks in fire-and-forget mode collecting more numbers without meaning? The challenge with 'overclocking' the N2 is not trottling but stability/reliability as can be easily seen with the cpuminer tests that are sufficient for reliability testing (see N2 notes here). The DVFS OPP are defined in a closed firmware BLOB and the whole thing happens on the Cortex-M3 inside S922X. N2 has no LPDDR4 but DDR4, memory performance depends not just on type of memory but on DRAM initialization (done with BLOBs on both RK3399 and S922X). TL Lim said Rockchip will provide a new BLOB to make use of faster LPDDR4 access on RockPro64 in 2018 but I don't know whether this has already happened or not Memory benchmark scores depend on stuff like dmc or CONFIG_HZ since how would you explain better memory performance when switching from CONFIG_HZ=1000 to CONFIG_HZ=250 on RK3399 (previously known as difference between RK's 4.4 kernel and mainline though it's just different CONFIG_HZ defaults). Same with executing a memory benchmark on a little vs. big core Memory bus width is different between S922X and RK3399 (32-bit vs. 64-bit) but whether this will result in faster execution depends on a lot of factors (application in question, DRAM initialization BLOB, kernel settings, kernel tunables, see dmc memory governor with RK3399, and so on)  
Added some updates to https://github.com/ThomasKaiser/Knowledge/blob/master/articles/Quick_Preview_of_ODROID-N2.md#updates

Really looking forward to this HAT
 
BTW: I've not the slightest idea how much efforts and initial development costs are needed for such a HAT. But in case the Marvell based 4-port SATA solution will be somewhat expensive maybe designing another one with an ASMedia ASM1062 (PCIe x2 and 2 x SATA) and just one Molex for 2 drives might be an idea. Could be one design made for NEO4 that will work on M4 too with a larger (or dual-purpose) HAT PCB?

When did we do that the last time? Ah, that must have be Stone Age or was it already the Dark Ages?
 
That reminds me to check u-boot's algorithm to generate the MAC address based on sunxi SoC's SID to create dnsmasq entries automagically based on the SID of the board in question. 
 
BTW: One of the many Armbian advantages is the ability to deploy devices headless without crap like connecting a serial console first or fiddle around in configuration files. And static IP addresses can be assigned in a central location and not by editing text files on a bunch of devices. It's 2016 and not 1970 any more!

My english is better than that

Armbianmonitor: http://ignorance.stupidity Which kind of idiot 'designed' 4 checkboxes without an alternative each that all have to be checked? What's the purpose of this mess? Anyone awake here?
 
 

Nope. Needs 3.9 or above.

Of course. You need to fix this otherwise everything you do is just a waste of time. And it's under-VOLTAGE and not under-current so as long as you ignore Ohm's law you're getting nowhere. The problem is high resistance and most probably (and as usual) the cable between PSU and device is to blame.

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.

Hmm... to summarize the 'OpenSSL 1.0.2g  1 Mar 2016' results for the 3 boards/SoC tested above with some more numbers added (on all A53 cores with crypto extensions enabled performance is directly proportional to CPU clockspeeds -- nice):
ODROID N1 / RK3399 A72 @ 2.0GHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 377879.56k 864100.25k 1267985.24k 1412154.03k 1489756.16k aes-192-cbc 325844.85k 793977.30k 1063641.34k 1242280.28k 1312189.10k aes-256-cbc 270982.47k 721167.51k 992207.02k 1079193.94k 1122691.75k ODROID N1 / RK3399 A53 @ 1.5GHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 103350.94k 326209.49k 683714.13k 979303.08k 1118808.75k aes-192-cbc 98758.18k 291794.65k 565252.01k 759266.99k 843298.13k aes-256-cbc 96390.77k 273654.98k 495746.99k 638750.04k 696857.94k MacchiatoBin / ARMADA 8040 @ 1.3GHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 360791.31k 684250.01k 885927.34k 943325.18k 977362.94k aes-192-cbc 133711.13k 382607.98k 685033.56k 786573.31k 854780.59k aes-256-cbc 314631.74k 553833.58k 683859.97k 719003.99k 738915.67k Orange Pi One Plus / H6 @ 1800 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 226657.97k 606014.83k 1013054.98k 1259576.66k 1355773.27k aes-192-cbc 211655.34k 517779.82k 809443.75k 963041.96k 1019251.37k aes-256-cbc 202708.41k 470698.97k 692581.21k 802039.13k 840761.34k NanoPi Fire3 / Nexell S5P6818 @ 1400 MHz (4.14.40 64-bit kernel): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 96454.85k 303549.92k 637307.56k 909027.59k 1041484.46k aes-192-cbc 91930.59k 274220.78k 527673.43k 705704.40k 785708.37k aes-256-cbc 89652.23k 254797.65k 460436.75k 594723.84k 648388.61k ROCK64 / Rockchip RK3328 @ 1296 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 163161.40k 436259.80k 729289.90k 906723.33k 975929.34k aes-192-cbc 152362.85k 375675.22k 582690.99k 693259.95k 733563.56k aes-256-cbc 145928.50k 337163.26k 498586.20k 577371.48k 605145.77k PineBook / Allwinner A64 @ 1152 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 144995.37k 387488.51k 648090.20k 805775.36k 867464.53k aes-192-cbc 135053.95k 332235.56k 516605.95k 609853.78k 650671.45k aes-256-cbc 129690.99k 300415.98k 443108.44k 513158.49k 537903.10k Espressobin / Marvell Armada 3720 @ 1000 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 68509.24k 216097.11k 453277.35k 649243.99k 741862.06k aes-192-cbc 65462.17k 194529.30k 375030.70k 503817.22k 559303.34k aes-256-cbc 63905.67k 181436.03k 328664.06k 423431.51k 462012.42k OPi PC2 / Allwinner H5 @ 816 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 102568.41k 274205.76k 458456.23k 569923.58k 613422.42k aes-192-cbc 95781.66k 235775.72k 366295.72k 435745.79k 461294.25k aes-256-cbc 91725.44k 211677.08k 313433.77k 362907.31k 380482.90k Banana Pi R2 / MediaTek MT7623 @ 1040 MHz and MTK Crypto Engine active type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 519.15k 1784.13k 6315.78k 25199.27k 124499.22k aes-192-cbc 512.39k 1794.01k 6375.59k 25382.23k 118693.89k aes-256-cbc 508.30k 1795.05k 6339.93k 25042.60k 112943.10k MiQi / RK3288 @ 2000 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 87295.72k 94739.03k 98363.39k 99325.95k 99562.84k ODROID-HC1 / Samsung Exynos 5244 @ (A15 core @ 2000 MHz): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 78690.05k 89287.85k 94056.79k 95104.34k 95638.87k aes-192-cbc 69102.10k 77545.47k 81156.61k 81964.71k 82351.45k aes-256-cbc 61715.85k 68172.80k 71120.73k 71710.72k 72040.45k ODROID-C2 / Amlogic S905 @ 1752 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 51748.63k 59348.22k 62051.33k 62763.35k 62963.71k aes-192-cbc 46511.57k 52507.95k 54599.08k 55151.27k 55312.38k aes-256-cbc 42094.22k 46302.95k 47941.46k 48372.74k 48513.02k NanoPi M3 / Nexell S5P6818 @ 1400 MHz (3.4.39 32-bit kernel): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 44264.22k 54627.49k 58849.88k 59756.35k 60257.62k aes-192-cbc 39559.11k 47999.32k 51095.30k 51736.15k 52158.46k aes-256-cbc 35803.41k 42665.24k 44926.47k 45733.21k 45883.39k Clearfog Pro / Marvell Armada 38x @ 1600 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 47352.87k 54746.43k 57855.57k 58686.12k 58938.71k aes-192-cbc 41516.52k 47126.91k 49317.55k 49932.63k 50151.42k aes-256-cbc 36960.26k 41269.63k 43042.65k 43512.15k 43649.71k Raspberry Pi 3 / BCM2837 @ 1200 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 31186.04k 47189.70k 52744.87k 54331.73k 54799.02k aes-192-cbc 30170.93k 40512.11k 44541.35k 45672.11k 45992.62k aes-256-cbc 27073.50k 35401.37k 38504.70k 39369.39k 39616.51k Banana Pi M3 / Allwinner A83T @ 1800 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 36122.38k 43447.94k 45895.34k 46459.56k 46713.51k aes-192-cbc 32000.05k 37428.74k 39234.30k 39661.91k 39718.95k aes-256-cbc 28803.39k 33167.72k 34550.53k 34877.10k 35042.65k Banana Pi R2 / MediaTek MT7623 @ 1040 MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 22082.67k 25522.92k 26626.22k 26912.77k 26995.37k aes-192-cbc 19340.79k 21932.39k 22739.54k 22932.82k 23008.60k aes-256-cbc 17379.62k 19425.11k 20058.03k 20223.66k 20267.01k Edit: Added results for Pinebook and ODROID-HC1 ensuring both were running at max cpufreq
 
Edit 2: Added cpufreq settings for each tested device. Please note throttling dependencies and multi-threaded results below
 
Edit 3: Added Banana Pi M3 single thread performance above. Performance with 8 threads sucks since A83T throttles down to 1.2GHz within 10 minutes and overall AES253 score is below 190000k.
 
Edit 4: Added EspressoBin numbers from here. Another nice example for the efficiency of ARMv8 crypto extensions.
 
Edit 5: Added NanoPi M3 numbers from there.
 
Edit 6: Added Clearfog Pro numbers (Cortex-A9 -- unfortunately OpenSSL currently doesn't make use of CESA crypto engine otherwise numbers would be 3 to 4 times higher)
 
Edit 7: Added Banana Pi R2 numbers from here (Cortex-A7, cpufreq scaling broken since ever so SoC only running with 1040 MHz, numbers might slightly improve once MTK manages to fix cpufreq scaling)
 
Edit 8: Added numbers for ARMADA8040 (A72) from CNX comment thread.
 
Edit 9: Added RK3288 (Cortex A17) numbers from here.
 
Edit 10: Added RPI 3 (BCM2837) numbers. Please be aware that these are not Raspbian numbers but made with 64-bit kernel and Debian arm64 userland. When using Raspbian you get lower numbers!
 
Edit 11: Added Allwinner H6 numers from here.
 
Edit 12: Added RK3399 numbers from here.
 
Edit 13: Added new S5P6818 numbers since now with mainline 64-bit kernel ARMv8 crypto extensions are available

Overview
 
(Disclaimer: The following is for techies only that like to dig a bit deeper. And if you're not interested in energy-efficient servers then probably this is just a waste of time  ) 
 
EDIT: Half a year after this poorly designed SBC has been released just one of the many design flaws has been fixed: Micro USB for DC-IN has been replaced by the barrel jack that was present on the pre-production batches. If you were unfortunate to get a Micro USB equipped M3 please have a look here how to fix this. Apart from that check the Banana forums what to expect regarding software/support first since this is your only source)
 

 
SinoVoip sent me a review sample of the recently shipped so called "Banana Pi M3" yesterday. It's a SBC sharing name and form factor of older "Banana Pi" models but is of course completely incompatible to them due to a different SoC, an A83T (octa-core Cortex-A7 combined with a PowerVR SGX544 GPU). For detailed and up-to-date informations please always refer to the linux-sunxi wiki.
 
This new model distinguishes itself from the Banana Pi M2 with twice as much CPU cores and DRAM (LPDDR3), 8 GB eMMC onboard and BT4.0. And compared to the "M1" (the original Banana Pi) it features also 802.11 b/g/n Wi-Fi. Unlike the M2 the M3 is advertised as being SATA capable. But that's not true, it's just an onboard GL830 USB-to-SATA bridge responsible for horribly slow disk access. Unfortunately the GL830 and both externally available USB ports are behind an internal USB hub therefore all ports have to share bandwidth this way and use just one single USB connection to the SoC.
 
Since my use cases for ARM boards are rather limited you won't find a single word about GPIO stuff (should work if pin mappings are defined correctly), GPU performance, BT, Wi-Fi or Android. Simply because I don't care 
 
Getting Started:
 
The board arrived without additional peripherals (no PSU) therefore you need an USB cable using a Micro-USB connector to power the board. Both DC-IN and USB-OTG feature an Micro-USB connector which is bad news since pre-production samples had a real DC-In connector (4.0mm/1.7mm barrel plug, centre positive like the M2). I suffered from several sudden shutdowns under slight load until I realized that I used a crappy cable. Many (most?) USB cables lead to voltage drops and when the board demands more power it gets in an undervoltage situation and the PMU shuts off.
 
Same will happen to you unless you can verify that you've a good cable. I did not succeed querying the M3's powermanagement unit (PMU) regarding available voltage (/sys/devices/platform/axp81x_board/axp81x-supplyer.47/power_supply/ac/voltage_now shows always 0). This was a lot easier with the older Banana Pi M1: Here you can watch my cable being responsible for voltage drops under high load (I accidentally used this again with the M3).
 
To avoid the crappy Micro-USB connector (limited to 1.8A maximum by specs and tiny contacts) you can desolder it and solder a cable or a barrel plug -- the PCB is already prepared for the latter. Or ask SinoVoip if they can fix this mistake with the next batch of PCBs. On the bottom side of the PCB there are also solder pads for a Li-Ion battery. It has to be confirmed whether the AXP813 PMU can also be fed with 5V through the Li-Ion connector since this is the preferred way to fix the faulty power design other SinoVoip products show.
 
One final word regarding power: It seems currently something's wrong with power initialisation in the early boot stages (u-boot). With a connected bus-powered USB disk the board won't start or immediately shut down when the disk is connected within the first 10 seconds. I didn't verify when exactly because if you've a look at SinoVoip's commit log it seems they began to fix many obvious bugs just right now after they already started shipping the board (we've seen that with the M2 also).
 
First Showstoppers:
 
Since the board came with an unpopulated eMMC (why the heck?) I had to try out the available OS images from the banana-pi.org download site. Unlike everyone else on this planet they don't provide MD5/SHA1 checksums to be able to check integrity of downloads and even if you tell them that they've uploaded corrupted images they don't care. From 4 OS images 3 are corrupted (according to unzip) and all failed soon after boot with kernel panics. I tried the Android image to verify FEL mode works.
 
But since Android is of zero use for me, I decided to build an own OS image from an Ubuntu distro running on the Orange Pi where I had the SD-card inserted. Since details are boring just as a reference. From then on I used this Ubuntu image and exchanged only the freshly built stuff from SinoVoip's BSP Github repo (3.4.39 kernel, modules, bootloader and also simple things like hardware initialisation since kernel/u-boot they prefer does NOT support script.bin)
 
First Impressions:
 
Heat (dissipation):
 
The A83T needs a heatsink otherwise you won't be able to benefit from its performance. Allwinner's 3.4.39 kernel provides 'budget cooling' using 2 techniques: thermal throttling and shutting down CPU cores. You can define this 'thermal configuration' in sysconfig.fex and have to take care that you understand what you're doing since if throttling doesn't help your CPU cores will be deactivated and you have to can't bring them back online manually the usual way since Allwinner's kernel doesn't allow so:
echo 1 >/sys/devices/system/cpu/cpuX/online Therefore it's better to stay with the thermal defaults to allow throttling and improve heat dissipation instead. I used a $0.5 heatsink that performs ok. Without heatsink when running CPU intensive jobs throttling limited clockspeed to 1.2 GHz but with the heatsink I was able to run most of the times at ~1.6Ghz under full load. With heatsink and an annoying fan I managed to let the SoC run constantly at 1.8GHz and achieved a 7-zip score close to 6000 and finished "sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=8" in less than 53 seconds.
 
This is an example for wrong throttling values (too high) so that the kernel driver does not limit clockspeeds but starts to drop CPU cores instead:
 

 
CPU performance:
 
Since the H3 (used on the more recent Orange Pis) and the A83T seem to use much of the same kernel sources (especially the 'thermal stuff') I did a few short tests. When running with identical clockspeed and the same amount of cores they perform identical (that means they're slower than older Cortex-A7 SoCs like eg. the A20 when running at identical clockspeed -- a bit strange). Obviously the difference between H3 and A83T is the process. Both already made in 28nm but the A83T as 'tablet SoC' in the more energy efficient HPC process allowing less voltage and higher clockspeeds. According to sysconfig.fex the SoC should be able to clock above 2.1 GHz but since exceeding 1.6 Ghz already needs a fan this is pretty useless on a SBC (might be different inside a tablet where the back cover could be used as a large heatsink).
 
Network throughput:
 
I used my usual set of iperf testings and tried GBit Ethernet performance (with and without network tunables it remains the same -- reason below):
 
BPi-M3 --> Client:
[ 4] 0.0-10.0 sec 671 MBytes 563 Mbits/sec [ 4] 0.0-10.0 sec 673 MBytes 564 Mbits/sec [ 4] 0.0-10.0 sec 870 MBytes 729 Mbits/sec [ 4] 0.0-10.0 sec 672 MBytes 564 Mbits/sec [ 4] 0.0-10.0 sec 675 MBytes 566 Mbits/sec Client --> BPi-M3: [ 4] 0.0-10.0 sec 714 MBytes 599 Mbits/sec [ 5] 0.0-10.0 sec 876 MBytes 734 Mbits/sec [ 4] 0.0-10.0 sec 598 MBytes 501 Mbits/sec [ 5] 0.0-10.0 sec 690 MBytes 578 Mbits/sec [ 4] 0.0-10.0 sec 604 MBytes 506 Mbits/sec When I used longer test periods (-t 120) then the "Client --> BPi-M3" performance increased up to the theoretical limit: 940 Mbits/s. Then a second iperf thread jumped in, both utilising a single CPU core fully. And that's the problem: Networking is CPU bound, a single client-server connection will not exceed 500-600 Mbits/sec as it was the case when I started with A20 based boards 2 years ago. Since all we have now with the A83T is an outdated 3.4.39 kernel and since I/O bandwidth on the M3 is so low, I stopped here since it's way too boring to try to improve network throughput and also useless (disk access is so slow that it simply doesn't matter when Ethernet is limited to half of the theoretical GBit Ethernet speed... at least for me  )
 
Accessing disks:
 
Since there's a SATA connector on the board I gave it a try.
 
Important: the SATA-power connector uses the same polarity as older Banana Pis and Orange Pis (keep that in mind since combined SATA data/power cables from LinkSprite and Cubietech that share exactly the same connector use inverted polarity!).
 
I started with the Samsung EVO I always use for tests (but due to the old 3.4 kernel using ext4 instead of btrfs) and was shocked: 13.5/23 MB/s is the worst result I ever measured. I then realised that I limited maximum cpufreq to 480 MHz and tried with 1800 MHz again. A bit better but far away from acceptable:
GL830 USB-to-SATA performance: 480 MHz: kB reclen write rewrite read reread 4096000 4 13529 13466 22393 22516 4096000 1024 13588 13411 22717 26115 1.8 GHz: 4096000 4 15090 15082 30968 30316 4096000 1024 15174 15131 30858 29441 I disconnected the SSD from the 'SATA port' and put it in an enclosure with a JMicron JMS567 USB-to-SATA bridge and measured again: Now sequential transfer speeds @ 1800 MHz exceeded 35/34 MB/s. The GL830 is responsible for low throughput -- especially writes are slow as hell.
 
I made then a RAID-1 through mdadm consisting of an external 3TB HDD (good news: the GL830 can deal with partitions larger than 2 TB) and the SSD. First test with the HDD connected to the M3's GL830 bridge (GL) and the SSD connected to the JMS567 (JM). Then I disconnected the HDD from the GL830 and put it in another external enclosure with an ASMedia 1053 (ASM). 
 
Obviously SinoVoip's decision to use an internal USB hub and only one host port of the SoC leads in both situations to limited (shared) bandwidth. But in case the internal USB-to-SATA bridge is involved performance is even worse:
GL/JM: kB reclen write rewrite read reread 4096000 4 17800 17140 14382 16807 4096000 1024 17741 17258 14493 14368 JM/ASM: 4096000 4 19307 18458 22855 26241 4096000 1024 19231 18518 21995 22362 If SinoVoip would've saved the GL830 USB-to-SATA bridge and wired both SoC's host ports to the 2 type-A USB ports directly without the internal hub in between overall performance would be twice as good. And obviously the M3's 'SATA port' is the worst choice to connect a disk to. Any dirt-cheap external USB enclosure will perform better.
 
SD-card and eMMC:
 
Just a quick check with the usual iozone settings running @ 1.8 GHz:
kB reclen write rewrite read reread eMMC: 4096000 4 26572 27014 59187 59239 4096000 1024 25875 26614 56587 56667 SD-card: 4096000 4 20483 20855 22473 22892 4096000 1024 20526 19948 22285 22660 LOL, eMMC twice as fast as 'SATA'. The performance numbers of the SD-card (SanDisk "Extreme Pro") are irrelevant since I can not provide performance numbers from a known fast reference implementation. But since I might be able to provide this the next few days, I decided to give it a try. On older Allwinner SoCs there's a hard limitation regarding SDIO/SD-card speed. Maybe this applies here too.
 
EDIT: Yes, it's a board/SoC limitation. When reading/writing the SD-card on a MacBook Pro I achieve ~80 MB/s. It seems SDIO on A83T is limited to ~20MB/s
 
Other issues:
 
If you want to try out the M3 you'll have to stay on the bleeding edge. Don't expect that any of the available OS images are close to useable. They just recently started to fix a lot of essential bugs in code and hardware initialisation. If you want to test the M3 be prepared to compile the BSP daily and exchange the bootloader/kernel/initialisation stuff on your SD-card/eMMC Currently average load is always 1 or above. When we started over 2 years ago with Cubieboards (and an outdated kernel 3.4.x) there was a similar issue. Maybe it's related. I just opened a Github issue Mainline kernel support in very early stage. Don't count on this that soon (situation with Banana Pi M2 was a bit different. All the OS images from SinoVoip based on kernel 3.3 weren't useable but the community provided working distros backed by the work of the linux-sunxi community and existing mainline kernel support for the M2's A31s) Always keep in mind that hardware without appropriate software is somewhat useless. SinoVoip has a long history of providing essential parts of software way too late or not at all (still applies to the M2 -- before you buy any SinoVoip product better have a look into their forums to get the idea which level of support you can expect: zero). Even worse: For the M2 and its A31s SoC there exists mainline kernel support (everything developed by the community while the vendor held back necessary informations). This does not apply to the A83T used on the M3. At the moment you're somewhat lost since you've to rely on the manufacturer's OS images (all of them currently being broken)  
Conclusion:
 
Still no idea what to do with such a device.
 
Integer performance is great when you use a heatsink and even greater with an annoying fan. But where's the use case? If I would use the M3 with Android then everything that's relevant for performance does not depend on CPU (but instead CedarX for HW accelerated video decoding and GPU for 2D/3D acceleration -- BTW: the A83T is said to contain only a single core SGX544MP1 but the fex file's contents let me believe it's a faster MP2 instead).
 
Due to limited I/O and network bandwidth the integer performance is also irrelevant for nearly all kinds of server tasks. If it's just about 'SBC stuff' why wasting so much money? Triggering GPIO pins works also with cheap H3 based boards like Orange Pi PC or Orange Pi One that also have 4 times more I/O bandwidth compared to the M3 (due to 4 available USB ports instead of one).
 
And if I would really need a performant ARM SoC then I would buy such a thing and not an outdated Cortex-A7 design. I still have no idea what the M3 is made for. Except of selling something under the "Banana" brand to clueless people. Don't know. For my use cases the Banana Pi M1 outperforms the M3 easily -- both regarding price and performance (sufficient CPU power, 3 x USB and real SATA not 'worst USB-to-SATA implementation ever'). As usual: YMMV 
 
Maybe the worst design decision (next to choosing the crappy Micro-USB connector for DC-IN) on the M3 is the 'SATA port'. If they would've saved both internal USB hub and GL830 and instead use the two available USB host ports then achievable I/O bandwidth would be way higher. Now both USB ports and the 'SATA port' have to share the bandwidth of a single USB 2.0 connection. Almost as bad as with the Raspberry Pis.
 
But most importantly: Check software und support situation first and don't rely on 'hardware features'. Remember: SinoVoip shipped the M2 with OS images where not a single GPIO pin was defined and Ethernet worked only with 100Mb/s since they 'forgot' to define GMAC pins. They fixed that months later but still not for every OS image (the Android image they provide is corrupted since months but they don't care even if users complain several times). Visit their forums first to get an idea what to expect. It's important!
 
Armbian support:
 
Not to be expected soon. It's worthless when having to rely on Allwinner's old 3.4.39 kernel. I combined loboris' H3 Debian image with kernel/bootloader stuff for the A83T and it worked as expected (even my RPi-Monitor setup matched almost perfectly).
 
Unless the linux-sunxi community improves mainline support for the A83T this situation won't change. But maybe someone interested in M3 (definitely not me) teaches SinoVoip how to escape from u-boot/kernel without support for script.bin in the meantime. Would be a first step.

Only some 'MHz fanatics' were really concerned. Or to be more precise: people who do not understand the difference between performance and clockspeeds and who also do not understand the challenges to run chips at high clockspeeds (both consumption and heat increase a lot). Again: https://www.cnx-software.com/2016/08/28/amlogic-s905-and-s912-processors-appear-to-be-limited-to-1-5-ghz-not-2-ghz-as-advertised/#comment-530956 (there you can also read what happened then in detail to get more control over clockspeeds on C2)
 
If I'm concerned about performance I need a use case first and then I test for performance with this use case (and don't rely on theoretical clockspeeds since this is plain stupid). That's what both Willy Tarreau and @willmore did unlike those people who for whatever reasons bought an ODROID-C2 instead of an RPi 3 due to '2 GHz' vs. '1.2 GHz' (those people exist en masse). So it was pretty obvious once that happened that an A53 'clocked at 2 GHz' performing like one clocked at 1.5 GHz is just that: limited to 1.5 GHz. So what? This is on those devices always the result of consumption and thermal constraints so why bother?
 
Since I mentioned 'use case' and Raspberry Pi 3:
If you need the performance for a use case called 'AES encryption' (VPN, full disk encryption, stuff like that) then looking at clockspeeds is what? Plain stupid as usual! Both ODROID-C2 regardless of being able to clock at 2 GHz or just 1.5 GHz performs as crappy as the RPi 3. They both do not support ARMv8 Crypto Extensions and perform magnitudes slower than any cheap NanoPi NEO2 or Orange Pi Zero Plus running at below 1 GHz CPU clockspeed: https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829 RPi 3 is the SBC with the most screwed up DVFS/cpufreq/clockspeed situation. The problem should be well known since 2015: an awful lot of RPi suffer from underpowering and run then frequency capped (limited to 600 MHz). But just like in situations when throttling is happening the kernel has not the slightest idea at which clockspeed the CPU cores are running and reports bogus values like 900 MHz on RPi 2, 1200 MHz on RPI 3 and 1400 MHz on RPi 3+ while in reality being limited to 600 MHz. Is this 'cheating' or at least a problem? Not when your target audience is only absolutely clueless people (RPi users). They're happy to achieve top clockspeeds only in idle and being limited to 600 MHz once performance would be needed and even start to complain once they are made aware of the real problem (seriously: check this link, it's unbelievable)  

Just to add another potential reason why reboot seems to not work: since the board gets stuck on u-boot prompt due to some noise on serial RX line or via USB devices. The latter was one of the reasons why we disabled USB in u-boot for H3 boards (still can't remember whether this change made it already in the available 5.14 releases) and we just recently discovered that on NanoPi NEO obviously noisy power sources lead to u-boot waiting endlessly for input on the prompt since it misinterpreted some signals before and stopped autoboot behaviour.
 
In other words: reboot works perfectly but then the board waits sitting at the u-boot prompt for instructions (had this several times with NanoPi NEO the last days but only when connected to a specific PSU source).
 
BTW: Since you mentioned contact resistance and also consumption measurements in another thread. Contact and cable resistance might influence your consumption readouts (too much) and on the other hand I did a lot of research/tests the last weeks how to lower idle consumption especially of various H3 based boards. Good starting points might be
http://forum.armbian.com/index.php/topic/1748-sbc-consumptionperformance-comparisons/ http://forum.armbian.com/index.php/topic/1614-running-h3-boards-with-minimal-consumption/ http://forum.armbian.com/index.php/topic/1728-rfc-default-settings-for-nanopi-neoair/

Great. So you got the 'you can run FreedomBox on any computer that you can install Debian on'. Now you just need to know what Armbian is (Ubuntu or Debian userland with optimized kernel and optimized settings), then as long as you are able to accept running an Armbian Debian flavor is in some way comparable to 'running Debian' you can start. If Armbian is not for you for whatever reason simply wait a few months or years until upstream support for recent/decent ARM hardware arrived in Debian.
 
In case you choose Armbian you need to ensure to freeze kernel and u-boot upgrades since otherwise you use a stable distro on an unstable basis (it seems stuff like this needs to happen from time to time for reasons unknown to me).

Count the patches and search for NEO2 there: https://github.com/armbian/build/tree/master/patch/kernel/sunxi-next