ebin-dev

Members
  • Content Count

    178
  • Joined

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Everything posted by ebin-dev

  1. 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
  2. @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
  3. @Fan KunPeng Are you using the latest boot loader ?
  4. Edit: Also the latest beta works fine (Debian Stretch with Armbian Linux 4.19.50-mvebu64)
  5. 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)
  6. Did you try this with the 800_800 or 600_600 bootloader ?
  7. 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 ...
  8. Very interesting ! Performance is up by 25% too. Is it stable ??
  9. 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.
  10. 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
  11. 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.
  12. 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)
  13. @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)
  14. 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)
  15. @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
  16. 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.
  17. You could ask for a replacement V7 board AND for a V5 board as some kind of compensation for all the trouble you had so far. My V5_0_1 boards are running 24/7 (with Armbian Stretch, mainline-stable, kernel 4.19.20) ...
  18. Updated sources for A3700-utils were published yesterday by Marvell. The changes enhance ddr tuning with the aim to enhance stability. The corresponding updated flash images can be downloaded here (updated rescue images are indicated as 18.12-v2).
  19. @barish Please try the new 600_600 flash image.
  20. @FlashBurn @spqr Please find the updated bootloader here (u-boot is unchanged; WTMI is updated to 18.12.1) - it should solve the stability issues and it works fine on my V5_0_1 EspressoBin (https://pastebin.com/xJCtLXsH). The recovery images are also updated: sata-images and uart-images. Could you please test if your EspressoBin ist stable now and if you can apply the pending cpufreq and xtal kernel patch without creating any further issues ? Edit: links updated ; images are now available through Armbian servers
  21. @kostap Thank you very much ! @Anders Please find the updated bootloader here (u-boot is unchanged; WTMI is updated to 18.12.1) - it works fine on my V5_0_1 EspressoBin (https://pastebin.com/xJCtLXsH). It should solve the stability issues ... Edit: the recovery images are also updated: sata-images and uart-images Edit: links changed ; the images are now available through Armbian servers
  22. We are desperately waiting for the next release of u-boot / atf / A3700-utils by Marvell (enhanced DDR tuning for all EspressoBins is expected). Together with the pending patch performance may increase by about 20 % and stability of V7 EspressoBins will hopefully be established too ...
  23. Could you flash your bootloader to 600_600 and try again ? If no errors occur in that case we could assume that the bootloader needs to be adapted at least for V7 boards ...
  24. After the update from kernel 4.19.20 to 4.19.41 my V5_0_1 Espresso does not boot successfully anymore (see log). It produces a kernel panic after 10 s: "Internal error: synchronous parity or ECC error". @Igor Please disable the update to kernel 4.19.41 for the next-stable branch.