TonyMac32

@hjc, I've used your dev tree to make an image for my newly received NanoPC-T4 !
Thanks for your work ! Do you planing having this effort merged into main branch by issuing a PR ?
 

In the meantime I built GCC 8.2 on Stretch on the NanoPC T4. Cpuminer now scores 10.27 kH/s on Debian Stretch when built with GCC 8.2 vs. 8.24 kH/s when built with Stretch's GCC 6.3.
 
This is stuff I want to outline. How cheap it can be to get better performance by simply caring about software  
 
To build a new GCC version on the machine I followed this recipe (last line important since cpuminer needs to be rebuild afterwards):
GCCVer="7.3.0" # replace with "8.2.0" when wanting to use this version cd /usr/local/src wget https://ftp.gnu.org/gnu/gcc/gcc-${GCCVer}/gcc-${GCCVer}.tar.xz tar xf gcc-${GCCVer}.tar.xz && rm gcc-${GCCVer}.tar.xz mkdir build cd gcc-${GCCVer} ./contrib/download_prerequisites cd ../build ../gcc-${GCCVer}/configure make -j $(grep -c '^processor' /proc/cpuinfo) make install echo "/usr/local/lib64" >/etc/ld.so.conf.d/usrLocalLib64.conf ldconfig gcc --version [ -d /usr/local/src/cpuminer-multi ] && rm -rf /usr/local/src/cpuminer-multi (I did the first steps always on a RK3399 board, and then transferred the build directoy to a RK3328 board and executed the final steps starting with 'make install' there -- twice as fast)

Le Potato:  http://ix.io/1iSQ
(1.408 GHz max speed when 1.512 commanded)
 
Tinker: http://ix.io/1iSX
(Claiming throttling, but I think it's because we add OC OPPs and limit it to 1.8 GHz by default)
 
NanoPi K2 (S905 has different blob than S905X): http://ix.io/1iT1
(I need to build a 4.18 and see if that makes some of the differences go away. )
 
The Potato and the K2 had extremely different results, I need to re-run the K2 with a 4.18 kernel and see if that changes things, since Meson64 mainline is still active development, whereas RK3288 is more or less stable
 
Memory access in Meson64, it seems the Potato wins by a good margin,
 
Potato: standard memcpy : 1812.9 MB/s (0.2%) standard memset : 5731.6 MB/s K2: standard memcpy : 1655.6 MB/s (0.3%) standard memset : 3871.9 MB/s C2: standard memcpy : 1424.9 MB/s (0.2%) standard memset : 2600.6 MB/s ... But then miner showed something odd:
 
K2: Total: 4.62 kH/s C2: Total: 4.63 kH/s Potato: Total: 3.93 kH/s <---- wtf?!?!  

After becoming discouraged after hearing about Libre Computer's plans to not release any of their board design files and noticing that all the OLinuXino boards are designed in KiCad and openly available on GitHub, I decided to purchase one of these boards (rev D).
 
Although I am already a contributor on several other Olimex products, this is the first one that I now personally own!  I would be interested in helping out on this platform, but first I would need some guidance with where everything is at with this board and the best way to get started.  Also, I am interested in doing what I can to have more of a pure Debian experience and rely less and less on Ubuntu.

So now a quick overview of the relevant SoC families with Armbian -- results in 7-zip-MIPS:
A20 @ 912 MHz: ~900 A64 @ 1152 MHz: ~2550 H3 @ 1100 MHz: ~2100 H5 @ 816 MHz: ~2200 H6 @ 912 MHz: ~2550 i.MX6 @ 1000 MHz: ~2100 RK3288 @ 1800 MHz: ~5400 RK3328 @ 1392 MHz: ~3600 S5P6818 @ 1400 MHz: ~7200 S905 @ 1500 MHz: ~3700 (for A20, H3, H5, H6, RK3328 and S5P6818 results see above, for A64 see here and there, for i.MX6 see here (search for my Wandboard), for RK3288 see MiQi results here and for S905 see ODROID-C2 numbers there)
 
All the SoCs above are quad-core except A20 (dual) and S5P6818 (octa). And it's all about the type of CPU cores: A20 and H3 are Cortex-A7, A64/H5/H6/RK3328/S5P6818/S905 are Cortex-A53, i.MX6 is Cortex-A9 and RK3288 is Cortex-A17. So let's look at all the results, take count of cores into account and MHz also. The following is a table of 7-zip-MIPS per single core at 1GHz clockspeed:
A7: 475 A9: 525 A53: 625 A15: 700 A17: 750 A72: 850 (yeah, A15 and A72 also exist -- see below).
 
So that's roughly what you can expect from each individual Cortex core running at 1 GHz. As expected if a SoC contains more cores specific workloads that benefit from parallel code execution get faster (once again: most workloads are single-threaded!). Also as expected clockspeeds matter: if you buy an H3 or H5 board without voltage regulation limiting the maximum clockspeed then obviously this board will perform slower compared to another H3/H5 board with sophisticated voltage regulation allowing the CPU cores to clock much higher.
 
What also matters with this benchmark and most if not all real world workloads: memory bandwidth. Boards with just a 16-bit memory interface are slower than those with 32- or even 64-bit memory interfaces (something that the incapable sysbench pseudo cpu test is not able to report since whole execution happens inside the CPU cores). Boards that use 'better' DRAM (DDR4 vs DDR3) can be faster as long as available software/settings are available (and that's often not the case -- for example we're still waiting for Rockchip releasing new BLOBs with faster DRAM initialization for (L)PPDR4 equipped Rockchip boards).
 
Speaking about software/settings it should also be obvious that in the meantime we always also have to take care about heat dissipation of ARM SoCs used today. Heat dissipation is an issue to prevent damaging the SoCs due to overheating under load. But without fully functioning cpufreq/dvfs/thermal drivers we can not allow the CPU cores to clock at their upper limits since we need working throttling to protect the chips. And that's why the results for Allwinner H5 and H6 boards look that bad: since linux-sunxi community still is working on upstreaming driver support and/or we at Armbian have not incorporated latest patches flying around into the build system. Once cpufreq/dvfs/thermal is ready for those newer Allwinner SoCs H5 boards will get 1.5 as fast and H6 boards almost twice as fast as today.
 
Software/settings matter. Always. That's why it's so disappointing to see all those benchmark numbers flying around not taking this into account.
 
What about Cortex-A15 and A72? When we look at boards Armbian supports we find those cores in SoCs implementing big.LITTLE: ODROID XU4/HC1/HC2 use Exynos 5442 which consists of 4 fast A15 and 4 slow A7 cores (32-bit ARMv7). Boards based on RK3399 have 2 fast A72 cores and 4 slow A53 cores (64-bit ARMv8)
 
Does it make sense to run the very same 7-zip benchmark on those big.LITTLE designs? Not that much since we can not easily draw any conclusion for normal workloads from such a benchmark number. For example when executing '7z b' on all 6 cores of an ODROID-N1 at the same time we get an overall score of ~6550 7-zip MIPS. When limiting benchmark execution to only the 2 fast A72 cores at 2 GHz we get ~3350 (that's ~1700 7-zip MIPS per core), when we execute the benchmark on the 4 little cores only (1.5GHz) then it's ~3900 (~975 7-zip MIPS per core). A single threaded task running on one of the two big cores will perform almost twice as fast compared to running on a little core. That's important to keep in mind since based on the workload running in reality some of the benchmark numbers are simply misleading or just... numbers without meaning.
 
Same with ODROID-XU4/HC1/HC2: when running on the A15 big cores ~4950 7-zip MIPS are reported at around 1.8GHz (~1250 7-zip MIPS per big core), when running only on the little A7 cores at 1.4 GHz it's ~2725 (~675 per core). Same situation as with RK3399: single threaded stuff moved to the big cores performs almost twice as fast as on the little cores. I never measured 7-zip running on all cores together since 'numbers without meaning' but I would assume we get something similar as with RK3399: not the addition of big+little numbers (3350+3900=7250 vs. 6550 in reality) but something lower since all cores have to fight for memory bandwidth.
 
Other things to keep in mind:
When looking at the above benchmark numbers we see A53 cores performing with this specific benchmark 30% better compared to A7 cores at the same clockspeed (so there's a slight advantage ARMv8/64-bit has over ARMv7/32-bit). But as soon as we use other software/benchmarks that make heavy use of NEON optimizations we usually see a performance increase much higher (A53 usually performing twice as fast as A7 -- can be easily checked with cpuminer). So as always it depends on the use case. Speaking of 'use case' we should also keep in mind that all those ARM SoCs have special engines for this and that. Almost all ARMv8/64-bit SoCs for example contain a cryptographic acceleration engine called 'ARMv8 Crypto Extensions' that make a massive difference with AES for example compared to 32-bit/ARMv7 SoCs that have to do crypto stuff on the CPU cores (see here for numbers). So again: it's about the use case: if you're interested in VPN stuff or disk encryption looking at generic CPU benchmarks is BS since you want an ARMv8 SoC with crypto support (almost all have, the only exceptions are RPi 3/3+, ODROID-C2 and NanoPi K2) CPU performance with many use cases isn't that important. With Marvell based boards (EspressoBin, Clearfogs, Helios4) CPU benchmarks look rather low but these SoCs are designed for highest I/O and networking throughput and even if the SoC in question scores low in CPU benchmarks those boards outperform everything else if it's about fast storage and network  

NanoPi Fire3 with Samsung/Nexell S5P6818 which is an octa-core A53 clocked by default with 1.4 GHz (results irrelevant):
 
Why are results irrelevant? For two reasons:
Throttling occured. The board with vendor's standard heatsink starts to overheat badly when running demanding loads. Active cooling is needed and that's why monitoring when running benchmarks is that important! This is an octa-core Cortex-A53 SoC showing with this benchmark a score of well above 7000 when no throttling happens. Once again: such multithreaded results are BS wrt most real world workloads. An RK3399 board like an ODROID-N1 scoring 'just' 6500 will be the faster performing board with almost all usual workloads since equipped with 2 fast A72 cores while the Fire3 only has 8 slow A53 cores. Most workloads do not scale linearly with count of CPU cores. This has to be taken into account.

@TonyMac32 yeah, I know this one, and I need to solve it. Hopefullyt it won't harm, it's just a warning I need to solve and find time to solve it...

I actively rebase my kernel on top of rockchip-linux to keep a list of patches somehow compact. My current workflow is not very good for community contribution, still: this is rebase of commit history, but I'm happy to change that.
One thing that is probably unique about my kernel that I release a new kernel version after every: https://gitlab.com/ayufan-repos/rock64/linux-kernel/ and https://github.com/ayufan-rock64/linux-kernel and this is released as debian packages that you can put on any distro and apt-get install: http://deb.ayufan.eu/ayufan-rock64/linux-kernel. In my latest builds, I effectively moved from building kernel each time to installing kernel/u-boot package for simplicity and split of responsibility (single resp repository).
 
Anyway. I don't want to be a bottleneck, so I would say that the best would be to start a new common repo branch and rebase all our work on this branch, give a few people review/merging capabilities and based the work on the good will of people. I know that being alone and reviewing/accepting is a job that can get boring, as you also need to ensure the quality, splitting the responsibility here is desirable. Now, I do all the stuff there myself, but also I only have to check rock64/rockpro64 which is to be fair not a lot of hurdle for me, but with more dependence on this work we simply need more people.
 
I somehow like the rebase workflow that we always keep a small number of patches, but I'm fine with merge workflow too
 

@guidol has a good looking case mentioned in the NanoPi K1+ thread:
 
 
 
 

@guidol has a good looking case mentioned in the NanoPi K1+ thread:
 
 
 
 

That is normal. Aptly 1.3.0 is broken on Bionic and I couldn't find any more elegant solution yet.

Update
 
All my boards have had continuous up-time for a full month now with rock solid consistency. I am really happy with this board so far and would recommend it to others. Just make sure the cooling is adequate and you will be happy with performance.
 
 
 

Ah, a XEON would be nice. my machine won't boot an nvme directly so I have a spinner for the system, I put the ccache local on the ssd.  16 GB DDR3.
 
I also have a setup on a cheap $300 ASUS laptop, i3 and spinning disk.  It is slow, but works if I'm wanting time away form my in-laws.

I second Igor's statement, I use an i7-3770 for the job.

Sent from my Pixel using Tapatalk

The only time I ever built any kernel in the cloud was good old Narcissus with Angstrom for my Mini2440.  I'm afraid I don't know of any free resources (or any resources) to do this with Armbian.

What about starting with this: https://apt.armbian.com/pool/main/l/linux-source-4.4.120-default-rockchip/

That's fine, I'm not too worried about the work needed, I've made the board work with 2 different kernel sources at this point, and mainline, and almost (at least in between commit-tastrophe's) the current Rockchip one.  As long as the thingy is stable and behaves itself we're good. 

U-Boot 2018.05-armbian (Jul 02 2018 - 00:54:54 -0400) Model: Tinker-RK3288 DRAM: 2 GiB PC event = 0x20 usb connected to SDP, force enter ums mode rk3288_maskrom_ctrl: enable_emmc = 1 usb_current_limit_ctrl: unlock_current = 1 MMC: dwmmc@ff0c0000: 1, dwmmc@ff0f0000: 0 Loading Environment from EXT4... ** Unable to use mmc 0:auto for loading the env ** Failed (-5) In: serial Out: serial Err: serial Model: Tinker-RK3288 Net: failed to enable clock 0 No ethernet found. UMS: LUN 0, dev 0, hwpart 0, sector 0x0, count 0x1d5a000 \wait for usb get descriptor cmd timeout rk3288_maskrom_ctrl: enable_emmc = 0 usb_current_limit_ctrl: unlock_current = 0 Hit any key to stop autoboot: 0 Card did not respond to voltage select! switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 1498 bytes read in 17 ms (85.9 KiB/s) ## Executing script at 00000000 U-boot loaded from eMMC 178 bytes read in 14 ms (11.7 KiB/s) 41042 bytes read in 35 ms (1.1 MiB/s) 4908082 bytes read in 238 ms (19.7 MiB/s) 9272512 bytes read in 433 ms (20.4 MiB/s) ## Loading init Ramdisk from Legacy Image at 21000000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4908018 Bytes = 4.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to 0fb51000, end 0ffff3f2 ... OK Loading Device Tree to 0fb43000, end 0fb50051 ... OK gets right to starting kernel.  The delay is the dev kernel I was building.

Hi @TonyMac32 this patch will solve the issue on 4.17 and 4.18-rc3 :
https://patchwork.kernel.org/patch/10462135/
it should be merged for -rc4 and hopefully be backported to 4.17 next week

Well, if the manufacturing is done intelligently, the tailings get recycled nicely.  You could argue the energy involved in it, but I'd probably counter the cast ones use far more energy than simply machining out of large blocks.  In general aluminum and steel are quite "eco" compared to any plastic, and certainly better than say copper as far as mining/refining are concerned.  (off topic, but interesting)

I tried it last night without any UART connection, it took it about 5 minutes to boot.  So I'm not certain what's going on, I have some other stuff to work on first in any case.

Sounds like ARM development summarized into 1 statement. 

Building Renegade....
 
***time goes by***
 
:-( 
[ 58.886742] EXT4-fs error (device mmcblk1p1): ext4_find_entry:1454: inode #16268: comm blueman-applet: reading directory lblock 0 [ 59.661737] EXT4-fs error (device mmcblk1p1): ext4_journal_check_start:56: [ 59.661785] EXT4-fs (mmcblk1p1): Remounting filesystem read-only I don't know what's doing that, this was one I built, let me try the official download, maybe I need to purge my build system again.  ;-)
 
Problem on my end it would seem.  Works good, now to play with it.
 
***installed to/booted from eMMC.***
 
Job well done, lads.

Building Renegade....
 
***time goes by***
 
:-( 
[ 58.886742] EXT4-fs error (device mmcblk1p1): ext4_find_entry:1454: inode #16268: comm blueman-applet: reading directory lblock 0 [ 59.661737] EXT4-fs error (device mmcblk1p1): ext4_journal_check_start:56: [ 59.661785] EXT4-fs (mmcblk1p1): Remounting filesystem read-only I don't know what's doing that, this was one I built, let me try the official download, maybe I need to purge my build system again.  ;-)
 
Problem on my end it would seem.  Works good, now to play with it.
 
***installed to/booted from eMMC.***
 
Job well done, lads.

Says Igor clone #4, apparently.  I couldn't make it into my basement and start an SSH session before he fixed it...  ;-)