All Activity

This stream auto-updates     

  1. Past hour
  2. Debian testing is not supported. We have enough problems without that. You are welcome to discuss this further in the general area.
  3. ennoente

    ARMBIAN for Amlogic S905 and S905X

    Hello, I have K2Pro s905 would like to install on nand. can i install -other languages -usb G4 / LTE dongle -use as a wifi router which version is best? Thank you
  4. I've seen that 4.17.X kernel has more features for EspressoBin so I wanted to switch to the NEXT. Ddebian Stretch has 4.4. right?
  5. 5kft

    Nanopi NEO2 CPU frequency issue

    Thank you! There's no rush of course, only when absolutely convenient for you. Many thanks again
  6. It should be [Network] DHCP=ipv4
  7. ebin-dev

    Espressobin Debian testing

    You are on Debian buster testing - that causes your problem. Is there a reason why you are not using Debian stretch mainline/stable ? The interfaces are up and running: # ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff 3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff 4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 532 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff 5: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff 6: lan0@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br0 state LOWERLAYERDOWN group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff 7: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br0 state LOWERLAYERDOWN group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff 8: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff inet 192.168.xx.yy/24 brd 192.168.xx.255 scope global dynamic br0 valid_lft 861638sec preferred_lft 861638sec inet6 2a02:810d:1500:7c44:f2ad:4eff:xxxx:yyyy/64 scope global mngtmpaddr noprefixroute dynamic valid_lft 5214sec preferred_lft 2514sec inet6 fe80::f2ad:4eff:xxxx:yyyy/64 scope link valid_lft forever preferred_lft forever
  8. Today
  9. Same for me man. My ip addr show: nashome@espressobin:/etc/systemd/network$ ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff 3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff 4: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 532 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff 5: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 532 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff 6: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff So no lan0, lan1 are up, so maybe that's the reason it doesn't work.
  10. ebin-dev

    Espressobin Debian testing

    I have changed the configuration in 10-eth0.network to DHCP=no. It is working, but networkctl reports it failed. # networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 bond0 ether off unmanaged 3 dummy0 ether off unmanaged 4 eth0 ether carrier configuring 5 wan ether carrier failed 6 lan0 ether no-carrier failed 7 lan1 ether no-carrier failed 8 br0 ether routable configured 8 links listed.
  11. tkaiser

    Benchmarking CPUs

    NanoPi Fire3 with Samsung/Nexell S5P6818 which is an octa-core A53 clocked by default with 1.4 GHz (results irrelevant): Why are results irrelevant? For two reasons: Throttling occured. The board with vendor's standard heatsink starts to overheat badly when running demanding loads. Active cooling is needed and that's why monitoring when running benchmarks is that important! This is an octa-core Cortex-A53 SoC showing with this benchmark a score of well above 7000 when no throttling happens. Once again: such multithreaded results are BS wrt most real world workloads. An RK3399 board like an ODROID-N1 scoring 'just' 6500 will be the faster performing board with almost all usual workloads since equipped with 2 fast A72 cores while the Fire3 only has 8 slow A53 cores. Most workloads do not scale linearly with count of CPU cores. This has to be taken into account.
  12. tkaiser

    Benchmarking CPUs

    PineH64 with Allwinner H6 using mainline kernel which has no working cpufreq/dvfs/thermal drivers, therefore clocking H6 with 916 MHz (results irrelevant): PineH64 scores close to 2600 which as said already is irrelevant for the SoC's performance since with current mainline kernel the SoC runs at a fixed clockspeed reported by 7-zip as ~910 MHz -- it's 916 MHz). We know that the chip can clock up to 1.8 GHz (confirmed by @wtarreau's cool mhz tool) so once cpufreq/dvfs is working we see almost twice the numbers than these 2600. Why only 'almost twice'? Since the 7-zip benchmark depends also on memory bandwidth (like any real workload -- that's just another reason why sysbench sucks as CPU benchmark since sysbench does not depend on memory bandwidth at all). Those numbers are made with 4 tasks stressing all 4 CPU cores in parallel. Most real world workloads look differently and are single threaded. So even if a H6 clocked at 1.8 GHz produces 7-zip scores above 5000 any big.LITTLE ARM SoC with a similar score will be way faster in reality since when single threaded loads are running on the big cores they perform much faster.
  13. Pat

    Nanopi NEO2 CPU frequency issue

    @guidol Yes I should be able to test the image either today or tomorrow. @5kftThank you for your work and the clear test procedure (I've no serial console). My feedback as soon as possible.
  14. Smurfix

    Espressobin Debian testing

    There is no physical interface named "eth0" you could talk on. There are interfaces named "lan1", "lan0" and "wan". However, eth0 is what the CPU uses to multiplex these, so you need to set that to "up" too. I do it with this simple systemd-networkd rule: # cat /etc/systemd/network/49-switch.network [Match] Name=eth0 [Network] DHCP=no Then you can access the three real interfaces normally.
  15. We only support Armbian builds here.
  16. ebin-dev

    Espressobin Debian testing

    You should not change the content of /etc/network/interfaces if you use systemd-networkd. If it is of some help for you - see my configuration below: # cat /etc/network/interfaces # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback # cd /etc/systemd/network # ls 10-br0.netdev 10-br0.network 10-eth0.network 10-lan0.network 10-lan1.network 10-wan.network # cat * [NetDev] Name=br0 Kind=bridge MACAddress=XX:XX:XX:XX:XX:XX [Match] Name=br0 [Network] DHCP=ipv4 [Match] Name=eth0 [Network] DHCP=ipv4 [Match] Name=lan0 [Network] Bridge=br0 [Match] Name=lan1 [Network] Bridge=br0 [Match] Name=wan [Network] Bridge=br0
  17. Hi @ebin-dev I'm on Debian too: Linux version 4.17.5-mvebu64 (root@nightly) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #87 SMP PREEMPT Sun Jul 8 19:16:19 UTC 2018 lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux testing (buster) Release: testing Codename: buster It shows me some messages about eth0: [ 2868.894331] mvneta d0030000.ethernet eth0: could not attach PHY: -19 [ 2868.898077] mvneta d0030000.ethernet eth0: cannot probe MDIO bus Is there any way, how to debug this? I've tried to define eth0 with DHCP in "/etc/network/interfaces", or run "sudo dhclient eth0". Both with no luck
  18. tkaiser

    Benchmarking CPUs

    With this commit I added 7-zip benchmark reporting to Armbian now. Will be available after next updates and with next batch of new images. Why not recommending to just do an 'apt install p7zip ; 7zr b'? Since 'fire and forget' benchmarking is always BS. You need some monitoring in parallel to know whether your system was really idle and at which clockspeeds the CPU cores were operating (throttling occuring or not?). Most recent 7-zip contains an own routine to 'pre-heat' the system prior to starting the benchmark (to let cpufreq scaling switch from low clockspeeds to highest ones and e.g. on Intel systems let the system enter TurboBoost modes). This 7-zip code runs single threaded so based on the kernel's scheduler sometimes ending up on the 'wrong' CPU core (e.g. a little core on big.LITTLE SoCs) On a NanoPC T4 with conservative settings (limiting big CPU cores to 1.8 GHz and little cores to 1.4 GHz) this looks like this: root@nanopct4:/home/tk# armbianmonitor -z Preparing benchmark. Be patient please... 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,6 CPUs LE) LE CPU Freq: 1413 1414 1414 1411 1413 1414 1414 1414 1415 RAM size: 3878 MB, # CPU hardware threads: 6 RAM usage: 1323 MB, # Benchmark threads: 6 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 3642 363 976 3543 | 98020 543 1540 8359 23: 3691 365 1030 3761 | 95217 541 1522 8239 24: 3606 354 1094 3878 | 92662 535 1520 8133 25: 4597 451 1164 5249 | 89079 529 1498 7928 ---------------------------------- | ------------------------------ Avr: 383 1066 4108 | 537 1520 8165 Tot: 460 1293 6136 Monitoring output recorded while running the benchmark: Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St. 10:16:19: 1800/1416MHz 0.12 12% 1% 7% 2% 1% 0% 44.4°C 0/5 10:16:25: 408/ 600MHz 0.11 0% 0% 0% 0% 0% 0% 43.9°C 0/5 10:16:30: 600/1416MHz 0.10 1% 0% 0% 0% 0% 0% 45.0°C 0/5 10:16:35: 1800/1416MHz 0.17 40% 0% 39% 0% 0% 0% 49.4°C 0/5 10:16:40: 1800/1416MHz 0.32 77% 0% 77% 0% 0% 0% 55.0°C 0/5 10:16:45: 1800/1416MHz 0.94 73% 0% 72% 0% 0% 0% 51.1°C 0/5 10:16:50: 1800/1416MHz 0.94 65% 0% 65% 0% 0% 0% 53.3°C 0/5 10:16:55: 1800/1416MHz 1.19 68% 0% 67% 0% 0% 0% 56.1°C 0/5 10:17:00: 1800/1416MHz 1.49 79% 1% 78% 0% 0% 0% 53.9°C 0/5 10:17:06: 1800/1416MHz 1.45 31% 0% 31% 0% 0% 0% 57.8°C 0/5 10:17:11: 1800/1416MHz 2.07 68% 0% 67% 0% 0% 0% 57.2°C 0/5 10:17:17: 1800/1416MHz 2.30 78% 0% 77% 0% 0% 0% 58.9°C 0/5 10:17:22: 1800/1416MHz 2.52 90% 1% 89% 0% 0% 0% 57.8°C 0/5 10:17:27: 1800/1416MHz 2.72 81% 0% 80% 0% 0% 0% 57.2°C 0/5 Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St. 10:17:32: 1800/1416MHz 2.66 61% 0% 60% 0% 0% 0% 60.6°C 0/5 We get an overall score of above 6100 and 7-zip's 'CPU Freq' line reports CPU0 (a little core) being clocked at 1.4 GHz. But since this is a big.LITTLE design we need the monitoring output that gets displayed below 7-zip benchmark numbers. By looking at the 2nd line we see that the system was totally idle prior to starting the benchmark (I implemented a 10 second sleep between starting monitoring and firing up the benchmark for this reason -- to control whether the system was already busy or not). As a comparison 7-zip numbers of another RK3399 board that allowed the CPU cores to clock slightly higher (2.0/1.5 GHz): ODROID-N1 scored 6500. As a reference some other boards. Rock64 with new 1.4 GHz settings: NanoPi NEO with cpufreq scaling limited to 816 MHz to keep the board always at lowest DVFS voltage (results irrelevant) Please keep in mind that benchmarks that run fully multi threaded are NOT representative for most workloads running on computers (they're single threaded). Also please keep in mind that while 7-zip is not that much affected by different compiler settings (like the infamous sysbench) of course it is somewhat. So when you see 7-zip benchmark numbers generated few years ago when the 7z binary has been built with a GCC 4.x most probably with today's software and a binary built by GCC 7.x you see higher scores. So take these comparison numbers with a grain of salt: https://s1.hoffart.de/7zip-bench/ To get new armbianmonitor with -z funtionality today it's as easy as wget -O /usr/bin/armbianmonitor https://raw.githubusercontent.com/armbian/build/master/packages/bsp/common/usr/bin/armbianmonitor
  19. Ubuntu Bionic? It has plenty of (upstream) bugs and that is the reason we don't support it.
  20. ebin-dev

    Espressobin Debian testing

    I am on Debian stretch- mainline/stable (4.17.5) (Armbian 5.44) - and it works just fine ... Welcome to ARMBIAN 5.44 user-built Debian GNU/Linux 9 (stretch) 4.17.5-mvebu64 # cat /proc/version Linux version 4.17.5-mvebu64 (root@armbian) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #34 SMP PREEMPT Mon Jul 9 16:32:32 UTC 2018 # journalctl -u systemd-networkd-wait-online.service -- No entries -- # systemd --v systemd 232 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN @Igor Is there a problem with systemd-networkd in Ubuntu ?
  21. Ok thx, fortunatelly my board works pretty well Anyway, my network manager doesn't work as I switched from 4.4. kernel to the next 4.17.5. It shows me just: sudo journalctl -u systemd-networkd-wait-online.service - [sudo] password for nashome: -- Logs begin at Sat 2018-07-21 09:50:37 UTC, end at Sat 2018-07-21 09:57:12 UTC Jul 21 09:50:40 espressobin systemd[1]: Starting Wait for Network to be Configur Jul 21 09:52:40 espressobin systemd-networkd-wait-online[566]: Event loop failed Jul 21 09:52:40 espressobin systemd[1]: systemd-networkd-wait-online.service: Ma Jul 21 09:52:40 espressobin systemd[1]: systemd-networkd-wait-online.service: Fa Jul 21 09:52:40 espressobin systemd[1]: Failed to start Wait for Network to be C Because I'm connected it through "screen" so it looks that it break lines of that log :-/
  22. pro777

    Armbian for Amlogic S912

    What is your chip Wi-Fi?
  23. jernej

    AV/HDMI switch and display rotation

    Address is correct. I would suggest you first find devmem2 program (source is all over the net). It does almost exactly what you want, but universally (you give it physical address on command line which you want to read).
  24. tkaiser

    Benchmarking CPUs

    For people not rejecting reality... again why sysbench is unrealiable (not able to indicate CPU performance AT ALL). Sysbench not able to compare different CPU architectures since only a compiler benchmark (you get 15 times higher 'CPU performance' reported with a 64-bit distro than a 32-bit distro on 64-bit ARM boards) Switch the distro and your sysbench numbers differ (in fact it's just different distros building their packages with different GCC versions) Update your distro and your sysbench numbers improve (since it's just a compiler benchmark) Different sysbench version, different 'benchmark' results (start at 'Performance with legacy Armbian image') Why sysbench's method to 'calculate CPU performance' is that weird and does not apply to anything performance relevant in the real world For people loving to 'shoot the messenger'... it's not only me who describes sysbench as the totally wrong tool, e.g. https://www.raspberrypi.org/forums/viewtopic.php?t=208314&amp;start=25 Again: 7-zip's benchmark mode is not just using an insanely limited synthetic benchmark routine like sysbench (calculating prime numbers only involving CPU caches but no memory access), 7-zip is not dependent on compiler versions or platform switches and 7-zip allows for cross-platform comparisons. You'll find a lot of numbers here in the forum and some comparisons on the net e.g. https://s1.hoffart.de/7zip-bench/ (again: it's just a rough estimate but at least something somewhat reliable related to CPU performance) The most important thing with benchmarking is 'benchmarking the benchmark'. Since most tools (especially the popular ones) do not do what they pretend to do. Active benchmarking is needed and not just throwing out numbers without meaning. BTW: sysbench is part of MySQL and when used correctly a great tool to provide insights. It's just the 'cpu test' that is not a CPU test at all. And it's about people firing up sysbench in 'passive benchmarking' mode generating numbers without meaning and praising insufficient tools.
  25. balbes150

    Armbian for Amlogic S912

  26. balbes150

    ARMBIAN for Amlogic S905 and S905X

    The update of the kernel 3.14. Added dtb files for S905W. This core was collected new images in the directory "5.44\kernel_3.14_20180721". I'm Checked the operation of the Mate image on X96 mini s905w 2\16. After automatic OTA update of Android firmware in eMMC to 20180505, the images work WITHOUT manual addition of dtb file. Checked the installation of the system in eMMC (using the script /root/install.sh), everything is installed without errors and the system works from eMMC.
  27. pbies

    Benchmarking CPUs

    @tkaiser I don't understand your negativity. Banana Pi's are bad, sysbench is bad... The whole world is bad, isn't it? I'm sorry but I won't be arguing with you.
  1. Load more activity