zador.blood.stained

Okay, composited:
root@orangepipc2 Doing aes-128-cbc for 3s on 16 size blocks: 19231577 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 12853395 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 5372534 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 1669698 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 224642 aes-128-cbc's in 3.00s Doing aes-192-cbc for 3s on 16 size blocks: 17959061 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 64 size blocks: 11051987 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 256 size blocks: 4292528 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 1024 size blocks: 1276599 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 8192 size blocks: 168931 aes-192-cbc's in 3.00s Doing aes-256-cbc for 3s on 16 size blocks: 17198520 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 9922363 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 3673052 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 1063205 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 139337 aes-256-cbc's in 3.00s The 'numbers' are in 1000s of bytes per second processed. 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 root@odroid64 Doing aes-128-cbc for 3s on 16 size blocks: 9702869 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 2781948 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 727164 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 183877 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 23058 aes-128-cbc's in 3.00s Doing aes-192-cbc for 3s on 16 size blocks: 8720919 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 64 size blocks: 2461310 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 256 size blocks: 639833 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 1024 size blocks: 161576 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 8192 size blocks: 20256 aes-192-cbc's in 3.00s Doing aes-256-cbc for 3s on 16 size blocks: 7892666 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 2170451 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 561814 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 141717 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 17766 aes-256-cbc's in 3.00s 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  

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

It's most likely "benchmarking gone wrong".
-evp here applies only to the next algo on the command line (aes-128-cbc), 2 next ones are not affected by this option. So I would advise to rerun the test 3 times, 1 algo at a time, and edit/post a combined table.
openssl speed -elapsed -evp aes-128-cbc openssl speed -elapsed -evp aes-192-cbc openssl speed -elapsed -evp aes-256-cbc  

The most developed mainline kernel. There is also a BSP/vendors kernel that may have better support for some hardware features, but nobody except for the vendor is interested in it, especially for less popular devices such as M3.

Took some time to get some actual numbers.
"crypsetup benchmark" shows similar (within ±5% margin) results on both Xenial and Stretch:
root@rock64:~# cryptsetup benchmark # Tests are approximate using memory only (no storage IO). PBKDF2-sha1 273066 iterations per second for 256-bit key PBKDF2-sha256 514007 iterations per second for 256-bit key PBKDF2-sha512 214872 iterations per second for 256-bit key PBKDF2-ripemd160 161817 iterations per second for 256-bit key PBKDF2-whirlpool 72817 iterations per second for 256-bit key # Algorithm | Key | Encryption | Decryption aes-cbc 128b 366.3 MiB/s 455.7 MiB/s serpent-cbc 128b 25.0 MiB/s 27.4 MiB/s twofish-cbc 128b 29.4 MiB/s 30.9 MiB/s aes-cbc 256b 314.2 MiB/s 412.9 MiB/s serpent-cbc 256b 25.3 MiB/s 27.4 MiB/s twofish-cbc 256b 29.5 MiB/s 30.9 MiB/s aes-xts 256b 401.9 MiB/s 403.9 MiB/s serpent-xts 256b 26.7 MiB/s 28.0 MiB/s twofish-xts 256b 31.3 MiB/s 31.6 MiB/s aes-xts 512b 365.8 MiB/s 365.4 MiB/s serpent-xts 512b 26.7 MiB/s 27.9 MiB/s twofish-xts 512b 31.4 MiB/s 31.6 MiB/s openssl benchmark results are a little bit different, so I'm not sure if "benchmarking gone wrong" or what
Jessie:
root@rock64:~# openssl speed -elapsed -evp aes-128-cbc aes-192-cbc aes-256-cbc (cut) OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM The 'numbers' are in 1000s of bytes per second processed. 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 Stretch:
OpenSSL 1.1.0f 25 May 2017 built on: reproducible build, date unspecified options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/aarch64-linux-gnu/engines-1.1\"" The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 89075.61k 281317.21k 589750.10k 844657.32k 965124.10k 975323.14k aes-192-cbc 85167.28k 252748.95k 487843.41k 655406.42k 727607.98k 733538.99k aes-256-cbc 83124.71k 235290.07k 427535.10k 550874.11k 600997.89k 603417.26k Edit: looks like benchmarking actually went wrong and "-evp" parameter placement (or existence) on the command line affects the benchmark
Edit 2: Redid and updates Stretch numbers
Edit 3: Redid and updated Xenial numbers
 
Had to run "openssl speed -elapsed -evp <alg>" for each algorithm separately.

Rock64 also shows exceptionally high numbers for the AES encryption in cryptsetup benchmark, and I wonder if it would also show such high numbers in Syncthing, which would make it a very good node for personal backup infrastructure based on Syncthing (or BTSync which also uses AES).

Different wireless chips may have different powering scheme and different wake/enable/reset GPIOs. I.e. OPi Zero has a separate GPIO controlled regulator for the wireless while OPi Lite drives wireless from the main 3.3V bus directly.

You can't really compare A20 and H3 in the host mode. A20 will use rather limited host emulation (MUSB) mode by the OTG controller. H3, H5 and A64 OTG port can be multiplexed to a "real" EHCI/OHCI host which doesn't have any limitations (as long as the OTG port can provide enough power to your DVB-T tuner).
 
Sorry, I didn't try to be harsh or rude, I just already said on the previous page that I'm planning to upgrade when 4.13 is released and I didn't think that OTG may be of interest to anyone since H5 (compared to A64) has enough USB host controllers for most use cases.

I'm sorry, but why starting it in the first place? For the sole purpose of humiliating the vendor?
As I said previously, I'm against creating a "board bring up" threads without an actual intent to add support for the hardware in the nearest future. And while the M2 berry thread can be called a "quick review" because it is based on evaluating an actual hardware sample, this thread is based mostly on speculations and it contains more than 3 pages of anything but a board bring up related discussion.
The worst part of it is that a personal opinion (that at first glance can only be described as "toxicity towards a specific vendor") can be associated with the Armbian project and community as a whole, and I wouldn't be surprised if some other vendors that wanted to establish contact with us decided to not do it because they don't need a shitstorm in their direction for a couple of bad decisions made in the past.
IMO this thread belongs in the "General chit chat" section if not in the recycle bin.

Unfortunately this is not the first time I hear this, but you still wasted your time in this thread, BPi M2 berry thread or almost every recent article on the cnx-software related to hardware made by Sinovoip.
 
Again, my point is that a "board bring up" thread should be started with the intention of adding support for the device, and it should consist mostly of the discussions related to the hardware, and software and documentation for this specific device.
 
Until the board in question meets the basic requirements already (somebody has a sample, all necessary documentation and sources were already released) let's keep these threads in a different format - review, discussion, speculation based on the public information, but not a "board bring up".
 
The first and third posts in this thread already have a drama regarding deleting forum posts, questioning the vendors reputation, comparison to other unrelated devices, a history lesson regarding different efforts to improve the vendor or even helping them, and the 4th post focuses on a different (completely unrelated) device, and I don't see how this can help us with bringing this device to our build system.
 
I intend to move it to the "General chit chat" section and remove the [Board Bring Up] prefix in the title.
Also BPi M2 Berry thread can be moved to the reviews subforum since you tested an actual hardware sample.
 
If/when vendor releases updated/corrected specifications it would be easy to copy-paste them into a newly created board bring up thread, but I don't have to tell you what are the chances of this happening.

I'm sorry, but why starting it in the first place? For the sole purpose of humiliating the vendor?
As I said previously, I'm against creating a "board bring up" threads without an actual intent to add support for the hardware in the nearest future. And while the M2 berry thread can be called a "quick review" because it is based on evaluating an actual hardware sample, this thread is based mostly on speculations and it contains more than 3 pages of anything but a board bring up related discussion.
The worst part of it is that a personal opinion (that at first glance can only be described as "toxicity towards a specific vendor") can be associated with the Armbian project and community as a whole, and I wouldn't be surprised if some other vendors that wanted to establish contact with us decided to not do it because they don't need a shitstorm in their direction for a couple of bad decisions made in the past.
IMO this thread belongs in the "General chit chat" section if not in the recycle bin.

I can agree with one thing - IMO it's better to ignore the hardware ot its vendor instead of constantly throwing dirt at them hoping that things will change. Instead of actively trying to improve them (which doesn't work as can be seen) let them improve themselves if they want the attention and possible software support.
 
While @tkaiser IMO spends too much time being negative about the vendor and/or hardware, he raises at least 3 valid points that apply to this vendor in general:
Wrong or incomplete technical specifications and documentation False advertising Hardware design issues While I didn't pay too much attention to the BPi R2 board, with other boards those points would cause some problems: people that buy hardware by public information and specifications won't be able to use some of the claimed features, and hardware design issues may result in either stability issues or inability to use some of the features without hardware mods (or both).
So R2 should be poked with a long stick first (to check if any of those points apply to this board), then somebody (not the vendor!) has to do stability tests and check if primary hardware features (LAN, SATA, mPCIe, wireless) are working as expected, and after that it's OK to start work on mainline based configuration.

I can agree with one thing - IMO it's better to ignore the hardware ot its vendor instead of constantly throwing dirt at them hoping that things will change. Instead of actively trying to improve them (which doesn't work as can be seen) let them improve themselves if they want the attention and possible software support.
 
While @tkaiser IMO spends too much time being negative about the vendor and/or hardware, he raises at least 3 valid points that apply to this vendor in general:
Wrong or incomplete technical specifications and documentation False advertising Hardware design issues While I didn't pay too much attention to the BPi R2 board, with other boards those points would cause some problems: people that buy hardware by public information and specifications won't be able to use some of the claimed features, and hardware design issues may result in either stability issues or inability to use some of the features without hardware mods (or both).
So R2 should be poked with a long stick first (to check if any of those points apply to this board), then somebody (not the vendor!) has to do stability tests and check if primary hardware features (LAN, SATA, mPCIe, wireless) are working as expected, and after that it's OK to start work on mainline based configuration.

Apart from some migration issues, the hash from a fixed serial will be constant (Edit: well, it's not a hash in the true sense of the word since it uses part of the SID directly and crc32 of another part of the SID). Whether MAC address will be generated using that hash or not is the question, and, as I said, if the MAC is random, then it's due to the Device Tree configuration, and it is a board specific problem since each board uses its own Device Tree.
Just for the reference: http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/board.c;h=800f412b383ddf9ac90972e50a684c534d40fea4;hb=HEAD#l656
 
Random ones are not generated from a hash, obviously.
 
For some reason I've spent wasted some time and found the exact reason why the MAC is random in some cases. I guess blaming systemd and NetworkManager without trying to understand and debug the problem is easier.
 
Are you talking about stability in images that are marked "development" and "provided with no support"? For testing/development purposes random MAC is not an issue, completely broken Ethernet is not an issue, even missing CPU frequency scaling and thermal protection is not an issue. As long as it builds without issues and boots to a command prompt on a serial console it's working as intended, everything else is a nice bonus.

Apart from some migration issues, the hash from a fixed serial will be constant (Edit: well, it's not a hash in the true sense of the word since it uses part of the SID directly and crc32 of another part of the SID). Whether MAC address will be generated using that hash or not is the question, and, as I said, if the MAC is random, then it's due to the Device Tree configuration, and it is a board specific problem since each board uses its own Device Tree.
Just for the reference: http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/board.c;h=800f412b383ddf9ac90972e50a684c534d40fea4;hb=HEAD#l656
 
Random ones are not generated from a hash, obviously.
 
For some reason I've spent wasted some time and found the exact reason why the MAC is random in some cases. I guess blaming systemd and NetworkManager without trying to understand and debug the problem is easier.
 
Are you talking about stability in images that are marked "development" and "provided with no support"? For testing/development purposes random MAC is not an issue, completely broken Ethernet is not an issue, even missing CPU frequency scaling and thermal protection is not an issue. As long as it builds without issues and boots to a command prompt on a serial console it's working as intended, everything else is a nice bonus.

Isn't that reversed : it is the lower that was working but not the upper ...
This is now fixed with this commit : https://github.com/armbian/build/commit/cc4e1ccc8e236b0a3eadabaa9c7b74af43065512

Make the Raspberry Pi great again! 

Fixed. 

Even though it's off-topic, I'm using dd with verifying for unattended writing images to SD cards on a build host.
 
Not a mistake, but putting the u-boot on a SPI flash can be used to boot images from USB if for some reason you want to store rootfs on USB drive instead of SD/eMMC.

It looks to be a bug in the ARICS firmware. I reported it to TL LIm, but good luck & have fun waiting for Allwinner to fix (or even acknowledge) anything.
Obviously comparing the behavior to other releases would be good to see if it depends on u-boot DT (or maybe it's a "feature", not a bug).

Yes, it is listed as "required", not "optional".

On Zero SPI bus 0 is wired to the SPI flash pads (even if the flash itself it's not soldered), and SPI bus 1 is wired to the pin headers, so it should be
target = <&spi1>; instead

Symptoms:
Board does not boot Armbian from inserted SD card, but may boot other distributions (based on old/legacy u-boot).
Following or similar output can be grabbed from the serial console:
U-Boot SPL 2017.01-armbian (Feb 02 2017 - 03:04:04) DRAM: 2048 MiB Trying to boot from MMC1MMC: no card present spl: mmc init failed with error: -123 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### The key message here is "MMC: no card present"
 
Most likely cause:
Malfunctioning microSD slot card detect switch.
It can be verified either visually (with a magnifying glass) or electronically (with a multimeter) - at least in the slots used on Orange Pi boards and on Pine64 the pin near the switch should be shorted to the ground (i.e. SD slot casing) when card is inserted.
 
Illustration (example) of a working switch:

 
Verification (with a multimeter):
Probe 1 - slot pin near the switch (may be different for different slot types, but at least true for Oranges and Pine64)
Probe 2 - microSD slot casing or other parts connected to GND (not shown on the photo)
No card - circuit is open
Card inserted - circuit is shorted
 
Photos - card is not inseted on the left and is fully inserted on the right:
Orange Pi
 
Pine64 (switch is more visible)
 
Can it be fixed?
Yes if the switch is not broken completely, by carefully adjusting (bending) the stationary contact (left on the pictures and photos, it usually is a part of the SD slot casing) i.e using a needle so it touches the moving contact (mostly hidden inside the slot on the photos) when card is inserted and not touching it when it is not inserted.

Yes, it is listed as "required", not "optional".

On Zero SPI bus 0 is wired to the SPI flash pads (even if the flash itself it's not soldered), and SPI bus 1 is wired to the pin headers, so it should be
target = <&spi1>; instead