gprovost

Members
  • Content Count

    58
  • Joined

  • Last visited

1 Follower

About gprovost

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    http://kobol.io

Profile Information

  • Gender
    Male
  • Location
    Singapore

Recent Profile Visitors

517 profile views
  1. gprovost

    Helios4 Support

    @nemo19 Sorry to hear that now you are facing some other instability with the board. Please next time it occurs, can you send me your syslog files along the link generated by armbianmonitor -u
  2. gprovost

    Helios4 Support

    If LED1 is not blinking, it either means that the system hanged OR the system was shutdown || put in suspend-mode. First I would advice that you update to the latest kernel, for that you will need to change your repo to nightly build. Use armbian-config utility for that. armbian-config > System > Nightly This will automatically update your system with latest kernel and u-boot. Beside that, I don't see anything wrong with your system. Next time your system hangs, can you post your system log (all the syslog files in /var/log and /var/log.hdd). You can send it to me by PM.
  3. gprovost

    Helios4 Support

    @soydemadrid First, as Igor suggested, please use armbianmonitor -u and share the link it will generate here. The issue you are witnessing is unrelated to the grep command output you are sharing. However your grep command that you are running from the root directory effectively highlights a weird recursive symlink loops in sysfs. We will look at it but in any case it's unrelated to your unreachable Helios4 issue. When you say all lights are out, Do you also mean the LED8 is also off ? This led is located close to the DC input power connector. Or do you mean LED8 is ON but LED1 and the others one are not blinking ? Can you also check with the following command last -x | less if you see some reboot or shutdown events that seems suspicious.
  4. gprovost

    Helios4 Support

    We have been investigating the issue of the network interface that is sometimes not properly initialized (as reported by @JakeK) and we found the issue. During u-boot board initialization, the network PHY is supposed to be reset by toggling a GPIO (GPIO19). Unfortunately in our u-boot implementation the PHY reset call was happening too early when the SoC pin muxing wasn't completed yet, which means the GPIO pull up and pull down wasn't physically happening. We have added the fix to our u-boot repo : https://github.com/helios-4/u-boot-marvell/commit/15c179624b28ddab7d212a0ef0571bcec91cf2ed @Igor Any chance you can trigger a build of just Helios4 u-boot and publish the u-boot .deb in the armbian repo ? This way everyone can easily get the fix by doing an upgrade. Thanks.
  5. gprovost

    Benchmarking CPUs

    I understand that, and I'm sure everyone appreciate a lot the great work you are doing with sbc-bench since it was something clearly missing out there... I think it could actually become the baseline reference for sbc benchmark. I'm pretty sure many people will look at the numbers without reading all the explanation your provided or without reading this thread. The fact that the Clearfog which is based on the same SoC then Helios4 shows completely different number for AES-128-CBC 16Byte block is clearly confusing. I would prefer we display both value, with | without hw engine.
  6. gprovost

    Benchmarking CPUs

    @tkaiser Why in your benchmark table for AES-128-CBC you are showing the results for 16Byte block while for AES-256-CBC you are show the results for 16KByte ? I'm obliviously asking because for Helios4 showing the perf on 16Byte block while using the cryptodev is a bit unfair
  7. gprovost

    Benchmarking CPUs

    I must admit it's quite cool Now I'm trying to make apache2 (for nextcloud use case) offload HTTPS on the cryptodev. Not trivial at tall Need to recompile stuff.
  8. gprovost

    Benchmarking CPUs

    As Zador said, offloading to hw engine has a little overhead that will get obvious on tiny block benchmark. That's correct. I just download the openssl src from official website then do the following (on target directly). $> ./config shared enable-engine enable-dso enable-afalgeng enable-devcryptoeng --prefix=/opt/openssl --openssldir=/opt/openssl $> make $> sudo make install $> export LD_LIBRARY_PATH=/opt/openssl/lib $> openssl version OpenSSL 1.1.0f 25 May 2017 (Library: OpenSSL 1.1.1-pre8 (beta) 20 Jun 2018)
  9. gprovost

    Benchmarking CPUs

    @tkaiser Here the link of my latest benchmark of Helios4 : http://ix.io/1jCy I get the following result for OpenSSL speed OpenSSL results: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 1280.56k 5053.40k 18249.13k 52605.27k 102288.04k 109390.51k aes-128-cbc 1285.51k 5030.68k 18256.13k 53001.90k 100128.09k 109188.44k aes-192-cbc 1276.82k 4959.19k 18082.22k 51421.53k 96897.71k 103093.59k aes-192-cbc 1290.35k 4961.09k 17777.24k 51629.74k 95647.06k 102596.61k aes-256-cbc 1292.07k 5037.99k 17762.90k 50542.25k 92782.59k 98298.54k aes-256-cbc 1281.35k 5050.94k 17874.77k 49915.90k 93164.89k 98822.83k In order to leverage on hw crypto engine, I had no choice but to use OpenSSL 1.1.1 lib (openssl-1.1.1-pre8) and I decided to use cryptodev-linux instead of AF_ALG since it gives me slightly better result (+5-10%). Here a bit of findings regarding OpenSSL engines implementation : As stated in the changelog Changes between 1.0.2h and 1.1.0 [25 Aug 2016] *) Added the AFALG engine. This is an async capable engine which is able to offload work to the Linux kernel. In this initial version it only supports AES128-CBC. The kernel must be version 4.1.0 or greater. [Catriona Lucey] So using Debian Stretch package OpenSSL 1.1.0f, or any more recent 1.1.0 version, the only cipher supported by AFALG engine was effectively AES-128-CBC $> openssl engine -c (dynamic) Dynamic engine loading support (afalg) AFALG engine support [AES-128-CBC] Starting OpenSSL 1.1.1, even though it is not mentioned anywhere in the changelog, AES192-CBC and AES256-CBC is supported by the AFALG engine $> openssl engine -c (dynamic) Dynamic engine loading support (afalg) AFALG engine support [AES-128-CBC, AES-192-CBC, AES-256-CBC] But one thing much more exiting about OpenSSL 1.1.1 is the following Changes between 1.1.0h and 1.1.1 [xx XXX xxxx] *) Add devcrypto engine. This has been implemented against cryptodev-linux, then adjusted to work on FreeBSD 8.4 as well. Enable by configuring with 'enable-devcryptoeng'. This is done by default on BSD implementations, as cryptodev.h is assumed to exist on all of them. [Richard Levitte] So now with the 1.1.1 is pretty straight forward to use cryptodev, no need to patch or configure anything in openssl, openssl will detect automatically if module cryptodev is loaded and will offload crypto operation on it if presents. $> openssl engine -c (devcrypto) /dev/crypto engine [DES-CBC, DES-EDE3-CBC, BF-CBC, AES-128-CBC, AES-192-CBC, AES-256-CBC, AES-128-CTR, AES-192-CTR, AES-256-CTR, AES-128-ECB, AES-192-ECB, AES-256-ECB, CAMELLIA-128-CBC, CAMELLIA-192-CBC, CAMELLIA-256-CBC, MD5, SHA1] (dynamic) Dynamic engine loading support Based on those info, and making the assumption that sooner than later openssl 1.1.1 will be available in Debian Stretch (via backports most probably), i think the best approach to add openssl crypto engine support in Armbian is via the cryptodev approach. This way we can support all the ciphers now. I will look how to patch properly dpkg openssl_1.1.0f-3+deb9u2 to activate cryptodev supports. @zador.blood.stained maybe you have a different option on the topic ?
  10. gprovost

    Benchmarking CPUs

    @zador.blood.stained I think there isn't any distro OpenSSL packages that is built with hardware engine support. Also, even if engine is installed, OpenSSL doesn't use any engine by default, you need to configure it in openssl.cnf. But you right about cryptsetup (dm-crypt), it uses AF_ALG by default. I was wondering why so much delta between my 'cryptsetup benchmark' and 'openssl speed' test on Helios4. I just did a test by compiling openssl-1.1.1-pre8 with the AF_ALG (... enable-engine enable-afalgeng ...) and here are the benchmark result on Helios4 : $> openssl speed -evp aes-xxx-cbc -engine afalg -elapsed type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 745.71k 3018.47k 11270.23k 36220.25k 90355.03k 101094.74k aes-256-cbc 739.49k 2964.93k 11085.23k 34178.05k 82597.21k 90461.53k The difference is quite interesting, with AF_ALG it performs much better on bigger block size, but poorly on very small block size. $> openssl speed -evp aes-xxx-cbc -elapsed type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 44795.07k 55274.84k 59076.27k 59920.04k 59719.68k 59353.77k aes-256-cbc 34264.93k 40524.42k 42168.92k 42496.68k 42535.59k 42500.10k System : Linux helios4 4.14.57-mvebu #2 SMP Tue Jul 24 08:29:55 UTC 2018 armv7l GNU/Linux Supposedly you can even have better perf with cryptodev, but I think Crypto API AF_ALK is more elegant and easier to setup. Once I have a cleaner install of this AF_ALK (or cryptodev), I will run sbc_bench and send you ( @tkaiser ) the output.
  11. gprovost

    Helios4 Support

    @JakeK Full power cycle doesn’t solve the issue ?
  12. gprovost

    Helios4 Support

    That’s a good news. I should have effectively adviced to try that. Might have a been a bad board to board connection. @hatschi1000 you don’t want to try the same thing before returning the item ?
  13. gprovost

    Helios4 Support

    @rifanoz ok, please send me a pm, and we see how we can proceed to an exchange.
  14. gprovost

    Helios4 Support

    @rifanoz Ok noted. So even after a full power cycle, which means switch off the power adapter for 2min (time capacitors discharge) and switch back on, still don't make the board output anything on serial port ?
  15. gprovost

    Helios4 Support

    @rifanoz when is the issue appeared ? FYI the boards go through a FAT (Factory Acceptance Test) before being sent out. Which means each board had a test run with all interfaces tested. So I guess the issue didn't appear on day one ?