ebin-dev

Members
  • Content Count

    133
  • Joined

  • Last visited


Reputation Activity

  1. Like
    ebin-dev got a reaction from nasbdh9 in Update uboot is invalid   
    Your u-boot was not provided by Armbian - you can convince yourself by comparing it to the ones in the Archive (yours was compiled on June 1st, in timezone GMT +8 ...).
     
    Your EspressoBin is equipped with a Macronix SPI - if you need to rescue it start from here or here.
  2. Like
    ebin-dev reacted to skandalfo in Espressobin: rescue instruction for macronix SPI chip   
    So, I just checked that I could use the images in this folder to flash the current ones in its grand-parent one, and that I still was able to boot from the Armbian already installed in my SD card with a Macronix chip. Thanks a lot for these fixed images! 
     
    Steps:
    Had to use miniterm: miniterm --eol CR /dev/ttyUSB0 115200 rather than minicom. Minicom would interfere with the transfer from WtpDownload by trying to reopen the serial port once it had lost it; and then WtpDownload_linux would get interrupted. Set the jumpers for UART recovery and powered the board. In miniterm I hit enter until I got the E prompt, then entered "wtp". Then I ran the upload:  <path>/<to>/WtpDownload_linux -P UART -C 0 -R 115200 -B TIM_ATF.bin -I wtmi_h.bin -I boot-image_h.bin -E  
    As my bootable SD card was in, the just-downloaded bootloader in RAM would quickly go and start Linux from the SD card. If your EspressoBIN is borked, you probably should just remove any boot device. In my case I didn't bother; I just restarted miniterm quickly after WtpDownload had finished and pressed enter a number of times to interrupt the boot sequence.
    I plugged in a USB stick with flash-image-2g-2cs-1000_800.bin in it.
    I flashed it to SPI:
    Marvell>> bubt flash-image-2g-2cs-1000_800.bin spi usb Burning U-BOOT image "flash-image-2g-2cs-1000_800.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... 1 USB Device(s) found scanning bus 1 for devices... 2 USB Device(s) found reading flash-image-2g-2cs-1000_800.bin Image checksum...OK! SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB     Updating, 8% 126859 B/s    Updating, 16% 127704 B/s    Updating, 31% 167458 B/s    Updating, 39% 155994 B/s 262144 bytes written, 593344 bytes skipped in 2.249s, speed 389342 B/s Done! I then powered the board off, switched the boot jumpers back to their default position, and powered it on again. The board booted Armbian from SD card as usual.
     
  3. Like
    ebin-dev got a reaction from guidol in Looking for an enclosure for espressobin   
    The problem with the Molex male power connector was solved with a soldering iron :-)) - the male power connector at the end of a sata power cable was replaced by a female one - a not so difficult task, since the pins can be removed from the female connector.
     
    If there is some interest in these enclosures, I will try to find a company to produce and sell them (with an obligation to donate 1 USD/ 1 EUR to Armbian per housing sold). 
  4. Like
    ebin-dev got a reaction from tom_i in Espressobin support development efforts   
    @Igor is working on it ... (my installation responds as expected):
    # apt-get install armbian-config Reading package lists... Done Building dependency tree Reading state information... Done armbian-config is already the newest version (5.45). Edit: did you see this ?  You can install it from there:
    https://github.com/armbian/config  
  5. Like
    ebin-dev got a reaction from darkdrgn2k in Espressobin support development efforts   
    Debian server - mainline kernel - make sure you are on the stable branch and update your system with 'apt-get update && apt-get upgrade'.
  6. Like
    ebin-dev got a reaction from tom_i in Espressobin support development efforts   
    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.
     
  7. Like
    ebin-dev got a reaction from Patrick in Espressobin support development efforts   
    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. Like
    ebin-dev got a reaction from Patrick in Espressobin support development efforts   
    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. Like
    ebin-dev got a reaction from arm-push in Looking for an enclosure for espressobin   
    I can confirm that the 4 Port SATA III 6G Mini PCI Express Marvel 88SE9215 Controller Card is working out of the box with EspressoBin. It is the same as this one known to work and tested by Igor (results for EspressoBin).
     
    It is possible to use the mPCIe card inside the enclosure and loop through the 4 SATA cables to an external backplane - but then the internal 2.5" drive has to be removed from the enclosure of the EspressoBin due to space constraints. In that case it still can be used externally as a 5th drive if needed.
  10. Like
    ebin-dev got a reaction from arm-push in Espressobin support development efforts   
    EspressoBin has Cortex A53 processors and is therefore not affected by Meltdown/Spectre attacks: see ARM link.
  11. Like
    ebin-dev got a reaction from tkaiser in Looking for an enclosure for espressobin   
    We have produced a few minimalistic housings for the EspressoBin (120x42x81mm) with space for a 2.5" drive using a CNC molding cutter.
    Passive cooling of the processor and topaz switch by thermal coupling to the housing works well (housing temperature 31 degrees, ambient temperature 20 degrees).




     
     

  12. Like
    ebin-dev reacted to tkaiser in Looking for an enclosure for espressobin   
    And guess what: I have a huge box here labeled 'PC-Schraddel' (PC junk), just checked it for those cables and to my surprise I found in there my EspressoBin and also the right cable with 2 female Molex jacks:

  13. Like
    ebin-dev got a reaction from guidol in Looking for an enclosure for espressobin   
    The problem with the Molex male power connector was solved with a soldering iron :-)) - the male power connector at the end of a sata power cable was replaced by a female one - a not so difficult task, since the pins can be removed from the female connector.
     
    If there is some interest in these enclosures, I will try to find a company to produce and sell them (with an obligation to donate 1 USD/ 1 EUR to Armbian per housing sold). 
  14. Like
    ebin-dev got a reaction from tkaiser in Looking for an enclosure for espressobin   
    We have produced a few minimalistic housings for the EspressoBin (120x42x81mm) with space for a 2.5" drive using a CNC molding cutter.
    Passive cooling of the processor and topaz switch by thermal coupling to the housing works well (housing temperature 31 degrees, ambient temperature 20 degrees).




     
     

  15. Like
    ebin-dev got a reaction from Patrick in Espressobin support development efforts   
    @Igor Thank you for the update. I have just contacted our friends from Free Electrons - support for the Marvell Security Engine of the EspressoBin is probably finished within the next weeks and is exprected to be part of the crypto tree in Mainline 4.16. I`ll keep you informed.
     
    I have just updated my EspressoBin with the latest nightly builds: unfortunately 'armbian-config' has disappeared - is someone working on it ?
  16. Like
    ebin-dev got a reaction from tom_i in Espressobin support development efforts   
    For the ones who like to try the Armbian xenial default image (4.4.88) (cpufreq ondemand governor and systemd-networkd enabled) - installation instructions and a download link are here:
     
    Get the Armbian image (Armbian download link), flash it to an sd card (Etcher is recommended) and insert it into EspressoBin.
    Connect the USB cable to the micro USB port and establish a serial connection with a computer (see wiki).
    Connect the 12V power supply to boot EspressoBin and press a key to stop the boot process in u-boot.
    At the "Marvell>>" prompt enter the following instructions (environment) to change the environment settings (skip setenv ethaddr ...).
    Enter "saveenv" and press the reset button - that's it (https://pastebin.com/fq326KR3).
     
    You will be greeted by the Armbian welcome screen (user: root, password: 1234).
    You are invited to post your comments in this forum.
     
    Edit: Disconnect the USB cable for the serial connection a.s.a.p. if your computer is connected to a power grid.
            Use 'ssh root@<ipaddress>' instead of the console (or use a battery driven laptop if you wish to permanently use the console)
    Edit: If your EspressoBin produces a kernel panic you need to flash u-boot with a lower CPU frequency (u-boot 17.10.1 flash images)
    Edit: If you select a flash-image with another CPU frequency than 1000MHz you must adapt min/max values in /etc/default/cpufrequtils to available values displayed by 'cpufreq-info' and reboot (otherwise cpufreq will not work).
     
    If you are happy with Armbian please consider a donation.
     
  17. Like
    ebin-dev got a reaction from Igor in Espressobin support development efforts   
    You can safely use one of the flash images to update your board to the very latest version now (u-boot 17.10.1, atf1.3-17.10 for the 512MB and 1GB version released a week ago, atf1.3-17.08 for the 2GB version) (flash-instructions are included) (nobody bricked a device with them)
     
    The sources are available on Github and the build process is not complicated - you have explained it earlier in this forum. Official support for the 2GB EspressoBin is also expected soon.
     
    May be I do not understand you correctly - but any further tests using a bootloader on SATA drives to confirm that the images are working do not seem to be necessary.
     
    Once you have updated your board any new u-boot can be chainloaded using tftp to test its functionality - the process works (but not with the preinstalled u-boot / atf 17.02). 
     
    Nevertheless, I will see what needs to be done to boot directly from SATA leaving SPI alone.
  18. Like
    ebin-dev got a reaction from Igor in Espressobin support development efforts   
    You can safely use one of the flash images to update your board to the very latest version now (u-boot 17.10.1, atf1.3-17.10 for the 512MB and 1GB version released a week ago, atf1.3-17.08 for the 2GB version) (flash-instructions are included) (nobody bricked a device with them)
     
    The sources are available on Github and the build process is not complicated - you have explained it earlier in this forum. Official support for the 2GB EspressoBin is also expected soon.
     
    May be I do not understand you correctly - but any further tests using a bootloader on SATA drives to confirm that the images are working do not seem to be necessary.
     
    Once you have updated your board any new u-boot can be chainloaded using tftp to test its functionality - the process works (but not with the preinstalled u-boot / atf 17.02). 
     
    Nevertheless, I will see what needs to be done to boot directly from SATA leaving SPI alone.
  19. Like
    ebin-dev got a reaction from lanefu in Espressobin support development efforts   
    Network Manager does have its weaknesses and behaves sometimes erratic.  SBCs with more than one network interface such as the ClearFog Pro, ClearFog Base and  EspressoBin may require more complex configurations (i.e. firewalled router) - to realise that in a reliable way using Network Manager is a nightmare. Even bridged interfaces lead to erratic interruptions during boot.
     
    One could switch to systemd-networkd - it is already installed and just needs to be configured. No more hassles with jobs for raising network interfaces  .
     
    Interfaces wan, lan0 and lan1 are hot-pluggable and work with full speed (iperf3 results are as expected: 112MByte/s and 103MBytes/s in reverse direction). A working example configuration for bridged network interfaces is here:
    #purge network manager: apt-get --purge autoremove network-manager #copy three lines to the interfaces file: cat /etc/network/interfaces # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback #start services and create a symbolic link to resolv.conf: sudo rm /etc/resolv.conf systemctl start systemd-networkd.service systemctl start systemd-resolved.service systemctl enable systemd-networkd.service systemctl enable systemd-resolved.service ln -s /var/run/systemd/resolve/resolv.conf /etc/resolv.conf #create the 5 network configuration files in /etc/systemd/network/ #(do not delete empty lines): cd /etc/systemd/network/ cat 10-br0.netdev [NetDev] Name=br0 Kind=bridge cat 10-dhcp-br0.network [Match] Name=br0 [Network] DHCP=ipv4 cat 10-dhcp-eth0.network [Match] Name=eth0 [Network] DHCP=ipv4 cat 10-bridged-lan0.network [Match] Name=lan0 [Network] Bridge=br0 cat 10-bridged-lan1.network [Match] Name=lan1 [Network] Bridge=br0 #and restart systemd-networkd: systemctl restart systemd-networkd  
  20. Like
    ebin-dev got a reaction from lanefu in Espressobin support development efforts   
    You can compile your own Armbian xenial image with headers (still without asm/*) but with cpufreq support:
    apt-get -y -qq install git git clone --depth 1 https://github.com/armbian/build cd build nano ./config/sources/mvebu64.conf #change the last digit in case 'default' to: KERNELBRANCH='branch:linux-4.4.52-armada-17.06' #change to: MAX_SPEED=1000000 ./compile.sh BOARD=espressobin BRANCH=default BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=yes INSTALL_HEADERS=yes RELEASE=xenial During kernel configuration select: CPU Power Management - CPU Frequency Scaling - Default Governor - ondemand
    and you may disable other governors. Output is Armbian_5.32_Espressobin_Ubuntu_xenial_default_4.4.87.img with cpufreq ondemand governor enabled..
     
    More information about the Armbian build system can be found here: https://docs.armbian.com/Developer-Guide_Build-Preparation/
     
    EDIT: @lanefu  A commit for changing /config/sources/mvebu64.conf to default KERNELBRANCH linux-4.4.52-armada-17.06 and to MAX_SPEED=1000000 would avoid breaking cpufreq when updating Armbian xenial 4.4.73 images.