lupus

Edit: this seems to related to a hardware issue on cubietruck. Currently there is no access to nand anymore from sd ... This may not be a top priority issue, but I observe problems with Armbian 5.33 on nand using jessie, stretch and xenial (legacy kernel). It seems to be related to armbian-config observed on a cubietruck. User built systems with legacy kernel 113 were flashed onto an sd card. Booting from SD works well and formatting, transferring the system to nand using armbian-config and booting into nand works too. After the first boot df displays the availability of 7GB of nand2 storage and 32MB of nand1 storage. The filesystem is writable. It is indicated on the welcome screen that a reboot is necessary to complete resizing of the file system ! The first reboot hangs for minutes and a cold start needs to be performed. After that the file system is mounted in read only mode - not writable anymore. Edit: There seems to be a hardware problem with nand. CPU temp is 53 degrees after booting from nand - but only 42 degrees after booting from sd... ____ _ _ _ _ / ___| _| |__ (_) ___| |_ _ __ _ _ ___| | __ | | | | | | '_ \| |/ _ \ __| '__| | | |/ __| |/ / | |__| |_| | |_) | | __/ |_| | | |_| | (__| < \____\__,_|_.__/|_|\___|\__|_| \__,_|\___|_|\_\ Welcome to ARMBIAN 5.33 user-built Ubuntu 16.04.3 LTS 3.4.113-sun7i System load: 0.57 0.31 0.12 Up time: 1 min Memory usage: 1 % of 1966MB IP: CPU temp: 53°C Usage of /: 17% of 7.0G mkdir /mnt/nand2 mkdir: cannot create directory '/mnt/nand2': Read-only file system df -h Filesystem Size Used Avail Use% Mounted on /dev/root 7.0G 1.1G 5.6G 17% / devtmpfs 976M 0 976M 0% /dev tmpfs 984M 0 984M 0% /dev/shm tmpfs 984M 8.5M 975M 1% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 984M 0 984M 0% /sys/fs/cgroup tmpfs 984M 0 984M 0% /tmp /dev/nand1 32M 5.8M 27M 19% /boot log2ram 50M 944K 50M 2% /var/log tmpfs 197M 0 197M 0% /run/user/0 cat /etc/fstab # <file system> <mount point> <type> <options> <dump> <pass> tmpfs /tmp tmpfs defaults,nosuid 0 0 /var/swap none swap sw 0 0 /dev/nand1 /boot vfat defaults 0 0 /dev/nand2 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1

u-boot 17.08.1 flash images for all combinations of Marvell supported CPU/DDR3 frequencies (600/600, 800/800, 1000/800, 1200/750) With kind support of @Igor and @aldzune I could build and test u-boot 17.08.1 and 17.06.3 flash images for all frequency combinations indicated above (boot snippets 17.08: https://pastebin.com/kKTvP5sx and 17.06: https://pastebin.com/8DZ37Wti , available functions: https://pastebin.com/kN5WBjW9 ). The flash-image.bin files (u-boot-images.tar.gz are attached below) just have to be resident in the root directory of a USB stick attached to the Espressobin and they can be flashed at the u-boot prompt: Marvell>> bubt flash-image-XXX_YYY.bin spi usb (XXX: CPU Frequency, YYY: DDR3 Frequency) 'ARMBIAN 5.32.170817 nightly Debian GNU/Linux 9 (stretch) 4.4.82-mvebu64' boots smoothly in all 4 scenarios (see i.e. https://pastebin.com/KkZsU8sk ). (A static IP address is assigned in /etc/network/interfaces to get rid of the 'raise network interface' issue) EDIT: With the new firmware I receive I/O errors after some time while accessing the sd card. The firmware needs to be properly tested by Marvell / Globalscale Technologies and made available by them. Please contact Globalscale Technologoies / Marvell if you are interested in a more recent firmware.

Openssl speed performance of Espressobin with kernel 4.12.1-ebin and security offload enabled: Configuraton options used for the kernel are: 'CONFIG_CRYPTO_HW=y' and '# CONFIG_CRYPTO_DEV_MARVELL_CESA is not set' (CPU frequency is assumed to be 1000MHz, cpufreq support is currently not enabled) root@ebin:~# cat /proc/version Linux version 4.12.1-ebin-g4b13ed5-dirty (ubuntu@ebin) (gcc version 6.3.0 20170519 (Ubuntu/Linaro 6.3.0-18ubuntu2~16.04) ) #1 SMP PREEMPT Wed Jul 12 16:25:39 UTC 2017 root@ebin:~# openssl speed -elapsed -evp aes-128-cbc root@ebin:~# openssl speed -elapsed -evp aes-192-cbc root@ebin:~# 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) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/aarch64-linux-gnu/engines-1.1\"" The 'numbers' are in 1000s of bytes per second processed. combined output: 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 I wonder how the results will change if the Marvell Security Engine is enabled ... Update: Please find attached the content of /proc/crypto : https://pastebin.com/ub4J4AiG

Netatalk is configured to use the afp protocol - I do not use samba. The networking issue in Ubuntu 16.04. occurs independent of the protocol used to connect to espressobin. BTW - The new "Armbian_5.32.170817_Espressobin_Debian_stretch_default_4.4.82.7z" image boots from SD ( https://pastebin.com/pHbvcQ39 ). The boot process of Debian stretch is not interrupted by a process for raising network interfaces. Update: Espressobin boots Debian stretch from SD with mainline kernel 4.12.1-ebin from @umiddelb (see https://pastebin.com/GXH7fLNF ) The following environment was used: https://pastebin.com/hbYA6p7B Update2: The system also boots from ssd ( https://pastebin.com/9KZRK2Cj ). I used the following environment: https://pastebin.com/mAVY3Hut The following options need to be used under Debian stretch for formatting the SATA device in order to be accessible by u-boot (thanks to @umiddelb): sudo mkfs.ext4 -O '^64bit' -O '^metadata_csum' /dev/sdaX Update3: Espressobin still stops responding over the network with 4.12.1-ebin (while Helios LanTest reads data from it) but remains accessible via the console.

I have tested kernel 4.4.79-mvebu64 from beta.armbian.com - it runs fine and is rock stable. Thanks to @umiddleb I have access to mainline kernels for the espressobin - I tried 4.12.1-ebin and 4.13.0-rc4-ebin. They are booting from SD and SATA ( see i.e. https://pastebin.com/jYsrkypw ). Unfortunately the Helios LanTest crashes renders the system on both 4.12 and 4.13 unresponsive. (I have recompiled Netatalk, but to no avail) Could this be related to clock frequencies selected ? Booting the Armbian Ubuntu Image with any kernel is very often interrupted by a job for raising network interfaces: "[** ] A start job is running for Raise ne... interfaces (1min 41s / 5min 4s)". Could this be fixed ? Update: As a stability test I compiled squid3 on 4.13.0-rc4-ebin without any problems (both cpus fully loaded for about an hour). Helios LanTest does not complete since espressobin stops responding over the network but it is still accessible via the console. Mainline kernels seem to work well, but network interfaces need to be fixed. Ubuntu 16.04.3 LTS espressobin ttyMV0 espressobin login: root Password: Last login: Mon Aug 14 11:47:57 CEST 2017 on ttyMV0 _____ _ _ | ____|___ _ __ _ __ ___ ___ ___ ___ | |__ (_)_ __ | _| / __| '_ \| '__/ _ \/ __/ __|/ _ \| '_ \| | '_ \ | |___\__ \ |_) | | | __/\__ \__ \ (_) | |_) | | | | | |_____|___/ .__/|_| \___||___/___/\___/|_.__/|_|_| |_| |_| Welcome to ARMBIAN 5.32 user-built Ubuntu 16.04.3 LTS 4.13.0-rc4-ebin-130271-gabe3c92 System load: 0.04 0.18 0.14 Up time: 8 min Memory usage: 16 % of 992MB IP: 192.168.240.42 HDD temp: 30??C Usage of /: 5% of 110G storage/: 5% of 110G [ General system configuration: armbian-config ] root@espressobin:~# ping google.com ping: unknown host google.com

I am using tkaisers image http://kaiser-edv.de/tmp/NumpU8/Armbian_5.32_Espressobin_Ubuntu_xenial_default_4.4.78.7z - updated with apt-get update && apt-get upgrade (powersave enabled - no cpufreq available). With an ambient temperature of 26 degrees Celsius, the temperature of the marvell 3720 is 50 degrees (steady state, measured after 10 minutes with an infrared thermometer), idle power consumption is 3.7W now ! The hottest chip (60 degrees) is the small one next to the 3720 with the label "U5" next to it. 50 degrees is far to hot to touch but should be OK for the silicon. Please find attached the output of armbianmonitor -u: http://sprunge.us/CWFi

The update worked for me using apt-get update && apt-get upgrade. Power consumption went up to 4.5 W due to powersave instead of ondemand. Helios LanTest results are OK (test run on 28.07.) The issue reported by tom_i seems to be related to the wifi card "Modules linked in: mwifiex_pcie mwifiex cfg80211 rfkill". Did you try to boot without the wifi card ?

Regarding potential thermal issues: There would not appear to be any. I checked the temperature of the Marvell 3720 using an infrared thermometer while at the Marvell>> prompt in U-boot. The chip reached a steady state temperature of 55 degrees Celsius within 10 minutes (ambient temperature 25 degrees Celsius). Power consumption of espressobin is about 5W in this context. Then I did boot Armbian_5.32.170626_Espressobin_Ubuntu_xenial_default_4.4.73.7z and within the first 10 minutes the 3720 reached a steady state temperature of 45 degrees Celsius (idle, ondemand, CPU frequency 200MHz). The power consumption in this context is about 3.5 W (can probably be further reduced my managing eth phy). Although these values were measured at the outside (not core temperatures), they would not appear to be problematic at all. According to Globalscaletechnologies, even core temperatures around 65 - 73 degrees Celsius (idle) would be considered normal. They observe these core temperatures in U-boot and on buildroot OS (idle). I conclude, that Armbian does already better due to cpu frequency scaling. BTW - I could not find any direct thermal monitoring in /sys/...

My board also started to overheat at the u-boot prompt - but after the environment variables were correctly set it could boot Armbian_5.32.170626_Espressobin_Ubuntu_xenial_default_4.4.73.7z and the thermal issues were gone after that. Please send a PM in case you wish to replace your board.

Marvell>> help ? - alias for 'help' base - print or set address offset bdinfo - print Board Info structure boot - boot default, i.e., run 'bootcmd' bootd - boot default, i.e., run 'bootcmd' bootelf - Boot from an ELF image in memory booti - boot arm64 Linux Image image from memory bootm - boot application image from memory bootp - boot image via network using BOOTP/TFTP protocol bootvx - Boot vxWorks from an ELF image bubt - Burn a u-boot image to flash cmp - memory compare cp - memory copy crc32 - checksum calculation echo - echo args to console editenv - edit environment variable env - environment handling commands exit - exit script ext2load- load binary file from a Ext2 filesystem ext2ls - list files in a directory (default /) ext4load- load binary file from a Ext4 filesystem ext4ls - list files in a directory (default /) ext4size- determine a file's size ext4write- create a file in the root directory false - do nothing, unsuccessfully fatinfo - print information about filesystem fatload - load binary file from a dos filesystem fatls - list files in a directory (default /) fatsize - determine a file's size fdt - flattened device tree utility commands fsinfo - print information about filesystems fsload - load binary file from a filesystem image go - start application at address 'addr' gpio - query and control gpio pins help - print command description/usage i2c - I2C sub-system ir - ir - Reading and changing internal register values. loop - infinite loop on address range ls - list files in a directory (default /) map - Display address decode windows md - memory display mdio - MDIO utility commands mii - MII utility commands mm - memory modify (auto-incrementing address) mmc - MMC sub system mmcinfo - display MMC info mw - memory write (fill) nm - memory modify (constant address) pci - list and access PCI Configuration Space ping - send ICMP ECHO_REQUEST to network host printenv- print environment variables remap - Remap the output address of a window reset - Perform RESET of the CPU resetenv- resetenv - reset all variables to default run - run commands in an environment variable saveenv - save environment variables to persistent storage scsi - SCSI sub-system scsiboot- boot from SCSI device setenv - set environment variables sf - SPI flash sub-system showvar - print local hushshell variables sleep - delay execution for some time sspi - SPI utility command test - minimal test like /bin/sh tftpboot- boot image via network using TFTP protocol true - do nothing, successfully usb - USB sub-system usbboot - boot from USB device version - print monitor, compiler and linker version Marvell>>

Unfortunately espressobin does not find the boot image (I am trying OMV_3_0_85_ESPRESSOBin_4.12.0.7z) even if the environtment variables given in https://github.com/armbian/build/blob/master/config/bootscripts/boot-espressobin.cmd are used: Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device ** File not found boot/Image ** 4803565 bytes read in 1749 ms (2.6 MiB/s) ** File not found boot/dtb/marvell/armada-3720-community.dtb ** Bad Linux ARM64 Image magic! Marvell>> Please find attached the current environment: Marvell>> printenv baudrate=115200 boot_interface=mmc bootargs=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/mmcblk0p1 rw rootwait 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;setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_ar bootdelay=3 bootmmc=mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $fdt_addr $fdt_name;setenv bootargs $console root=/dev/mmcblk0p1 rw rootwait; booti $kernel_addr - $fdt_addr console=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 eth1addr=00:00:00:00:51:82 eth2addr=00:00:00:00:51:83 ethact=neta0 ethaddr=F0:AD:4E:03:69:D0 ethprime=egiga0 fdt_addr=0x1000000 fdt_high=0xffffffffffffffff fdt_name=boot/dtb/marvell/armada-3720-community.dtb filesize=494bed gatewayip=10.4.50.254 get_images=mmc dev 0; fatload mmc 0 $kernel_addr $image_name; fatload mmc 0 $fdt_addr $fdt_name; run get_ramfs get_ramfs=if test "${ramfs_name}" != "-"; then setenv ramfs_addr 0x3000000; tftp $ramfs_addr $ramfs_name; else setenv ramfs_addr -;fi hostname=marvell image_name=boot/Image initrd_addr=0x1100000 initrd_image=boot/uInitrd initrd_size=0x2000000 ipaddr=192.168.240.42 kernel_addr=0x2000000 loadaddr=0x2000000 loads_echo=0 netdev=eth0 netmask=255.255.255.0 ramfs_addr=- ramfs_name=- root=root=/dev/mmcblk0p1 rw rootdev=/dev/mmcblk0p1 rootfstype=ext4 rootpath=/srv/nfs/ serverip=0.0.0.0 set_bootargs=setenv bootargs $console $root stderr=serial stdin=serial stdout=serial verbosity=1 Environment size: 1650/65532 bytes Marvell>>

Did you set the the environment parameters of espressobin (after Marvell>>) according to https://github.com/armbian/build/blob/master/config/bootscripts/boot-espressobin.cmd ? In particular "setenv fdt_name boot/dtb/marvell/armada-3720-community.dtb" needs to be set, since "boot/armada-3720-community.dtb" does not exist.

The script uses devmem - such a binary is not part of the Ubuntu image. I compiled devmem2 from gitgub sources (https://github.com/pavel-a/devmemX). The output of the adapted script unfortunately just produced a bunch of segmentation faults ...

Workaround (as suggested by tkaiser): I stored the following two lines in /etc/rc.local - after a reboot ondemand governor switches between 200MHz (!) and 1GHz depending on system load: cpufreq-set -c 0 -d 500000 -u 1000000 -g ondemand cpufreq-set -c 1 -d 500000 -u 1000000 -g ondemand root@espressobin:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq 11:12:27: 1000MHz 0.43 32% 10% 19% 0% 3% 0% 11:12:32: 200MHz 0.40 29% 9% 17% 0% 2% 0% 11:12:37: 200MHz 0.37 27% 8% 16% 0% 2% 0% 11:12:42: 200MHz 0.34 25% 8% 14% 0% 2% 0% 11:12:47: 200MHz 0.31 24% 7% 14% 0% 2% 0% 11:12:52: 200MHz 0.28 22% 7% 13% 0% 2% 0% 11:12:57: 200MHz 0.26 21% 6% 12% 0% 1% 0% 11:13:02: 200MHz 0.24 20% 6% 11% 0% 1% 0% 11:13:07: 1000MHz 0.22 19% 6% 11% 0% 1% 0% 11:13:12: 1000MHz 0.20 19% 6% 10% 0% 1% 0% 11:13:17: 200MHz 0.19 18% 6% 10% 0% 1% 0% 11:13:22: 200MHz 0.17 17% 6% 9% 0% 1% 0% 11:13:27: 200MHz 0.16 16% 5% 9% 0% 1% 0% 11:13:32: 200MHz 0.14 15% 5% 8% 0% 1% 0% iperf3 results are now both fine: MacBookPro:~ lupus$ iperf3 -c 192.168.240.42 Connecting to host 192.168.240.42, port 5201 [ 4] local 192.168.240.41 port 58907 connected to 192.168.240.42 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 68.9 MBytes 578 Mbits/sec [ 4] 1.00-2.00 sec 103 MBytes 862 Mbits/sec [ 4] 2.00-3.00 sec 105 MBytes 882 Mbits/sec [ 4] 3.00-4.00 sec 104 MBytes 876 Mbits/sec [ 4] 4.00-5.00 sec 102 MBytes 851 Mbits/sec [ 4] 5.00-6.00 sec 106 MBytes 892 Mbits/sec [ 4] 6.00-7.00 sec 102 MBytes 860 Mbits/sec [ 4] 7.00-8.00 sec 106 MBytes 892 Mbits/sec [ 4] 8.00-9.00 sec 105 MBytes 882 Mbits/sec [ 4] 9.00-10.00 sec 104 MBytes 876 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 1007 MBytes 845 Mbits/sec sender [ 4] 0.00-10.00 sec 1004 MBytes 842 Mbits/sec receiver iperf Done. MacBookPro:~ lupus$ iperf3 -R -c 192.168.240.42 Connecting to host 192.168.240.42, port 5201 Reverse mode, remote host 192.168.240.42 is sending [ 4] local 192.168.240.41 port 58911 connected to 192.168.240.42 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 111 MBytes 933 Mbits/sec [ 4] 1.00-2.00 sec 111 MBytes 932 Mbits/sec [ 4] 2.00-3.00 sec 112 MBytes 937 Mbits/sec [ 4] 3.00-4.00 sec 112 MBytes 937 Mbits/sec [ 4] 4.00-5.00 sec 112 MBytes 936 Mbits/sec [ 4] 5.00-6.00 sec 112 MBytes 937 Mbits/sec [ 4] 6.00-7.00 sec 112 MBytes 936 Mbits/sec [ 4] 7.00-8.00 sec 112 MBytes 936 Mbits/sec [ 4] 8.00-9.00 sec 112 MBytes 936 Mbits/sec [ 4] 9.00-10.00 sec 111 MBytes 935 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec receiver iperf Done. Helios LanTest write performance is good too:

There are only specific frequencies supported with the current system: root@espressobin:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 200000 250000 500000 1000000 However, cpufrequtils is currently configured to use another maximum value: root@espressobin:~# cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=200000 MAX_SPEED=800000 GOVERNOR=ondemand I have changed MAX_SPEED to 1000000 but unfortunately espressobin does not boot reliably anymore (crashes upon login). I have received my order of 10 espressobin this week ($49 each plus shipping) - I still have 7 to give away for the price I have paid. I have sent to you a PM with my contact details in any case ...