15 15
lanefu

Espressobin support development efforts

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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)

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)

 

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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 ?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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"

 

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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?

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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 by ebin-dev
updated: environment settings, versions tested, 1cs and 2cs versions

Share this post


Link to post
Share on other sites
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..

Share this post


Link to post
Share on other sites
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´.    

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 by ebin-dev
added: current numbers for firmware 17-10 (03-2018) and 17.10 (10-2017), reference to armv8 crypto extensions

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
15 15