• Content Count

  • Joined

  • Last visited

 Content Type 


Member Map






Everything posted by ebin-dev

  1. Unfortunately there are no details about your board. Do you own a V5_0_1 EspressoBin with 2GB RAM (2 x 8Gbit DDR3, one on each side of the board) ?
  2. @msmol I have corrected the error in DDR_Topology_6 as identified by @Rainbaby and recompiled flash, sata and uart images for the V7-2G EspressoBin (uboot version is still the same). Please let me know if the flash images now also work with the 2GB version of the V7 EspressoBin (download link). EDIT: download link changed to dl.armbian.com
  3. @Igor In armbian-config on EspressoBin (Buster - fully updated und upgraded) there are currently not options for alternative kernels under System -> Other. I am currently on the nightly branch (Linux version 4.19.66-mvebu64). Edit: Switching back to stable kernels in armbian-config now leads to the installation of Linux version 4.19.85-mvebu64. Everything went fine without any issues. armbian-config now presents alternative kernels under System -> Other: either "legacy" kernel 4.14.135-mvebu64 or "next" kernel 4.19.56-mvebu64.
  4. @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.
  5. 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=
  6. 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 ?
  7. It is more convenient to use Etcher to flash the Armbian ímage to sd.
  8. The UART recovery procedure is described here. You need miniterm to connect to your EspressoBin.
  9. 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.
  10. 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.
  11. 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
  12. @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
  13. @Fan KunPeng Are you using the latest boot loader ?
  14. Edit: Also the latest beta works fine (Debian Stretch with Armbian Linux 4.19.50-mvebu64)
  15. 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)
  16. Did you try this with the 800_800 or 600_600 bootloader ?
  17. 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 ...
  18. Very interesting ! Performance is up by 25% too. Is it stable ??
  19. 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.
  20. 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
  21. 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.
  22. 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)
  23. @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)