Jump to content

tom_i

Members
  • Posts

    53
  • Joined

  • Last visited

Reputation Activity

  1. Like
    tom_i reacted to cuker in Link to u-boot files doesn't work   
    Maybe this?   https://armbian.hosthatch.com/archive/espressobin/u-boot/
  2. Like
    tom_i got a reaction from lanefu in lvcreate doesn't work - solved   
    @lanefu - thx man, swithching to nightly solve that problem
  3. Like
    tom_i reacted to ebin-dev 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  
  4. Like
    tom_i reacted to Igor in Espressobin support development efforts   
    Do apt update and upgrade. I added a new version of armbian-config to the stable repository ... try once again @y52 might have the same problem.
  5. Like
    tom_i reacted to ebin-dev 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.
     
  6. Like
    tom_i reacted to Igor in Espressobin support development efforts   
    You don't have any better alternative. Other builds are not even on this level. I would not say we are in the early development. Just development. To my observation, it looks like those stability issues are tied to some particular board revision(s). Some work good. 
     

    The development team is exhausted and we don't receive help not even for simple tasks which we ask 
    https://forum.armbian.com/topic/4089-espressobin-support-development-efforts/?do=findComment&comment=49271 (taking some responsibility) https://forum.armbian.com/topic/6420-preparing-for-ubuntu-1804/ (copy pasting and test)  
  7. Like
    tom_i reacted to chrisf in Espressobin support development efforts   
    I had a quick look over the diff for 4.16-rc1 and it looks like there's progress on support for DVFS too
  8. Like
    tom_i reacted to ebin-dev 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.
     
  9. Like
    tom_i reacted to ebin-dev 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.
  10. Like
    tom_i reacted to lupus in Espressobin support development efforts   
    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  
  11. Like
    tom_i reacted to tkaiser in What about H8 SoC?   
    Well, we're talking here about Globalscale Technologies and the board is called Marvell ESPRESSOBin. Globalscale are those who made the *Plug computers (SheevaPlug and so on) and can be considered the company doing 'Marvell for normal users' stuff. Everything happens in the open (see especially at the bottom of this page -- block diagram already explains everything) and the ESPRESSOBin is considered a 'community board' (they're doing the same with their way more powerful 8040 SoC but there they partner with Solid-Run and this is a lot more expensive)
     
    Agreed, normal orders will take some time but everything else looks really promising. I would suppose they chose Kickstarter to manufacture in high volumes to meet the price tags and maybe also to get some valuable feedback regarding product development.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines