Espressobin support development efforts

lanefu · April 21, 2017

I'm sooooo close to sharing a WIP for building armbiain for espressobin , but I'm having trouble getting armbian builder to use the file name for the kernel package deb.

 │ dpkg-deb: building package 'linux-headers-4.4.8-mvebu64' in '../linux-headers-4.4.8-mvebu64_5.27_arm64.deb'.                                                             │  
  │ dpkg-deb: building package 'linux-libc-dev' in '../linux-libc-dev_5.27_arm64.deb'.                                                                                       │  
  │ dpkg-deb: building package 'linux-image-4.4.8-mvebu64' in '../linux-image-4.4.8-mvebu64_5.27_arm64.deb'.                                                                 │  
  │ dpkg-deb: building package 'linux-image-4.4.8-mvebu64-dbg' in '../linux-image-4.4.8-mvebu64-dbg_5.27_arm64.deb'.                                                         │  
  │ dpkg-genchanges: binary-only upload (no source code included)                                                                                                            │  
  └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘  
    


dpkg-deb: error: failed to read archive '/root/output/debs/linux-image-mvebu64_5.27_arm64.deb': No such file or directory

What's the cleanest way to have the resulting deb and armbianbuilder line up?

Stuff I've done:

made esspressobin.wip board config
Made mvebu64 sources config
Made mvebu64 Kernel config
Made kernel patch to elminate the localversion file
assured VERSION_AUTO is disabled in kernel config

Files n stuff

esspressobin.wip

Spoiler

# Marvell Armada 37x 1xmPCIe 2xGBE

BOARD_NAME="espressobin"

LINUXFAMILY="mvebu64"

BOOTCONFIG="mvebu_espressobin-88f3720_defconfig"

#BOOTCONFIG="mvebu_armada-37xx"

MODULES="mv_cesa"

MODULES_NEXT="mv_cesa"

CLI_TARGET="jessie,xenial:default,next"

KERNEL_TARGET="default,next"

BUILD_DESKTOP="no"

#

BOARDRATING=""

CHIP="http://docs.armbian.com/Hardware_Other/#marvel-armada-espressobin"

REVIEW="http://forum.armbian.com/index.php/topic/TBD/"

HARDWARE="http://wiki.espressobin.net/tiki-index.php?page=About+ESPRESSObin"

FORUMS="http://forum.armbian.com/index.php/forum/11-other-boards/"

mvebu64.conf

Spoiler

ARCH=arm64

KERNEL_IMAGE_TYPE=Image

HAS_UUID_SUPPORT=yes

#OFFSET=2

BOOTSCRIPT="boot-marvell.cmd:boot.cmd"

BOOTSOURCE=$MAINLINE_UBOOT_SOURCE

BOOTDIR=$MAINLINE_UBOOT_DIR

BOOTBRANCH=tag:v2017.05-rc1

BOOTENV_FILE='clearfog-default.txt'

HAS_UUID_SUPPORT=yes

case $BRANCH in

default)

KERNELSOURCE='https://github.com/MarvellEmbeddedProcessors/linux-marvell.git'

KERNELBRANCH='branch:linux-4.4.8-armada-17.02-espressobin'

KERNELDIR='linux-marvell'

DEB_BRANCH=4.4.8

# CHOSEN_KERNEL=linux-image-linux-4.4.8-armada-17.02-${LINUXFAMILY}

;;

next)

KERNELSOURCE=$MAINLINE_KERNEL_SOURCE

KERNELBRANCH=$MAINLINE_KERNEL_BRANCH

KERNELDIR=$MAINLINE_KERNEL_DIR

KERNEL_ALT_GCC='> 6.1'

;;

esac

## can probaly go slower

CPUMIN=800000

CPUMAX=1200000

GOVERNOR=ondemand

write_uboot_platform()

{

# dd if=$1/u-boot.mmc of=$2 bs=512 seek=1 status=noxfer > /dev/null 2>&1

echo "hey"

}

family_tweaks()

{

chroot $CACHEDIR/$SDCARD /bin/bash -c "apt-get -y -qq remove --auto-remove lirc linux-sound-base alsa-base alsa-utils bluez>/dev/null 2>&1"

}

Edited April 23, 2017 by zador.blood.stained
Renamed to reflect the contents

y52 · 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)

y52 · 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.

Tazz · 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)

ebin-dev · 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)

tom_i · March 7, 2018

Looking forward to rebuild your systems @ebin-dev

y52 · 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 ?

ebin-dev · 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.

Tazz · 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.

Patrick · 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

ebin-dev · 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"

Patrick · 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

y52 · 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?

TaNGSoFT · 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?

ebin-dev · 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.

TaNGSoFT · 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.

ebin-dev · March 13, 2018

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

y52 · 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?

y52 · 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

Now in Self-refresh Mode
Restore termination values to original values
Exited self-refresh ...

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..

umiddelb · 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´.

y52 · 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?

Igor · 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

y52 · 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?

Tazz · March 18, 2018

GlobalScaleTechnologies .dtb is for their own provided kernel.

As you are using Armbian, use what is provided by Armbian.

y52 · 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?

Tazz · 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.

TaNGSoFT · 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.

ebin-dev · March 18, 2018

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

Tazz · 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.

TaNGSoFT · 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?

y52 · March 19, 2018

On 18/03/2018 at 12:58 PM, Tazz said:

GlobalScaleTechnologies .dtb is for their own provided kernel.

As you are using Armbian, use what is provided by Armbian.

The Armbian's dtb raises kernel panic on my board

setenv fdt_name_a boot/dtb/marvell/armada-3720-community.dtb

[ OK ] Reached target Graphical Interface.
Starting Update UTMP about System Runlevel Changes...
[ OK ] Started Update UTMP about System Runlevel Changes.

Debian GNU/Linux 9 espressobin ttyMV0

espressobin login: [ 108.552976] Unable to handle kernel paging request at virtual address 555555555555cd
[ 108.560575] pgd = ffffffc07780e000
[ 108.564546] [555555555555cd] *pgd=000000007697c003, *pud=000000007697c003, *pmd=0000000000000000
[ 108.573474] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 108.579140] Modules linked in: bridge stp llc xt_nat iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 ip6t_rt nf_defrag_ipv4 xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter iptable_filter ip6_tables ip_tables x_tables
[ 108.602572] CPU: 1 PID: 7 Comm: rcu_preempt Not tainted 4.4.112-mvebu64 #8
[ 108.609767] Hardware name: Marvell Armada 3720 Community Board (DT)
[ 108.615981] task: ffffffc07807c500 ti: ffffffc0780b8000 task.ti: ffffffc0780b8000
[ 108.623909] PC is at mv_udc_irq+0x730/0xc00
[ 108.628135] LR is at mv_udc_irq+0x728/0xc00

....

[ 115.737495] Process kworker/1:3 (pid: 554, stack limit = 0xffffffc0777c4020)
[ 115.744526] Stack: (0xffffffc0777c7cd0 to 0xffffffc0777c8000)

...

[ 115.961471] Call trace:
[ 115.964001] [<ffffffc000095f9c>] check_and_switch_context+0x2c/0x450
[ 115.970582] [<ffffffc0009e44cc>] __schedule+0x17c/0x5d8
[ 115.975633] [<ffffffc0009e496c>] schedule+0x44/0xb8
[ 115.981036] [<ffffffc0000cd5dc>] worker_thread+0x1ac/0x4d0
[ 115.986626] [<ffffffc0000d3250>] kthread+0xf8/0x110
[ 115.991669] [<ffffffc000085dd0>] ret_from_fork+0x10/0x40
[ 115.997251] Code: a90363f7 a90153f3 2a0103f7 a9046bf9 (b9413382)

The board is stable at 1000/800 u-boot with the GlobalScaleTechnologies's dtb

setenv fdt_name_a boot/dtb/marvell/armada-3720-community-v5.dtb

Sign In

Espressobin support development efforts

Question

Link to comment

Share on other sites

887 answers to this question

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Important Information