tkaiser

Whom have you talked to? The UK guy trying to get as much people as possible currently sending him money through PayPal?
 
The M2 Zero is just the most boring H2+/H3 device we've ever seen. Since those irresponsible guys do not 'develop' in the open you have to download 'BPI-files/SD/BPI-BOOT/BPI-BOOT-bpi-m2z.tgz', then extract this archive and look into bpi-m2z/linux/sys_config.fex (line 3 already being wrong -- as lousy as expected). They use my recommendation to clock single bank DRAM H2+/H3 boards with 'dram_clk = 408', they use our kernel and all our settings for their M2+ (even 'corekeeper_enabled = 1' we developed last year having a hard time dealing with their crappy other H3 device), if 'pmuic_type = 0' is true then they again moronically 'forgot' to implement voltage regulation (the reason why BPi M2+ so badly overheats, if they use now the same fixed VDD_CPUX voltage setup on this M2 Zero good luck since due to much smaller board size heat dissipation is even more of an issue!).
 
But we don't know whether these settings are not as usual just the result of their copy&paste monkey doing something stupid or if these are really settings that match the hardware. In the past they never succeeded to provide these fex hardware descriptions correctly and it would be a wonder if they would do this time. And since they're too ignorant or stupid to provide schematics (still nothing to see here) we'll need to buy the next Banana board ourselves to see which flaws they implemented this time. If we're stupid of course, better ignore hardware that is not supported by its own manufacturer.
 
If their fex file would be correct it would take me less than an hour to get this BPi M2 Zero FULLY SUPPORTED by Armbian. We did this with the following other H2+/H3 boards in the past without having them in our hands solely based on CORRECT hardware descriptions provided by the board makers: NanoPi Neo, NanoPi Air, NanoPi M1, Orange Pi Zero, Orange Pi Zero Plus 2, NanoPi M1+ -- if you deal with hardware vendors that do NOT behave like brain damaged retards you get correct hardware descriptions (either fex file or DT and schematics of course -- all correct and not the result of 'copy&paste gone wrong'). That's really all you need as developer and that separates other board makers from SinoVoip.
 
But since the SinoVoip guys still behave like brain damaged retards I hope no one will be dumb enough to add this M2 Zero thingie to Armbian's build system ever. Unless they hire someone able to write technical documentation (or at least someone who understands that providing CORRECT information is necessary), they stop censoring their forum and start to support their own hardware nothing will change. You must be stupid as open source community member to try to support their hardware...
 
BTW: Since with their 'RPi Zero W' competitor called M2 Zero they completely rely on our underlying work you get at least a kernel patched up to latest 3.4 LTS version (3.4.113 fixing tons of issues). Unfortunate customers buying their 'RPi 3 killer' called M2 Berry suffer from their ignorance/stupidity and get a 3.10.65 kernel only (outdated since over 2.5 years containing a lot of exploitable security vulnerabilities). Community tried to help them by even sending them all the fixes necessary to get to latest 3.10.107 LTS kernel or the fix for the DRAM instability issues: https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/pulls
 
It would take them maybe 10 seconds to merge these pull request. They refuse to do since they don't seem to give a sh*t about anything else than selling hardware to clueless people (or maybe the 'responsible' guys over there are simply too ignorant to get the meaning of 'security' just like they don't understand what 'open source' means).

Yeah, but that's all just due to some of my personal superheroes doing such a great work (talking about especially icenowy and you right now). Thank you BTW
 
But still it's a huge problem with Allwinner SoCs that we can't use what board or chip makers provide (at least not without wasting insane amounts of time to turn Allwinner's BSP crap into something useful like longsleep did two years ago). And then there's the insanely time consuming mainline upstreaming process...

http://linux-sunxi.org/Banana_Pi_M3 and here in the forum you need to search for 'NanoPi M3' (that's the cheaper variant with same SoC and just 1 GB DRAM now replaced by NanoPi Fire3 which should be the fastest el cheapo SBC around with 8 x A53 clockable at up to 1.6 GHz according to Willy Tarreau -- click on 'reviews' here: http://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=206)
 
Fascinating aspect is that all the more powerful SBC except the ODROIDs are prone to underpowering by design by using the most crappy connector possible. And also an awfu lot of them show thermal problems since the 'engineers' forgot to allow to mount an appropriate heatsink/fansink. No idea what those 'engineers' thought...

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.

I just looked through those numbers on https://libre.computer/2018/03/21/raspberry-pi-3-model-b-review-and-comparison/ again just to realize that there's also something seriously wrong. The OpenSSL tests are also a great benchmark to check for real CPU clockspeeds since not affected by memory bandwidth at all (the AES scores with ARMv8 Crypto Extensions available scale linearly with clockspeed when comparing different A53).
 
When comparing Le Potato (S905X claiming to run at 1.5 GHz) with Renegade (RK3328 at 1.3 GHz) then it's pretty obvious that the S905X was running with 1320 MHz maximum. Which is a bit too low even if we already take into account that S905X can't reach the 1.5 GHz anyway due to bl30.bin situation.
 
There's something seriously wrong with CPU clockspeeds on Amlogic platforms. And maybe there's also a relationship with broken/weird scheduling though I really don't understand how this can happen (there should be no difference on a quad-core CPU whether the kernel decides to run on cpu 0-3 or the user 'forces' exactly the same using 'taskset -c 0-3' -- but reality draws a different picture)

Agreed.  Indeterminate behavior counts as an issue, since it could, in as yet unknown circumstances, result in undefined behavior, or at least unexpected.
 

True, I notice that USB3 port was not working. I was happy that it booted in the first place. I already merged into our main sunxi DEV branch (attached back to upstream master) and will try to remake this with a working USB3.

Nope, I was talking about 'clueless people' just to outline which challenges those TV box manufacturers face. Unlike premium STB device makers like BroadCom or HiSilicon where the SoCs can be reasonably designed to do the job since no end customer has to 'choose' them based on specs they don't understand (those boxes are given away 'for free' by their broadband provider) those 'el cheapo TV box' SoC makers have to design their devices in a way they look appealing to... clueless people (many CPU cores, high CPU clockspeeds). On the other hand those TV boxes can't be designed well since... clueless customers prefering devices with poor heat dissipation.
 
In the 'TV box world' those Amlogic things work pretty well since CPU performance is irrelevant anyway (only exception: exotic codecs the video engine -- VPU -- can not handle). But on SBCs it's something different since there the users expect from a SoC advertised as 'octa-core at 2 GHz' a bit more than the laughable 'octa-core at an average 1.2 GHz' performance they get with S912 in reality.

First Pine H64/H6 mainline testing images based on @Icenowy patchset https://dl.armbian.com/pineh64/ Boot log: http://ix.io/18DU

2018 SD card update
 
It's 2018 now, SD Association's A1 'performance class' spec is out over a year now and in the meantime we can buy products trying to be compliant to this performance class. SD cards carrying the A1 logo must be able to perform at least 1500 random read input-output operations per second (IOPS) with 4KB block size, 500 random write IOPS and 10 MB/s sustained sequential performance (see here for more details and background info)
 
Why is this important? Since what we do on SBC at least for the rootfs is mostly random IO and not sequential IO as it's common in cameras or video recorders (that's the stuff SD cards have been invented to be used with in the beginning). As an SBC (or Android) user we're mostly interested in high random IO performance with smaller blocksizes since this is how 'real world' IO patterns mostly look like. Prior to A1 and A2 performance classes there was no way to know how SD cards perform in this area prior to buying. Fortunately this has changed now.
 
Last week arrived an ODROID N1 dev sample so I bought two SanDisk A1 cards with 32GB capacity each. An el cheapo 'Ultra A1' for 13€ (~$15) and an 'Extreme A1' for 23€. I wanted to buy a slightly more expensive 'Extreme Plus A1' (since even more performance and especially reliability/longevity) but ordered the wrong one  Please keep in mind that the 'Extreme Plus' numbers shown below are made with an older card missing the A1 logo.
 
Let's look how these things perform, this time on a new platform: RK3399 with an SD card interface that supports higher speed modes (requires kernel support and switching between 3.3V to 1.8V at the hardware layer). So results aren't comparable with the numbers we generated the last two years in this and other threads but that's not important any more... see at the bottom.
 
A1 conformance requires at least 10 MB/s sequential performance and 500/1500 (write/read) IOPS with 4K blocksize. I tested also with 1K and 16K blocksizes for the simple reason to get an idea whether 4K results are useful to determine performance with smaller or larger blocksizes (since we already know that the vast majority of cheap SD cards out there shows a severe 16K random write performance drop which is the real reason so many people consider all SD cards being crap from a performance point of view).
 
I tested with 7 cards, 4 of them SanDisk, two Samsung and the 'Crappy card' being a results mixture of a 4GB Kingston I started to test with and old results from a 4GB Intenso from two years ago (see first post of this thread). The Kingston died when testing with 4K blocksize and the performance of all these crappy 'noname class' cards doesn't vary that much:
1K w/r 4K w/r 16K w/r Crappy card 4GB 32 1854 35 1595 2 603 Samsung EVO+ 128GB 141 1549 160 1471 579 1161 Ultra A1 32GB 456 3171 843 2791 548 1777 Extreme A1 32GB 833 3289 1507 3281 1126 2113 Samsung Pro 64GB 1091 4786 1124 3898 478 2296 Extreme Plus 16GB 566 2998 731 2738 557 2037 Extreme Pro 8GB 304 2779 323 2754 221 1821 (All results in IOPS --> IO operations per second) For A1 compliance we only need to look at the middle column and have to expect at least 500/1500 IOPS minimum here. The 'Crappy card' fails as expected, the Samsung EVO+ too (but we already knew that for whatever reasons newer EVO+ or those with larger capacity perform worse than the 32GB and 64GB variants we tested two years ago), the Samsung Pro shows the best performance here while one of the 4 SanDisk also fails. But my Extreme Pro 8GB is now 3 years old, the other one I had showed signs of data corruption few months ago and when testing 2 years ago (see 1st post in this thread) random write performance was at 800. So most probably this card is about to die soon and the numbers above are partially irrelevant..
 
What about sequential performance? Well, 'Crappy card' also not able to meet specs and all the better cards being 'bottlenecked' by ODROID N1 (some of these cards show 80 MB/s in my MacBook's card reader but Hardkernel chose to use some safety headroom for good reasons and limits the maximum speed for improved reliability)
MB/s write MB/s read Crappy card 4GB 9 15 Samsung EVO+ 128GB 21 65 Ultra A1 32GB 20 66 Extreme A1 32GB 59 68 Samsung Pro 64GB 61 66 Extreme Plus 16GB 63 67 Extreme Pro 8GB 50 67 Well, sequential transfer speeds are close to irrelevant with single board computers or Android but it's good to know that boards that allow for higher SD card speed modes (e.g. almost all ODROIDs and the Tinkerboard) also show an improvement in random IO performance if the card is a good one. The ODROID N1 was limited to DDR50 (slowest SD card mode) until today when Hardkernel unlocked UHS capabilities so that my cards (except of 'Crappy card') could all use SDR104 mode. With DDR50 mode sequential performance is limited to 22.5/23.5MB/s (write/read) but more interestingly random IO performance also differs. See IOPS results with the two SanDisk A1 cards, one time limited to DDR50 and then with SDR104:
1K w/r 4K w/r 16K w/r Ultra A1 DDR50 449 2966 678 2191 445 985 Ultra A1 SDR104 456 3171 843 2791 548 1777 1K w/r 4K w/r 16K w/r Extreme A1 DDR50 740 3049 1039 2408 747 1068 Extreme A1 SDR104 833 3289 1507 3281 1126 2113 We can clearly see that the larger the blocksize the more the interface speed influences also random IO performance (look especially at 16K random reads that double with SDR104)
 
Some conclusions:
When comparing results above the somewhat older Samsung Pro performs pretty similar to the Extreme A1. But great random IO performance is only guaranteed with cards carrying the A1 logo (or A2 soon) so it might happen to you that buying another Samsung Pro today results in way lower random IO performance (see Hardkernel's results with a Samsung Pro Plus showing 224/3023 4k IOPS which is way below the 1124/3898 my old Pro achieves with especially write performance 5 times worse and below A1 criteria) We still need to focus on the correct performance metrics. Sequential performance is more or less irrelevant ('Class 10', 'UHS' and so on), all that matters is random IO (A1 and A2 soon). Please keep in mind that you can buy a nice looking UHS card from 'reputable' brands like Kingston, Verbatim, PNY and the like that might achieve theoretical 80MB/s or even 100MB/s sequential performance (you're not able to benefit from anyway since your board's SD card interface will be the bottleneck) but simply sucks with random IO performance. We're talking about up to 500 times worse performance when trusting in 'renowned' brands and ignoring performance reality (see 16k random writes comparing 'Crappy card' and 'Extreme A1') Only a few vendors on this planet run NAND flash memory fabs, only a few companies produce flash memory controllers and have the necessary know-how in house. And only a few combine their own NAND flash with their own controllers to their own retail products. That's the simple reason why at least I only buy SD cards from these 4 brands: Samsung, SanDisk, Toshiba, Transcend The A1 performance speed class is a great and necessary improvement since now we can rely on getting covenant random IO performance. This also helps in fighting counterfeit flash memory products since even if fraudsters in the meantime produce fake SD cards that look real and show same capacity usually these fakes suck at random IO performance. So after testing new cards with either F3 or H2testw it's now another iozone or CrystalDiskMark test to check for overall performance including random IO (!) and if performance sucks you simply return the cards asking for a refund. TL;DR: If you buy new SD cards choose those carrying an A1 or A2 logo. Buy only good brands (their names start with either S or T). Don't trust in getting genuine products but always expect counterfeit stuff. That's why you should only buy at sellers with a 'no questions asked' return/refund policy and why you have to immediately check your cards directly after purchase. If you also care about reliability/resilience buy more expensive cards (e.g. the twice as expensive Extreme Plus A1 instead of Ultra A1) and choose larger capacities than needed.
 
Finally: All detailed SD card test results can be found here: https://pastebin.com/2wxPWcWr As a comparison performance numbers made with same ODROID N1, same settings but vendor's orange eMMC modules based on Samsung eMMC and varying only in size: https://pastebin.com/ePUCXyg6

If you want a KODI box why not asking the KODI guys?
Bootlin is today working on Allwinner SoCs that are horribly outdated (A33 being the only expection somehow, the others are A10, A13 and A20 from 5 to 8 years ago). They're all ARMv7 and support for Allwinner SoCs that are just outdated (A64 and H5) will come later. According to their Kickstarter page at the end of Dec 2018 if they succeed.
 
Welcome to the Allwinner reality. Get the hardware, be able to use only a shitty Android or crappy Android/Linux hybrids, wait for software support becoming mature (100% relying on community) and use the hardware as intended when it's already obsolete.

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)  

I would prefer to do it correctly: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892768
 
And IMO there's no need to hurry and I honestly do not understand the bunch of hacks recently added to get 18.04 built now...

Noted.
 

True, there is no need to hurry but its more convenient to repair things on the way. As a side task. My intention was to bring it to the level, where one can build and test. We are there now. We can build, we have a network, a desktop is up, ... There are small known problems and probably many hidden. Some will be fixed upstream and some can be fixed by people interested to run Bionic ASAP. I will still fix things if I bump into them, but will not hunt them.

RTL8211 is used as PHY on all GbE capable SBC I know. The majority of boards uses RTL8211E, some RTL8211F and Olimex used also RTL8211CL a while ago. Pretty much irrelevant since always the GbE MAC implementation lives inside the SoC and the RTL8211 PHY is just attached via RGMII (so the MAC and PCIe parts of these RealTek chips are not used on SBC anyway. Might change soon since more and more SoCs are PCIe equipped).
 
But even on the soon to be released Orange Pi R2 the two RTL8211E are only used as PHY and attached via RGMII (RTD1296 has 3 GbE MACs but only one internal GbE PHY so for the two additional GbE interfaces external PHYs are needed):

http://wiki.friendlyarm.com/wiki/index.php/NanoPi_K1_Plus
 
RPi 3 form factor like their K2, maximum DRAM (2GB), Gigabit Ethernet, Wi-Fi with onboard aerial provided by RTL8189ETV, still using their own/new eMMC socket. According to schematics and their Github repo a SY8106A voltage regulator is used which is great news since then it's possible to clock the H5 well above 1.3 GHz.

http://wiki.friendlyarm.com/wiki/index.php/NanoPi_K1_Plus
 
RPi 3 form factor like their K2, maximum DRAM (2GB), Gigabit Ethernet, Wi-Fi with onboard aerial provided by RTL8189ETV, still using their own/new eMMC socket. According to schematics and their Github repo a SY8106A voltage regulator is used which is great news since then it's possible to clock the H5 well above 1.3 GHz.

TL;DR: the following is a simple summary of the issue:
 
Amlogic SoCs contain an own embedded microcontroller (Cortex-M3) used for controlling power and clocks A proprietary and closed source firmware is loaded on the M3 at boot. This stuff is contained in the bl30.bin blob we have to include This firmware controls the real clockspeeds, ignores what the cpufreq framework running in the Linux kernel wants and even reports back bogus clockspeeds (the kernel wants to set 1512 MHz, the M3 ignores this and sets 1416 MHz instead but the code returns faked 1512 MHz) Various tests showed that this is not related to thermal protection but just to $something we currently don't understand and out of our control Hardkernel are the only ones who managed to get a bl30.bin blob from Amlogic for their ODROID-C2 that does not cheat on us but honours the cpufreq framework, sets the wanted clockspeeds and also returns real and not faked cpufreq values. On all other Amlogic SBC situation is different  
 
 
Talking about 'not entirely honest' when it's about bold lies is funny
 
It's some proprietary crap that controls DVFS on Amlogic SoCs (a bl30.bin BLOB loading some firmware on the embedded Cortex-M3 which controls DVFS/cpufreq on its own) and Hardkernel is the only vendor that got this BLOB from Amlogic in a way where the installation does not cheat on you. In case the BLOB does also DRAM initialization (most likely) it should be hard to exchange it between boards.
 
https://forum.armbian.com/topic/2138-armbian-for-amlogic-s912/?do=findComment&comment=43338 (S912 and S905X are both known to cheat on the Linux kernel. The cpufreq values are all faked. Most probably this does also apply to all S905 devices except ODROID-C2 since Hardkernel managed to get a fixed BLOB from Amlogic)
 

2018 SD card update
 
It's 2018 now, SD Association's A1 'performance class' spec is out over a year now and in the meantime we can buy products trying to be compliant to this performance class. SD cards carrying the A1 logo must be able to perform at least 1500 random read input-output operations per second (IOPS) with 4KB block size, 500 random write IOPS and 10 MB/s sustained sequential performance (see here for more details and background info)
 
Why is this important? Since what we do on SBC at least for the rootfs is mostly random IO and not sequential IO as it's common in cameras or video recorders (that's the stuff SD cards have been invented to be used with in the beginning). As an SBC (or Android) user we're mostly interested in high random IO performance with smaller blocksizes since this is how 'real world' IO patterns mostly look like. Prior to A1 and A2 performance classes there was no way to know how SD cards perform in this area prior to buying. Fortunately this has changed now.
 
Last week arrived an ODROID N1 dev sample so I bought two SanDisk A1 cards with 32GB capacity each. An el cheapo 'Ultra A1' for 13€ (~$15) and an 'Extreme A1' for 23€. I wanted to buy a slightly more expensive 'Extreme Plus A1' (since even more performance and especially reliability/longevity) but ordered the wrong one  Please keep in mind that the 'Extreme Plus' numbers shown below are made with an older card missing the A1 logo.
 
Let's look how these things perform, this time on a new platform: RK3399 with an SD card interface that supports higher speed modes (requires kernel support and switching between 3.3V to 1.8V at the hardware layer). So results aren't comparable with the numbers we generated the last two years in this and other threads but that's not important any more... see at the bottom.
 
A1 conformance requires at least 10 MB/s sequential performance and 500/1500 (write/read) IOPS with 4K blocksize. I tested also with 1K and 16K blocksizes for the simple reason to get an idea whether 4K results are useful to determine performance with smaller or larger blocksizes (since we already know that the vast majority of cheap SD cards out there shows a severe 16K random write performance drop which is the real reason so many people consider all SD cards being crap from a performance point of view).
 
I tested with 7 cards, 4 of them SanDisk, two Samsung and the 'Crappy card' being a results mixture of a 4GB Kingston I started to test with and old results from a 4GB Intenso from two years ago (see first post of this thread). The Kingston died when testing with 4K blocksize and the performance of all these crappy 'noname class' cards doesn't vary that much:
1K w/r 4K w/r 16K w/r Crappy card 4GB 32 1854 35 1595 2 603 Samsung EVO+ 128GB 141 1549 160 1471 579 1161 Ultra A1 32GB 456 3171 843 2791 548 1777 Extreme A1 32GB 833 3289 1507 3281 1126 2113 Samsung Pro 64GB 1091 4786 1124 3898 478 2296 Extreme Plus 16GB 566 2998 731 2738 557 2037 Extreme Pro 8GB 304 2779 323 2754 221 1821 (All results in IOPS --> IO operations per second) For A1 compliance we only need to look at the middle column and have to expect at least 500/1500 IOPS minimum here. The 'Crappy card' fails as expected, the Samsung EVO+ too (but we already knew that for whatever reasons newer EVO+ or those with larger capacity perform worse than the 32GB and 64GB variants we tested two years ago), the Samsung Pro shows the best performance here while one of the 4 SanDisk also fails. But my Extreme Pro 8GB is now 3 years old, the other one I had showed signs of data corruption few months ago and when testing 2 years ago (see 1st post in this thread) random write performance was at 800. So most probably this card is about to die soon and the numbers above are partially irrelevant..
 
What about sequential performance? Well, 'Crappy card' also not able to meet specs and all the better cards being 'bottlenecked' by ODROID N1 (some of these cards show 80 MB/s in my MacBook's card reader but Hardkernel chose to use some safety headroom for good reasons and limits the maximum speed for improved reliability)
MB/s write MB/s read Crappy card 4GB 9 15 Samsung EVO+ 128GB 21 65 Ultra A1 32GB 20 66 Extreme A1 32GB 59 68 Samsung Pro 64GB 61 66 Extreme Plus 16GB 63 67 Extreme Pro 8GB 50 67 Well, sequential transfer speeds are close to irrelevant with single board computers or Android but it's good to know that boards that allow for higher SD card speed modes (e.g. almost all ODROIDs and the Tinkerboard) also show an improvement in random IO performance if the card is a good one. The ODROID N1 was limited to DDR50 (slowest SD card mode) until today when Hardkernel unlocked UHS capabilities so that my cards (except of 'Crappy card') could all use SDR104 mode. With DDR50 mode sequential performance is limited to 22.5/23.5MB/s (write/read) but more interestingly random IO performance also differs. See IOPS results with the two SanDisk A1 cards, one time limited to DDR50 and then with SDR104:
1K w/r 4K w/r 16K w/r Ultra A1 DDR50 449 2966 678 2191 445 985 Ultra A1 SDR104 456 3171 843 2791 548 1777 1K w/r 4K w/r 16K w/r Extreme A1 DDR50 740 3049 1039 2408 747 1068 Extreme A1 SDR104 833 3289 1507 3281 1126 2113 We can clearly see that the larger the blocksize the more the interface speed influences also random IO performance (look especially at 16K random reads that double with SDR104)
 
Some conclusions:
When comparing results above the somewhat older Samsung Pro performs pretty similar to the Extreme A1. But great random IO performance is only guaranteed with cards carrying the A1 logo (or A2 soon) so it might happen to you that buying another Samsung Pro today results in way lower random IO performance (see Hardkernel's results with a Samsung Pro Plus showing 224/3023 4k IOPS which is way below the 1124/3898 my old Pro achieves with especially write performance 5 times worse and below A1 criteria) We still need to focus on the correct performance metrics. Sequential performance is more or less irrelevant ('Class 10', 'UHS' and so on), all that matters is random IO (A1 and A2 soon). Please keep in mind that you can buy a nice looking UHS card from 'reputable' brands like Kingston, Verbatim, PNY and the like that might achieve theoretical 80MB/s or even 100MB/s sequential performance (you're not able to benefit from anyway since your board's SD card interface will be the bottleneck) but simply sucks with random IO performance. We're talking about up to 500 times worse performance when trusting in 'renowned' brands and ignoring performance reality (see 16k random writes comparing 'Crappy card' and 'Extreme A1') Only a few vendors on this planet run NAND flash memory fabs, only a few companies produce flash memory controllers and have the necessary know-how in house. And only a few combine their own NAND flash with their own controllers to their own retail products. That's the simple reason why at least I only buy SD cards from these 4 brands: Samsung, SanDisk, Toshiba, Transcend The A1 performance speed class is a great and necessary improvement since now we can rely on getting covenant random IO performance. This also helps in fighting counterfeit flash memory products since even if fraudsters in the meantime produce fake SD cards that look real and show same capacity usually these fakes suck at random IO performance. So after testing new cards with either F3 or H2testw it's now another iozone or CrystalDiskMark test to check for overall performance including random IO (!) and if performance sucks you simply return the cards asking for a refund. TL;DR: If you buy new SD cards choose those carrying an A1 or A2 logo. Buy only good brands (their names start with either S or T). Don't trust in getting genuine products but always expect counterfeit stuff. That's why you should only buy at sellers with a 'no questions asked' return/refund policy and why you have to immediately check your cards directly after purchase. If you also care about reliability/resilience buy more expensive cards (e.g. the twice as expensive Extreme Plus A1 instead of Ultra A1) and choose larger capacities than needed.
 
Finally: All detailed SD card test results can be found here: https://pastebin.com/2wxPWcWr As a comparison performance numbers made with same ODROID N1, same settings but vendor's orange eMMC modules based on Samsung eMMC and varying only in size: https://pastebin.com/ePUCXyg6

Sorry, at the day job, now on lunch.  
 
I never used the Tinker Board kernel, so the DVFS settings were always patched in using the Tinker and Rockchip references.  I will verify the settings 
 
As far as power, there is no debate.  The 1.8 A is the minimum spec for current capability, I have information that says these are tested far beyond that, but again, multiple mate/unmate cycles would reduce that.  So, having dozens implemented with excellent supplies and top quality cables only plugged in a handful of times is not representative of a realistic situation for most users.  I applaud the quality of the deployment in this case, but consider it anecdotal evidence at best that Ohm and Kirchoff can be safely ignored.
 
 
This is independent of Tinker.  While it's not uncommon to see in the field, "USB" and "industrial" are a bad combination.

Quite possible that different DVFS settings are used. IIRC @TonyMac32 switched with kernel/settings from Tinker sources to upstream Rockchip BSP a while ago. The individual DVFS OPP should be accessible from userspace (sysfs -- but don't know details. I skipped RK3288 entirely so far)

Use /sbin/mount_cifs on your Linux box for SMB shares. If you mount them via GUI performance will be crappy (one of the many reasons why I hate 'Desktop Linux')

https://www.cnx-software.com/2018/03/27/turris-mox-is-a-modular-router-with-wifi-ssd-lte-modem-ethernet-and-sfp-fiber-modules-crowdfunding/#comment-552639

OMV is based on Debian. That's the simple reason it won't install on Ubuntu (dependency hell, different package versions). And if someone wants to run OMV I strongly recommend to check first whether there are available images at the download page or otherwise choose an Armbian Stretch next variant and then use armbian-config to install OMV.
 
Even if someone interested in NAS does not want to rely on OMV/Debian looking into the various performance tweaks we did is worth the efforts: https://forum.armbian.com/topic/3953-preview-generate-omv-images-for-sbc-with-armbian/?do=findComment&comment=44097
 
 
And for any NAS usage next kernel is strongly recommended since better hardware support (especially UAS support for USB storage).

OMV is based on Debian. That's the simple reason it won't install on Ubuntu (dependency hell, different package versions). And if someone wants to run OMV I strongly recommend to check first whether there are available images at the download page or otherwise choose an Armbian Stretch next variant and then use armbian-config to install OMV.
 
Even if someone interested in NAS does not want to rely on OMV/Debian looking into the various performance tweaks we did is worth the efforts: https://forum.armbian.com/topic/3953-preview-generate-omv-images-for-sbc-with-armbian/?do=findComment&comment=44097
 
 
And for any NAS usage next kernel is strongly recommended since better hardware support (especially UAS support for USB storage).