ebin-dev

May be you did a reset while the 17.10 image was still loaded. Anyway - you can now also use the adapted environment settings on the EspressoBin download page (just changed by Igor). Boot priority with the load_script is: 1. USB, 2. SATA, 3. SD card, 4. eMMC

The new 18.09 bootloader flash images are now available through the EspressoBin downoad page. Please remember that it is mandatory to reset the environment settings once the 18.09 image is loaded the first time (Marvell>> env default -a). Then the updated environment settings as shown on the EspressoBin download page should be used.

Thanks.

Did you reset your environment settings ? Please use the new ones: setenv default -a setenv verbosity "2" setenv boot_interface mmc setenv image_name boot/Image setenv initrd_image "boot/uInitrd" setenv fdt_name boot/dtb/marvell/armada-3720-espressobin.dtb setenv fdt_high "0xffffffffffffffff" setenv rootdev "/dev/mmcblk1p1" setenv rootfstype "ext4" setenv initrd_addr "0x1100000" setenv usbstoragequirks "0x2537:0x1066:u,0x2537:0x1068:u" setenv fdt_addr "0x6000000" setenv kernel_addr "0x7000000" setenv loadaddr "0x8000000" setenv initrd_size "0x2000000" 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; setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr' setenv ethaddr F0:AD:4E:..... setenv eth1addr F0:AD:4E:..... setenv eth2addr F0:AD:4E:..... setenv eth3addr F0:AD:4E:..... env save

@jrtaylor You are using the official 17.10 image: U-Boot 2017.03-armada-17.10.3-g06ad760 (Aug 26 2018 - 19:00:03 +0200). You need to set the environment settings as specified on the EspressoBin download page (bootloader script). (Before you apply the settings you can reset your environment to default values with Marvell>> env default -a ) The new 18.09 images as linked in my previous posting (not yet official) currently do not work with that script since load addresses were moved - therefore you need to use the environment settings shown above - only for those 18.09 images.

There are some new bootloader flash images for the EspressoBin (see the parallel thread). U-Boot 2017.03-armada-18.09.1-ga92bd86-armbian WTMI-devel-18.07.0-6050fd5 atfv1.5(release):711ecd3 (Marvell-armada-18.09.4) It is mandatory to reset the environment settings and to use the new ones (load addresses have changed). Edit: 18.09 images with slightly improved performance: sbc-bench/17.10 vs. sbc-bench/18.09

The current 18.09 bootloader images (compiled Sept. 5th, 21:49) do work fine with the adapted address ranges. (u-boot 2017.03-18.09 used, macronix support confirmed by @FoodGenius, 1g-2cs images tested) Booting from SD into the current Armbian Stretch 4.18.y image works fine with these environment settings: setenv default -a setenv verbosity "2" setenv boot_interface mmc setenv image_name boot/Image setenv initrd_image "boot/uInitrd" setenv fdt_name boot/dtb/marvell/armada-3720-espressobin.dtb setenv fdt_high "0xffffffffffffffff" setenv rootdev "/dev/mmcblk1p1" setenv rootfstype "ext4" setenv initrd_addr "0x1100000" setenv usbstoragequirks "0x2537:0x1066:u,0x2537:0x1068:u" setenv fdt_addr "0x6000000" setenv kernel_addr "0x7000000" setenv loadaddr "0x8000000" setenv initrd_size "0x2000000" 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; setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr' setenv ethaddr F0:AD:4E:..... setenv eth1addr F0:AD:4E:..... setenv eth2addr F0:AD:4E:..... setenv eth3addr F0:AD:4E:..... env save ... and the environment to boot from SCSI into a current Armbian Stretch 4.18.y image: setenv default -a setenv verbosity "2" setenv boot_interface scsi setenv image_name boot/Image setenv initrd_image "boot/uInitrd" setenv fdt_name boot/dtb/marvell/armada-3720-espressobin.dtb setenv fdt_high "0xffffffffffffffff" setenv rootdev "/dev/sda1" setenv rootfstype "ext4" setenv initrd_addr "0x1100000" setenv usbstoragequirks "0x2537:0x1066:u,0x2537:0x1068:u" setenv fdt_addr "0x6000000" setenv kernel_addr "0x7000000" setenv loadaddr "0x8000000" setenv initrd_size "0x2000000" 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; setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr' setenv ethaddr F0:AD:4E:..... setenv eth1addr F0:AD:4E:..... setenv eth2addr F0:AD:4E:..... setenv eth3addr F0:AD:4E:..... env save Edit: SCSI environment added Edit: Linked to https://dl.armbian.com/espressobin/u-boot/

@kostap I have made available firmware images compiled with u-boot 2017.03-18.09 in my previous post. @FoodGenius now you have something worth trying.

So here there is finally a set of new flash-images-18.09 (with u-boot 2017.03-18.09 and with macronix support - not tested) (patch provided by @kostap - thanks!). The official Armbian flash images are still version 17.10 as compiled on Aug. 26th (without macronix support). Edit: 18.09 images compiled with u-boot 2017.03-18.09, macronix support Edit: 18.09 images are confirmed to work on the 1g-2cs EspressoBin, but changes to the Armbian bootscript are necessary in order to boot Armbian images with the environment settings shown on the EspressoBin download page.

Thank you for making public the issue with the unsupported Macronix chip. There is a corresponding warning on the EspressoBin download page. I have a reason to assume that this issue is already being dealt with. We have reverted back the flash-images to 17.10 as compiled on Aug. 26th since there still seem to exist some issues with the new 18.09 images that need to be resolved.

The issue with your Macronix chip needs to be dealt with by the manufacturer - unannounced board changes leading to unsupported systems are not very pleasant.

If I am compiling all of the images in one go and in parallel - indeed this time the file size of one or two images differ - I haven't noticed that. This would appear to be an effect of the compilers and/or OS used and could simply be avoided by compiling the images in sets of 4 - without any other changes. You can find the current images here. The 1g-2cs images are confirmed to be working. I have changed by build scripts so that this does not happen anymore. Sorry for the inconvenience.

A file got overwritten accidentally. I have therefore just recompiled the images for the 1g-2cs EspressoBin. You can download all of them here. The firmware is working - remember the environment needs a reset. There may be further changes necessary in Armbian to boot the OS.

The new 18.09 u-boot flash-images are available for download now. The environment must be reset to default values: Marvell>> env default -a Marvell>> saveenv and the environment settings as shown on the EspressoBin Download page should be used.

$ strings flash-image-1g-2cs-1000_800_boot_sd_and_usb.bin | grep mx25 mx25l2006e mx25l4005 mx25l8005 mx25l1605d mx25l3205d mx25l6405d mx25l12805 mx25l25635f mx25l51235f mx25u6435f mx25l12855e mx25u1635e

$ strings flash-image-1g-2cs-1000_800_boot_sd_and_usb.bin | grep mx25u3235f -> no references found.

@FoodGenius I still have to get it running (erase the old environment etc.). Will be available here if everything is fine.

I am currently testing new 18.09 flash images (thanks to Kosta): TIM-1.0 WTMI-devel-18.07.0-6050fd5 WTMI: system early-init CPU VDD voltage default value: 1.155V NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.5(release):711ecd3 (Marvell-armada-18.09.4) NOTICE: BL1: Built : 14:00:41, Sep 4 2018 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.5(release):711ecd3 (Marvell-armada-18.09.4) NOTICE: BL2: Built : 14:00:41, Sep 4 2018 NOTICE: BL1: Booting BL31 NOTICE: BL31: v1.5(release):711ecd3 (Marvell-armada-18.09.4) NOTICE: BL31: Built : 14:0 U-Boot 2018.03-armada-18.09.1-g8fe4031-armbian (Sep 04 2018 - 14:00:03 +0200) Model: Marvell Armada 3720 Community Board ESPRESSOBin CPU @ 1000 [MHz] L2 @ 800 [MHz] TClock @ 200 [MHz] DDR @ 800 [MHz] DRAM: 512 MiB Comphy chip #0: Comphy-0: USB3 5 Gbps Comphy-1: PEX0 2.5 Gbps Comphy-2: SATA0 6 Gbps Target spinup took 0 ms. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIE-0: Link down MMC: Loading Environment from SPI Flash... SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Marvell Armada 3720 Community Board ESPRESSOBin Net: eth0: neta@30000 [PRIME] Hit any key to stop autoboot: 0

So using old Linaro 2015_10 for compiling atf may solve the issue. Noted. Unfortunately compiling atf1.3-17.10 is currently broken - probably due to a recent update of Ubuntu 16.04 default compilers - at least on my system. I will therefore wait for the next series of updates in Marvells public repository on Github.

I have recompiled the u-boot flash images two days ago (u-boot 17.10.3, atf1.3-17.10.8, A3700utils-17.10.5). You can download them here. Does this solve the issue ? Edit: If the recompiled u-boot flash images still do not support the macronix chip on your EspressoBin we will have to wait for Marvell to release the code in their publicly available branch on github.

@Igor can you move this to peer-to-peer technical support please ? It seems that your installation is a mess. To boot from scsi is not officially supported yet. You can make it work but you need to understand what you do. After copying your working installation from SD to SSD using nand-sata-install you still need to manually copy /boot to /dev/sda1/ and to adapt the content of /dev/sda1/etc/fstab (rootdev UUID ; delete /boot entry ). You should also adapt the content of /dev/sda1/boot/armbianEnv.txt (rootdev UUID) and the content of /dev/sda1/boot/boot.cmd (setenv rootdev "/dev/sda1") followed by ‘mkimage -C none -A arm -T script -d boot.cmd boot.scr‘ to avoid any future mess. Then change your environment settings to boot from sata via SPI: setenv boot_interface scsi setenv image_name boot/Image setenv fdt_name boot/dtb/marvell/armada-3720-espressobin.dtb setenv fdt_high "0xffffffffffffffff" setenv rootdev "/dev/sda1" setenv root root=/dev/sda1 rw setenv rootfstype "ext4" setenv verbosity "1" setenv initrd_addr "0x1100000" setenv initrd_image "boot/uInitrd" setenv ethaddr "XX:XX:XX:XX:XX:XX" 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;setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr'

You are on Debian buster testing - that causes your problem. Is there a reason why you are not using Debian stretch mainline/stable ? The interfaces are up and running: # ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff 3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff 4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 532 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff 5: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff 6: lan0@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br0 state LOWERLAYERDOWN group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff 7: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br0 state LOWERLAYERDOWN group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff 8: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff inet 192.168.xx.yy/24 brd 192.168.xx.255 scope global dynamic br0 valid_lft 861638sec preferred_lft 861638sec inet6 2a02:810d:1500:7c44:f2ad:4eff:xxxx:yyyy/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 5214sec preferred_lft 2514sec inet6 fe80::f2ad:4eff:xxxx:yyyy/64 scope link valid_lft forever preferred_lft forever

I have changed the configuration in 10-eth0.network to DHCP=no. It is working, but networkctl reports it failed. # networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 bond0 ether off unmanaged 3 dummy0 ether off unmanaged 4 eth0 ether carrier configuring 5 wan ether carrier failed 6 lan0 ether no-carrier failed 7 lan1 ether no-carrier failed 8 br0 ether routable configured 8 links listed.

You should not change the content of /etc/network/interfaces if you use systemd-networkd. If it is of some help for you - see my configuration below: # cat /etc/network/interfaces # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback # cd /etc/systemd/network # ls 10-br0.netdev 10-br0.network 10-eth0.network 10-lan0.network 10-lan1.network 10-wan.network # cat * [NetDev] Name=br0 Kind=bridge MACAddress=XX:XX:XX:XX:XX:XX [Match] Name=br0 [Network] DHCP=ipv4 [Match] Name=eth0 [Network] DHCP=ipv4 [Match] Name=lan0 [Network] Bridge=br0 [Match] Name=lan1 [Network] Bridge=br0 [Match] Name=wan [Network] Bridge=br0

I am on Debian stretch- mainline/stable (4.17.5) (Armbian 5.44) - and it works just fine ... Welcome to ARMBIAN 5.44 user-built Debian GNU/Linux 9 (stretch) 4.17.5-mvebu64 # cat /proc/version Linux version 4.17.5-mvebu64 (root@armbian) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #34 SMP PREEMPT Mon Jul 9 16:32:32 UTC 2018 # journalctl -u systemd-networkd-wait-online.service -- No entries -- # systemd --v systemd 232 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN @Igor Is there a problem with systemd-networkd in Ubuntu ?