chrisf Posted March 6, 2018 Posted March 6, 2018 11 minutes ago, y52 said: The 1200 CPU firmware espressobin-bootloader-cpu-1200-ddr3-2cs-2g-atf-ga3306ab-uboot-gaee49fc-20180129-REL.bin doesn't run with my board. ---------------------------------------------------- TIM-1.0 WTMI-armada-17.10.1-b90dbf0 ENTER init_ddrgen DDR_TOPOLOGY is 7 : DDR3, 2CS 1G + 1G WTMI_CLOCK=3 Fill memory before self refresh...done Fill memory before self refresh...done Now in Self-refresh Mode Restore CAS Read and Write Latency Restore termination values to original values Exited self-refresh ... DLL TUNING ============== DLL 0xc0001050[21:16]: [0,24,12] DLL 0xc0001050[29:24]: [a,2f,1c] DLL 0xc0001054[21:16]: [0,21,10] DLL 0xc0001054[29:24]: [a,31,1d] DLL 0xc0001074[21:16]: [0,3f,1f] DLL 0xc0001074[29:24]: [0,3f,1f] DLL: pass The booting interrupts here. I don't know what WTMI_CLOCK is but it's appears to be related to DDR timing and it's different between the two firmwares. 0 Quote
y52 Posted March 6, 2018 Posted March 6, 2018 I've downgraded to the 1000/800 u-boot. root@espressobin:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 50.0 us. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 250 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 250 MHz. cpufreq stats: 200 MHz:7.83%, 250 MHz:75.88%, 500 MHz:0.43%, 1000 MHz:15.86% (216) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 50.0 us. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 250 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 250 MHz. cpufreq stats: 200 MHz:7.83%, 250 MHz:75.88%, 500 MHz:0.43%, 1000 MHz:15.86% (216) 0 Quote
y52 Posted March 6, 2018 Posted March 6, 2018 Globalscale Technology claims, that u-boot, supplied with the Armbian, i.e. U-Boot 2017.03-armada-17.10.1-g440395a (Sep 25 2017 - 15:43:51 +0200) : Seems the source mixed with other information when building uboot. This the reason cause the problem. If you’re using Debian, please confirm what version you have (Armada-17.10, 17.06, or 17.02), so I can provide the uboot match your version for testing. Which of the versions above the Armbian was built with ? What should we argue to Globalscale Technology ? I am not really qualified on that particular subject. 0 Quote
Tazz Posted March 6, 2018 Posted March 6, 2018 Armbian is based on Armada-17.10.1 (uboot and utils) Armada-17.10.3 with lots of ram init fixes/support was released on Jan 31, 2018 (Armada-17.10 branch, no GIT tag, only "localversion" file content change) Armbian espressobin firmwares need a rebuild with all these refreshed parts: A3700-utils-marvell Armada-17.10.3 atfv1.3 armada-17.10.7 uboot armada-17.10.2 (only for completeness, only fix mvneta bad RX descriptors) 0 Quote
ebin-dev Posted March 7, 2018 Posted March 7, 2018 11 hours ago, Tazz said: Armbian espressobin firmwares need a rebuild with all these refreshed parts: Thanks Tazz for the hint. I have constantly monitored Marvell sources on github but I did not see any changes relevant to EspressoBin since October last year. I have made available my build scripts to Armbian deveopers last year - to rebuild EspressoBin firmware with the refreshed parts should only take a few minutes. (Unfortunately my build system is currently not working due to a hardware issue) 1 Quote
tom_i Posted March 7, 2018 Posted March 7, 2018 Looking forward to rebuild your systems @ebin-dev 0 Quote
y52 Posted March 7, 2018 Posted March 7, 2018 On 04/03/2018 at 12:55 PM, y52 said: Is there some log file size restrictions ? The following resumed logging ; root@espressobin:/var/log# : > messages root@espressobin:/var/log# : > wtmp root@espressobin:/var/log# echo "Log files cleaned up." Log files cleaned up. root@espressobin:/var/log# systemctl restart rsyslog.service My logging is halted repeatedly : /e/2359 ] Mar 7 13:29:57 localhost liblogging-stdlog: action 'action 2' resumed (module 'builtin:omfile') [v8.24.0 try http://www.rsyslog.com/e/2359 ] Mar 7 13:29:57 localhost liblogging-stdlog: action 'action 2' suspended, next retry is Wed Mar 7 13:30:27 2018 [v8.24.0 try http://www.rsyslog.com/e/2007 ] Mar 7 13:30:27 localhost liblogging-stdlog: action 'action 2' resumed (module 'builtin:omfile') [v8.24.0 try http://www.rsyslog.com/e/2359 ] Mar 7 13:30:27 localhost liblogging-stdlog: action 'action 2' resumed (module 'builtin:omfile') [v8.24.0 try http://www.rsyslog.com/e/2359 ] Mar 7 13:30:27 localhost liblogging-stdlog: action 'action 2' resumed (module 'builtin:omfile') [v8.24.0 try http://www.rsyslog.com/e/2359 ] Mar 7 13:30:27 localhost liblogging-stdlog: action 'action 2' resumed (module 'builtin:omfile') [v8.24.0 try http://www.rsyslog.com/e/2359 ] Mar 7 13:30:27 localhost liblogging-stdlog: action 'action 2' resumed (module 'builtin:omfile') [v8.24.0 try http://www.rsyslog.com/e/2359 ] Mar 7 13:30:27 loca After cleaning and service restart : Mar 7 14:06:15 localhost liblogging-stdlog: [origin software="rsyslogd" swVersion="8.24.0" x-pid="546" x-info="http://www.rsyslog.com"] exiting on signal 15. Mar 7 14:06:15 localhost liblogging-stdlog: [origin software="rsyslogd" swVersion="8.24.0" x-pid="15527" x-info="http://www.rsyslog.com"] start Is there any solution ? Does the log rotate service work for Armbian ? 0 Quote
ebin-dev Posted March 8, 2018 Posted March 8, 2018 On 3/6/2018 at 11:06 PM, Tazz said: Armada-17.10.3 with lots of ram init fixes/support was released on Jan 31, 2018 (Armada-17.10 branch, no GIT tag, only "localversion" file content change) The vendor provided flash image released this month can be downloaded from here and I have tested it on a 1G board. There are currently only two flash-images available (1G and 2G, 1000_800). I have selected an EspressoBin board that was not able to run stable with 1000_800 anymore after being exposed to excessive thermal strain for at least an hour (running fully loaded without any cooling) while being exposed to a gnd loop (not by myself :-) ). However that board was still stable with Armbian firmware 800_800 afterwards (even with cpufreq enabled). I can confirm that the new vendor provided flash image for the 1G EspressoBin solves the stability issue - the above board now seems to run stable with 1000_800 again. I have tested that with ARMBIAN 5.41.180208 nightly Debian GNU/Linux 9 (stretch) 4.14.23-mvebu64 (with cpufreq enabled). That are good news. However, a quick RAM speed test seems to indicate a 14% lower RAM speed. You are invited to post your observations in this thread. Edit: RAM speed is reduced by only 2% on other boards. 1 Quote
Tazz Posted March 8, 2018 Posted March 8, 2018 Great, the new training algo compensate the damage done on your board. Perhaps we will get back these other 2% in a later release. But if 2% it is the price to pay for more garanties of stability, I buy it. If I really need more speed, I prefer to change the ram chips for better ones. 0 Quote
Patrick Posted March 11, 2018 Posted March 11, 2018 Hi, I had a little time and flashed the new firmware: espressobin-bootloader-cpu-1000-ddr3-2cs-1g-atf-ga3306ab-uboot-gaee49fc-20180129-REL.bin Set the environment settings again as found here: https://github.com/armbian/build/commit/e8868352324f5ee9567f2d06a0110c8f123a0384 Burned an image (Armbian_5.38_Espressobin_Debian_stretch_next_4.14.14.img) with Etcher. Sadly enough booting the ESPRESSObin doesn't complete Are the environment settings wrong? Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. done. Gave up waiting for root file system device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/mmcblk0p1 does not exist. Dropping to a shell! kr., Patrick 0 Quote
ebin-dev Posted March 11, 2018 Posted March 11, 2018 30 minutes ago, Patrick said: Are the environment settings wrong? The device name of the sd card has changed in 4.14. In order to boot from sd you need to set setenv rootdev "/dev/mmcblk1p1" 0 Quote
Patrick Posted March 11, 2018 Posted March 11, 2018 3 minutes ago, ebin-dev said: The device name of the sd card has changed in 4.14. In order to boot from sd you need to set setenv rootdev "/dev/mmcblk1p1" Thanks ebin-dev, That worked (but you already knew that) kr., Patrick 0 Quote
y52 Posted March 11, 2018 Posted March 11, 2018 How is the "config/bootscripts/boot-espressobin.cmd" passed for execution to u-boot? Is it enough editing the boot-espressobin.cmd stored on the MMC or USB, so that the environment settings and the bootcmd are performed? 0 Quote
TaNGSoFT Posted March 11, 2018 Posted March 11, 2018 look at this: https://patchwork.kernel.org/patch/10133165/ This patch adds a crypto node describing the EIP97 engine found in Armada 37xx SoCs. The cryptographic engine is enabled by default. I checked the mainline linux kernel, the above code is already there in the DTS file. is there any plan to port crypto-safexcel engine? 0 Quote
ebin-dev Posted March 11, 2018 Posted March 11, 2018 The driver for the 5Gbps Security Engine of the 3720 was provided by bootlin (formerly free-electrons). There are some known bugs that will be patched until the final release of 4.16. The new driver currently supports (quote): Quote Hashes: sha1, hmac(sha1), sha224, sha256. Ciphers: ecb(aes), cbc(aes). This allows to offload some IPsec connexions, depending on the configuration, as these algs can be combined by the crypto layer. More algs are coming, but there is no schedule for them. Edit: If it is working it will be enabled by default - I am looking forward to test that. 0 Quote
TaNGSoFT Posted March 13, 2018 Posted March 13, 2018 https://github.com/MarvellEmbeddedProcessors/linux-marvell/blob/linux-4.4.52-armada-17.10/drivers/crypto/inside-secure/user-guide.txt the above url shows the reference document of using crypto-safexcel engine in 3720 and 7K/8K SOCs. Basic Usage ----------- Currently EIP197/97 are avaialble on several Marvell SoC: Armada8040 - 2 EIP197 engines. Armada7040 - 1 EIP197 engine. Armada3700 - 1 EIP97 engine. 0 Quote
ebin-dev Posted March 13, 2018 Posted March 13, 2018 (edited) The new Armbian flash-images are online now (1g (1cs and 2cs), 2g and 512m versions were tested). All available CPU_DDR frequency combinations are there for all boards. Most EspressoBins out there have 2 DDR memory chips (one on each side of the board). Select the 2cs firmware version for your board in this case. If you are an owner of a brand new 1G EspressoBin you may just have 1 DDR memory chip on board (see here). In that case you have to select the 1cs firmware version for your board. The flash images were rebuilt with the following refreshed parts: A3700-utils-marvell Armada-17.10.3 atfv1.3 armada-17.10.7 uboot armada-17.10.2 Stability issues are solved with these updated versions by a refined DDR RAM training algorithm (provided by Marvell). With the new firmware installed you may need to enter the environment settings again (after a reset). If you wish to boot using a load script you need to enter the following environment settings (boots from SD and USB): setenv initrd_addr 0x1100000 setenv image_name boot/Image setenv load_script 'if test -e mmc 0:1 boot/boot.scr; then echo \"... booting from SD\";setenv boot_interface mmc;else echo \"... booting from USB/SATA\";usb start;setenv boot_interface usb;fi;if test -e \$boot_interface 0:1 boot/boot.scr;then ext4load \$boot_interface 0:1 0x00800000 boot/boot.scr; source; fi' setenv bootcmd "run get_images; run set_bootargs; run load_script;booti "\$kernel_addr \$ramfs_addr \$fdt_addr saveenv If that does not work in your use case - you can use the following environment settings: #Boot from SD: #with a legacy kernel on SD you have to change rootdev to /dev/mmcblk0p1 setenv boot_interface mmc setenv image_name boot/Image setenv fdt_name_a boot/dtb/marvell/armada-3720-community.dtb setenv fdt_name_b boot/dtb/marvell/armada-3720-espressobin.dtb setenv fdt_high "0xffffffffffffffff" setenv rootdev "/dev/mmcblk1p1" setenv rootfstype "ext4" setenv verbosity "1" setenv initrd_addr "0x1100000" setenv initrd_image "boot/uInitrd" setenv ethaddr "F0:AD:4E:03:64:7F" setenv bootcmd 'mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $initrd_addr $initrd_image; ext4load mmc 0:1 $fdt_addr $fdt_name_a;ext4load mmc 0:1 $fdt_addr $fdt_name_b;setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr' saveenv #Boot from SATA: setenv boot_interface scsi setenv image_name boot/Image setenv fdt_name_a boot/dtb/marvell/armada-3720-community.dtb setenv fdt_name_b boot/dtb/marvell/armada-3720-espressobin.dtb setenv fdt_high "0xffffffffffffffff" setenv rootdev "/dev/sda1" setenv rootfstype "ext4" setenv verbosity "1" setenv initrd_addr "0x1100000" setenv initrd_image "boot/uInitrd" setenv ethaddr "F0:AD:4E:03:64:7F" setenv bootcmd 'scsi scan; scsi dev 0; ext4load scsi 0:1 $kernel_addr $image_name;ext4load scsi 0:1 $initrd_addr $initrd_image; ext4load scsi 0:1 $fdt_addr $fdt_name_a;ext4load scsi 0:1 $fdt_addr $fdt_name_b;setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr' saveenv @TaNGSoFT Thanks for the info about the crypto-safexcel engine. Edited March 16, 2018 by ebin-dev updated: environment settings, versions tested, 1cs and 2cs versions 1 Quote
y52 Posted March 13, 2018 Posted March 13, 2018 7 hours ago, ebin-dev said: You need to enter the environment settings again How could this github script be applied to the u-boot environment? 0 Quote
y52 Posted March 17, 2018 Posted March 17, 2018 On 13/03/2018 at 10:48 AM, ebin-dev said: Stability issues are solved with these updated versions by a refined DDR RAM training algorithm (provided by Marvell). My board is not capable running at no circumstances, even with the March 15th built firmware, at CPU 1200 DDR 750 : flash-image-2g-2cs-1200_750_boot_sd_and_usb.bin Marvell>> bubt u-boot/flash-image-2g-2cs-1200_750_boot_sd_and_usb.bin spi usb Burning U-BOOT image "u-boot/flash-image-2g-2cs-1200_750_boot_sd_and_usb.bin" from "usb" to "spi" USB0: Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 USB1: USB EHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found Image checksum...OK! SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB 20480 bytes written, 798216 bytes skipped in 0.512s, speed 1634200 B/s Done! Marvell>> reset resetting ... TIM-1.0 WTMI-armada-17.10.3-06f9861 WTMI: system early-init Fill memory before self refresh...done Fill memory before self refresh...done Now in Self-refresh Mode Restore termination values to original values Exited self-refresh ... Self refresh Pass. DDR self test mode test done!! Self refresh Pass. DDR self test mode test done!! QS GATING ============= Calibration done: cycle = 0x00 tap =0x54 CH0_PHY_RL_Control_CS0_B0[0xC0001180]: 0x00000054 CH0_PHY_RL_Control_CS0_B1[0xC0001184]: 0x00000054 QS GATING ============= Calibration done: cycle = 0x00 tap =0x53 CH0_PHY_RL_Control_CS1_B0[0xC00011A4]: 0x00000053 CH0_PHY_RL_Control_CS1_B1[0xC00011A8]: 0x00000053 DLL TUNING ============== DLL 0xc0001050[21:16]: [0,25,12] DLL 0xc0001050[29:24]: [9,30,1c] DLL 0xc0001054[21:16]: [2,25,13] DLL 0xc0001054[29:24]: [e,30,1f] DLL 0xc0001074[21:16]: [0,3f,1f] DLL 0xc0001074[29:24]: [0,3f,1f] DLL: pass Booting stucks here.. I claimed the board manufacturer for an RMA. The CPU @ 1000 [MHz] DDR @ 800 [MHz] u-boot flash runs normally.. 0 Quote
umiddelb Posted March 18, 2018 Posted March 18, 2018 On 13/03/2018 at 6:37 PM, y52 said: How could this github script be applied to the u-boot environment? All firmware versions that I know of are using the same offsets to store the permanent u-boot environment. After writing the new firmware via `bubt ...´ you can save the actual environment via `saveenv´. 0 Quote
y52 Posted March 18, 2018 Posted March 18, 2018 On 13/03/2018 at 10:48 AM, ebin-dev said: If you wish to boot using a load script you need to enter the following environment settings (boots from SD and USB): I liked a solution posted by ebin-dev , where u-boot environment and execution scripts are passed from OS storage device rather than from an EPROM : test -e \$boot_interface 0:1 boot/boot.scr;then ext4load \$boot_interface 0:1 0x00800000 boot/boot.scr; Could somebody specify, how is the "boot/boot.scr" generated? Is it generated from the "boot/boot.cmd" during the OS distribution build? If you change the "boot/boot.cmd" after the OS is installed, could a new "boot/boot.scr" be built? 0 Quote
Igor Posted March 18, 2018 Posted March 18, 2018 17 minutes ago, y52 said: I liked a solution posted by ebin-dev , where u-boot environment and execution scripts are passed from OS storage device rather than from an EPROM : test -e \$boot_interface 0:1 boot/boot.scr;then ext4load \$boot_interface 0:1 0x00800000 boot/boot.scr; https://www.armbian.com/espressobin/ -> "Notes" Quote Could somebody specify, how is the "boot/boot.scr" generated? Is it generated from the "boot/boot.cmd" during the OS distribution build? If you change the "boot/boot.cmd" after the OS is installed, could a new "boot/boot.scr" be built? 1 You can. Command to recompile script into .scr format:https://github.com/armbian/build/blob/master/config/bootscripts/boot-espressobin.cmd#L31 0 Quote
y52 Posted March 18, 2018 Posted March 18, 2018 1 hour ago, Igor said: Command to recompile script into .scr format: Finally, it takes shape. Both links above provide with the systematic solution. Is that the one to recompile the boot.scr ? # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr What is a good choice for the .dtb ? GlobalScaleTechnologies offers: fdt_name boot/dtb/marvell/armada-3720-community-v5.dtb while you point to 2 other versions? setenv fdt_name_a boot/dtb/marvell/armada-3720-community.dtb setenv fdt_name_b boot/dtb/marvell/armada-3720-espressobin.dtb When do you schedule building the stable Armbian version? 0 Quote
Tazz Posted March 18, 2018 Posted March 18, 2018 GlobalScaleTechnologies .dtb is for their own provided kernel. As you are using Armbian, use what is provided by Armbian. 0 Quote
y52 Posted March 18, 2018 Posted March 18, 2018 54 minutes ago, Tazz said: As you are using Armbian, use what is provided by Armbian. Why does Armbian provide with the 2 options? What's the difference between fdt_name_a and fdt_name_b? How is the choice made at boot time? 0 Quote
Tazz Posted March 18, 2018 Posted March 18, 2018 armada-3720-espressobin.dtb is for the mainline kernel armada-3720-community.dtb is for the BSP/Legacy (4.4.x) kernel There is no "real" choice made. If the file is present, it will be loaded (load address is the same). If the two are there, last win. 0 Quote
TaNGSoFT Posted March 18, 2018 Posted March 18, 2018 openssl speed -elapsed -evp aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-cbc for 3s on 16 size blocks: 16324336 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 9558658 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 3542371 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 1034291 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 135914 aes-256-cbc's in 3.00s OpenSSL 1.0.2n 7 Dec 2017 built on: reproducible build, date unspecified options:bn(64,64) rc4(ptr,char) des(idx,cisc,2,int) aes(partial) blowfish(ptr) compiler: aarch64-openwrt-linux-musl-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -I/xbuild/espressobin/staging_dir/target-aarch64_cortex-a53_musl/usr/include -I/xbuild/espressobin/staging_dir/target-aarch64_cortex-a53_musl/include -I/xbuild/espressobin/staging_dir/toolchain-aarch64_cortex-a53_gcc-7.3.0_musl/usr/include -I/xbuild/espressobin/staging_dir/toolchain-aarch64_cortex-a53_gcc-7.3.0_musl/include/fortify -I/xbuild/espressobin/staging_dir/toolchain-aarch64_cortex-a53_gcc-7.3.0_musl/include -znow -zrelro -DOPENSSL_SMALL_FOOTPRINT -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DOPENSSL_NO_ERR -DTERMIOS -Os -pipe -mcpu=cortex-a53 -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -iremap/xbuild/espressobin/build_dir/target-aarch64_cortex-a53_musl/openssl-1.0.2n:openssl-1.0.2n -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -fpic -I/xbuild/espressobin/package/libs/openssl/include -ffunction-sections -fdata-sections -fomit-frame-pointer -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-256-cbc 87063.13k 203918.04k 302282.33k 353037.99k 371135.83k trying to compile cryptographic API module :crypto-safexcel in openwrt, and get the above openssl benchmark, I don't know the number is good or not. 0 Quote
ebin-dev Posted March 18, 2018 Posted March 18, 2018 (edited) 4 hours ago, TaNGSoFT said: openssl speed -elapsed -evp aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-cbc for 3s on 16 size blocks: 16324336 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 9558658 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 3542371 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 1034291 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 135914 aes-256-cbc's in 3.00s OpenSSL 1.0.2n 7 Dec 2017 built on: reproducible build, date unspecified options:bn(64,64) rc4(ptr,char) des(idx,cisc,2,int) aes(partial) blowfish(ptr) compiler: aarch64-openwrt-linux-musl-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -I/xbuild/espressobin/staging_dir/target-aarch64_cortex-a53_musl/usr/include -I/xbuild/espressobin/staging_dir/target-aarch64_cortex-a53_musl/include -I/xbuild/espressobin/staging_dir/toolchain-aarch64_cortex-a53_gcc-7.3.0_musl/usr/include -I/xbuild/espressobin/staging_dir/toolchain-aarch64_cortex-a53_gcc-7.3.0_musl/include/fortify -I/xbuild/espressobin/staging_dir/toolchain-aarch64_cortex-a53_gcc-7.3.0_musl/include -znow -zrelro -DOPENSSL_SMALL_FOOTPRINT -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DOPENSSL_NO_ERR -DTERMIOS -Os -pipe -mcpu=cortex-a53 -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -iremap/xbuild/espressobin/build_dir/target-aarch64_cortex-a53_musl/openssl-1.0.2n:openssl-1.0.2n -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -fpic -I/xbuild/espressobin/package/libs/openssl/include -ffunction-sections -fdata-sections -fomit-frame-pointer -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-256-cbc 87063.13k 203918.04k 302282.33k 353037.99k 371135.83k trying to compile cryptographic API module :crypto-safexcel in openwrt, and get the above openssl benchmark, I don't know the number is good or not. The results for the EspressoBin (with armv8 crypto extensions enabled in /proc/crypto) are here for kernel 4.12.1, firmware 17.02: # openssl speed -elapsed -evp aes-128-cbc # openssl speed -elapsed -evp aes-192-cbc # openssl speed -elapsed -evp aes-256-cbc 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) Espressobin / Marvell 3720 @ 1000MHz: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 68509.24k 216097.11k 453277.35k 649243.99k 741862.06k 748459.35k aes-192-cbc 65462.17k 194529.30k 375030.70k 503817.22k 559303.34k 563014.31k aes-256-cbc 63905.67k 181436.03k 328664.06k 423431.51k 462012.42k 464972.46k With the current system (kernel 4.14.27, firmware 17.10 (15 March 2018)) the results are different: # openssl speed -elapsed -evp aes-128-cbc # openssl speed -elapsed -evp aes-192-cbc # openssl speed -elapsed -evp aes-256-cbc 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) 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 54373.25k 171399.96k 358798.93k 515015.68k 589043.03k 594187.61k aes-192-cbc 52008.32k 153951.49k 297897.39k 399866.88k 443921.75k 447315.97k aes-256-cbc 50723.99k 143690.56k 260875.01k 335907.16k 366663.00k 369087.83k In order to estimate the effect of the new firmware I include these results (kernel 4.14.27, firmware 17.10 (04 October 2017)): [There is no measurable effect wrt openssl performance on my current system due to the new firmware 17.10 (15 March 2018)] # openssl speed -elapsed -evp aes-128-cbc # openssl speed -elapsed -evp aes-192-cbc # openssl speed -elapsed -evp aes-256-cbc 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) 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 54796.20k 172342.44k 362010.88k 517955.93k 593231.87k 599075.50k aes-192-cbc 52330.10k 155258.30k 300081.83k 402562.05k 447231.32k 451089.75k aes-256-cbc 51088.98k 144065.90k 262597.89k 338562.73k 369300.82k 371316.05k Edited March 18, 2018 by ebin-dev added: current numbers for firmware 17-10 (03-2018) and 17.10 (10-2017), reference to armv8 crypto extensions 0 Quote
Tazz Posted March 18, 2018 Posted March 18, 2018 All of this is software crypto. You need to patch you armada-37xx.dtsi and rebuild your dtb to add the eip node and look at your kernel message at boot to see if it is properly detected. It should be "mainlined" for 4.17. (It is already in linux-next). But it will not be suffisant as the EIP97 support was only merged in for 4.16 and have fix pending in -next. 0 Quote
TaNGSoFT Posted March 19, 2018 Posted March 19, 2018 13 hours ago, Tazz said: All of this is software crypto. You need to patch you armada-37xx.dtsi and rebuild your dtb to add the eip node and look at your kernel message at boot to see if it is properly detected. It should be "mainlined" for 4.17. (It is already in linux-next). But it will not be suffisant as the EIP97 support was only merged in for 4.16 and have fix pending in -next. For whatever reason, I cannot get any kernel message of detecting eip engine. According to marvell docs (https://raw.githubusercontent.com/MarvellEmbeddedProcessors/linux-marvell/linux-4.4.52-armada-17.10/Documentation/devicetree/bindings/crypto/inside_secure_eip.txt) , no firmware needed for eip97. root@espressobin:~# cat /proc/interrupts CPU0 CPU1 3: 22916 68315 GICv3 30 Level arch_timer 6: 0 0 GICv3 23 Level arm-pmu 7: 1636 0 GICv3 32 Level d0010600.spi 9: 9797 0 GICv3 43 Level serial 10: 259 0 GICv3 74 Level eth0 11: 1842 0 GICv3 35 Level xhci-hcd:usb2 12: 0 0 GICv3 49 Level ehci_hcd:usb1 14: 73244 0 GICv3 52 Level d0090000.eip97 15: 63031 0 GICv3 53 Level d0090000.eip97 16: 111785 0 GICv3 54 Level d0090000.eip97 17: 67682 0 GICv3 55 Level d0090000.eip97 19: 1284 0 GICv3 57 Level mmc0 20: 1714 0 GICv3 59 Level ahci-mvebu[d00e0000.sata] 21: 280650 0 GICv3 61 Level advk-pcie 39: 2 0 GICv3 79 Level d0060900.xor 40: 2 0 GICv3 80 Level d0060900.xor 42: 280651 0 d0070000.pcie-irq 0 Level mwlwifi IPI0: 324162 297117 Rescheduling interrupts IPI1: 100 1521 Function call interrupts IPI2: 0 0 CPU stop interrupts IPI3: 0 0 CPU stop (for crash dump) interrupts IPI4: 0 0 Timer broadcast interrupts IPI5: 2413 5066 IRQ work interrupts IPI6: 0 0 CPU wake-up interrupts Err: 0 root@espressobin:~# time -v openssl speed -elapsed -evp aes-256-cbc -engine cryp todev engine "cryptodev" set. You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-cbc for 3s on 16 size blocks: 73679 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 70972 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 66822 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 63928 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 28820 aes-256-cbc's in 3.00s OpenSSL 1.0.2n 7 Dec 2017 built on: reproducible build, date unspecified options:bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr) compiler: aarch64-openwrt-linux-musl-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -I/xbuild/espressobin/staging_dir/target-aarch64_cortex-a53_musl/usr/include -I/xbuild/espressobin/staging_dir/target-aarch64_cortex-a53_musl/include -I/xbuild/espressobin/staging_dir/toolchain-aarch64_cortex-a53_gcc-7.3.0_musl/usr/include -I/xbuild/espressobin/staging_dir/toolchain-aarch64_cortex-a53_gcc-7.3.0_musl/include/fortify -I/xbuild/espressobin/staging_dir/toolchain-aarch64_cortex-a53_gcc-7.3.0_musl/include -znow -zrelro -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DOPENSSL_NO_ERR -DTERMIOS -pipe -mcpu=cortex-a53 -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -iremap/xbuild/espressobin/build_dir/target-aarch64_cortex-a53_musl/openssl-1.0.2n:openssl-1.0.2n -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -O3 -fpic -I/xbuild/espressobin/package/libs/openssl/include -ffunction-sections -fdata-sections -fomit-frame-pointer -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-256-cbc 392.95k 1514.07k 5702.14k 21820.76k 78697.81k Command being timed: "openssl speed -elapsed -evp aes-256-cbc -engine cryptodev" User time (seconds): 0.52 System time (seconds): 4.14 Percent of CPU this job got: 29% Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 15.65s Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 11824 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 152 Voluntary context switches: 304387 Involuntary context switches: 604 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 root@espressobin:~# openssl engine (cryptodev) BSD cryptodev engine (dynamic) Dynamic engine loading support root@espressobin:~# egrep '^module|^name' /proc/crypto name : ecdh module : ecdh_generic name : hmac(sha1) module : crypto_safexcel name : sha256 module : crypto_safexcel name : sha224 module : crypto_safexcel name : sha1 module : crypto_safexcel name : cbc(aes) module : crypto_safexcel name : ecb(aes) module : crypto_safexcel name : lzo module : kernel name : lzo module : kernel name : crc32 module : kernel name : crc32c module : kernel name : zlib-deflate module : kernel name : deflate module : kernel name : deflate module : kernel name : ecb(arc4) module : kernel name : arc4 module : kernel name : aes module : kernel name : des3_ede module : kernel name : des module : kernel name : sha384 module : kernel name : sha512 module : kernel name : sha224 module : kernel name : sha256 module : kernel name : sha1 module : kernel name : digest_null module : kernel name : compress_null module : kernel name : ecb(cipher_null) module : kernel name : cipher_null module : kernel You can find from above output: 1. interrupts increase 2. cryptodev engine set 3. aes is accelerated by crypto-safexcel module 4. crypto is offload and cpu time is about 29 Let me know what else we can do? 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.