NicoD

Works in firefox. Even in Armbian. I don't know how. But it does. But Firefox does suck for surfing.
For that I use Vivaldi. There 1/3 lost frames in 1080p Youtube. Chromium 2/3 lost frames. Firefox 0 frames lost. All video works perfect. I even use it as video player on the NanoPi M4.
For me the NanoPi M4 is the perfect 2nd desktop pc. It's very fast. It's got an amazing heatsink. It's stable, haven't had 1 crash with it in hundreds of hours use. I've tried many different sbc's on there desktop capabillity's. The Odroid C2 was the best until the NanoPi M4.
Tinker board does ok in video, but many things don't work. I've tried it again this week, and it even got worse. I need 3 different OS'es to be able to do everything.
To my knowledge not many others than the C2, tinker, rasp and RK3399 have HW acc in Linux. The Raspberry sucks to work with.

I`ve got exactly the same adapter and it works immediatly here.
Armbian Bionic kernel 4.4.162-rockchip.
Are you using the volume control? Here it finds the adapter and puts the sound thru the moment I connect.

I`ve got exactly the same adapter and it works immediatly here.
Armbian Bionic kernel 4.4.162-rockchip.
Are you using the volume control? Here it finds the adapter and puts the sound thru the moment I connect.

Well, that is in a sense what is done now with "board families". All the boards in the same family share the kernel and most filesystem tweaks, and differ only in the device tree and some adjustments for specific hardware. But it is only possible when all the boards share the same SoC or a very close one. With completely different SoC's, that is not possible, each one needs a different kernel. Notice that all different boxes supported by balbes150's images have some Amlogic Meson SoC, and that is why they can use the same image with minor tweaks.

People of firefox don't care about Linux on ARM devices. It's been broken for a long time on armhf. Even on arm64 it crashes constantly.
This is a fork of Chromium. But better optimised for ARM. I don't know how, but on most arm devices the video playback is a lot better than Chromium. This without using hardware acceleration.

For example, on my NanoPi M4 I get 2/3 lost frames 1080p. While on Vivaldi it's only 1/3 lost frames.
I use it to surf on most devices since it's fast and stable.
Greetings.
 

It's quite cool. Not really multitasking. But instead of using delay what stops everything you check if the time has passed long enough to start a task. So you can do other tasks during that waiting time.
But when a task is busy you can't start another task. That 2nd task will start when the 1st task is done.

Very simple but effective. Why didn't anybody come up with this earlier?

I assume it comes with SPI, so.. testing a small display on breadboard is easy.. And my famous balance example.. normally I need the measured weights when I write lab journal on my normal computer.. so, display is not really needed on the balance.. it still has one.. I just need it stored.. It somehow replaces the god old paper..  okay I'm working on a RFID implementation as well.. but that's just to have some sort of an inventory system but that's future..
 
as soon as you integrate area under signals a regular python makes things a way easier.. python has cool modules for such funny stuff. Indeed a bunch of this stuff could be achieved with ESPs but you must be somehow a masochist to do it.

I don't think so, IMO the nanopi duo was somehow 'useless' due to crappy wifi. So without a carrier board you didn't had a sane solution to drive it headless. AP6212 will fix this mostly. Having a board which is breadboard capable by default makes it quite easy to set up some testing. And once your small 'pet project' works as expected you can even solder it to something like this:

or you etch your custom pcb for a few bucks (it's a way cheaper than it was in the past). Those RPi compatible headers always need an adapter or a custom made adapter or PCB to get it usable for such tasks. Still wonder why breadboard like hats aren't default for all those boards. IMO something like this:

should be in every boardmakers store by default (with the default size for their RPi a like boards). Sell them for 5 bucks each and you'll sell a bunch of them.
Don't get me wrong, the ESP32 is a great board (especially some of the drawbacks on the ESP8266 were properly solved, e.g 512kb ram is a great enhancement for micro-python on it). It's even possible now to have somehow a 'nice' web-interface on it. Storing data on the SPI 'somehow' works but it's not as convenient as on a 'average Armbian board'. My ESPs mostly cache data only for a short time and then send them over mqtt to a linux machine where you've great frameworks for handling those data.. most of it would be possible with an ESP as well (there's not much fancy numbers crushing) but I'm simply to lazy to program such stuff in micro-python or 'C++' (aka arduino for ESPs). As soon as you want a more enhanced web-interface you're soon getting to the ESPs limits (e.g. user authentication, graphs, getting out logs - everything is possible, but it needs a lot of work to achieve). Storing on SD-Cards on ESPs is somehow archaic.. It works but my I like to pull data from my stuff without rejecting the SD-Card and doing this on ESPs is IMO hacky.
 
+ camera interface
 
To summarize, it's a BPi-M2-Zero with different pinheader...

Works in firefox. Even in Armbian. I don't know how. But it does. But Firefox does suck for surfing.
For that I use Vivaldi. There 1/3 lost frames in 1080p Youtube. Chromium 2/3 lost frames. Firefox 0 frames lost. All video works perfect. I even use it as video player on the NanoPi M4.
For me the NanoPi M4 is the perfect 2nd desktop pc. It's very fast. It's got an amazing heatsink. It's stable, haven't had 1 crash with it in hundreds of hours use. I've tried many different sbc's on there desktop capabillity's. The Odroid C2 was the best until the NanoPi M4.
Tinker board does ok in video, but many things don't work. I've tried it again this week, and it even got worse. I need 3 different OS'es to be able to do everything.
To my knowledge not many others than the C2, tinker, rasp and RK3399 have HW acc in Linux. The Raspberry sucks to work with.

Up to @tkaiser for results on sbc-bench...
 
working on an addition - byte-unixbench and sorting out things... removing some gcc over optimizations, looking at threads...
 
https://github.com/sfx2000/byte-unixbench
 
It's a better bench than sysbench, and portable... Doing a -c 1 -1 and -c4 -i 1  keeps things short - however - letting it run thru pushes heat/throttles...
 
UnixBench is interesting from a system perspective...
 
RPI3 B Plus vs Tinker....
 
Tinker is 15 pounds of power in a 5 pound sack - RPi3 B+ is a CPU that can do better that it is with raspbian....
 
Tinkerboard - Cortex-A12/A17 - Armbian ------------------------------------------------------------------------ Benchmark Run: Sat Oct 20 2018 17:02:37 - 17:31:22 4 CPUs in system; running 1 parallel copy of tests System Benchmarks Index Values               BASELINE       RESULT    INDEX Dhrystone 2 using register variables         116700.0    8709974.2    746.4 Double-Precision Whetstone                       55.0       1031.4    187.5 Execl Throughput                                 43.0       1095.7    254.8 File Copy 1024 bufsize 2000 maxblocks          3960.0      91960.7    232.2 File Copy 256 bufsize 500 maxblocks            1655.0      26583.4    160.6 File Copy 4096 bufsize 8000 maxblocks          5800.0     246267.0    424.6 Pipe Throughput                               12440.0     149851.8    120.5 Pipe-based Context Switching                   4000.0      25850.9     64.6 Process Creation                                126.0       2429.0    192.8 Shell Scripts (1 concurrent)                     42.4       2061.9    486.3 Shell Scripts (8 concurrent)                      6.0        432.0    720.1 System Call Overhead                          15000.0     442992.8    295.3                                                                    ======== System Benchmarks Index Score                                         258.2 System Benchmarks Index Values               BASELINE       RESULT    INDEX Dhrystone 2 using register variables         116700.0   13538575.0   1160.1 Double-Precision Whetstone                       55.0       1982.4    360.4 Execl Throughput                                 43.0       1752.7    407.6 File Copy 1024 bufsize 2000 maxblocks          3960.0      87122.4    220.0 File Copy 256 bufsize 500 maxblocks            1655.0      22948.6    138.7 File Copy 4096 bufsize 8000 maxblocks          5800.0     281302.7    485.0 Pipe Throughput                               12440.0     321233.1    258.2 Pipe-based Context Switching                   4000.0      40012.9    100.0 Process Creation                                126.0       3820.3    303.2 Shell Scripts (1 concurrent)                     42.4       3399.0    801.7 Shell Scripts (8 concurrent)                      6.0        433.6    722.7 System Call Overhead                          15000.0     952658.0    635.1                                                                    ======== System Benchmarks Index Score                                         373.1 Rpi 3B+ - Cortex-A53 - VCOS/ThreadX - Raspian ------------------------------------------------------------------------ Benchmark Run: Sat Oct 20 2018 17:02:32 - 17:30:38 4 CPUs in system; running 1 parallel copy of tests System Benchmarks Index Values               BASELINE       RESULT    INDEX Dhrystone 2 using register variables         116700.0    4324740.1    370.6 Double-Precision Whetstone                       55.0        957.4    174.1 Execl Throughput                                 43.0        908.8    211.4 File Copy 1024 bufsize 2000 maxblocks          3960.0     140312.9    354.3 File Copy 256 bufsize 500 maxblocks            1655.0      40618.4    245.4 File Copy 4096 bufsize 8000 maxblocks          5800.0     353296.2    609.1 Pipe Throughput                               12440.0     280908.2    225.8 Pipe-based Context Switching                   4000.0      50734.2    126.8 Process Creation                                126.0       2212.2    175.6 Shell Scripts (1 concurrent)                     42.4       1780.5    419.9 Shell Scripts (8 concurrent)                      6.0        575.7    959.5 System Call Overhead                          15000.0     594784.0    396.5                                                                    ======== System Benchmarks Index Score                                         302.2 System Benchmarks Index Values               BASELINE       RESULT    INDEX Dhrystone 2 using register variables         116700.0   17082008.4   1463.8 Double-Precision Whetstone                       55.0       3803.4    691.5 Execl Throughput                                 43.0       2240.8    521.1 File Copy 1024 bufsize 2000 maxblocks          3960.0     228921.9    578.1 File Copy 256 bufsize 500 maxblocks            1655.0      62777.0    379.3 File Copy 4096 bufsize 8000 maxblocks          5800.0     578721.9    997.8 Pipe Throughput                               12440.0    1112342.2    894.2 Pipe-based Context Switching                   4000.0      98478.8    246.2 Process Creation                                126.0       4789.7    380.1 Shell Scripts (1 concurrent)                     42.4       4464.7   1053.0 Shell Scripts (8 concurrent)                      6.0        589.0    981.7 System Call Overhead                          15000.0    2289227.2   1526.2                                                                    ======== System Benchmarks Index Score                                         705.6  

Gah - watched the video - and a lot of problems across the board (pardon the pun).
 
Different kernels, built with different versions of GCC, userland (for example, Raspbian userland is all ARMv6 with exception of the kernel for the A7/A53 boards)....
 
(I wouldn't have included the any of the Pi's in the set of boards being evaluated because of the userland - <soapbox> nothing against Pi's in general, one must appreciate that 35M+ boards means they're doing something right, and they've spawned an entire HW/SW ecosystem around their platform, that's ok - and that ecosystem has in turn made affordable ARM boards available for hobbyists, makers, and developers - before Pi, if one wanted to do development around ARM, boards were expensive, and SW support was very limited to the vendor BSP - these days, it's a lot more open - not perfect, but much better than it was</soapbox>)
 
Rock64 vs Odroid XU4 - Quad A53 vs A7/A15 big.LITTLE - the big.LITTLE is a challenge for the scheduler, and depending on the BSP from the OEM, it's easy to get wrong, where threads can land on the lesser preferred core, this is an issue even on Android, where much work has been done outside of the mainline kernels (ARM and Qualcomm, I know they've done a lot of research there, but much of that has not been pushed back to mainline).
 
In my experience, with supported boards (for me this is Tinker and NanoPi NEO), Armbian is generally faster than the vendor's images - and that's doing Byte-Unixbench, which is discounted because it is compiler sensitive - that being said, it's still a useful tool when comparing apples to apples (e.g. tweaking settings on the same OS/Platform, but comparing Platform A to Platform B, one has to take the results with a grain of salt)
 
I haven't found a lot of evidence of cheating by any of the SBC vendors - it's really hard to do with FOSS, compared to Android, where cheating has occurred with certain OEM's and specific benchmark APK's - Android has enough hooks to enable this kind of cheating in any event.
 
sbc-bench, in my humble opinion, is a good benchmark for supported boards - as long as the boards being compared are all on the same version of Armbian - and this is made clear in the script comments (please review the script on github, and @tkaiser has been pushing updates, so if one has cloned the repo, it's worthwhile to do a git pull to get the latest revision.
 
To answer your question about the different versions of Cortex...
 
Small Cores - A7, A53 are the low power cores focused on efficiency
Big Cores - A15, A12(A17), A72 - big cores... 
 
Think of it like Atom (Small Core) vs Core i3/i5/i7 (Big Core) - even at the same clock, the big core is going to get more work done, but perhaps at the cost of heat, so thermal solution needs to be considered.

as far as I can see, the same wifi chip as for the firefly is populated on this board.. so by using the same drivers, and ensure it's properly defined in DT chances are high(er) that it should work 'as expected'. Using the same kernel as @hjc used for the firefly..
 
GbE is also the same, then it should be just adjustments in case DT definition changed slightly..  And if it performs badly:
https://github.com/ayufan-rock64/linux-build/blob/master/recipes/gmac-delays-test/range-test
 
well you've to be in case you want to give it a try.. I'll only help you.. build and test is then up to you... I prefer to mess with DT rather than fixing then broken things after the image is created.. From the sources, this is mostly a reference board with a few additional stuff populated (http://vamrs.com/sapphire-excavator).. There's not much an reason why things should not work. 
 
doesn't need years, DT is good enough described in the documentation to learn it.. 

interesting that they want to dive into the Intel world.. Well I assume it's less work to maintain (e.g. just fire up a recent ubuntu and you're done no hacky arm digging in u-boot or kernel ). CPU reminds me to the old AMDs 10/15 years ago where you always had to be afraid to kill it by mounting the cooler (kill one of those small caps on it and silver thermal paste was the standard so shorting was also an option ). A nice homeserver/NAS thingie for those who don't want to deal with arm. They planed funny cases.. e.g 'iteration iv':

 
but consumption looks IMO impressive (I've to admit, I've no clue how much recent intel low-level CPUs normally need - my last intel was a 7'' atom tablet with 16GB ram and a crappy display for 40$ on discount  the tablet collects dust and the USB charger is used to power an OPi Zero - they sent it with a good powering cable  ) 
 

Under 20$
the Raspberry Pi Zero W for 10$. It's very slow with only 1 core at 1Ghz. You can watch youtube with kiosk browser. And surf, very slowly.
The Banana Pi M2 Zero for 20$. A lot faster. 4x1.2Ghz. You need a good heatsink for it or it overheats constantly. Not very good video playback.
For 25$ the Rock64. Faster, better, but no wifi on-board.
A raspberry pi 3b+ is 35$ and again a bit better.
For your use case an Odroid C2 is perfect. Good Youtube playback, fast, doesn't overheat, ... That's about 50$

Those or the ones I have, and I can recommend. But for 20$ you will not get much.
You need to know that many sbc's don't have hardware acceleration for video playback in browsers. So expect choppy and low resolution video with most. The Odroid C2 does this best in Linux.
Also if a board only has 512MB ram then you want be able to open many tabs.

FriendlyArm also has got some interesting cheap boards.

I review sbc's on their desktop capabilities. Of all those I've got a video, except the C2.
https://www.youtube.com/channel/UCpv7NFr0-9AB5xoklh3Snhg

That NanoPi M4 looks really great, even though it's still pretty new and software support is still in the works. I might be willing to take a gamble on this board since I suspect the Rockchip 3399 will become fairly well supported.
 
I forgot to mention that small form factor is important to me as my project is concealing a wifi-enabled server in an RGB accent lamp which I will carry around with me while living an "ultramobile" lifestyle So, the NanoPi M4 wins on form factor as well. I suspect I could arrive at a tolerable thermal situation by some combination of a copper shim to the heatsink, mounting non-horizontally and building the enclosure with convection in mind, and perhaps some tinkering with clock speeds as needed.
 
Looks like wifi might still be a bit dodgy. I suppose I'll have to take my chances with that and fall back on a known good USB adapter if support is problematic for longer than I have to wait.
 
Thanks so much for the pointers!

This is a good review of the Nano Pi M4.
 
 

I replaced the cable with a 0.25m USB Type-A to Type-C cable (a really cheap one), and it turns out that the voltage is much more stable. At full load+2*RTL8153, it's still up at ~4.97V, and multiple RTL8153 works like a charm now.
 
However it seems that multiple RTL8153 behind a hub has some limitations. On the switch I can see traffic coming out on both USB attached ports, but they're only ~1.3Gbps total. When doing all port test (internal GbE+2 RTL8153, peer is 6*82583v configured with LACP), CPU0 is 100% and CPU2 is near 100%. I guess the A53 cores are not capable of handling such load. Anyway, currently the best choice seems to be attaching one additional RTL8153 for networking. It handles 2Gbps traffic in both directions simultaneously.

That hat is specially for this board. I'll order it when it's out.
For NAS this board is perfect. With an external hd with usb3 or with that sata hat.

@nicoD
Fantastic video you made for this board. I really really want to order one after watching your video!
Thanks a lot!

Hi all.
The undervoltage problem was a bad cable. It's a lot more stable with the original cable.
I've finished my review video about the NanoPi M4.
Again with a great working Armbian. Thank you to everyone who worked on Armbian. Great job.
Greetings.
NicoD
 

Hi all.
The undervoltage problem was a bad cable. It's a lot more stable with the original cable.
I've finished my review video about the NanoPi M4.
Again with a great working Armbian. Thank you to everyone who worked on Armbian. Great job.
Greetings.
NicoD
 

So it's not a defect of the board, right? That's good news. I'd get some shorter cable w/ lower resistance and try to test 2*RTL8153 again.

The problem was my cable. I'm sorry for the confusion.
I've tried again with the short cable they gave with it, and it's a lot better. 1A load and cpu maxed in Armbian makes it sink 0.4V instead of 1V. A huge difference. I should have seen it earlier. The cable was too short to put the M4 on my table with it...
Sorry. Only issue is that it reached 85°C without a fan. But that's only after +14minutes full load. People who max these things should know to use a fan.
Cheers
 

well, there you go: http://docs.armbian.com/Process_Contribute/ 
The way this might be possible is over devicetree overlay. Someone has to implement it, someone has to test it and to quote @Igor: Those 'someones' are rare and the few we have are already overloaded. You may want to make a video how you improved armbian by patching not only reporting?  
Maybe you can simply adjust it similar to here?
 
I never tested it on big.LITTLE SoCs 

I can confirm that my M4 also has the voltage drop issue.
1 RTL8153 connected, system idle: 4.9V Running iperf3 and generate 2Gbps traffic: 4.7V Running iperf3 with 6x cpuburn: 4.5V On NanoPC T4 the voltage is always 5.0V no matter what workload I run.