ebin-dev

Members
  • Content Count

    153
  • Joined

  • Last visited

2 Followers

About ebin-dev

  • Rank
    Elite member

Recent Profile Visitors

719 profile views
  1. Since the patch is not working for all EspressoBins I would suggest to consider it a WIP or to delete it. Marvell already allocated resources in order to solve the issue. Edit: I have tested patched kernel 4.19.20 on three V5 EspressoBins - one used and two new ones. All of them produce the same issues (i.e. a kernel panic "Internal error: synchronous parity or ECC error" with bootloader 1000_800). With this patch applied we risk to lose the installed base of V3-V5 EspressoBins. It is simply not enough to just change parts of the cpufreq code - the problem has a wider scope and the bootloader probably needs some adjustments too.
  2. There are probably more elegant ways of doing that - but you can simply replace the content of ~/build/cache/sources/linux-mainline/linux-4.19.y by the 4.19.20 tarball and switch off your network connection. You will then build in offline mode - without any further modifications to the sources.
  3. In order to exclude any issues potentially caused by other kernel versions, I compiled a patched kernel 4.19.20 (download links: kernel debs, patches). Without the patches kernel 4.19.20 operates 24/7 on my Espresso without any issues with any of the current Armbian bootloader versions (but with a reduced CPU clock). The patched kernel is stable with latest Armbian boot loader 800_800. Kernel panics are observed upon reboot - but no issues occur after a power cycle. I observe kernel panics with 1000_800. The kernel stops loading with 1200_750 (latest Armbian boot loader). So - I can't confirm that the patched kernel would work without issues on a V5_0_1 EspressoBin with the current boot loader.
  4. You could switch to Nightly builds in armbian-config -> System and Security Settings. Then 4.19.27 will be installed on your Espresso.
  5. Unfortunately it does not work on a V5_0_1 EspressoBin with latest u-boot 1000_800 and 1200_750. The kernel starts to load but stops: [ 0.000000] bootconsole [ar3700_uart0] enabled You can download the patched kernel debs here (stretch 4.19.27) and give it a try. Edit: With the latest u-boot 600_600 and 800_800 the patched kernel is working on my EspressoBin - it runs with 600MHz and 800MHz as expected ! With 1000_800 and 1200_750 the patched kernel stops loading or even produces a kernel panic.
  6. ebin-dev

    espressobin u-boot can't detect emmc

    @kostap @Fan KunPeng I have manually enabled the second controller as suggested in u-boot/arch/arm/dts/armada-3720-espressobin.dts and rebuilt the images (see here). If you have time to test, please let me know if the mmc device is now detected by u-boot (I don't have an eMMC-EspressoBin for testing): Marvell>> mmc dev 1 Edit: Link changed to https://dl.armbian.com/espressobin/u-boot/
  7. ebin-dev

    espressobin u-boot can't detect emmc

    The current u-boot can be found here. It includes DDR3 (V5 EspressoBins) or DDR4 (V7 EspressoBins) in the name. Please use the correct one and post the output and the details about your board.
  8. With kernel 4.12.1 and stock firmware 17.02 openssl performance was fine - with kernel 4.14.27 and firmware 17.10 (both versions compiled 15 March 2018 and 4 October 2017) openssl performance was degraded (see here).
  9. Just in case someone wants to load the bootloader from eMMC: the necessary emmc flash images are here. (BOOTDEV is set to EMMCNORM) - EMMCNORM - eMMC Download Mode Download boot loader or program code from eMMC flash into CM3 or CA53 Requires full initialization and command sequence
  10. @FlashBurn, @ManoftheSea Did you adapt the settings in /etc/default/cpufrequtils ? The default ondemand governor settings are for a 1000Mhz CPU max clock speed and have to be adapted to other 'available frequency steps' in case you use 1200MHz (see the output of 'cpufreq-info' for a 1000_800 bootloader): cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=250000 MAX_SPEED=1000000 GOVERNOR=ondemand cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 250 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 250 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:0.00%, 250 MHz:80.32%, 500 MHz:0.60%, 1000 MHz:19.08% (3243) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 250 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 250 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:0.00%, 250 MHz:80.32%, 500 MHz:0.60%, 1000 MHz:19.08% (3243) Edit: sbc-bench results for a V5_0_1 board (1000_800) are here. The 'measured' CPU frequency is about 800MHz. The OpenSSL benchmark is also down by about 20% compared to values achieved in August 2017 (different bootloader). I think that this decline in performance was introduced some time ago by changes in the bootloader in order to get rid of the stability issues observed by some users.
  11. Could you post the output of U-Boot 18.12.3 ? Does it recognise your SPI flash now ?
  12. The new 18.12 bootloader should also support issi flash (see the parallel thread).
  13. ebin-dev

    Update uboot is invalid

    @nasbdh9 @JDL : the new boot loader 18.12 is available now. See the parallel thread.
  14. Thank you for the update @kostap. I built all images for the EspressoBin bootloader (download links: flash-images, sata-images and uart-images). The bootloader is now updated to the following versions: U-Boot 2018.03-devel-18.12.3 atf-v1.5 Marvell-devel-18.12.2 WTMI-devel-18.12.0 SPI Flash supported: stmicro, winbond, gigadevice, issi V7 EspressoBins are supported - but Armbian Stretch and Bionic images have to be adapted to them. DDR3 images are for V3-V5 EspressoBins (i.e. V5, 1g-2cs, see log) and DDR4 images are for V7 EspressoBins. Please flash the images according to the instructions on the EspressoBin download page - just insert 'DDR3' or 'DDR4' into the bubt command string. EDIT: download links changed to dl..armbian.com
  15. ebin-dev

    I can not switch channels other than 36 and 44

    You can try to boot Armbian Stretch or Armbian Bionic with kernel 4.18.x and your preinstalled u-boot 17.x on your V7 EspressoBin based on the following environment settings (to be entered at the Marvell>> prompt): #boot from SD: env default -a setenv boot_interface mmc setenv image_name boot/Image setenv fdt_name boot/dtb/marvell/armada-3720-espressobin.dtb setenv fdt_high "0xffffffffffffffff" setenv rootdev "/dev/mmcblk1p1" setenv root root=/dev/mmcblk1p1 rw setenv rootfstype "ext4" setenv verbosity "1" setenv initrd_addr "0x1100000" setenv initrd_image "boot/uInitrd" 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 #OR boot from SCSI: env default -a 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 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' saveenv