ebin-dev

Members
  • Content Count

    183
  • Joined

2 Followers

About ebin-dev

  • Rank
    Elite member

Recent Profile Visitors

1001 profile views
  1. The UART rescue images to be used are those here (18.12-v2). To be on the safe side, please use the 600_600 or 800_800 images for your board. Did you follow the uart recovery instructions (use miniterm - not minicom etc.) ? Do you use a V7 or a V5_0_1 EspressoBin ?
  2. It is more convenient to use Etcher to flash the Armbian ímage to sd.
  3. The UART recovery procedure is described here. You need miniterm to connect to your EspressoBin.
  4. Your EspressoBin should work again if you flash the latest boot loader with 800_800 or 600_600 CPU_DDR frequencies (NOT 1000_800). You can find the current UART recovery images here and the latest u-boot flash images are here. Do not forget to use the latest environment settings.
  5. You may try the current Debian Buster image. It works fine without any issues so far on the EspressoBin (kernel 4.19.57). I did not try Ubuntu - but there were some postings related to issues with systemd-networkd in Ubuntu Bionic.
  6. No issues so far with Buster on EspressoBin. Nextcloud is faster with PHP 7.3.4 -- I am thrilled. _____ _ _ | ____|___ _ __ _ __ ___ ___ ___ ___ | |__ (_)_ __ | _| / __| '_ \| '__/ _ \/ __/ __|/ _ \| '_ \| | '_ \ | |___\__ \ |_) | | | __/\__ \__ \ (_) | |_) | | | | | |_____|___/ .__/|_| \___||___/___/\___/|_.__/|_|_| |_| |_| Welcome to Debian Buster with Armbian Linux 4.19.57-mvebu64 System load: 0.06 0.12 0.15 Up time: 8:04 hours Memory usage: 42 % of 990MB IP: 12.34.56.78 Usage of /: 18% of 908G
  7. @Jens Bauer @ManoftheSea @anubisg1 The MAC address of the bridge can be specified in 10-br0.netdev. This works without any issues in Stretch and in Buster (at least on a V5_0_1 EspressoBin). If you have problems with Ubuntu Bionic, then their implementation of systemd-networkd may be the reason. # cat 10-br0.netdev [NetDev] Name=br0 Kind=bridge MACAddress=XX:XX:XX:XX:XX:XX # networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 eth0 ether degraded configured 3 wan dsa degraded configured 4 lan0 dsa no-carrier configuring 5 lan1 dsa no-carrier configuring 6 br0 bridge routable configured _____ _ _ | ____|___ _ __ _ __ ___ ___ ___ ___ | |__ (_)_ __ | _| / __| '_ \| '__/ _ \/ __/ __|/ _ \| '_ \| | '_ \ | |___\__ \ |_) | | | __/\__ \__ \ (_) | |_) | | | | | |_____|___/ .__/|_| \___||___/___/\___/|_.__/|_|_| |_| |_| Welcome to Debian Buster with Armbian Linux 4.19.57-mvebu64 System load: 0.15 0.13 0.11 Up time: 17:54 hours Memory usage: 37 % of 990MB Zram usage: 36 % of 495Mb Usage of /: 18% of 908G
  8. @Fan KunPeng Are you using the latest boot loader ?
  9. Edit: Also the latest beta works fine (Debian Stretch with Armbian Linux 4.19.50-mvebu64)
  10. If you have some time for further tests on your V7 Espresso you could switch to kernel 4.14.79 (it is the current kernel provided by Marvell, cpufreq patch is not applied): in ‘armbian-config‘ switch to stable builds (select System->Stable) and if the process is finished, switch from next to other kernels (System->Other kernels-> 4.14.79). Edit: Marvells kernel 4.14.79 is an option - it ist stable at least on V5 EspressoBins with bootloader 1000_800. But the real CPU frequency reported by 7zip is also only 800MHz instead of 1000MHz (same behaviour as kernel 4.19.4x and 5.x)
  11. Did you try this with the 800_800 or 600_600 bootloader ?
  12. OK - kernel 4.4.52-armada-17.10.4-g719fc86-dirty has some other known (dts) issues. We need to identify the patch Armbian is missing ...
  13. Very interesting ! Performance is up by 25% too. Is it stable ??
  14. That are good news for V7 owners. But it also means that the boot loader needs some finishing touches for V7 (boot loader crashes, 1200_750 bricks the V7, CPU runs with 800MHz instead of 1000MHz) and V3-5 EspressoBins too (1000_800 causes kernel panics on boot, CPU runs with 800MHz instead of 1000MHz). These issues occur at least with kernel 4.19.4x and above (cpufreq patch applied). I don't think that we need to report anything else directly to GST/Marvell. Regarding the other patches in the pipeline: There were many undocumented/unannounced changes by GlobalScle to the hardware of V5 and V7 EspressoBins. Most of the issues caused by that were already corrected in the boot_loader by Marvell and in Armbian. I hope that @Igor will have a look at those patches some time. As far as I know the required hardware (V7 EspressoBin with soldered emmc) is not available for testing purposes ... Edit: of course everybody is invited to test patches on their hardware and to post observations in the forum.