• Content Count

  • Joined

 Content Type 


Member Map





Everything posted by ebin-dev

  1. @sfx2000 What about the cooling system ? There would not appear to be any fan inside the housing. Passive cooling inside an essentially closed box ? I don't think this is going to work.
  2. That is true - but EspressoBin is an exception - systemd-networkd is used instead: root@ebin:~# nmtui NetworkManager is not running. root@ebin:~# 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 6 links listed. @StarSurfer The default configuration is DHCP=ipv4. So your router determines the ip address: root@ebin:/etc/systemd/network# cat 10-br0.network [Match] Name=br0 [Network] DHCP=ipv4 You may specify a static IP in 10-br0.network. According to this explanation the following should work (change the address according to your needs): root@ebin:/etc/systemd/network# cat 10-br0.network [Match] Name=br0 [Network] Address= Gateway= DNS= #DNS=
  3. 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 ?
  4. It is more convenient to use Etcher to flash the Armbian ímage to sd.
  5. The UART recovery procedure is described here. You need miniterm to connect to your EspressoBin.
  6. 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.
  7. 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.
  8. 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: Usage of /: 18% of 908G
  9. @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
  10. @Fan KunPeng Are you using the latest boot loader ?
  11. Edit: Also the latest beta works fine (Debian Stretch with Armbian Linux 4.19.50-mvebu64)
  12. 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)
  13. Did you try this with the 800_800 or 600_600 bootloader ?
  14. 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 ...
  15. Very interesting ! Performance is up by 25% too. Is it stable ??
  16. 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.
  17. If you have a look at armada-37xx-cpufreq.c in the source tree of kernel 4.19.46 and 5.1.6 you will see that i.e. lines 449, 450 have changed to unsigned long u_volt = avs_map[dvfs->avs[load_lvl]] * 1000; freq = base_frequency / dvfs->divider[load_lvl]; This corresponds to new lines 442, 443 of the patch file. So both kernels were patched (I just took the corresponding tar balls from kernel.org). Thank you for testing kernel 4.19.46 on your V7 EspressoBin. It is not stable with the 1000_800 bootloader - not even at the u-boot prompt, the CPU is clocked with 800MHz instead of 1000MHz and the 1200_750 bootloader even bricks your EspressoBin. I think that the vendor must be made aware of this. If you now switch to the other bootloader 800_800 - is your V7 Espresso stable now with kernel 4.19.46 ? cat /etc/default/cpufrequtils #800_800 ENABLE=true MIN_SPEED=200000 MAX_SPEED=800000 GOVERNOR=ondemand
  18. If you want to learn something you need to test with kernel 4.19.46 (please select next-nightly in armbian-config) with the new boot loader 1000_800 and 800_800. /etc/default/cpufrequtils should be adapted to: cat /etc/default/cpufrequtils #1000_800 ENABLE=true MIN_SPEED=250000 MAX_SPEED=1000000 GOVERNOR=ondemand Otherwise It is difficult to say if the crashes on boot are caused by kernel 5.2 or by the new boot loader.
  19. Warning notice: With newer kernels >= 4.19.4x, I would recommend 600_600 or 800_800 (1000_800 for testing purposes only). 1200_750 should be avoided at least for V7 EspressoBins, they may be bricked. System performance is the same with kernel 4.19.46 and 800_800 compared to kernel 4.19.20 and 1000_800, since the cpufreq patch is applied to the newer kernel, it still runs with a true CPU clock of 800 MHz. CPU temperature: I can't test V7 EspressoBins - but I think they come with a heat sink. They should not stay at the Marvell>> prompt for too long, since DVFS is not active and they run at 100% CPU frequency at this stage. I don't have any problems with V5 EspressoBins if they are passively cooled, though. Edit: thanks for the adjustments in config/kernel/linux-mvebu64-next.config. But I am not sure if it is necessary to apply the (Armbian) cpufreq patch to kernel 4.19.46 - it may not work if those files were already patched upstream. Edit: Also the latest beta works fine (ARMBIAN 5.88.190606 nightly Debian GNU/Linux 9 (stretch) 4.19.48-mvebu64)
  20. @Anders The reason for the different CPU clock speeds with kernel 4.19.20 and 5.1.0 is that the above patches already made it into the kernel (since 4.19.4x). Therefore with newer kernels the CPU is clocked as expected. In kernel 4.19.20 (and with earlier kernels) the CPU was clocked with lower speeds (800MHz instead of 1000MHz, 300MHz instead of 600MHz) as you have seen yourself. Now the new boot loader has to (ddr) tune the system such that it is stable under these new circumstances. Would you please test the 1000_800 image again (from here) ? I am surprised that the CPU only runs at 800 MHz in this case. Please press the reset button once you have flashed the 1000_800 image ... (You need to adapt the values in /etc/default/cpufrequtils to available values shown by cpufreq-info and to reboot)
  21. Thank you for your feedback. Do you realise that the CPU clock speed is different with kernel 4.19.20-mvebu64 (about 300MHz) and with 5.1.0-g72cf0b074 (about 600MHz) ? (see my comment in the other thread)
  22. @Igor Switching to the newer kernel 4.19.46 (and probably to 5.1 too) is possible without negatively affecting system performance if the new boot loader is downgraded to 800_800 beforehand (600_600 for some V7 users): I have just switched from next stable (ARMBIAN 5.73 stable Debian GNU/Linux 9 (stretch) 4.19.20-mvebu64 ) to next-nightly (ARMBIAN 5.87.190526 nightly Debian GNU/Linux 9 (stretch) 4.19.46-mvebu64). This process runs smoothly if I downgrade the new boot loader from 1000_800 to 800_800 beforehand - V5_0_1 EspressoBins are stable with this configuration (I don't own a V7 EspressoBin for testing purposes). Kernel 4.19.46 would appear to include the pending cpufreq patch - the new boot loader is currently not able to establish a stable system with a true CPU clock of 1000MHz. However, system performance is not negatively affected, since the true CPU clock is still running at 800MHz in this configuration: # kernel 4.19.46 and bootloader 800_800 # 7zr b 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 791 794 794 794 793 794 793 793 RAM size: 990 MB, # CPU hardware threads: 2 RAM usage: 441 MB, # Benchmark threads: 2 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 718 148 472 699 | 17428 193 770 1488 23: 705 147 488 719 | 17062 192 769 1477 24: 701 148 511 754 | 17395 199 769 1527 25: 692 150 528 790 | 17198 199 770 1531 ---------------------------------- | ------------------------------ Avr: 148 499 741 | 196 770 1506 Tot: 172 635 1123
  23. That is the reason why we can't update our EspressoBins to kernel 4.19.4x and above anymore without experiencing crashes. Hopefully the new bootloader released by marvell recently will be able to handle the new frequencies in the system.