mdel

well i'd go as far as saying that my special use case should be anyone's when it comes to dev boards, meaning use it to its full potential. Moreover if you're talking about "NAS", i expect you to know about QNAP, Synology and such, which by default invite you to install a large variety of "apps" on your "NAS", including vpn, p2p, ownclound, plex, and so on.. Bandwidth wise i do agree my use case (fast vpn) can be seen as specific but fiber finally getting on here, we get multiple hundreds of Mbps of bandwidth at home. That's when you learn that your most powerful 4K HEVC arm soc can't really do anything decent with single threaded encryption. I should also add that p2p clients can use quite a lot of memory (deluge in particular) so you should be careful about that as well. Anyways on the cheap side i would assume that tkaiser has pretty much covered the subject on his NAS thread, with his choice being the opi pc2 (i think), gigabit and multiple usb hosts. My preferred choice would be a more powerful s905 soc for "fast" openvpn and i'm actually using some ultra cheap android tv box (a95x) running armbian. You could actually add "many android tv boxes" to your list, because they aren't very different from most of those "basic" boards (hdmi, usb, 100/1000Mbps). As long as you can find a distro running on your box, you're good to go. For faster vpn and better I/O (sata / usb3) i'm using a laptop motherboard with an i5 560M, still quite cheap (around 80e), but then that's really off topic..

nice a "new" soc to play with. could someone post the result of : openssl speed -elapsed -evp bf-cbc aes-128-cbc also i see on cnx rk3288 specs, the following : Standalone crypto and decrypto, compatible with AES 128bits/DES/3DES/SHA-1/SHA-256/MD5/160bits PRNGfound some /lib/modules/../kernel/arch/arm/crypto/ modules on the git link posted above. any trace of crypto engines in armbian's legacy kernel ? maybe some more info in /proc/crypto thx.

it may be a little off topic but i have to mention that with those boards, you will get nas without (very) fast vpn. i will assume that some of us think of "NAS" as "with my p2p client", and when you mention p2p some of us have to also mention vpn (openvpn), and that's when thing get hairy with those arm socs. So far the fastest (by far) soc i have tested is the amlogic s905 (s912 gives the same performance) which can achieve 90-100 Mbps max (aes-128-cbc), with one core at 100%, openvpn being single threaded. H5/A64 is much slower, and 32bit socs tend to be slower as well unless they have a very high clock speed (2GHz).. I will mention that there's some work done on a H5 crypto engine driver but couldn't get it to work or show any performance improvement compared to non accelerated crypto. All my tests are done with armbian (vanilla or legacy kernels depending on the soc). So if you plan on using that nas to do some high speed p2p through a vpn link, you have to expect speeds (well) below 100 Mbps.

@balbes150 i'm also seeing that you've fixed CONFIG_CPU_FREQ_GOV_PERFORMANCE=y in the kernel is cpu freq scaling not working on those kernels at the moment ? it was working on your old "s905" images. thx

ok thx for the explanation, i'll try to do that. Actually can i do it on the box directly, as i see you've included the dtc tools to manipulate device tree files ? Then i have to try to understand why the gigabit on my minimxiii is so bad. Don't worry it's not related to your linux image, i already tested that in adb with the stock android. Well doing iperf3 tests, i get 980Mbps downstream (iperf3 -s on the box) and barely 100Mbps upstream (iperf -c ipofserver, on the box). The upstream stability is ridiculous, it fluctuates between 5Mbps and 100Mbps. If there's no way of fixing that then it's another device that will end up in my "useless crap" box. I know tkaiser talked about fixing ethernet timings based on board tracks but i can't find it back..

okay it booted with gxbb_p200_2G.dtb do you know why it won't boot with my original dtb file ? (extracted from /dev/block/boot)

@balbes150 ok, i copied the dtb directory 20161103 (boot ok) into the 20161223 BOOT partition (replaced the original dtb directory). it did not work. then i extracted my dtb.img from the /dev/block/boot dump (adb dump before installing aml_autoscript and booting armbian) and copied it into the BOOT partition root of both sdcards. 20161103 still works fine, of course i can't confirm which dtb was loaded in uboot but if s905_autoscript works then it should have loaded my dtb.img. and 20161223 did not boot with that very same dtb.img. I noticed that the filenames inside the dtb directory are completely different between the 20161103 (mini_m8s.dtb, mxq_pro_4k.dtb ...) and 20161223 (gxbb_p200_2G.dtb, gxbb_p200.dtb...) Do i have to rename all the dtb somehow ? Anyways i was never very confident with those dtb files, i never managed to get a system to boot by trying random dtb files, and my original device dtb should boot the 20161223 image, right ? Also i was reading kszaq s905/x libreelec install notes and he writes this : "Important: Do not use device trees from previous build! You also cannot use device tree from Android firmware as in 99% cases it won't work." - "Do not use device trees from previous build!" : that i can understand as dts sources are build against your kernel source and config. - but why does he say the next thing ? "You also cannot use device tree from Android firmware as in 99% cases it won't work." and does that also concern the /dev/block/boot dtb already in the internal memory ? or is it specific to his libreelec builds ? I'll test his latest libreelect image and see if it works. But i'll most likely try to solder serial as soon as i can so we can understand why your new s905x image won't boot here. i'll also the same 20161223 image on my other s905 box i have here, see if it boots or not.

Okay then there's a problem somewhere. - I found back my old image that is working fine and flashed it to another sdcard, so i could test a full firstrun boot : Armbian_5.24_Vegas95_Ubuntu_xenial_3.14.79_desktop_20161103.img That image boots okay on my minimxiii, "first run" then reboot, hdmi ok, ethernet ok, 2GB ram ok. - Now i flashed your new image on another sdcard and it will not boot : Armbian_5.24_Amlogic-s905x_Ubuntu_xenial_3.14.29_20161223.img As i said above it stays stuck at the beelink logo (probably uboot). I have not used a /boot/dtb.img on either of those two clean images. Do they both use the same uboot code or has it changed between versions ? Do you want me to test something else before i solder a serial to see uboot ? Sorry i don't quite understand what you mean. I did not install armbian to emmc, if that's what you're asking, i'm only using your universal boot v0.6 aml_autoscript and sdcard. thx

hello balbes150, i'm back testing armbian on my amlogic devices. i'd like to know if things have changed with dtb (auto) loading ? i'm testing a beelink minimxiii (s905, 2GB, Gigabit), installed your universal boot v0.6 and booted 4-6 weeks old image (xenial desktop, don't know which version but it had a kernel 3.14.79, now it's 3.14.29, what happened ?) and it booted fine, ethernet "ok" (poor up performances), 2GB ram available. Then flashed your latest Armbian_5.24_Amlogic-s905x_Ubuntu_xenial_3.14.29_20161223.img, and it won't boot. Stuck at the beelink logo, probably didn't pass uboot, i will install serial if necessary but no time right now. i haven't done anything concerning dtb (no dtb.img on the root folder) but i have already dumped the /dev/block/boot in adb so i can extract my dtb from it. i don't know the board version of that minimx yet. i'm assuming your "s905x" images are also for s905, as you don't have "s905" image anymore, am i wrong ? thx for clearing up those basic questions so i don't loose too much time doing things that are not correct anymore.

yeah sorry i meant legacy not vanilla. okay so i'll forget about btrfs, not a problem i can format that partition to ext4 and copy everything again.

hi, i'm running Armbian with kernel 3.14.73 from @balbes150 image for s905 i was trying to upgrade an usb hard drive and started transferring about 400GB of data from the old usb hdd (ext4) to the new one (brtfs) when this happened : i've added the initial btrfs disk mount. [ 95.972270] scsi 1:0:0:0: Direct-Access ATA Hitachi HUA72302 A840 PQ: 0 ANSI: 6 [ 95.990817] sd 1:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) [ 96.007364] sd 1:0:0:0: [sdb] Write Protect is off [ 96.020930] sd 1:0:0:0: [sdb] Mode Sense: 43 00 00 00 [ 96.021451] sd 1:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 96.081024] sdb: sdb1 sdb2 [ 96.087622] sd 1:0:0:0: [sdb] Attached SCSI disk [ 96.467915] BTRFS: device label USBBackup devid 1 transid 10 /dev/sdb2 [ 96.509151] BTRFS: device label USBLinux devid 1 transid 44 /dev/sdb1 [ 96.526054] BTRFS: device label USBBackup devid 1 transid 10 /dev/sdb2 [ 96.541960] BTRFS: device label USBLinux devid 1 transid 44 /dev/sdb1 [ 277.575889] BTRFS: device label USBLinux devid 1 transid 44 /dev/sdb1 [ 277.593542] BTRFS info (device sdb1): btrfs: use no compression [ 277.623166] BTRFS info (device sdb1): disk space caching is enabled [ 280.020449] EXT4-fs (sda2): mounted filesystem with writeback data mode. Opts: data=writeback [17089.147117] BTRFS: sdb1 checksum verify failed on 577847296 wanted 3949F1FD found 26D7F292 level 0 [17089.172645] BTRFS: sdb1 checksum verify failed on 577847296 wanted 3949F1FD found 26D7F292 level 0 [17089.189544] BTRFS: sdb1 checksum verify failed on 577847296 wanted 3949F1FD found 26D7F292 level 0 [17089.199629] BTRFS: sdb1 checksum verify failed on 577847296 wanted 3949F1FD found 26D7F292 level 0 [17089.208591] ------------[ cut here ]------------ [17089.214854] WARNING: CPU: 0 PID: 2160 at fs/btrfs/inode.c:878 $x+0x368/0x420 [btrfs]() [17089.223015] Modules linked in: tun meson_ir nfsd auth_rpcgss oid_registry nfs_acl nfs lockd sunrpc i2c_gpio i2c_algo_bit bonding fuse autofs4 btrfs xor raid6_pq [17089.243100] CPU: 0 PID: 2160 Comm: btrfs-transacti Not tainted 3.14.73-vegas95 #1 [17089.250014] Call trace: [17089.255068] [<ffffffc001089040>] dump_backtrace+0x0/0x140 [17089.260153] [<ffffffc0010891a4>] show_stack+0x24/0x2c [17089.265214] [<ffffffc00183fa48>] dump_stack+0x80/0xa4 [17089.270261] [<ffffffc0010ad7fc>] warn_slowpath_common+0x94/0xb8 [17089.275740] [<ffffffc0010ad968>] warn_slowpath_null+0x38/0x44 [17089.281604] [<ffffffbffc059fb0>] $x+0x368/0x420 [btrfs] [17089.286744] [<ffffffbffc05a404>] $x+0x39c/0x968 [btrfs] [17089.291911] [<ffffffbffc05ac68>] $x+0x298/0x370 [btrfs] [17089.297089] [<ffffffbffc071eb4>] __extent_writepage+0x660/0x7c4 [btrfs] [17089.303643] [<ffffffbffc0721c4>] $x+0x1ac/0x2d4 [btrfs] [17089.308819] [<ffffffbffc07333c>] extent_writepages+0x68/0x88 [btrfs] [17089.315112] [<ffffffbffc055d54>] $x+0x34/0x48 [btrfs] [17089.319987] [<ffffffc001182f08>] do_writepages+0x40/0x6c [17089.325247] [<ffffffc001177678>] __filemap_fdatawrite_range+0x6c/0x78 [17089.331628] [<ffffffc0011777a4>] filemap_fdatawrite_range+0x34/0x40 [17089.337970] [<ffffffbffc06c6f4>] btrfs_wait_ordered_range+0x80/0x16c [btrfs] [17089.344958] [<ffffffbffc092800>] __btrfs_write_out_cache+0x52c/0x6f8 [btrfs] [17089.351945] [<ffffffbffc093d48>] $x+0x98/0xfc [btrfs] [17089.356941] [<ffffffbffc0434d8>] btrfs_write_dirty_block_groups+0x4e8/0x628 [btrfs] [17089.364540] [<ffffffbffc0c5404>] commit_cowonly_roots+0x13c/0x204 [btrfs] [17089.371261] [<ffffffbffc0530b4>] btrfs_commit_transaction+0x454/0x888 [btrfs] [17089.378333] [<ffffffbffc04f5c0>] $x+0x150/0x1d0 [btrfs] [17089.383380] [<ffffffc0010d1fe0>] kthread+0xdc/0xf0 [17089.388956] ---[ end trace 6da0e760a6c1ab74 ]--- my cp command got stuck and kswapd0 started to go haywire showing 1.5GB/s of I/O i'm only guessing that a btrfs process crashed, i don't know much about btrfs so i have not configured anything special besides adding the compress=no to my fstab. The first 200GB copy completed properly. I did notice that the I/O rate was not completely stable, going around 35MB/s read and write from the two disks, but every 10-15 sec stopping and a btrfs commit process started doing some io for a couple of seconds then the devices read write would come back. Reading about those "checksum verify" messages, i see quite a lot of mentions of btrfs kernel bugs, so i'm wondering about my choice of btrfs on the current vanilla kernel. Although it is not the latest one i don't expect it has moved far beyond my version with an up to date kernel..

thx i knew it was somewhere around here. it doesn't look like Shimon gave us some followups about stability when removing those timers, do you know if it fixed the problem ? or are there other forums discussing that, i'll try to browse odroid c2 forums for that as well.. Quick question, i see that all your Linux/Armbian images are labelled s905x, are they compatible with s905 or did you move your s905 images elsewhere or stopped making them ?

@@balbes150 i was looking into recovering gpu reserved memory on my headless s905 1GB box and reading at some odroid (c1) posts, i was wondering if it could be possible to implement the same thing with your s905_autoscript. the idea would be to remove those dts entries dynamically using ftd commands but in a sub script like s905_headless that would be loaded by s905_autoscript, if found on the /boot partition. Then for a desktop image you would simply remove the s905_headless sub script and it would still boot with full gpu hardware init. I have not yet investigated s905 specifics to know exactly which dts elements could be removed, so this is only an example in order to know if the sub script idea is a possibility, or if you can't load a sub script from an parent one. In that case you would need two "s905_autoscript", full init or gpu disabled. One last thing, i remember reading about those dts modifications and people were saying that i could introduce stability problems because of timers associated with some of those hardware units, but i can't remember if it was related to amlogic or allwinner. thx

i've ordered a Meecool bb2 (s912 2G 16G), so at some point i'll also do some tests with balbes150 images. I really have no use for an s912 but i can play wit it a bit and see how it performs against s905 for my own use case. @lvmc yeah, i know those internal antennas are really weak but i was more interested in seeing AC performances, because my tests with xiaomi mini router in AC mode were quite impressive, although my wifi knowledge is quite thin as i tend to use it as little as possible. I believe i saw an external antenna hack for the GT1 somewhere but it's really the same for any box, drill/screw an antenna mount on the case and solder it to the antenna pads on the board.

i was looking at those s912 boxes, including the GT1, and i'm curious, do they really have 802.11AC wifi or is it simply (a)/b/g/n 2.4GHz + 5GHz ?? if yes then how is it performing ? thx

yes you need to build an AF_ALG engine then configure openssl to use it, or force it on the benchmark command line with -engine af_alg "-elapsed" then becomes very import to get proper results, otherwise it will spit out crazy number looking at the "cpu time" (being not used..). i believe i used that one on my test : https://github.com/sarnold/af_alg But my understanding was that once the hw engine is used, cpu load should drop significantly, or are there still parts of the computing that will max out cpu load ? I don't understand my H3 results, i did get crazy numbers when using the engines and not adding "-elapsed", but the cpu load always went to 100% on one core, and then with "-elapsed" the results were within 1% of my non accelerated tests.. i don't understand what's the difference between cryptodev and af_alg or if they have specific applications. i will keep a close eye on that Armada 3700 kickstarter board, it seems you can only order the 1GB ram version which was the one i wanted, then it's 45e+27e shipping. For the moment i'll get myself a 35$ 2GB/8GB s905 box with Gigabit and see how it compares to the Odroid C2.

yup same error with lxde. To make sure i was not missing something obvious, i made the exact same installation inside a debian testing VM (x64) and it works fine, both xfce4 and lxde. it's also supposed to be able to run single app but don't know if that works differently than having the whole window manager, it fails the same way here anyways. I'm starting to wonder if it's not an arm64 system (xenial) problem but i only have s905 socs to test it on, or maybe with x2go ppa build. I will try that ppa on a 32bit arm H3 or s805 and then your git packages if nothing works. if it does work, i'll test installing a tested armhf build on my aarch64 system and see how it goes..

thx @lvmc it's more or less (a little less for some reasons) the same as s905. It's as expected, s912 having the same A53 cores clocks as the s905.

[off topic] @zador.blood.stained are those benchmarks for the Marvell A388 ? Your figures are almost as high as the s905 for openssl which is quite good i imagine (A3700 > A388?). The other board i've investigated is the XU4 which gives 1.5-2x the s905 performance, so i guess the A15 at 2GHz does the trick compared to a A53 at 1.5GHz. [/off topic] @lvmc if you already managed to boot a linux on your s912 could you run that benchmark ? openssl speed -elapsed -evp bf-cbc aes-128-cbc aes-256-cbc you can post them here if you don't want to pollute this thread, although it would be relevant to the s912 this time. I would still be interested in an s912 box, mainly because they are quite cheap now, come with 2G of ram and Gbe. i have to check the s912 diagram again to see if there would be more things of interest to me (not the gpu stuff), i know it has an x265 encoder that i could make use of, but we can probably wait until the end of time before any software can actually use it..

Very interesting board and at a decent price, looking at the block diagram, do you know if the Armada 3700 Security Engine already has mainline support or if a driver has been discussed by the devs. the datasheet says "Complete SDK including U-Boot, Mainline Linux BSP", but well you know.. I'm again trying to see if that soc would have any kind of decent performance (+100Mbps) with openvpn (ssl / aes-128-cbc). Not sure how kickstarter works and if that kind of question can be asked directly.

posted some openssl benchmark for the H5 (opi pc2) on my crypto vpn stuff thread.

well i did manage to build that ss driver along with crytodev but not sure the hw engine was ever put to work with my openssl cryptodev build. Modules are loaded, and show some usage when openssl runs but the figures are almost exactly the same with or without the hardware engine, and the cpu load is always 100% on a the single core used. Anyways i've decided to stick with Amlogic s905 which is definitely far more powerful than H3 in the current software crypto environment. I've also tested my Opi PC2 H5 with Xulong Xenial server image Ubuntu_Server_Xenial_PC2_V0_9_0.img >sudo openssl speed -elapsed -evp bf-cbc aes-128-cbc 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 32461.71k 34913.11k 35852.12k 36085.08k 36162.22k bf-cbc 26314.67k 31261.35k 32766.81k 33205.93k 33333.25k I understand that the current Opi BSP image is junk, possibly the cpu being stuck at 1GHz, and actually the temperature from /sys/devices/virtual/thermal/cooling_device0/subsystem/thermal_zone0/temp would only go from 41 to 45 while running the test (no heatsink).. But those figures don't look very promising to me, and the steadiness of those figures for various packets size looks a bit funny but i'll trust the benchmark for now and won't bother testing that live with a vpn link. Considering montjoie's comments on the H5 crypto engine being the same as H3/A64 with some buggy / removed parts from the datasheets i would probably recommend staying away from Allwinner CPU if any crypto intensive use is expected. Maybe something else will come out of 2017, we'll see, in the meantime i'm going back to my ODROID-C2, best "cheap" board for intensive (usb) nas / vpn if you ask me.

tried the same thing on my a95x s905 (arm64) box running armbian xenial desktop (xfce) i'm using x2go stable ppa. I can see the x2go window on the client (x2go background displayed), then it goes black and closes. the generic error from .xsession-x2go-error is the following : The program 'xfce4-session' received an X Window System error. This probably reflects a bug in the program. The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 47 error_code 2 request_code 2 minor_code 0) No idea what's goin on, almost no other error output is logged, not much in syslog which has x2goserver output..

okay sorry i completely missed that one =)

okay the build works but i have a kernel config problem when simply changing the dev kernel git source, it doesn't seem to use the git kernel config, maybe because i did build a mainline (not dev) kernel first, i don't know. i've tried with full image build and KERNEL_ONLY=yes Anyways my dev build has : # CONFIG_CRYPTO_DEV_SUN8I_SS is not set so the driver is not there : ls /lib/modules/4.9.0-sun8i/kernel/drivers/crypto/sunxi-ss/ sun4i-ss.ko what's the armbian way to set kernel options when using a dev source ? i'll try fiddling with KERNEL_KEEP_CONFIG but i'm not sure i understand its real purpose. Also my bench with that 4.9 mainline kernel (xenial image) seems to be somewhat worse than with the legacy kernel (jessie), any idea why that would be : Armbian 5.24 kernel 4.9.0-sun8i xenial. >openssl speed -elapsed -evp bf-cbc aes-128-cbc The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 23108.93k 24980.25k 25877.42k 26112.00k 26184.36k bf-cbc 18900.00k 21908.86k 22817.79k 23052.63k 23123.29k i will try building a mainline jessie image to see if it gets back to the earlier benchmarks.