• Content count

  • Joined

  • Last visited

1 Follower

About ebin-dev

  • Rank
    Advanced Member

Recent Profile Visitors

245 profile views
  1. I am testing Armbian 5.42 on an EspressoBin 1G (boots from SPI/sata): It boots just fine: Welcome to ARMBIAN 5.42.180317 nightly Debian GNU/Linux 9 (stretch) 4.14.27-mvebu64 Linux version 4.14.27-mvebu64 (root@xeon) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #4 SMP PREEMPT Fri Mar 16 20:18:10 CET 2018 However: After switching from stable branch (kernel 4.14.24) to nightly (kernel 4.14.27) I observe two kernel installations in /boot: 4.14.27 and 4.4.121 (however, only 4.14.27 is configured - I just deleted *4.4.* also from /lib/modules etc.). (This may be specific to my installation) The only problem I observe is that with a mainline kernel on SSD (sata) reboot stops after shutdown is completed (with a manual reset it boots again): [ OK ] Reached target Shutdown. [ 234.934734] reboot: Power down ERROR: a3700_systPANIC at PC : 0x0000000004023248 This is also reported in the forum to happen with a mainline kernel on SD.
  2. 1GB EspressoBin won't Take 1GB U-Boot Firmware

    Armbian's bootloader is always up to date - for all flavours of EspressoBins. You can even select CPU_DDR frequencies for your use case. (you can see the difference if you compare the versions of the three software components of the firmware in your logs above) The factory images used to be outdated: 17.02 was preinstalled on all devices purchased last summer. Device support for the mPCIe interface was very limited. In August last year Armbian therefore started to distribute firmware images with a final release of 17.10 versions in early October with enhanced device support i.e. for the mPCIe interface. In November 17.06 factory images were published and finally 17.10 factory images this month - compiled in January. In the end all those firmware images are compiled from sources provided by Marvell on github - but Armbian (driven by a small group of enthusiastic developers) can react more quickly to the demand expressed by forum members. There is a lot more to say about the distribution itself.
  3. 1GB EspressoBin won't Take 1GB U-Boot Firmware

    This happens if you use a mainline kernel on SD. /dev/mmcblk0p1 is still correct if you use a legacy kernel (see the more detailed instructons here). This is the first time an EspressoBin appeared in the wild with only one DDR RAM chip. Is the memory chip soldered to the bottom (next to the 3720 and Topaz) or to the top of the PCB ? (let me guess: bottom) EDIT: I have already compiled new images for the 1G EspressoBin with only one DDR RAM chip on board (1g-1cs) using DDR_TOPOLOGY_4. They are already here. Do they work on your device ?
  4. 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.
  5. 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): Edit: If it is working it will be enabled by default - I am looking forward to test that.
  6. 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"
  7. 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.
  8. 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)
  9. I have several 1G EspressoBin boards around and they are stable with Armbian (Debian stretch with legacy kernel). The important aspect is not to expose them to excessive electrical/thermal strain. Thermal strain can easily be avoided by using a heat sink/fan or a huge passive heat sink (i.e. aluminium housing). CPU temperature will then stay below 35 degrees. Electrical strain arises if you power the board with two different GND potentials (AC or DC differences) while using the console - it will heat up substantially. You can harm your board within a few minutes. It can be avoided if you use a battery driven laptop to connect to the console. Did you ever measure the temperature of CPU / PMU / Topaz of your device during operation - in particular while being connected to the console ? If there is anything to improve then I would say that the vendor should sell EspressoBins with an enclosure together with an active or passive cooling mechanism and to reduce the effects of electrical strain on the board. You can not draw any conclusions about Armbian from using a defective board ...
  10. So - what do you conclude from all that ? What happens to all those kernel panics if you flash your device to 600_600 (with adapted /etc/default/cpufrequtils) ?
  11. The network configuration files of systemd-networkd reside in /etc/systemd/network/
  12. Your hardware ist stable with 800_800 but not with 1000_800 - this clearly shows that you have a hardware problem not related to Armbian in any way. Your EspressoBin does not fulfil the specs - you purchased a device with a 1000MHz CPU clock. Everybody having the same issues should contact GlobalScale and RMA the device. Edit: If you flash something else than 1000_800 you need to adapt min and max values in /etc/default/cpufrequtils to values shown by 'cpufreq-info'.
  13. There are two more flash images 800_800 and 600_600. I would test the board with those images - and RMA the device.
  14. In case you bricked your device, @Igor proposes SATA boot recovery. By the way - change the following environment settings to permanently boot from SATA: setenv boot_interface scsi setenv rootdev "/dev/sda1" setenv root root=/dev/sda1 rw 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'
  15. Your problems with the ondemand governor are specific to boards with hardware issues. You may have caused these issues yourself. These problems seem to arise (after some time) if your board is powered simultaneously by two sources with different GND potentials (check DC and AC). In this case your board will be exposed to severe electrical and thermal strain causing hardware issues after some time. It can be avoided if you access the serial console using a laptop that is not connected to a power supply itself (see https://forum.armbian.com/topic/4089-espressobin-support-development-efforts/?page=7&tab=comments#comment-39671 ).