tkaiser
-
Posts
5462 -
Joined
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by tkaiser
-
-
6 hours ago, Lion Wang said:
Edited 46 minutes ago by Tido
deleted empty quote, cannot find posting of TK in this thread: On 2017/6/24 at 5:54 PM, tkaiser said:@Tido: You as a moderator should also think about telling @Lion Wang personally that a board bring up thread in Armbian forum is related to documenting whether a specific board is worth the efforts or not FOR US to start working on it. This is a software development thread suitable to discuss and publicly document what Armbian developers think about supporting a board or not.
If @Lion Wang feels he needs to spam this forum by mirroring stupid posts like this here I'll start to mirror even more stupid posts like Herbal Aloe Concentrate which pretty much describes manufacturer's BPi-R2 reality: A single person too ignorant to get anything being the responsible guy posting as 'sinovoip bpi team' for censoring their forum, flodding it with BS and lies while at the same time never answering customers' technical questions. I suspect the same person is also responsible for the 'copy&paste gone wrong' collection this company considers being technical documentation and maybe he's even the same ignoring all tries to help this company on Github (these losers still don't merge the pull requests here)
For anyone concerned about kernel quality issues with BPi-R2 better look at https://github.com/BPI-SINOVOIP/BPI-R2-bsp/commits/master instead of upstream mainline patches. But maybe @sean.wang can comment a bit on mainlining efforts again.
-
On 07/08/2017 at 5:33 PM, mdel said:
could someone post some figures for ssl performance on that rk3328 cortex A53 soc
Benchmarks test software not hardware
Here you go:
Debian Jessie armhf: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 44271.21k 52204.07k 55156.22k 56023.72k 56142.51k aes-256 cbc 34693.89k 39353.94k 41079.04k 41499.31k 41645.40k bf-cbc 29864.52k 37308.12k 39764.57k 40467.80k 40667.82k Debian Stretch armhf: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128 cbc 42906.97k 51552.64k 54543.45k 55381.67k 55536.30k 55437.99k aes-256 cbc 29686.84k 37227.41k 39764.91k 40532.99k 40719.70k 40654.17k bf-cbc 28744.72k 39247.51k 43142.74k 44282.20k 44583.59k 44569.94k Debian Stretch arm64: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128 cbc 41623.29k 44895.06k 46213.89k 46552.41k 46620.67k 46574.25k aes-256 cbc 33123.65k 35228.65k 36029.53k 36235.26k 36268.71k 36235.95k bf-cbc 29389.00k 39838.93k 43663.10k 44790.10k 45118.81k 45105.15k Ubuntu Xenial armhf: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 44997.09k 51821.85k 54241.71k 54892.20k 55025.66k aes-256 cbc 34964.21k 38755.18k 40066.39k 40408.06k 40501.25k bf-cbc 32691.63k 38896.87k 40785.58k 41335.13k 41487.02k Ubuntu Xenial arm64: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 40718.71k 44137.43k 45305.69k 45607.59k 45662.21k aes-256 cbc 32820.84k 34230.12k 34952.36k 35160.41k 35687.08k bf-cbc 33233.00k 39495.68k 41386.75k 41935.19k 42087.77kIn case any moderator cares about readability please add spoiler tags for the following (I will never use this functionality again with this interactive forum mess here):
RK3328 allowed to clock at 1296 MHz max. Numbers below for Debian Jessie armhf userland running on 2GB and 4GB ROCK64 (same single bank DRAM config using same slower 1600 MHz DRAM settings on all boards BTW):
Spoiler4GB/armhf:
root@rock64:~# openssl speed -elapsed -evp bf-cbc aes-128-cbc aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128 cbc for 3s on 16 size blocks: 8230706 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 2455789 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 256 size blocks: 647968 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 1024 size blocks: 164304 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 8192 size blocks: 20517 aes-128 cbc's in 3.00s Doing aes-256 cbc for 3s on 16 size blocks: 6497443 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 64 size blocks: 1846899 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 256 size blocks: 480433 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 1024 size blocks: 121630 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 8192 size blocks: 15222 aes-256 cbc's in 3.00s Doing bf-cbc for 3s on 16 size blocks: 5611448 bf-cbc's in 3.00s Doing bf-cbc for 3s on 64 size blocks: 1752438 bf-cbc's in 3.00s Doing bf-cbc for 3s on 256 size blocks: 465283 bf-cbc's in 3.00s Doing bf-cbc for 3s on 1024 size blocks: 118437 bf-cbc's in 3.00s Doing bf-cbc for 3s on 8192 size blocks: 14864 bf-cbc's in 3.00s OpenSSL 1.0.1t 3 May 2016 built on: Fri Jan 27 00:26:25 2017 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_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 43897.10k 52390.17k 55293.27k 56082.43k 56025.09k aes-256 cbc 34653.03k 39400.51k 40996.95k 41516.37k 41566.21k bf-cbc 29927.72k 37385.34k 39704.15k 40426.50k 40588.63k root@rock64:~# free total used free shared buffers cached Mem: 4020056 451412 3568644 27896 14464 328152 -/+ buffers/cache: 108796 3911260 Swap: 0 0 0 root@rock64:~# rock64_diagnostics.sh -u Generating diagnostic logs... Running file integrity checks... IP obfuscated log uploaded to http://sprunge.us/cMOL Please post the above URL on the forum where you've been asked for it.2GB/armhf:
root@rock64:~# openssl speed -elapsed -evp bf-cbc aes-128-cbc aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128 cbc for 3s on 16 size blocks: 8300852 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 2447066 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 256 size blocks: 646362 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 1024 size blocks: 164132 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 8192 size blocks: 20560 aes-128 cbc's in 3.00s Doing aes-256 cbc for 3s on 16 size blocks: 6505104 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 64 size blocks: 1844716 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 256 size blocks: 481395 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 1024 size blocks: 121580 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 8192 size blocks: 15251 aes-256 cbc's in 3.00s Doing bf-cbc for 3s on 16 size blocks: 5599597 bf-cbc's in 3.00s Doing bf-cbc for 3s on 64 size blocks: 1748818 bf-cbc's in 3.00s Doing bf-cbc for 3s on 256 size blocks: 465991 bf-cbc's in 3.00s Doing bf-cbc for 3s on 1024 size blocks: 118558 bf-cbc's in 3.00s Doing bf-cbc for 3s on 8192 size blocks: 14893 bf-cbc's in 3.00s OpenSSL 1.0.1t 3 May 2016 built on: Fri Jan 27 00:26:25 2017 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_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 44271.21k 52204.07k 55156.22k 56023.72k 56142.51k aes-256 cbc 34693.89k 39353.94k 41079.04k 41499.31k 41645.40k bf-cbc 29864.52k 37308.12k 39764.57k 40467.80k 40667.82k root@rock64:~# free total used free shared buffers cached Mem: 1975212 217108 1758104 25464 12120 112972 -/+ buffers/cache: 92016 1883196 Swap: 0 0 0 root@rock64:~# rock64_diagnostics.sh -u Generating diagnostic logs... Running file integrity checks... IP obfuscated log uploaded to http://sprunge.us/ZSRW Please post the above URL on the forum where you've been asked for it.No differences wrt DRAM size (as expected). Now using a Debian Stretch arm64 userland on 4GB board:
root@rock64:/home/rock64# openssl speed -elapsed -evp bf-cbc aes-128-cbc aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128 cbc for 3s on 16 size blocks: 7804367 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 2104456 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 256 size blocks: 541569 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 1024 size blocks: 136384 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 8192 size blocks: 17073 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 16384 size blocks: 8528 aes-128 cbc's in 3.00s Doing aes-256 cbc for 3s on 16 size blocks: 6210685 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 64 size blocks: 1651343 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 256 size blocks: 422221 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 1024 size blocks: 106158 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 8192 size blocks: 13282 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 16384 size blocks: 6635 aes-256 cbc's in 3.00s Doing bf-cbc for 3s on 16 size blocks: 5510437 bf-cbc's in 3.00s Doing bf-cbc for 3s on 64 size blocks: 1867450 bf-cbc's in 3.00s Doing bf-cbc for 3s on 256 size blocks: 511677 bf-cbc's in 3.00s Doing bf-cbc for 3s on 1024 size blocks: 131221 bf-cbc's in 3.00s Doing bf-cbc for 3s on 8192 size blocks: 16523 bf-cbc's in 3.00s Doing bf-cbc for 3s on 16384 size blocks: 8259 bf-cbc's in 3.00s 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 41623.29k 44895.06k 46213.89k 46552.41k 46620.67k 46574.25k aes-256 cbc 33123.65k 35228.65k 36029.53k 36235.26k 36268.71k 36235.95k bf-cbc 29389.00k 39838.93k 43663.10k 44790.10k 45118.81k 45105.15k root@rock64:/home/rock64# free total used free shared buff/cache available Mem: 4020056 44540 3849972 8448 125544 3936988 Swap: 0 0 0 root@rock64:/home/rock64# rock64_diagnostics.sh -u Generating diagnostic logs... Running file integrity checks... IP obfuscated log uploaded to http://sprunge.us/hCeH Please post the above URL on the forum where you've been asked for it.Now Ubuntu Xenial arm64 on the 4 GB board:
root@rock64:~# openssl speed -elapsed -evp bf-cbc aes-128-cbc aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128 cbc for 3s on 16 size blocks: 7634759 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 2068942 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 256 size blocks: 530926 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 1024 size blocks: 133616 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 8192 size blocks: 16722 aes-128 cbc's in 3.00s Doing aes-256 cbc for 3s on 16 size blocks: 6153907 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 64 size blocks: 1604537 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 256 size blocks: 409598 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 1024 size blocks: 103009 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 8192 size blocks: 13069 aes-256 cbc's in 3.00s Doing bf-cbc for 3s on 16 size blocks: 6231187 bf-cbc's in 3.00s Doing bf-cbc for 3s on 64 size blocks: 1851360 bf-cbc's in 3.00s Doing bf-cbc for 3s on 256 size blocks: 485001 bf-cbc's in 3.00s Doing bf-cbc for 3s on 1024 size blocks: 122857 bf-cbc's in 3.00s Doing bf-cbc for 3s on 8192 size blocks: 15413 bf-cbc's in 3.00s 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 40718.71k 44137.43k 45305.69k 45607.59k 45662.21k aes-256 cbc 32820.84k 34230.12k 34952.36k 35160.41k 35687.08k bf-cbc 33233.00k 39495.68k 41386.75k 41935.19k 42087.77k root@rock64:~# free total used free shared buff/cache available Mem: 4020056 28684 3847976 8448 143396 3939604 Swap: 0 0 0 root@rock64:~# rock64_diagnostics.sh -u Generating diagnostic logs... Running file integrity checks... IP obfuscated log uploaded to http://sprunge.us/eCcI Please post the above URL on the forum where you've been asked for it.And now finally Ubuntu Xenial armhf on the 4 GB board:
root@rock64:~# openssl speed -elapsed -evp bf-cbc aes-128-cbc aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128 cbc for 3s on 16 size blocks: 8436954 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 2429149 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 256 size blocks: 635645 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 1024 size blocks: 160817 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 8192 size blocks: 20151 aes-128 cbc's in 3.00s Doing aes-256 cbc for 3s on 16 size blocks: 6555789 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 64 size blocks: 1816649 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 256 size blocks: 469528 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 1024 size blocks: 118383 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 8192 size blocks: 14832 aes-256 cbc's in 3.00s Doing bf-cbc for 3s on 16 size blocks: 6129681 bf-cbc's in 3.00s Doing bf-cbc for 3s on 64 size blocks: 1823291 bf-cbc's in 3.00s Doing bf-cbc for 3s on 256 size blocks: 477956 bf-cbc's in 3.00s Doing bf-cbc for 3s on 1024 size blocks: 121099 bf-cbc's in 3.00s Doing bf-cbc for 3s on 8192 size blocks: 15193 bf-cbc's in 3.00s OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) 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 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_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 44997.09k 51821.85k 54241.71k 54892.20k 55025.66k aes-256 cbc 34964.21k 38755.18k 40066.39k 40408.06k 40501.25k bf-cbc 32691.63k 38896.87k 40785.58k 41335.13k 41487.02k root@rock64:~# free total used free shared buff/cache available Mem: 4020056 26360 3859864 8448 133832 3942152 Swap: 0 0 0 root@rock64:~# rock64_diagnostics.sh -u Generating diagnostic logs... Running file integrity checks... IP obfuscated log uploaded to http://sprunge.us/EWRI Please post the above URL on the forum where you've been asked for it.And finally 'stock' Debian Stretch image from here: http://wiki.pine64.org/index.php/ROCK64_Main_Page#Stock_Build_Debian_Jessie_LXDE_Linux_Kernel_ver_4.4_.5BmicroSD_Boot.5D_.5B20170705.5D_Pre-Release_version
root@linaro-alip:/home/linaro# lsb_release -c Codename: stretch root@linaro-alip:/home/linaro# openssl speed -elapsed -evp bf-cbc aes-128-cbc aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128 cbc for 3s on 16 size blocks: 8045057 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 2416530 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 256 size blocks: 639181 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 1024 size blocks: 162251 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 8192 size blocks: 20338 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 16384 size blocks: 10151 aes-128 cbc's in 3.00s Doing aes-256 cbc for 3s on 16 size blocks: 5566282 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 64 size blocks: 1745035 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 256 size blocks: 465995 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 1024 size blocks: 118749 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 8192 size blocks: 14912 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 16384 size blocks: 7444 aes-256 cbc's in 3.00s Doing bf-cbc for 3s on 16 size blocks: 5389635 bf-cbc's in 3.00s Doing bf-cbc for 3s on 64 size blocks: 1839727 bf-cbc's in 3.00s Doing bf-cbc for 3s on 256 size blocks: 505579 bf-cbc's in 3.00s Doing bf-cbc for 3s on 1024 size blocks: 129733 bf-cbc's in 3.00s Doing bf-cbc for 3s on 8192 size blocks: 16327 bf-cbc's in 3.00s Doing bf-cbc for 3s on 16384 size blocks: 8161 bf-cbc's in 3.00s OpenSSL 1.1.0e 16 Feb 2017 built on: reproducible build, date unspecified options:bn(64,32) rc4(char) des(long) aes(partial) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/arm-linux-gnueabihf/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 42906.97k 51552.64k 54543.45k 55381.67k 55536.30k 55437.99k aes-256 cbc 29686.84k 37227.41k 39764.91k 40532.99k 40719.70k 40654.17k bf-cbc 28744.72k 39247.51k 43142.74k 44282.20k 44583.59k 44569.94k root@linaro-alip:/home/linaro# file $(which openssl) /usr/bin/openssl: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=c14ec07b1c33d019cab7024195ccefb454bc0c37, stripped root@linaro-alip:/home/linaro# free total used free shared buff/cache available Mem: 4019968 119588 3710644 26580 189736 3843704 Swap: 0 0 0 root@linaro-alip:/home/linaro# dmesg | curl -F 'sprunge=<-' http://sprunge.us http://sprunge.us/IhXf -
On 31.7.2017 at 10:41 PM, enki said:
the tinker board, great h/w
Not really, it's a nice collection of various hardware flaws and could even serve as a perfect 'how not to design a single board computer' example: https://forum.armbian.com/index.php?/topic/4614-asus-tinker-board/
-
It seems the Trusted Firmware version burned to SPI NOR flash now uses the following config to set CPU and DRAM clockspeeds on the Espressobin production version shipped recently: https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/blob/A3700_utils-armada-17.06/clocks-1000-800.txt
Has anyone of you already played around with other settings available there or has a clue how to apply them?
-
I let that Linpack ran over night in a loop with heatsink and fan active:
root@espressobin:/usr/local/src/StabilityTester# grep -c "FAILED" nohup.out 0 root@espressobin:/usr/local/src/StabilityTester# grep -c "PASSED" nohup.out 732No problems occured. Still interested in other users reporting thermal 'feelings' (we don't have thermal readouts active in any kernel yet so it needs a finger pressed on the SoC or SD card slot nearby if touching the SoC hurts too much)
-
2 minutes ago, umiddelb said:
Mainline kernel doesn't come with cpufreq support.
As does legacy kernel. Thanks for your 7-zip numbers that show identical performance with mainline and legacy kernel (the whole 'test' is just about both kernels using same CPU and DRAM clock speeds which is obviously true according to the numbers).
I'm still thinking we have a heat related instability issue here and should investigate about DVFS settings (or at least DFS!). Can other users who don't use a heatsink and fan do the primitive 'thumb test' on the SD card slot? On my board at an uptime of ~15 minutes this already feels way too hot.
-
Update: I stopped cpuburn-a53 after almost 3 hours, then switched to an optimized Linpack:
sudo apt install libmpich-dev cd /tmp git clone https://github.com/ThomasKaiser/StabilityTester cd StabilityTester/ while true ; do ./xhpl64 ; doneI get 1.48 GFLOPS on average. Stopped then the fan to see what happens. Linpack reported 'PASSED' all the time but since I touched the heatsink with my fingers from time to time and it again started to hurt I stopped the test (switched on the fan again).
Currently to me it seems we are (or at least I am) running in an overheating issue with this board. Please can other Espressobin users share the result of a 'thumb test'? Put your thumb on the SoC while the board is idling. Does it hurt or not?
-
1 hour ago, Igor said:
Perhaps we should do for 4.12 and have at least one working alternative?
Well, currently I'm trying to figure out why I didn't manage to get any stable experience with Espressobin so far. Since Uli reported 4.4 kernel would freeze after some time I just thought let's check whether he's also able to report overheating and maybe settings are different between legacy and mainline kernel (eg. mainline only with one CPU core active running at very low clockspeeds).
Currently I've no idea whether we're making use of DVFS with any kernel on 3720 and I also don't know at which voltage the CPU cores are fed with. I only know that for me adding heatsink and fan seemed to solve my issues:
root@espressobin:~# ps auxwww | grep burn root 5942 99.5 0.0 1624 320 pts/0 R 09:51 126:56 /usr/local/bin/cpuburn-a53 root 5943 99.5 0.0 1624 80 pts/0 R 09:51 126:55 /usr/local/bin/cpuburn-a53 root 9027 0.0 0.2 4200 1968 pts/1 S+ 11:59 0:00 grep burnIf cpuburn-a53 is running now for over 2 hours without problems and the board is still stable and I got even ext4 fs errors before when it only idled around (while touching the SD card slot burned my finger)... then I think thermal issues might be worth an investigation here.
-
On 12.7.2017 at 9:54 PM, umiddelb said:
the board tends to crash silently with the marvell-linux 4.4 kernel after a couple of hours.
Have you ever checked SoC temperature (touching with a finger is enough, if it doesn't hurt then something's different compared to my experiences with Armada 3720 so far. And did you check clockspeeds with mainline kernel?
I did a quick check with 7-zip's benchmark mode and get with legacy kernel (running at 1.0GHz according to u-boot output) this -- can you or others running mainline kernel please check too:
root@espressobin:~# 7z b 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,2 CPUs) RAM size: 926 MB, # CPU hardware threads: 2 RAM usage: 425 MB, # Benchmark threads: 2 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 726 143 495 706 | 18868 199 858 1703 23: 722 143 514 735 | 18631 199 858 1705 24: 720 143 540 775 | 18387 199 859 1706 25: 710 142 572 811 | 18290 199 863 1720 ---------------------------------------------------------------- Avr: 143 530 757 199 859 1709 Tot: 171 695 1233I added a heatsink and a fan powered by a random SinoVoip product and let now cpuburn-a53 run for at least an hour. So far no freezes/instabilities and SD card slot doesn't feel hot unlike before with neither heatsink nor fan:
-
I'm giving up on ESPRESSOBin for now. Even with the 2nd board I'm now playing with I'm still not able to access serial console (read is ok but not able to interact). Besides that the board horribly overheats with our legacy kernel.
I let a new OMV image build few hours ago which boots but then runs into instabilities after some time (eg. ext4 errors, by touching the SD card slot next to the ARMADA 3720 I already burned my finger and touching the SoC itself was only possible for a very short fraction of time). Serial console output here and debug output there. It seems cpufreq scaling is not available while @lupus mentioned that power consumption increased by 1.5W after I switched from ondemand to CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE=y some days ago which makes not that much sense anyway.
According to boot log the SoC runs at 1.0GHz and should even be capable to run at up to 1.2GHz. Given the huge amounts of heat it dissipates I fear I need active cooling to play further with this thing. What do other experience with legacy kernel after let's say 5 minutes uptime? Does it hurt to press a finger on the SoC or not?
-
On 5.8.2017 at 12:28 PM, op1tjaap said:
Really shocking that nobody at these companies seems to bother to read this forum and learn from mistakes from the past.
If your board is still equipped with USB power this is really unbelievable after all we now know about the problems it will cause.
This specific company responsible for BPi-M2 Berry's power design knows exactly what they do. Here their CEO (Lion Wang) explained that you need a PSU with 5.5V to compensate for voltage drops with a connected HDD when powering the crappy way (Micro USB): '5V power for some hardisk is not good to work , but we test . if you use 5.5V , 2.A will work fine . so we do 5.5V , 2.1A power for R1'
Different Banana, same (long known) problem. But since they want to advertise this BPi-M2 Berry as being 'fully compatible' with Raspberries they chose this absolute unreliable powering scheme again. And when then more and more unsatisfied customers start to fill their forum with complaints they simply shut it down -- that's why the above is only available through web.archive.org any more.
Edit: Under-voltage reports:
-
Final benchmark (after fighting against this lousy OS image called '2017-07-10-ubuntu-16.04-mate-desktop-beta-bpi-m2u-sd-emmc.img'). After moving an orphaned /etc/samba/smb.conf out of my way I used our 'armbian-config' tool to conveniently install Samba. I added the usual OMV/Armbian performance options and then did a benchmark using Gigabit Ethernet and the usual Samsung EVO840 SSD I always use for such tests (so you can compare results here):
As already said: I did not optimize settings like IRQ affinity further but simply used the stupid SinoVoip defaults (not giving a sh*t about what's important on these small ARM boards to get somewhat decent performance).
Please check also dmesg output: http://sprunge.us/KfTO -- while benchmarking this pretty power efficient SSD numerous occurences of 'ata1: hard resetting link' happened. It seems the power design of this board is not even capable of providing enough power to SSDs. Tests were done with a short 20AWG rated Micro USB cable and with my 'standard' PSU known to provide stable 5.0V even at 1.8A load. Well, if your 'business model' is simply trying to cash in on Raspberry Pi popularity and involves lying to your potential customers and claiming your device would be 'fully compatible' to every RPi accessory then of course you have to also use shitty Micro USB for DC-IN to create the impression of 'compatibility'.
But on Raspberries starting with 2nd generation RPi Foundation implemented under-voltage detection circuitry that triggers actions when input voltage drops below 4.65V. The firmware then starts to throttle down CPU, memory, GPU and VPU. Nothing of this is implemented on this M2 Berry thingie. It simply fails with providing enough voltage to a connected SATA disk.
Since the hardware vendor doesn't provide schematics we can't have a look into details and whether it's possible to fix the issue here or there. Most simple solution: stay away from such irresponsible vendors. They'll make their profit anyway as @zador.blood.stained already explained.
-
The above is a so called 'Banana Pi M2 Berry' I bought yesterday and will return today to get my money back (due to 'Irreführende Werbung' / false advertising) showing most probably the use case this device will be bought by clueless people: To connect a SATA 2.5" disk to it since 'native SATA'. Of course this doesn't work as expected since the board's power design is an absolute fail.
The manufacturer already knows what a shit show using Micro USB for DC-IN is. I simply used the same average USB cable I used to demonstrate the problem a few years ago with the original Banana Pi. With an average USB cable the disk does not even spin up but only produces ugly noise (clicks and motor spinning on/off constantly). Check dmesg output at the bottom of http://sprunge.us/FaFL to see how under-voltage shows up in the logs. When the poor disk made ugly noise I measured on pin 2 and 6 (5V/GND) and saw voltage dropping as low as 4.4V which is definitely way too low for a variety of disks. Check with Hardkernel's findings wrt exactly the same issue: 'We found that Seagate 2TB and HGST/Hitachi 1TB HDDs are quite sensitive to the input voltage level while WD 1TB/500GB, Samsung Momentum and Toshiba HDDs are working well even with 4.4Volt input.'
Please note that in the above setup I did not use Gigabit Ethernet. GbE significantly increases consumption and then voltage drops even more. In other words: Depending on the USB cable users choose, the PSU/charger, the type of connected disk and additional load on the board the stuff people buy this board for (NAS use cases) will either work or not. Since all the advertisements for this board are misleading the average buyer of this board must be also clueless -- since if he does some research before he wouldn't buy the board. If Armbian starts to support this board we deal with a user base blaming us for the shitty power design of this board (since not understanding stuff like Ohm's law and talking about instable software where it's just under-voltage/hardware) and also why Armbian is incompatible to Raspberries (omxplayer won't work here, raspivid/raspistill don't work, every graphics stuff for Raspberries doesn't work and the users expect 'spoon feed' mode as known from Raspberry Pi forums).
Since I had the board already on my desk and the vendor itself is as usual too lazy or too stupid to provide any performance numbers I checked quickly for myself:
- The USB design of this board is as shitty as DC-IN: all 4 USB receptacles are behind the same USB hub so all have to share bandwidth (the SoC's 2nd real USB2 host port is not used. Responsible board makers in such situations connect only 3 USB receptacles to the hub and the other real USB host port to the fourth USB receptacle so this port doesn't need to share bandwidth and can be used with another disk for example). Here 'lsusb -t' output from me connecting my test USB disk to each of the 4 receptacles.
- Some CPU/memory performance numbers: https://pastebin.com/gANnaQJ5 (please keep in mind that you need to understand the influence of compiler/OS version to interpret sysbench numbers)
- Some storage performance made with a good 20AWG rated USB cable between board and my 5V/2A PSU (USB performance shitty since only USB2 and no UAS available with SinoVoip OS images, SATA performance shitty due to Allwinner's SATA implementation being slow): https://pastebin.com/24tTn05L
- Gigabit Ethernet performance: 654 Mbits/sec in TX direction and 866 Mbits/sec in RX direction (I did not try to tune settings but simply used the stupid SinoVoip defaults). Same shit show as with A20 on the older Bananas: networking is faster in RX direction while with SATA it's the opposite. So in NAS use cases when you need both Ethernet and storage bandwidth at the same time you're always bottlenecked by one of the two): https://pastebin.com/UTT9v9wN
- Wi-Fi performance not overwhelming (TX 26.6 Mbits/sec, RX 33.5 Mbits/sec, board 1m away from AP), the onboard antenna they use doesn't perform as good as the one on RPi Zero W or RPi 3 (you can't attach an external antenna since SinoVoip's technical documentation consists more or less only of lies like this): https://pastebin.com/AzMtYbFQ
The board's advertising consists mostly of lies ('fully compatible to Raspberries and all Raspberry Pi accessories'), same can be said about the 'technical documentation', the hardware vendor doesn't support his own boards (just check the forum: http://forum.banana-pi.org/latest), while the board is already sold they still don't provide schematics (and if they'll provide schematics anytime most probably they cripple them as they did with their R2 board) and the manufacturer also still refuses to merge these pull requests providing tons of security fixes for BPi M2 Ultra and this Berry here.
In other words: customers of this hardware must be absolutely clueless to buy it (trusting in false advertising and not doing any research before) while open source developers must even be stupid starting to work on this hardware given the above problems.
Final remarks: V40 SoC without heatsink idles at +55°C which seems reasonable verifying with 'thumb test', running heavy loads like cpuminer temperature exceeded 80°C but throttling with SinoVoip's OS image is configured to jump in later. DRAM frequency is not 733 MHz as claimed but 576 MHz max (will be lowered by legacy kernel throttling code at high temperatures and can be read out using /sys/devices/1c62000.dramfreq/devfreq/dramfreq/cur_freq), average load of SinoVoip's OS image never goes below 1 as usual (they really repeat every single mistake with every new board again and again) and if you're unfortunate enough to have bought this poor design you should be aware that on their OS image the first 60 seconds the below process is occupying a single CPU core fully:
root@bpi-iot-ros-ai:~# ps auxwww | grep brcm_patchram_plus root 3812 0.0 0.0 3744 548 ? S 15:48 0:00 /usr/bin/timeout 60s /usr/local/bin/brcm_patchram_plus -d --patchram /lib/firmware/ap6212/bcm43438a0.hcd --enable_hci --no2bytes --tosleep 1000 --bd_addr 43:29:B1:55:01:01 /dev/ttyS1 root 3813 100 0.0 1444 252 ? R 15:48 0:49 /usr/local/bin/brcm_patchram_plus -d --patchram /lib/firmware/ap6212 bcm43438a0.hcd --enable_hci --no2bytes --tosleep 1000 --bd_addr 43:29:B1:55:01:01 /dev/ttyS1The PMIC theoretically exposes under-voltage readouts but for whatever reason 0 is the reported value (so 3rd parties trying to support this board and its users can't identify under-voltage situations. This device is a support nightmare with a 2.5" disk connected):
root@bpi-iot-ros-ai:~# find /sys -name "*_now" | while read ; do > echo -e "${REPLY}: $(cat "${REPLY}")" > done /sys/devices/soc/twi0/i2c-0/0-0034/axp22-charger/power_supply/ac/current_now: 0 /sys/devices/soc/twi0/i2c-0/0-0034/axp22-charger/power_supply/ac/voltage_now: 0 /sys/devices/soc/twi0/i2c-0/0-0034/axp22-charger/power_supply/usb/current_now: 0 /sys/devices/soc/twi0/i2c-0/0-0034/axp22-charger/power_supply/usb/voltage_now: 0Will now take the board back to the seller asking to refund me since the claim 'fully compatible to Raspberry Pi' is just a bold lie. Will take a RPi camera with me to show the staff that it's impossible to use RPi accessories like cameras due to different physical FPC connector.
-
25 minutes ago, zador.blood.stained said:
For official support (beyond providing something that boots and doesn't break on upgrade) we would need to have a hardware sample anyway.
Agreed.
But what we see here is again a hardware vendor most probably paying an employee or external consultant fiddling around with Armbian and failing somewhat which neither serves the hardware vendor (and his customers) nor us (I really hate to read such stories about 'Armbian on device xy breaks after updating'). Moving the hardware vendor's software development process into the open and donating a bit to Armbian project most probably will both decrease costs and increase software quality a lot.
-
34 minutes ago, zador.blood.stained said:
Official support
canmay be added if a couple of hardware samples are provided (ideally still with documentation like board schematics).Hmm... instead of providing board samples they could also donate (of course still providing documentation and schematics). This board seems to be not that cheap anyway due to the special hardware included on the board.
-
4 hours ago, renard said:
For the moment on official download page they only suggest Ubuntu 16.4 4.4.70.
Be assured they also will provide an ultra slow Raspbian and other OS images since their way to create OS images is simply: 'take one of our smelly rootfs we fiddle around manually since ages and combine it with bootloader+kernel'. That's what this reposity here https://github.com/BPI-SINOVOIP/BPI-files is all about. BLOBs that contain bootloader+kernel which then get added to their images (that's why there's a rather huge FAT partition filled with junk) and then they have a tool called 'bpi-bootsel' or something like that that overwrites u-boot and replaces kernel and then they think they made a perfect OS image for a specific device. Since they suffer from ignorance and still don't get what's important that's all we can expect from them.
4 hours ago, renard said:What is the significant difference between this Ubuntu arm distros and Armbian mainline?
What's the difference between don't giving a sh*t about everything important and fiddling around in a rootfs manually (dangerous since error prone!) and something that's not comparable since totally different?
In my eyes Armbian is the following:
- A research project trying to squeeze out the max out of the devices we support (focusing on high performance and/or low consumption and making those devices useable by a broader audience)
- A fully automated and also highly customizable build system suited for different types of developers trying to collect all the results of various research tasks into a scripted configuration (that's why Armbian ships with a startup service tuning various settings even on a per board basis, with something like armbian-config to configure various stuff in a similar way on every board supported or Armbian unique features like Device Tree overlays for sunxi devices)
- An approach to collect mainline kernel patches flying around that have not landed upstream yet for a variety of devices to make a lot of boards useable with most recent kernel months before the patches are really integrated in mainline kernel (unfortunately this is both pretty time consuming and not that rewarding at the same time since users of our mainline images simply ignore the 'work in progress' status)
- An approach to fix at least already known security vulnerabilities for the various legacy kernels we support. Where possible we patch the legacy kernels provided by SoC vendors up to latest LTS version so while you still shouldn't trust ANY vendor/legacy kernel (since hacked together by SoC maker employees most probably not understanding concepts called 'security' or at least suffering from the usual Android software management 'culture' focusing on 'Does it still crash? No? Let's ship the crap and move on to something else!') you can be ensured that the already known CVEs affecting the vendor kernels are fixed in Armbian
- An insanely high amount of testing efforts to ensure that all of the above ends up in OS images that can be built from scratch and do really work afterwards ('build from scratch' is mandatory since no one right in his mind wants to use an OS image where someone else did some stuff manually before. Or at least you must suffer from insanely naïve optimism to trust in OS images where human beings fiddled around manually since if these people are bad guys or simply had a bad day and made a mistake your OS image contains a root exploitable security flaw. All of this can be avoided by creating OS images only from scratch by scripts that live in a version control system)
- And at least one of my personal goals starting to promote Armbian heavily 2 years ago was to establish some sort of 'joint development efforts' here regardless of the distro or OS image used later. Vendor focused micro communities often suffer from being trapped in micro realities and don't realize that they could hugely benefit from work done in another micro community (good example: Orange Pi vs. Pine64 'communities'). But that's not really a 'pro Armbian' issue but one of interconnecting developers here and there.
I'm sure I missed something...
Ah, yes. A by-product of all of the above are OS images that are created on a regular basis (supporting several distros, currently Debian Jessie and Ubuntu Xenial, soon on most platforms also Debian Stretch). Oh, and I forgot that we bundle bootloader, 'board support packages' and kernel images as installable packages and provide them on apt.armbian.com (so 'Armbian' is also some sort of a support/software infrastructure). Ah, ok. And we monitor security relevant information sources and act on accordingly providing kernel security fixes as soon as possible (that's why every Armbian user on this planet had a fix for stuff like 'rootmydevice' or 'Dirty COW' within 24-48 hours on his device unlike the 'usual board maker behaviour' simply don't giving a sh*t about security issues at all. Those Banana retards are not different, they refuse to patch the vendor kernels for some of their devices even if they get everything in 'spoon feed' mode for free: https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/pulls)
Oh, almost forgot: Armbian is also free technical support (this forum). If you compare with vendor offerings you might get the difference easily (especially when comparing with board vendors that allow morons to 'run' their forums).
20 hours ago, renard said:on Ubuntu they as usual stuck with little older kernel between major releases (4.4 vs 4.9 for now)
Nope, Ubuntu and Debian only maintain kernels for x86/amd64 platforms, on ARM this is not covered by the upstream distro. That's why you get an Ubuntu running with a 3.4.39 kernel when you choose a BPi M3 (could be 3.4.113 instead but those Banana muppets are too lazy or stupid to patch kernels to latest LTS version), a 3.4.113 kernel when you choose BPi M2 Zero (since they took our work), and a 4.4.70 with BPi R2 (and not 4.4.78 since too lazy/stupid). Kernel version here and there happens only by accident since Bananas don't do software, they just take what they get from either SoC vendor or community. They don't give a sh*t about kernel versions and security in general.
-
2 hours ago, pfeerick said:
I'm guessing it wasn't intentional that the current legacy Armbian_5.30_Pine64_Ubuntu_xenial_default_3.10.105 image for the pine64 wouldn't work without the battery?
Obviously not, it's just that nobody uses a power button since you need a soldering iron for. Simple workaround: don't use the power button, most probably not so simple fix: dive into BSP power management code
If the problem also occurs with other 'distros' then it might be worth to compare DT and kernel config. But zero priority of course since you're the only Armbian user around having a power button soldered (or connected to EXP header)
-
4 hours ago, martinayotte said:
why are you trying to do ssh on port 2222 while standard port is 22 ?
Since the original tutorial requires installing dropbear-initramfs package and to avoid conflicts with OpenSSH it is configured to run on another port.
-
13 hours ago, CliffB said:
For the record they replied to my email saying the OS 'wasn't yet ready' and the board wasn't available in the UK but I could order one for 15 USD.
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).
-
Some more news. Since I thought the 1st ESPRESSOBin I bought from @lupuswould be broken (no way to access TX serial console through USB, overheating, crashing) he offered to replace the board and so we met again, I returned my board and I took his known to work.
In the meantime it happened that I realized being out of the office that my laptop's battery only lasted for 6 hours so I checked and realized that I had a zombie process running since days fully utilizing one CPU core:
83941 minicom 99.7 20:48:18 1/1 0 15 4096B 0B 460K 83941 1 running *0[1] 0.00000 0.00000 501 338 72This process obviously was stuck somewhere in IO (I used a PL2303 at the time and the macOS driver is known to be not the greatest piece of software) and obviously also reponsible for not being able to enter anything over serial console while playing with my ESPRESSOBin over days. To prepare arrival of my new board I changed some stuff (updating legacy kernel to Marvell's 17.08 branch and switching from ondemand governor to powersave as a shot in the dark). I also quickly built a new legacy Ubuntu image but didn't test myself yet: Armbian_5.32_Espressobin_Ubuntu_xenial_default_4.4.78.7z
In the meantime @lupus confirmed 'my' board being accessible through serial console and also that my board boots with the new image that changed default cpufreq governor. Might be related to http://espressobin.net/forums/topic/crash-after-booting-for-about-a-minute/
I remember when starting to support H3 boards last year with mainline kernel cpufreq scaling only worked without crashing after applying this u-boot patch. Maybe it's something similar here.
-
2 hours ago, CliffB said:
tkaiser's comments re the Banana Pi products (camera interface being incompatible for instance) have steered me away from them.
There's no need to rely on my comments, not rejecting reality is already sufficient. The CSI connector is physically incompatible and even if there were adapters still no Raspberry camera would be compatible to Bananas and vice versa. Same with the DSI display connector on the so called 'RPi 3 killer' also known as Banana Pi M2 Berry. At the same time resellers have to lie to their customers about 'all accessories being fully compatible' since SinoVoip simply doesn't give a shit about providing correct information (check this link and 'Fragen und Antworten' there).
Their official 'technical documentation' is just the result of a brain damaged retard playing 'copy&paste gone wrong' and if you want a proof that these Banana products are not supported even by their own manfucaturer just visit their forum and ask a very simple technical question. You will only get an answer if your question is sales related and/or the moron posting as 'sinovoip bpi team' responsible for censoring their forum thinks he can squeeze some money out of you. Just visit their forum to get the idea how lost you are if you have to rely on 'vendor support'.
Some people were stupid enough to try to help these irresponsible guys now for over 2.5 years ( @Tido and me amongst them) but they simply don't get that they need to improve, stop being notorious liars, provide correct information, release sources they have as soon as possible, provide correct schematics (they fail even with this! It's just unbelievable how lousy this company behaves). My last try to help was suggesting how to solve the M2 Ultra instabilities but now it's enough (I had to use a different account of course -- guess what happened as soon as they found out that 'charles' is 'tkaiser'? The 'sinovoip bpi team' moron immediately started to delete a lot of my posts)
Let's leave this Banana stuff for the clueless crowd they defined as their target audience, let them babble in Facebook groups or whereever they want and simply forget about it. At the moment the manufacturer starts to improve let's talk again.
-
5 minutes ago, CliffB said:
High speed connectivity isn't required for my unit but stability is.
So the original OPi Zero for $7 is an option. I would wait what's reported here https://forum.armbian.com/index.php?/topic/4805-the-dogafu-experiment-ds18b20-unreliable-sd-card-power-source/#comment-36433 or simply order one anyway.
BTW: I can't really comment on the OOM issue with legacy kernel for H3 but when I set up an official Armbian torrent seeder months ago I chose an Orange Pi Zero with 256 MB running with legacy kernel to see whether I run into any issues. Power consumption is below 700mW (yes, mW not mA) and memory footprint of this task is pretty low: http://sprunge.us/KLHN (check the bottom for 'free' output. Uptime is only 4 days since OPi Zero is powered by an USB port of my router and when I restart the router the Zero gets power cycled too)
-
8 minutes ago, CliffB said:
I have seen and considered the Orange PI Zero (Plus 2) but recent postings about hardware v1.4 having heat issues and earlier versions have flaky wifi devices steered me away from it.
Huh? Is OPi Zero Plus 2 also affected by 'heat issues' (which according to Xunlong are just different thermal calibration issues -- no idea since not having an OPi Zero 1.4 around. Also 'Wi-Fi' issues should be fixed by the hardware change on PCB rev 1.4 -- no idea since... no one is testing this for reasons unknown to me).
NanoPi Air as well as OPi Zero Plus 2 both feature AP6212A Wi-Fi which works pretty nice also with mainline kernel (maybe a 'firmware fix' -- renaming a file -- needed). And I found Wi-Fi on OPi Lite relatively performant (given it's 1T1R 2.4GHz Wi-Fi).
-
ROCK64
in Rockchip
Posted
Amlogic's S9xx SoCs are limited to 1.5GHz by default without overclocking. And no, not the slightest idea about the differences in numbers between armhf/arm64 but in 'active benchmarking' mode this would be the begin of the journey trying to figure out why that happens to improve numbers.