Igor Posted July 12, 2017 Share Posted July 12, 2017 4 hours ago, umiddelb said: I've booted the buildroot rootfs mentioned here and recognized that the ESPRESSObin was shipped with a Marvell wifi card: I switched to your branch It's better than plain mainline I guess. I'll try later if I'll get more luck with my PCI cards. 0 Quote Link to comment Share on other sites More sharing options...
umiddelb Posted July 12, 2017 Share Posted July 12, 2017 OK, I'll try to provide you the relevant patches and put them in the right place. More important, the board tends to crash silently with the marvell-linux 4.4 kernel after a couple of hours. 0 Quote Link to comment Share on other sites More sharing options...
umiddelb Posted July 12, 2017 Share Posted July 12, 2017 I forgot to mention that you have to pass the mtd partitioning information via the kernel command line, e.g. console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=UUID=99415e2c-d205-4dd4-84ba-6804c8e4bc79 rootwait rw fsck.repair=yes governor=ondemand no_console_suspend mtdparts=spi32766.0:1536k(uboot),64k(uboot-environment),-(reserved) net.ifnames=0 elevator=noop 1 Quote Link to comment Share on other sites More sharing options...
tom_i Posted July 13, 2017 Share Posted July 13, 2017 Hi, I've tried "Armbian_5.32.170626_Espressobin_Ubuntu_xenial_default_4.4.73.img" and for me it works perfectly. WIFI (2,4 & 5GHz), CPU scaling and LAN, these I've just tried yesterday night. Thank you guys, Armbian is really awesome I like it so much. 0 Quote Link to comment Share on other sites More sharing options...
tkaiser Posted July 13, 2017 Share Posted July 13, 2017 19 hours ago, lanefu said: iSuk I would've preferred iTestAgain 1 Quote Link to comment Share on other sites More sharing options...
lupus Posted July 21, 2017 Share Posted July 21, 2017 I have installed Netatalk 3.1.11 and tried the Helios Lan Test. The storage used by netatalk is an SSD (OCZ Vertex 128G) attached to the SATA port of espressobin (see the test results below). Additionally, I manually uploaded a 2260MB file via the macOS finder (afpd) to espressobin in 52s (43MB/s) and downloaded it again to a MacPro in 20s (113 MB/s). I guess that the write speed is limited by the SSD - read speed of netatalk/espressobin is pretty impressive ... I have used the latest Armbian image (Armbian_5.32.170626_Espressobin_Ubuntu_xenial_default_4.4.73.7z) - If you have a more recent image to test, please let me know. 1 Quote Link to comment Share on other sites More sharing options...
lupus Posted July 22, 2017 Share Posted July 22, 2017 Following up on my previous post: SSD read and write performance is above 200MB/s - can not be the reason for slow write performance. root@espressobin:~# hdparm -tT /dev/sda /dev/sda: Timing cached reads: 1128 MB in 2.00 seconds = 563.38 MB/sec Timing buffered disk reads: 678 MB in 3.01 seconds = 225.51 MB/sec root@espressobin:~# hdparm -tT --direct /dev/sda /dev/sda: Timing O_DIRECT cached reads: 414 MB in 2.00 seconds = 206.64 MB/sec Timing O_DIRECT disk reads: 634 MB in 3.01 seconds = 210.87 MB/sec root@espressobin:~# dd if=/dev/zero of=/mnt/ssd/var/cloud/afp/tempfile bs=1M count=1024 conv=fdatasync,notrunc 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.11181 s, 210 MB/s root@espressobin:~# echo 3 | sudo tee /proc/sys/vm/drop_caches 3 root@espressobin:~# dd if=/mnt/ssd/var/cloud/afp/tempfile of=/dev/null bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.90237 s, 275 MB/s iperf3 results reveal that the network is fine, but that there are issues if espressobin receives data: MacPro:~ admin$ iperf3 -c 192.168.240.42 Connecting to host 192.168.240.42, port 5201 [ 5] local 192.168.240.36 port 49537 connected to 192.168.240.42 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 27.6 MBytes 232 Mbits/sec [ 5] 1.00-2.00 sec 43.4 MBytes 364 Mbits/sec [ 5] 2.00-3.00 sec 45.8 MBytes 384 Mbits/sec [ 5] 3.00-4.00 sec 45.2 MBytes 379 Mbits/sec [ 5] 4.00-5.00 sec 47.0 MBytes 394 Mbits/sec [ 5] 5.00-6.00 sec 45.5 MBytes 382 Mbits/sec [ 5] 6.00-7.00 sec 45.4 MBytes 380 Mbits/sec [ 5] 7.00-8.00 sec 46.2 MBytes 387 Mbits/sec [ 5] 8.00-9.00 sec 48.4 MBytes 405 Mbits/sec [ 5] 9.00-10.00 sec 48.4 MBytes 407 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 443 MBytes 371 Mbits/sec sender [ 5] 0.00-10.00 sec 442 MBytes 371 Mbits/sec receiver iperf Done. MacPro:~ admin$ iperf3 -R -c 192.168.240.42 Connecting to host 192.168.240.42, port 5201 Reverse mode, remote host 192.168.240.42 is sending [ 5] local 192.168.240.36 port 49539 connected to 192.168.240.42 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 109 MBytes 910 Mbits/sec [ 5] 1.00-2.00 sec 112 MBytes 937 Mbits/sec [ 5] 2.00-3.00 sec 112 MBytes 937 Mbits/sec [ 5] 3.00-4.00 sec 112 MBytes 937 Mbits/sec [ 5] 4.00-5.00 sec 112 MBytes 937 Mbits/sec [ 5] 5.00-6.00 sec 112 MBytes 937 Mbits/sec [ 5] 6.00-7.00 sec 111 MBytes 934 Mbits/sec [ 5] 7.00-8.00 sec 112 MBytes 937 Mbits/sec [ 5] 8.00-9.00 sec 112 MBytes 937 Mbits/sec [ 5] 9.00-10.00 sec 112 MBytes 937 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.09 GBytes 935 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 1.09 GBytes 935 Mbits/sec receiver iperf Done. Probably network related tasks need to be redistributed among espressobin cpu´s. I would like to test again with mainline kernel once available. 0 Quote Link to comment Share on other sites More sharing options...
lupus Posted July 22, 2017 Share Posted July 22, 2017 The puzzle seems to be solved - the ondemand governor does not scale up the cpu frequencies as expected. Armbianmonitor -m always displays a maximum of 200MHz as the current cpu frequency: root@espressobin:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq 15:26:36: 200MHz 0.16 13% 3% 9% 0% 0% 0% 15:26:41: 0MHz 0.14 13% 3% 9% 0% 0% 0% 15:26:46: 200MHz 0.13 13% 3% 9% 0% 0% 0% 15:26:51: 200MHz 0.20 13% 3% 9% 0% 0% 0% 15:26:56: 0MHz 0.39 14% 3% 9% 0% 0% 1% 15:27:01: 0MHz 0.36 14% 3% 9% 0% 0% 1% 15:27:07: 200MHz 0.41 14% 3% 9% 0% 0% 1% 15:27:12: 200MHz 0.38 14% 3% 9% 0% 0% 1% 15:27:17: 200MHz 0.35 14% 3% 9% 0% 0% 1% 15:27:22: 0MHz 0.32 14% 3% 9% 0% 0% 1% 15:27:27: 200MHz 0.29 14% 3% 8% 0% 0% 1% 15:27:32: 200MHz 0.27 14% 3% 8% 0% 0% 1% Manually setting the frequency of both cpus to 1GHz leads to expected results of iperf3: root@espressobin:~# cpufreq-set -c 1 -d 1000000 -u 1000000 -g performance root@espressobin:~# cpufreq-set -c 0 -d 1000000 -u 1000000 -g performance root@espressobin:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq 15:38:48: 1000MHz 0.15 8% 2% 3% 0% 0% 1% 15:38:53: 1000MHz 0.13 8% 2% 3% 0% 0% 1% 15:38:58: 1000MHz 0.12 7% 2% 3% 0% 0% 1% 15:39:04: 1000MHz 0.19 8% 2% 3% 0% 0% 1% 15:39:09: 1000MHz 0.26 8% 2% 3% 0% 0% 1% 15:39:14: 1000MHz 0.24 8% 2% 3% 0% 0% 1% MacBookPro: admin$ iperf3 -c 192.168.240.42 Connecting to host 192.168.240.42, port 5201 [ 4] local 192.168.240.41 port 49642 connected to 192.168.240.42 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 73.5 MBytes 616 Mbits/sec [ 4] 1.00-2.00 sec 110 MBytes 920 Mbits/sec [ 4] 2.00-3.00 sec 108 MBytes 904 Mbits/sec [ 4] 3.00-4.00 sec 105 MBytes 881 Mbits/sec [ 4] 4.00-5.00 sec 105 MBytes 881 Mbits/sec [ 4] 5.00-6.00 sec 104 MBytes 874 Mbits/sec [ 4] 6.00-7.00 sec 106 MBytes 885 Mbits/sec [ 4] 7.00-8.00 sec 106 MBytes 885 Mbits/sec [ 4] 8.00-9.00 sec 106 MBytes 886 Mbits/sec [ 4] 9.00-10.00 sec 103 MBytes 867 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 1.00 GBytes 860 Mbits/sec sender [ 4] 0.00-10.00 sec 1.00 GBytes 860 Mbits/sec receiver iperf Done. MacBookPro: admin$ iperf3 -R -c 192.168.240.42 Connecting to host 192.168.240.42, port 5201 Reverse mode, remote host 192.168.240.42 is sending [ 4] local 192.168.240.41 port 49645 connected to 192.168.240.42 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 111 MBytes 933 Mbits/sec [ 4] 1.00-2.00 sec 112 MBytes 936 Mbits/sec [ 4] 2.00-3.00 sec 112 MBytes 937 Mbits/sec [ 4] 3.00-4.00 sec 112 MBytes 937 Mbits/sec [ 4] 4.00-5.00 sec 112 MBytes 937 Mbits/sec [ 4] 5.00-6.00 sec 112 MBytes 937 Mbits/sec [ 4] 6.00-7.00 sec 112 MBytes 937 Mbits/sec [ 4] 7.00-8.00 sec 112 MBytes 936 Mbits/sec [ 4] 8.00-9.00 sec 112 MBytes 936 Mbits/sec [ 4] 9.00-10.00 sec 112 MBytes 937 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 1.09 GBytes 936 Mbits/sec receiver iperf Done. 1 Quote Link to comment Share on other sites More sharing options...
tkaiser Posted July 22, 2017 Share Posted July 22, 2017 19 minutes ago, lupus said: The puzzle seems to be solved - the ondemand governor does not scale up the cpu frequencies as expected. Can you please check contents of /etc/init.d/armhwinfo for this: https://github.com/armbian/build/blob/4e04879249361f7f38117b82a12d1cf0c4969306/packages/bsp/armhwinfo#L90-L102 I moved this just recently from Armbian's OMV installation routine to armhwinfo so it might not be active on any image so far. It would be great if you can check. If it's not active then activate this manually and then repost results of iperf3 and LanTest benchmarks. Thank you! 0 Quote Link to comment Share on other sites More sharing options...
lupus Posted July 22, 2017 Share Posted July 22, 2017 18 minutes ago, tkaiser said: Can you please check contents of /etc/init.d/armhwinfo for this: https://github.com/armbian/build/blob/4e04879249361f7f38117b82a12d1cf0c4969306/packages/bsp/armhwinfo#L90-L102 I moved this just recently from Armbian's OMV installation routine to armhwinfo so it might not be active on any image so far. It would be great if you can check. If it's not active then activate this manually and then repost results of iperf3 and LanTest benchmarks. Thank you! I have checked /etc/init.d/armhwinfo for your patch. It was not there so I copied it into armhwinfo. After a reboot the ondemand governor still does not scale up (see below) - I am currently compiling netatalk again, CPU freq is 200MHz and the load is up to 2.05 ... root@espressobin:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq 16:51:07: 200MHz 1.92 73% 8% 63% 0% 0% 0% 16:51:12: 200MHz 1.85 73% 8% 63% 0% 0% 0% 16:51:17: 200MHz 1.78 73% 8% 63% 0% 0% 0% 16:51:22: 200MHz 1.80 73% 8% 63% 0% 0% 0% 16:51:27: 200MHz 1.81 73% 8% 63% 0% 0% 0% 16:51:32: 200MHz 1.83 73% 8% 64% 0% 0% 0% 16:51:37: 200MHz 1.84 74% 8% 64% 0% 0% 0% 16:51:42: 200MHz 1.85 74% 8% 64% 0% 0% 0% 16:51:47: 200MHz 1.79 74% 8% 64% 0% 0% 0% 16:51:53: 200MHz 1.80 74% 8% 64% 0% 0% 0% 16:51:58: 200MHz 2.06 74% 8% 65% 0% 0% 0% 16:52:03: 200MHz 2.05 75% 8% 65% 0% 0% 0% 16:52:08: 200MHz 2.05 75% 8% 65% 0% 0% 0% 16:52:13: 200MHz 2.05 75% 8% 65% 0% 0% 0% 0 Quote Link to comment Share on other sites More sharing options...
tkaiser Posted July 22, 2017 Share Posted July 22, 2017 15 minutes ago, lupus said: After a reboot the ondemand governor still does not scale up (see below) I would say as expected if you ran at the same time just an iperf3 benchmark. But when a combined load like LanTest (or any real-world NAS access) happens ondemand should ramp up clockspeeds immediately. So what I wanted to see is shitty iperf numbers and great LanTest scores We always should remember that on these weak ARM boards some tuned settings only help with synthetic benchmarks while hurting real-world performance: See here my approach to 'tune' iperf scores on NanoPi M3 that are most probably counterproductive for real-world scenarios: https://forum.armbian.com/index.php?/topic/1285-nanopi-m3-cheap-8-core-35/&do=findComment&comment=14623 0 Quote Link to comment Share on other sites More sharing options...
lupus Posted July 22, 2017 Share Posted July 22, 2017 16 minutes ago, tkaiser said: I would say as expected if you ran at the same time just an iperf3 benchmark. But when a combined load like LanTest (or any real-world NAS access) happens ondemand should ramp up clockspeeds immediately. So what I wanted to see is shitty iperf numbers and great LanTest scores So after applying the patch to armhwinfo I get the following results (while running iperf3): root@espressobin:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq 17:32:29: 200MHz 0.13 16% 8% 3% 0% 1% 2% 17:32:34: 200MHz 0.12 16% 8% 3% 0% 1% 2% 17:32:40: 200MHz 0.11 16% 8% 3% 0% 1% 2% 17:32:45: 200MHz 0.18 16% 8% 3% 0% 1% 2% 17:32:50: 200MHz 0.17 16% 8% 3% 0% 1% 2% 17:32:55: 200MHz 0.15 16% 8% 3% 0% 1% 2% MacPro:~ admin$ iperf3 -c 192.168.240.42 Connecting to host 192.168.240.42, port 5201 [ 5] local 192.168.240.36 port 49665 connected to 192.168.240.42 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 4.91 MBytes 41.1 Mbits/sec [ 5] 1.00-2.00 sec 51.5 MBytes 432 Mbits/sec [ 5] 2.00-3.00 sec 62.2 MBytes 522 Mbits/sec [ 5] 3.00-4.00 sec 56.9 MBytes 478 Mbits/sec [ 5] 4.00-5.00 sec 45.5 MBytes 381 Mbits/sec [ 5] 5.00-6.00 sec 47.4 MBytes 398 Mbits/sec [ 5] 6.00-7.00 sec 52.0 MBytes 436 Mbits/sec [ 5] 7.00-8.00 sec 47.0 MBytes 394 Mbits/sec [ 5] 8.00-9.00 sec 46.0 MBytes 386 Mbits/sec [ 5] 9.00-10.00 sec 53.9 MBytes 452 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 467 MBytes 392 Mbits/sec sender [ 5] 0.00-10.00 sec 466 MBytes 391 Mbits/sec receiver iperf Done. MacPro:~ admin$ iperf3 -R -c 192.168.240.42 Connecting to host 192.168.240.42, port 5201 Reverse mode, remote host 192.168.240.42 is sending [ 5] local 192.168.240.36 port 49668 connected to 192.168.240.42 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 111 MBytes 933 Mbits/sec [ 5] 1.00-2.00 sec 111 MBytes 931 Mbits/sec [ 5] 2.00-3.00 sec 112 MBytes 937 Mbits/sec [ 5] 3.00-4.00 sec 112 MBytes 937 Mbits/sec [ 5] 4.00-5.00 sec 112 MBytes 937 Mbits/sec [ 5] 5.00-6.00 sec 112 MBytes 937 Mbits/sec [ 5] 6.00-7.00 sec 111 MBytes 934 Mbits/sec [ 5] 7.00-8.00 sec 111 MBytes 931 Mbits/sec [ 5] 8.00-9.00 sec 112 MBytes 937 Mbits/sec [ 5] 9.00-10.00 sec 112 MBytes 937 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 1.09 GBytes 935 Mbits/sec receiver iperf Done. Helios LanTest still produces low write speed in this context: Then I manually set CPU frequencies to 1GHz and obtained the following results (while running iperf3): root@espressobin:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq 17:39:51: 1000MHz 0.02 10% 5% 2% 0% 1% 1% 17:39:56: 1000MHz 0.02 10% 5% 2% 0% 1% 1% 17:40:01: 1000MHz 0.10 10% 5% 2% 0% 1% 1% 17:40:06: 1000MHz 0.17 10% 5% 2% 0% 1% 2% 17:40:11: 1000MHz 0.16 10% 5% 2% 0% 0% 2% 17:40:16: 1000MHz 0.14 10% 5% 2% 0% 0% 2% MacPro:~ admin$ iperf3 -c 192.168.240.42 Connecting to host 192.168.240.42, port 5201 [ 5] local 192.168.240.36 port 49684 connected to 192.168.240.42 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 74.6 MBytes 626 Mbits/sec [ 5] 1.00-2.00 sec 76.7 MBytes 643 Mbits/sec [ 5] 2.00-3.00 sec 79.5 MBytes 667 Mbits/sec [ 5] 3.00-4.00 sec 101 MBytes 850 Mbits/sec [ 5] 4.00-5.00 sec 108 MBytes 905 Mbits/sec [ 5] 5.00-6.00 sec 104 MBytes 871 Mbits/sec [ 5] 6.00-7.00 sec 102 MBytes 858 Mbits/sec [ 5] 7.00-8.00 sec 104 MBytes 873 Mbits/sec [ 5] 8.00-9.00 sec 102 MBytes 857 Mbits/sec [ 5] 9.00-10.00 sec 105 MBytes 883 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 958 MBytes 803 Mbits/sec sender [ 5] 0.00-10.00 sec 956 MBytes 802 Mbits/sec receiver iperf Done. MacPro:~ admin$ iperf3 -R -c 192.168.240.42 Connecting to host 192.168.240.42, port 5201 Reverse mode, remote host 192.168.240.42 is sending [ 5] local 192.168.240.36 port 49687 connected to 192.168.240.42 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 112 MBytes 936 Mbits/sec [ 5] 1.00-2.00 sec 111 MBytes 932 Mbits/sec [ 5] 2.00-3.00 sec 112 MBytes 937 Mbits/sec [ 5] 3.00-4.00 sec 111 MBytes 932 Mbits/sec [ 5] 4.00-5.00 sec 112 MBytes 937 Mbits/sec [ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec [ 5] 6.00-7.00 sec 112 MBytes 937 Mbits/sec [ 5] 7.00-8.00 sec 111 MBytes 930 Mbits/sec [ 5] 8.00-9.00 sec 112 MBytes 937 Mbits/sec [ 5] 9.00-10.00 sec 110 MBytes 926 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.09 GBytes 937 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 1.09 GBytes 937 Mbits/sec receiver iperf Done. In this context Helios LanTest results are also pretty nice ... 0 Quote Link to comment Share on other sites More sharing options...
lupus Posted July 22, 2017 Share Posted July 22, 2017 4 hours ago, tkaiser said: I would say as expected if you ran at the same time just an iperf3 benchmark. But when a combined load like LanTest (or any real-world NAS access) happens ondemand should ramp up clockspeeds immediately. So what I wanted to see is shitty iperf numbers and great LanTest scores Unfortunately the ondemand tweak does not ramp up clockspeeds upon heavy loads. Please find below the armbianmonitor -m output collected during the Helios LanTest (also attached below): root@espressobin:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq 21:32:57: 200MHz 0.07 9% 5% 2% 0% 0% 0% 21:33:02: 200MHz 0.07 9% 5% 2% 0% 0% 0% 21:33:07: 0MHz 0.06 9% 5% 2% 0% 0% 0% 21:33:12: 0MHz 0.06 9% 5% 2% 0% 0% 0% 21:33:18: 200MHz 0.05 9% 5% 2% 0% 0% 0% 21:33:23: 200MHz 0.13 9% 5% 2% 0% 0% 0% 21:33:28: 200MHz 0.12 9% 5% 2% 0% 0% 1% 21:33:33: 200MHz 0.11 9% 5% 2% 0% 0% 1% 21:33:38: 200MHz 0.10 10% 5% 2% 0% 0% 1% 21:33:43: 200MHz 0.09 10% 6% 2% 0% 0% 1% 21:33:48: 200MHz 0.24 10% 6% 2% 0% 0% 1% 21:33:53: 200MHz 0.30 10% 6% 2% 0% 0% 1% 21:33:59: 200MHz 0.44 10% 6% 2% 0% 0% 1% 21:34:04: 200MHz 0.41 11% 6% 2% 0% 0% 1% Time CPU load %cpu %sys %usr %nice %io %irq 21:34:09: 200MHz 0.85 11% 6% 2% 0% 0% 1% 21:34:14: 0MHz 0.79 11% 6% 2% 0% 0% 1% 21:34:19: 200MHz 0.80 11% 7% 2% 0% 0% 1% 21:34:24: 200MHz 0.74 11% 7% 2% 0% 0% 1% 21:34:29: 200MHz 0.76 11% 7% 2% 0% 0% 1% 21:34:35: 200MHz 0.70 12% 7% 2% 0% 0% 1% 21:34:40: 200MHz 0.80 12% 7% 2% 0% 0% 1% 21:34:45: 200MHz 0.82 12% 7% 2% 0% 0% 1% 21:34:50: 200MHz 0.83 12% 7% 2% 0% 0% 1% 21:34:55: 200MHz 0.85 13% 8% 2% 0% 0% 2% 21:35:00: 200MHz 0.86 13% 8% 2% 0% 0% 2% 21:35:05: 200MHz 0.87 13% 8% 2% 0% 0% 2% 21:35:10: 200MHz 0.96 13% 8% 2% 0% 0% 2% 21:35:16: 200MHz 0.97 13% 8% 2% 0% 0% 2% 21:35:21: 200MHz 0.89 13% 8% 2% 0% 0% 2% Time CPU load %cpu %sys %usr %nice %io %irq 21:35:26: 200MHz 0.90 13% 8% 2% 0% 0% 2% 21:35:31: 200MHz 0.82 13% 8% 2% 0% 0% 2% 21:35:36: 200MHz 0.84 13% 8% 2% 0% 0% 2% 21:35:41: 200MHz 0.85 14% 8% 2% 0% 0% 2% 21:35:46: 200MHz 0.86 14% 8% 2% 0% 0% 2% 0 Quote Link to comment Share on other sites More sharing options...
tkaiser Posted July 23, 2017 Share Posted July 23, 2017 @lupusThanks a lot for the detailled and correct testing. Currently the lowest allowed clockspeed in /etc/defaults/cpufrequtils is just 200 MHz. It would be interesting to lift this to 400 or even 500 MHz there (I'm too lazy to search for but with ASUS Tinkerboard default cpufreq settings allowed the board to downclock to 126MHz which totally destroys IO performance with ondemand governor, lifting it to 600 MHz allowed the ondemand algorithm working way better). But no need to rush. I ordered an ESPRESSOBin myself which might get shipped soon to do some performance/consumption testing (I wouldn't expect a noticeable difference in idle consumption when increasing min cpufreq from 200 MHz to 400 MHz --> since I read all the time about DFS and not DVFS maybe there isn't any difference in consumption at all) Edit: Found Tinkerboard link: https://tinkerboarding.co.uk/forum/thread-310.html 0 Quote Link to comment Share on other sites More sharing options...
lupus Posted July 23, 2017 Share Posted July 23, 2017 2 hours ago, tkaiser said: @lupusThanks a lot for the detailled and correct testing. Currently the lowest allowed clockspeed in /etc/defaults/cpufrequtils is just 200 MHz. It would be interesting to lift this to 400 or even 500 MHz there (I'm too lazy to search for but with ASUS Tinkerboard default cpufreq settings allowed the board to downclock to 126MHz which totally destroys IO performance with ondemand governor, lifting it to 600 MHz allowed the ondemand algorithm working way better). There are only specific frequencies supported with the current system: root@espressobin:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 200000 250000 500000 1000000 However, cpufrequtils is currently configured to use another maximum value: root@espressobin:~# cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=200000 MAX_SPEED=800000 GOVERNOR=ondemand I have changed MAX_SPEED to 1000000 but unfortunately espressobin does not boot reliably anymore (crashes upon login). 2 hours ago, tkaiser said: I ordered an ESPRESSOBin myself which might get shipped soon I have received my order of 10 espressobin this week ($49 each plus shipping) - I still have 7 to give away for the price I have paid. I have sent to you a PM with my contact details in any case ... 1 Quote Link to comment Share on other sites More sharing options...
lupus Posted July 23, 2017 Share Posted July 23, 2017 Workaround (as suggested by tkaiser): I stored the following two lines in /etc/rc.local - after a reboot ondemand governor switches between 200MHz (!) and 1GHz depending on system load: cpufreq-set -c 0 -d 500000 -u 1000000 -g ondemand cpufreq-set -c 1 -d 500000 -u 1000000 -g ondemand root@espressobin:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq 11:12:27: 1000MHz 0.43 32% 10% 19% 0% 3% 0% 11:12:32: 200MHz 0.40 29% 9% 17% 0% 2% 0% 11:12:37: 200MHz 0.37 27% 8% 16% 0% 2% 0% 11:12:42: 200MHz 0.34 25% 8% 14% 0% 2% 0% 11:12:47: 200MHz 0.31 24% 7% 14% 0% 2% 0% 11:12:52: 200MHz 0.28 22% 7% 13% 0% 2% 0% 11:12:57: 200MHz 0.26 21% 6% 12% 0% 1% 0% 11:13:02: 200MHz 0.24 20% 6% 11% 0% 1% 0% 11:13:07: 1000MHz 0.22 19% 6% 11% 0% 1% 0% 11:13:12: 1000MHz 0.20 19% 6% 10% 0% 1% 0% 11:13:17: 200MHz 0.19 18% 6% 10% 0% 1% 0% 11:13:22: 200MHz 0.17 17% 6% 9% 0% 1% 0% 11:13:27: 200MHz 0.16 16% 5% 9% 0% 1% 0% 11:13:32: 200MHz 0.14 15% 5% 8% 0% 1% 0% iperf3 results are now both fine: MacBookPro:~ lupus$ iperf3 -c 192.168.240.42 Connecting to host 192.168.240.42, port 5201 [ 4] local 192.168.240.41 port 58907 connected to 192.168.240.42 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 68.9 MBytes 578 Mbits/sec [ 4] 1.00-2.00 sec 103 MBytes 862 Mbits/sec [ 4] 2.00-3.00 sec 105 MBytes 882 Mbits/sec [ 4] 3.00-4.00 sec 104 MBytes 876 Mbits/sec [ 4] 4.00-5.00 sec 102 MBytes 851 Mbits/sec [ 4] 5.00-6.00 sec 106 MBytes 892 Mbits/sec [ 4] 6.00-7.00 sec 102 MBytes 860 Mbits/sec [ 4] 7.00-8.00 sec 106 MBytes 892 Mbits/sec [ 4] 8.00-9.00 sec 105 MBytes 882 Mbits/sec [ 4] 9.00-10.00 sec 104 MBytes 876 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 1007 MBytes 845 Mbits/sec sender [ 4] 0.00-10.00 sec 1004 MBytes 842 Mbits/sec receiver iperf Done. MacBookPro:~ lupus$ iperf3 -R -c 192.168.240.42 Connecting to host 192.168.240.42, port 5201 Reverse mode, remote host 192.168.240.42 is sending [ 4] local 192.168.240.41 port 58911 connected to 192.168.240.42 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 111 MBytes 933 Mbits/sec [ 4] 1.00-2.00 sec 111 MBytes 932 Mbits/sec [ 4] 2.00-3.00 sec 112 MBytes 937 Mbits/sec [ 4] 3.00-4.00 sec 112 MBytes 937 Mbits/sec [ 4] 4.00-5.00 sec 112 MBytes 936 Mbits/sec [ 4] 5.00-6.00 sec 112 MBytes 937 Mbits/sec [ 4] 6.00-7.00 sec 112 MBytes 936 Mbits/sec [ 4] 7.00-8.00 sec 112 MBytes 936 Mbits/sec [ 4] 8.00-9.00 sec 112 MBytes 936 Mbits/sec [ 4] 9.00-10.00 sec 111 MBytes 935 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec receiver iperf Done. Helios LanTest write performance is good too: 0 Quote Link to comment Share on other sites More sharing options...
tkaiser Posted July 23, 2017 Share Posted July 23, 2017 2 hours ago, lupus said: Workaround (as suggested by tkaiser): I stored the following two lines in /etc/rc.local Hmm... usually cpufreq settings in /etc/rc.local don't stick since cpufrequtils gets called seconds later. Strange. Anyway, you have an email. 0 Quote Link to comment Share on other sites More sharing options...
tkaiser Posted July 24, 2017 Share Posted July 24, 2017 Thanks to @lupus I don't have to wait for Amazon shipping my board since one is already on my desk. Firtst surprise: my ASM1062 in the background can not be used due to SATA connector placement. So then I'm going to test AP functionality instead with a AR9380 3x3 MIMO Wi-Fi mPCIe card ($9 on eBay) 2 Quote Link to comment Share on other sites More sharing options...
Igor Posted July 24, 2017 Share Posted July 24, 2017 44 minutes ago, tkaiser said: my ASM1062 in the background can not be used due to SATA connector placement. So then I'm going to test AP functionality instead with a AR9380 3x3 MIMO Wi-Fi mPCIe card ($9 on eBay) 2 I am getting this one and can do some testing. Not that fast as you got your espresso Last time I was testing, there was no sign of PCI bus except in U-boot. Still, haven't tried with 4.12 0 Quote Link to comment Share on other sites More sharing options...
tkaiser Posted July 24, 2017 Share Posted July 24, 2017 3 minutes ago, Igor said: I am getting this one and can do some testing. Seems also Marvell 88SE9215 based -- then multi disk performance should be ok. With ASM1062 some tweaks might be needed (wanted to test this but will move back to Clearfog Pro then since there I can connect 2 SATA SSDs to ASM1062). 7 minutes ago, Igor said: Still, haven't tried with 4.12 I wanted to try out 4.13-rc2 (@umiddelb updated already) but fail already with u-boot: /var/syslog-ng/Armbian/sources/u-boot/v2017.07/lib/libfdt/pylibfdt/setup.py --quiet build_ext \ --build-lib tools LD arch/arm/cpu/built-in.o CC arch/arm/cpu/armv8/cpu.o as: unrecognized option '-EL' scripts/Makefile.build:280: recipe for target 'arch/arm/cpu/armv8/cpu.o' failed make[1]: *** [arch/arm/cpu/armv8/cpu.o] Error 2 Makefile:1257: recipe for target 'arch/arm/cpu/armv8' failed make: *** [arch/arm/cpu/armv8] Error 2 [ error ] ERROR in function compile_uboot [ common.sh:97 ] [ error ] U-boot compilation failed 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted July 24, 2017 Share Posted July 24, 2017 7 minutes ago, tkaiser said: I wanted to try out 4.13-rc2 (@umiddelb updated already) but fail already with u-boot: U-boot is being used the one from SPI (boot from SD is not possible AFAIK) and we don't update it so it's pointless to build it. Do some workaround to skip u-boot or fake u-boot building. Edit: will add useful technical conversation with Marvell later. 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted July 24, 2017 Share Posted July 24, 2017 Useful info from an email conversation with Marvell and some of my efforts: ATF compile by the wiki guide: Spoiler git clone https://github.com/MarvellEmbeddedProcessors/atf-marvell -b atf-v1.3-armada-17.06 cd atf-marvell export CROSS_COMPILE=/development/toolchains/gcc-linaro-4.9.4-2017.01-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu- export BL33=/development/sources/u-boot-espressobin/u-boot-2017.03-armada-17.06/u-boot.bin make distclean make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 CLOCKSPRESET=CPU_1000_DDR_800 DDR_TOPOLOGY=2 BOOTDEV=EMMCNORM PARTNUM=0 PLAT=a3700 all fip DEPS build/a3700/debug/bl31/marvell_helpers.d DEPS build/a3700/debug/bl31/a3700_console.d DEPS build/a3700/debug/bl31/console.d DEPS build/a3700/debug/bl31/platform_helpers.d DEPS build/a3700/debug/bl31/misc_helpers.d DEPS build/a3700/debug/bl31/cache_helpers.d DEPS build/a3700/debug/bl31/debug.d DEPS build/a3700/debug/bl31/context.d DEPS build/a3700/debug/bl31/psci_helpers.d DEPS build/a3700/debug/bl31/spinlock.d DEPS build/a3700/debug/bl31/cpu_helpers.d DEPS build/a3700/debug/bl31/cpu_data.d DEPS build/a3700/debug/bl31/crash_reporting.d DEPS build/a3700/debug/bl31/runtime_exceptions.d DEPS build/a3700/debug/bl31/bl31_entrypoint.d DEPS build/a3700/debug/bl31/platform_mp_stack.d DEPS build/a3700/debug/bl31/plat_helpers.d DEPS build/a3700/debug/bl31/cortex_a53.d DEPS build/a3700/debug/bl31/plat_common.d DEPS build/a3700/debug/bl31/marvell_common.d DEPS build/a3700/debug/bl31/xlat_tables.d DEPS build/a3700/debug/bl31/xlat_tables_common.d DEPS build/a3700/debug/bl31/marvell_cci.d DEPS build/a3700/debug/bl31/a3700_common.d DEPS build/a3700/debug/bl31/subr_prf.d DEPS build/a3700/debug/bl31/strncmp.d DEPS build/a3700/debug/bl31/strlen.d DEPS build/a3700/debug/bl31/strcmp.d DEPS build/a3700/debug/bl31/strchr.d DEPS build/a3700/debug/bl31/sscanf.d DEPS build/a3700/debug/bl31/puts.d DEPS build/a3700/debug/bl31/putchar.d DEPS build/a3700/debug/bl31/printf.d DEPS build/a3700/debug/bl31/mem.d DEPS build/a3700/debug/bl31/exit.d DEPS build/a3700/debug/bl31/assert.d DEPS build/a3700/debug/bl31/abort.d DEPS build/a3700/debug/bl31/tf_printf.d DEPS build/a3700/debug/bl31/bl_common.d DEPS build/a3700/debug/bl31/bakery_lock_normal.d DEPS build/a3700/debug/bl31/psci_system_off.d DEPS build/a3700/debug/bl31/psci_setup.d DEPS build/a3700/debug/bl31/psci_main.d DEPS build/a3700/debug/bl31/psci_common.d DEPS build/a3700/debug/bl31/psci_suspend.d DEPS build/a3700/debug/bl31/psci_on.d DEPS build/a3700/debug/bl31/psci_off.d DEPS build/a3700/debug/bl31/context_mgmt.d DEPS build/a3700/debug/bl31/cpu_data_array.d DEPS build/a3700/debug/bl31/std_svc_setup.d DEPS build/a3700/debug/bl31/runtime_svc.d DEPS build/a3700/debug/bl31/bl31_context_mgmt.d DEPS build/a3700/debug/bl31/interrupt_mgmt.d DEPS build/a3700/debug/bl31/bl31_main.d DEPS build/a3700/debug/bl31/delay_timer.d DEPS build/a3700/debug/bl31/plat_delay_timer.d DEPS build/a3700/debug/bl31/plat_psci_common.d DEPS build/a3700/debug/bl31/marvell_topology.d DEPS build/a3700/debug/bl31/marvell_pm.d DEPS build/a3700/debug/bl31/marvell_bl31_setup.d DEPS build/a3700/debug/bl31/pm_src.d DEPS build/a3700/debug/bl31/cci.d DEPS build/a3700/debug/bl31/plat_gicv3.d DEPS build/a3700/debug/bl31/gicv3_helpers.d DEPS build/a3700/debug/bl31/gicv3_main.d DEPS build/a3700/debug/bl31/gic_common.d DEPS build/a3700/debug/bl31/marvell_gicv3.d DEPS build/a3700/debug/bl31/sys_info.d DEPS build/a3700/debug/bl31/plat_bl31_setup.d DEPS build/a3700/debug/bl31/marvell_plat_config.d DEPS build/a3700/debug/bl31/io_addr_dec.d DEPS build/a3700/debug/bl31/dram_win.d DEPS build/a3700/debug/bl31/a3700_dram_cs.d DEPS build/a3700/debug/bl31/plat_pm.d DEPS build/a3700/debug/bl2/marvell_helpers.d DEPS build/a3700/debug/bl2/a3700_console.d DEPS build/a3700/debug/bl2/console.d DEPS build/a3700/debug/bl2/platform_helpers.d DEPS build/a3700/debug/bl2/misc_helpers.d DEPS build/a3700/debug/bl2/cache_helpers.d DEPS build/a3700/debug/bl2/debug.d DEPS build/a3700/debug/bl2/early_exceptions.d DEPS build/a3700/debug/bl2/spinlock.d DEPS build/a3700/debug/bl2/bl2_entrypoint.d DEPS build/a3700/debug/bl2/platform_up_stack.d DEPS build/a3700/debug/bl2/plat_common.d DEPS build/a3700/debug/bl2/marvell_common.d DEPS build/a3700/debug/bl2/xlat_tables.d DEPS build/a3700/debug/bl2/xlat_tables_common.d DEPS build/a3700/debug/bl2/marvell_cci.d DEPS build/a3700/debug/bl2/a3700_common.d DEPS build/a3700/debug/bl2/subr_prf.d DEPS build/a3700/debug/bl2/strncmp.d DEPS build/a3700/debug/bl2/strlen.d DEPS build/a3700/debug/bl2/strcmp.d DEPS build/a3700/debug/bl2/strchr.d DEPS build/a3700/debug/bl2/sscanf.d DEPS build/a3700/debug/bl2/puts.d DEPS build/a3700/debug/bl2/putchar.d DEPS build/a3700/debug/bl2/printf.d DEPS build/a3700/debug/bl2/mem.d DEPS build/a3700/debug/bl2/exit.d DEPS build/a3700/debug/bl2/assert.d DEPS build/a3700/debug/bl2/abort.d DEPS build/a3700/debug/bl2/tf_printf.d DEPS build/a3700/debug/bl2/bl_common.d DEPS build/a3700/debug/bl2/bl2_image_load.d DEPS build/a3700/debug/bl2/bl2_arch_setup.d DEPS build/a3700/debug/bl2/bl2_main.d DEPS build/a3700/debug/bl2/marvell_io_storage.d DEPS build/a3700/debug/bl2/marvell_bl2_setup.d DEPS build/a3700/debug/bl2/io_storage.d DEPS build/a3700/debug/bl2/io_memmap.d DEPS build/a3700/debug/bl2/io_fip.d DEPS build/a3700/debug/bl1/marvell_helpers.d DEPS build/a3700/debug/bl1/a3700_console.d DEPS build/a3700/debug/bl1/console.d DEPS build/a3700/debug/bl1/platform_helpers.d DEPS build/a3700/debug/bl1/misc_helpers.d DEPS build/a3700/debug/bl1/cache_helpers.d DEPS build/a3700/debug/bl1/debug.d DEPS build/a3700/debug/bl1/context.d DEPS build/a3700/debug/bl1/cpu_helpers.d DEPS build/a3700/debug/bl1/bl1_exceptions.d DEPS build/a3700/debug/bl1/bl1_entrypoint.d DEPS build/a3700/debug/bl1/platform_up_stack.d DEPS build/a3700/debug/bl1/cortex_a53.d DEPS build/a3700/debug/bl1/plat_helpers.d DEPS build/a3700/debug/bl1/plat_common.d DEPS build/a3700/debug/bl1/marvell_common.d DEPS build/a3700/debug/bl1/xlat_tables.d DEPS build/a3700/debug/bl1/xlat_tables_common.d DEPS build/a3700/debug/bl1/marvell_cci.d DEPS build/a3700/debug/bl1/a3700_common.d DEPS build/a3700/debug/bl1/subr_prf.d DEPS build/a3700/debug/bl1/strncmp.d DEPS build/a3700/debug/bl1/strlen.d DEPS build/a3700/debug/bl1/strcmp.d DEPS build/a3700/debug/bl1/strchr.d DEPS build/a3700/debug/bl1/sscanf.d DEPS build/a3700/debug/bl1/puts.d DEPS build/a3700/debug/bl1/putchar.d DEPS build/a3700/debug/bl1/printf.d DEPS build/a3700/debug/bl1/mem.d DEPS build/a3700/debug/bl1/exit.d DEPS build/a3700/debug/bl1/assert.d DEPS build/a3700/debug/bl1/abort.d DEPS build/a3700/debug/bl1/tf_printf.d DEPS build/a3700/debug/bl1/bl_common.d DEPS build/a3700/debug/bl1/plat_bl1_common.d DEPS build/a3700/debug/bl1/context_mgmt.d DEPS build/a3700/debug/bl1/bl1_context_mgmt.d DEPS build/a3700/debug/bl1/bl1_arch_setup.d DEPS build/a3700/debug/bl1/bl1_main.d DEPS build/a3700/debug/bl1/marvell_io_storage.d DEPS build/a3700/debug/bl1/marvell_bl1_setup.d DEPS build/a3700/debug/bl1/io_storage.d DEPS build/a3700/debug/bl1/io_memmap.d DEPS build/a3700/debug/bl1/io_fip.d DEPS build/a3700/debug/bl31/bl31.ld.d DEPS build/a3700/debug/bl2/bl2.ld.d DEPS build/a3700/debug/bl1/bl1.ld.d Building a3700 CC drivers/io/io_fip.c CC drivers/io/io_memmap.c CC drivers/io/io_storage.c CC plat/marvell/common/marvell_bl1_setup.c CC plat/marvell/common/marvell_io_storage.c CC bl1/bl1_main.c CC bl1/aarch64/bl1_arch_setup.c CC bl1/aarch64/bl1_context_mgmt.c CC lib/el3_runtime/aarch64/context_mgmt.c CC plat/common/plat_bl1_common.c CC common/bl_common.c CC common/tf_printf.c CC lib/stdlib/abort.c CC lib/stdlib/assert.c CC lib/stdlib/exit.c CC lib/stdlib/mem.c CC lib/stdlib/printf.c CC lib/stdlib/putchar.c CC lib/stdlib/puts.c CC lib/stdlib/sscanf.c CC lib/stdlib/strchr.c CC lib/stdlib/strcmp.c CC lib/stdlib/strlen.c CC lib/stdlib/strncmp.c CC lib/stdlib/subr_prf.c CC plat/marvell/a3700/common/aarch64/a3700_common.c CC plat/marvell/common/marvell_cci.c CC lib/xlat_tables/xlat_tables_common.c CC lib/xlat_tables/aarch64/xlat_tables.c CC plat/marvell/common/aarch64/marvell_common.c CC plat/common/aarch64/plat_common.c AS plat/marvell/a3700/common/aarch64/plat_helpers.S AS lib/cpus/aarch64/cortex_a53.S AS plat/common/aarch64/platform_up_stack.S AS bl1/aarch64/bl1_entrypoint.S AS bl1/aarch64/bl1_exceptions.S AS lib/cpus/aarch64/cpu_helpers.S AS lib/el3_runtime/aarch64/context.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/console/aarch64/console.S AS drivers/marvell/uart/a3700_console.S AS plat/marvell/common/aarch64/marvell_helpers.S PP bl1/bl1.ld.S LD build/a3700/debug/bl1/bl1.elf BIN build/a3700/debug/bl1.bin Built build/a3700/debug/bl1.bin successfully OD build/a3700/debug/bl1/bl1.dump CC drivers/io/io_fip.c CC drivers/io/io_memmap.c CC drivers/io/io_storage.c CC plat/marvell/common/marvell_bl2_setup.c CC plat/marvell/common/marvell_io_storage.c CC bl2/bl2_main.c CC bl2/aarch64/bl2_arch_setup.c CC bl2/bl2_image_load.c CC common/bl_common.c CC common/tf_printf.c CC lib/stdlib/abort.c CC lib/stdlib/assert.c CC lib/stdlib/exit.c CC lib/stdlib/mem.c CC lib/stdlib/printf.c CC lib/stdlib/putchar.c CC lib/stdlib/puts.c CC lib/stdlib/sscanf.c CC lib/stdlib/strchr.c CC lib/stdlib/strcmp.c CC lib/stdlib/strlen.c CC lib/stdlib/strncmp.c CC lib/stdlib/subr_prf.c CC plat/marvell/a3700/common/aarch64/a3700_common.c CC plat/marvell/common/marvell_cci.c CC lib/xlat_tables/xlat_tables_common.c CC lib/xlat_tables/aarch64/xlat_tables.c CC plat/marvell/common/aarch64/marvell_common.c CC plat/common/aarch64/plat_common.c AS plat/common/aarch64/platform_up_stack.S AS bl2/aarch64/bl2_entrypoint.S AS lib/locks/exclusive/aarch64/spinlock.S AS common/aarch64/early_exceptions.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/console/aarch64/console.S AS drivers/marvell/uart/a3700_console.S AS plat/marvell/common/aarch64/marvell_helpers.S PP bl2/bl2.ld.S LD build/a3700/debug/bl2/bl2.elf BIN build/a3700/debug/bl2.bin Built build/a3700/debug/bl2.bin successfully OD build/a3700/debug/bl2/bl2.dump CC plat/marvell/a3700/common/plat_pm.c CC plat/marvell/a3700/common/a3700_dram_cs.c CC plat/marvell/a3700/common/dram_win.c CC plat/marvell/a3700/common/io_addr_dec.c CC plat/marvell/a3700/common/marvell_plat_config.c CC plat/marvell/a3700/a3700/plat_bl31_setup.c CC plat/marvell/common/sys_info.c CC plat/marvell/common/marvell_gicv3.c CC drivers/arm/gic/common/gic_common.c CC drivers/arm/gic/v3/gicv3_main.c CC drivers/arm/gic/v3/gicv3_helpers.c CC plat/common/plat_gicv3.c CC drivers/arm/cci/cci.c CC plat/marvell/a3700/a3700/board/pm_src.c CC plat/marvell/common/marvell_bl31_setup.c CC plat/marvell/common/marvell_pm.c CC plat/marvell/common/marvell_topology.c CC plat/common/plat_psci_common.c CC plat/marvell/common/plat_delay_timer.c CC drivers/delay_timer/delay_timer.c CC bl31/bl31_main.c CC bl31/interrupt_mgmt.c CC bl31/bl31_context_mgmt.c CC common/runtime_svc.c CC services/std_svc/std_svc_setup.c CC lib/el3_runtime/cpu_data_array.c CC lib/el3_runtime/aarch64/context_mgmt.c CC lib/psci/psci_off.c CC lib/psci/psci_on.c CC lib/psci/psci_suspend.c CC lib/psci/psci_common.c CC lib/psci/psci_main.c CC lib/psci/psci_setup.c CC lib/psci/psci_system_off.c CC lib/locks/bakery/bakery_lock_normal.c CC common/bl_common.c CC common/tf_printf.c CC lib/stdlib/abort.c CC lib/stdlib/assert.c CC lib/stdlib/exit.c CC lib/stdlib/mem.c CC lib/stdlib/printf.c CC lib/stdlib/putchar.c CC lib/stdlib/puts.c CC lib/stdlib/sscanf.c CC lib/stdlib/strchr.c CC lib/stdlib/strcmp.c CC lib/stdlib/strlen.c CC lib/stdlib/strncmp.c CC lib/stdlib/subr_prf.c CC plat/marvell/a3700/common/aarch64/a3700_common.c CC plat/marvell/common/marvell_cci.c CC lib/xlat_tables/xlat_tables_common.c CC lib/xlat_tables/aarch64/xlat_tables.c CC plat/marvell/common/aarch64/marvell_common.c CC plat/common/aarch64/plat_common.c AS lib/cpus/aarch64/cortex_a53.S AS plat/marvell/a3700/common/aarch64/plat_helpers.S AS plat/common/aarch64/platform_mp_stack.S AS bl31/aarch64/bl31_entrypoint.S AS bl31/aarch64/runtime_exceptions.S AS bl31/aarch64/crash_reporting.S AS lib/el3_runtime/aarch64/cpu_data.S AS lib/cpus/aarch64/cpu_helpers.S AS lib/locks/exclusive/aarch64/spinlock.S AS lib/psci/aarch64/psci_helpers.S AS lib/el3_runtime/aarch64/context.S AS common/aarch64/debug.S AS lib/aarch64/cache_helpers.S AS lib/aarch64/misc_helpers.S AS plat/common/aarch64/platform_helpers.S AS drivers/console/aarch64/console.S AS drivers/marvell/uart/a3700_console.S AS plat/marvell/common/aarch64/marvell_helpers.S PP bl31/bl31.ld.S LD build/a3700/debug/bl31/bl31.elf BIN build/a3700/debug/bl31.bin Built build/a3700/debug/bl31.bin successfully OD build/a3700/debug/bl31/bl31.dump CC fiptool.c CC tbbr_config.c LD fiptool Built fiptool successfully Trusted Boot Firmware BL2: offset=0xB0, size=0x4008, cmdline="--tb-fw" EL3 Runtime Firmware BL31: offset=0x40B8, size=0xA2A0, cmdline="--soc-fw" Non-Trusted Firmware BL33: offset=0xE358, size=0x865CA, cmdline="--nt-fw" Built build/a3700/debug/fip.bin successfully make: option requires an argument -- 'C' Usage: make [options] [target] ... Options: -b, -m Ignored for compatibility. -B, --always-make Unconditionally make all targets. -C DIRECTORY, --directory=DIRECTORY Change to DIRECTORY before doing anything. -d Print lots of debugging information. --debug[=FLAGS] Print various types of debugging information. -e, --environment-overrides Environment variables override makefiles. --eval=STRING Evaluate STRING as a makefile statement. -f FILE, --file=FILE, --makefile=FILE Read FILE as a makefile. -h, --help Print this message and exit. -i, --ignore-errors Ignore errors from recipes. -I DIRECTORY, --include-dir=DIRECTORY Search DIRECTORY for included makefiles. -j [N], --jobs[=N] Allow N jobs at once; infinite jobs with no arg. -k, --keep-going Keep going when some targets can't be made. -l [N], --load-average[=N], --max-load[=N] Don't start multiple jobs unless load is below N. -L, --check-symlink-times Use the latest mtime between symlinks and target. -n, --just-print, --dry-run, --recon Don't actually run any recipe; just print them. -o FILE, --old-file=FILE, --assume-old=FILE Consider FILE to be very old and don't remake it. -O[TYPE], --output-sync[=TYPE] Synchronize output of parallel jobs by TYPE. -p, --print-data-base Print make's internal database. -q, --question Run no recipe; exit status says if up to date. -r, --no-builtin-rules Disable the built-in implicit rules. -R, --no-builtin-variables Disable the built-in variable settings. -s, --silent, --quiet Don't echo recipes. -S, --no-keep-going, --stop Turns off -k. -t, --touch Touch targets instead of remaking them. --trace Print tracing information. -v, --version Print the version number of make and exit. -w, --print-directory Print the current directory. --no-print-directory Turn off -w, even if it was turned on implicitly. -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE Consider FILE to be infinitely new. --warn-undefined-variables Warn when an undefined variable is referenced. This program built for x86_64-pc-linux-gnu Report bugs to <bug-make@gnu.org> Makefile:889: recipe for target '/wtptp_tool/linux/TBB_linux' failed make: *** [/wtptp_tool/linux/TBB_linux] Error 2 Quote This part: https://github.com/MarvellEmbeddedProcessors/atf-marvell/blob/atf-v1.3-17.04/docs/marvell/build.txt#L120 is a bit confusing. Where are those tools? I also didn't find - well didn't look very intense either - where to, on which locations to write those files to SD card? I want to achieve SD card booting first, than other methods ... Any tip what am I doing wrong will help to save some time. Thanks. Quote The tool is available at https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell , you may need to add one parameter WTP= /…/…/sources-a3700_utils-armada-17.06.1 to your make string to build the atf binary. I believe the ESPRESSOBin does not support to load the bootloader binary from SD card, it can load bootloader binary from SPI/EMMC/SATA. 2 Quote I manage to build ATF + u-boot, thanks to Benjamin, but I haven't proceeded with flashing yet. My initial idea was to go safely and play with SD card booting, but since this is not possible ... well. What is worse case scenario if a break SPI flash? Quote You will be then forced to bring up your board using "boot from UART" mode. Not the funniest process, but you still will not need to setup JTAG session. Details are described in https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2017.03-armada-17.06/doc/mvebu/uart_boot.txt BTW, you can use this method for trying your new flash image prior to bunting them on SPI. It's bit slow, but can save you from recovering your board due to a bad image. If you only change the u-boot sources, you can try to load your u-boot.bin image (without ATF part) to DRAM and run from there: Marvell>> tftpboot 0 u-boot.bin; go 0 This way you will not touch the image on SPI. Folks @ DENX and Suse are using this method. Quote I forgot to mention that a37xx supports boot from SATA. Please check the ATF and u-boit build documents for details. This is another option for you to experiment with new boot images. Just use dd for placing yoùr image on LBA1 next to MBR. 0 Quote Link to comment Share on other sites More sharing options...
tkaiser Posted July 24, 2017 Share Posted July 24, 2017 In the meantime I suceeded by exchanging the build host: OMV_3_0_85_ESPRESSOBin_4.12.0.7z But now stuck at u-boot prompt: Booting Trusted Firmware BL1: v1.2(release):armada-17.02.0: BL1: Built : 09:41:56, Jun 2 2NOTICE: BL2: v1.2(release):armada-17.02.0: NOTICE: BL2: Built : 09:41:57, Jun 2 20NOTICE: BL31: v1.2(release):armada-17.02.0: NOTICE: BL31: U-Boot 2015.01-armada-17.02.0-g8128e91 (Jun 02 2017 - 09:41:51) I2C: ready DRAM: 1 GiB Board: DB-88F3720-ESPRESSOBin CPU @ 1000 [MHz] L2 @ 800 [MHz] TClock @ 200 [MHz] DDR @ 800 [MHz] Comphy-0: PEX0 2.5 Gbps Comphy-1: USB3 5 Gbps Comphy-2: SATA0 5 Gbps Now running in RAM - U-Boot at: 3ff2b000 U-Boot DT blob at : 000000003fa18168 MMC: XENON-SDHCI: 0 SF: Detected W25Q32DW with page size 256 Bytes, erase size 4 KiB, total 4 MiB advk_pcie_pio_read_config(227): wait for PIO time out advk_pcie_pio_read_config(227): wait for PIO time out PCIE-0: Link up (Gen1-x1 2.5GHz, Bus0) SCSI: SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs advk_pcie_pio_read_config(227): wait for PIO time out advk_pcie_pio_read_config(227): wait for PIO time out advk_pcie_pio_read_config(227): wait for PIO time out advk_pcie_pio_read_config(227): wait for PIO time out advk_pcie_pio_read_config(227): wait for PIO time out Non-posted PIO Response Status: CA, 0xe00 @ 0xc Non-posted PIO Response Status: CA, 0xe00 @ 0x1000 Non-posted PIO Response Status: CA, 0xe00 @ 0x1000 Non-posted PIO Response Status: CA, 0xe00 @ 0x2000 Non-posted PIO Response Status: CA, 0xe00 @ 0x2000 Non-posted PIO Response Status: CA, 0xe00 @ 0x3000 Non-posted PIO Response Status: CA, 0xe00 @ 0x3000 Non-posted PIO Response Status: CA, 0xe00 @ 0x4000 Non-posted PIO Response Status: CA, 0xe00 @ 0x4000 Non-posted PIO Response Status: CA, 0xe00 @ 0x5000 Non-posted PIO Response Status: CA, 0xe00 @ 0x5000 Non-posted PIO Response Status: CA, 0xe00 @ 0x6000 Non-posted PIO Response Status: CA, 0xe00 @ 0x6000 Non-posted PIO Response Status: CA, 0xe00 @ 0x7000 Non-posted PIO Response Status: CA, 0xe00 @ 0x7000 Non-posted PIO Response Status: CA, 0xe00 @ 0xc Non-posted PIO Response Status: CA, 0xe00 @ 0x0 Non-posted PIO Response Status: CA, 0xe00 @ 0x0 Net: neta0 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device ** File not found boot/Image ** ** File not found boot/armada-3720-community.dtb ** Bad Linux ARM64 Image magic! Marvell>> Will look later into. Time for dinner... 0 Quote Link to comment Share on other sites More sharing options...
martinayotte Posted July 24, 2017 Share Posted July 24, 2017 Quote ** File not found boot/Image ** Is the symlink missing ? 0 Quote Link to comment Share on other sites More sharing options...
lupus Posted July 24, 2017 Share Posted July 24, 2017 4 minutes ago, tkaiser said: But now stuck at u-boot prompt: Did you set the the environment parameters of espressobin (after Marvell>>) according to https://github.com/armbian/build/blob/master/config/bootscripts/boot-espressobin.cmd ? In particular "setenv fdt_name boot/dtb/marvell/armada-3720-community.dtb" needs to be set, since "boot/armada-3720-community.dtb" does not exist. 0 Quote Link to comment Share on other sites More sharing options...
zador.blood.stained Posted July 24, 2017 Share Posted July 24, 2017 Looks like the default environment doesn't search for the boot script at all (or it does so incorrectly). Output of "env print" might be useful. 0 Quote Link to comment Share on other sites More sharing options...
tkaiser Posted July 24, 2017 Share Posted July 24, 2017 19 minutes ago, lupus said: Did you set the the environment parameters of espressobin (after Marvell>>) according to https://github.com/armbian/build/blob/master/config/bootscripts/boot-espressobin.cmd ? Not yet (ordered a Münchner Schnitzel right now ). Few hours ago I looked into Marvell's u-boot and IIRC fatload was used everywhere. Maybe that's a problem too. Will provide output of "env print" later. BTW: it seems the board overheats badly when sitting at the u-boot prompt waiting. I added copper heatsinks to SoC and switch IC and burned my fingers few minutes before touching them. Whole board was pretty hot Edit: fatload was used here http://wiki.espressobin.net/tiki-index.php?page=Downloading+image+and+boot+from+SD+card+-+Linux 0 Quote Link to comment Share on other sites More sharing options...
zador.blood.stained Posted July 24, 2017 Share Posted July 24, 2017 31 minutes ago, tkaiser said: Edit: fatload was used here http://wiki.espressobin.net/tiki-index.php?page=Downloading+image+and+boot+from+SD+card+-+Linux Your u-boot log says "File not found", not "Unrecognized filesystem", so u-boot seems to try ext4 at least for loading the DT and kernel. 0 Quote Link to comment Share on other sites More sharing options...
tkaiser Posted July 24, 2017 Share Posted July 24, 2017 4 hours ago, Igor said: I am getting this one I went into probable 'buy cheap, buy twice' mode and ordered the same card from China (currently you can get an Paypal coupon worth $5 when you register with a new account on Aliexpress, then this thingie costs around €30 including shipping). 0 Quote Link to comment Share on other sites More sharing options...
lupus Posted July 24, 2017 Share Posted July 24, 2017 Unfortunately espressobin does not find the boot image (I am trying OMV_3_0_85_ESPRESSOBin_4.12.0.7z) even if the environtment variables given in https://github.com/armbian/build/blob/master/config/bootscripts/boot-espressobin.cmd are used: Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device ** File not found boot/Image ** 4803565 bytes read in 1749 ms (2.6 MiB/s) ** File not found boot/dtb/marvell/armada-3720-community.dtb ** Bad Linux ARM64 Image magic! Marvell>> Please find attached the current environment: Marvell>> printenv baudrate=115200 boot_interface=mmc bootargs=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/mmcblk0p1 rw rootwait bootcmd=mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $initrd_addr $initrd_image; ext4load mmc 0:1 $fdt_addr $fdt_name;setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_ar bootdelay=3 bootmmc=mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $fdt_addr $fdt_name;setenv bootargs $console root=/dev/mmcblk0p1 rw rootwait; booti $kernel_addr - $fdt_addr console=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 eth1addr=00:00:00:00:51:82 eth2addr=00:00:00:00:51:83 ethact=neta0 ethaddr=F0:AD:4E:03:69:D0 ethprime=egiga0 fdt_addr=0x1000000 fdt_high=0xffffffffffffffff fdt_name=boot/dtb/marvell/armada-3720-community.dtb filesize=494bed gatewayip=10.4.50.254 get_images=mmc dev 0; fatload mmc 0 $kernel_addr $image_name; fatload mmc 0 $fdt_addr $fdt_name; run get_ramfs get_ramfs=if test "${ramfs_name}" != "-"; then setenv ramfs_addr 0x3000000; tftp $ramfs_addr $ramfs_name; else setenv ramfs_addr -;fi hostname=marvell image_name=boot/Image initrd_addr=0x1100000 initrd_image=boot/uInitrd initrd_size=0x2000000 ipaddr=192.168.240.42 kernel_addr=0x2000000 loadaddr=0x2000000 loads_echo=0 netdev=eth0 netmask=255.255.255.0 ramfs_addr=- ramfs_name=- root=root=/dev/mmcblk0p1 rw rootdev=/dev/mmcblk0p1 rootfstype=ext4 rootpath=/srv/nfs/ serverip=0.0.0.0 set_bootargs=setenv bootargs $console $root stderr=serial stdin=serial stdout=serial verbosity=1 Environment size: 1650/65532 bytes Marvell>> 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.