Armbian for Amlogic S912

[Jens Bauer]

On October 8, 2017 at 2:21 PM, kingul said:

Yes, static ip is working, all is ok.
I'm still using my Yoka KB2 as a server, non stop working, with ARMBIAN 5.27 stable Ubuntu 16.04.3 LTS 3.14.29, not a single problem what so ever.
Only one thing I'm not sure: how can I update armbian, when new version is out? If I reflash with the new image, all my settings are gone(and they are a lot, everywhere).

Thank you so much for the update (sorry for my late reply, my PowerMac G5 died so I have been offline for a while).

It is always a good idea to make a backup (mirror) of everything before you update.

If you're not booting from SD-card, then I think you could mount your file system as read-only, then do a dd copy to a USB drive or SD card.

If you're booting from SD-card, then it's easy to make an image from the SD-card using a PC or Mac.

On my CubieBoard2, I just do the following ...

sudo apt-get update && sudo apt-get upgrade

-I never lost any of my settings.

(Though on CubieBoard2, I get a message about some updates not installed, which I've been ignoring for a while).

[ksuwnchdf]

On 10/20/2017 at 10:25 PM, DenFox said:

Ok, finally i managed to run "Armbian_5.34_S9xxx_Ubuntu_xenial_3.14.29_mate_20171020" on my Beelink GT1 through my microSD,  but my piece stuck to the Login and loop it back again and again - can't pass beyond...

 

What to do?

 

 

 

Solution: Select 'MATE' from the tray icon at the top right of the login screen (next to accessibility). I installed "Armbian_5.34_S9xxx_Ubuntu_xenial_3.14.29_mate_20171027" on an EgoIggo S12 (S912) and got the same problem as you.

 

I have another problem with the "Armbian_5.34_S9xxx_Ubuntu_xenial_3.14.29_mate_20171027" on an EgoIggo S12 (S912) - no ethernet connections/adaptors are detected. I cannot connect to the internet. I cannot see any installed network devices. The network functionality is fine on the stock Android, so the physical device does work. I have installed Armbian Debian and the openSUSE images but none of them can see my network adaptor. Can anyone help?

 

edit: Using the Vega S96 dtb file has fixed the ethernet issue. Wireless device not recognised, but not important at the moment. Pre-installed Kodi was crashing on launch with graphical issues. Uninstalled the amlogic version of Kodi and installed the ubuntu version from Synaptic Package Manager. (15.2). Is it possible to install v17?

[ArtUrlWWW]

Hello, guys.

I've tried to install Armbian image from Balbes150 - Armbian_5.34_S9xxx_Ubuntu_xenial_3.14.29_mate_20171104.img.xz on Bee-link GT1 Ultimate, and I followed an instruction http://mxqproject.com/tutorial-s905s905xs912-linux-ubuntu-mate-install-tutorial/ . But I got no progress on it - when TV Box boots from sd card, only black screen showed and no boot progress info.

I used gxm_q200_3g.dtb as dtb.img . With gxm_q200_3g.dtb I successfully run LibreElec on Bee-link GT1 Ultimate.

Does anybody tried to start Balbes150's images on Bee-link GT1 Ultimate?

[jeanrhum]

Hi,

 

Yes I ran successfully (about 2 weeks ago) the 3.4 jessie version of Balbes150. I'll try to test again as soon as I have time (maybe this week-end). If I remember well, I used the same dtb as you. Which version of gt1 utlimate do you have (serial starting with S, G or A912, mine is G912)?

It was running very well. I even use armbianconfig default script to install it on the emmc and it worked. Just after accepting the installation, I remembered Balbes' install.sh script is recommended instead of default armbian script to avoid bricking the box. So take care of that if you plan to install it on emmc, maybe I was lucky with my version.

[tkaiser]

Any of the S912 device owners able to run the following simple benchmark on an Armbian Ubuntu Xenial image and provide complete output here?

for o in 1 4 8 ; do
	echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
	for i in $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies) ; do
		echo $i >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
		echo -e "$(( $i / 1000)): \c"
		sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=$o 2>&1 | grep 'execution time'
	done
done

Thank you!

 

Background info: https://forum.armbian.com/topic/5570-some-basic-benchmarks-for-le-potato/?do=findComment&comment=42950 (would be interesting whether S912 is also cheating on us)

 

[balbes150]

12 hours ago, tkaiser said:

Any of the S912 device owners able to run the following simple benchmark on an Armbian Ubuntu Xenial image and provide complete output here?

Khadas VIM2 Basic (S912) Armbian Ubuntu Xenial

 

root@amlogic:~# ./1.sh
-e 100:
    execution time (avg/stddev):   43.1555/0.00
-e 250:
    execution time (avg/stddev):   38.6359/0.00
-e 500:
    execution time (avg/stddev):   36.7715/0.00
-e 667:
    execution time (avg/stddev):   36.7342/0.00
-e 1000:
    execution time (avg/stddev):   36.6605/0.00
-e 1200:
    execution time (avg/stddev):   36.6654/0.00
-e 1512:
    execution time (avg/stddev):   25.8857/0.00
-e 100:
    execution time (avg/stddev):   12.2133/0.01
-e 250:
    execution time (avg/stddev):   11.1908/0.00
-e 500:
    execution time (avg/stddev):   10.4857/0.00
-e 667:
    execution time (avg/stddev):   10.0522/0.00
-e 1000:
    execution time (avg/stddev):   9.1695/0.00
-e 1200:
    execution time (avg/stddev):   8.5308/0.00
-e 1512:
    execution time (avg/stddev):   7.5821/0.00
-e 100:
    execution time (avg/stddev):   8.8878/0.01
-e 250:
    execution time (avg/stddev):   7.9328/0.01
-e 500:
    execution time (avg/stddev):   6.6367/0.01
-e 667:
    execution time (avg/stddev):   5.8735/0.00
-e 1000:
    execution time (avg/stddev):   4.7245/0.01
-e 1200:
    execution time (avg/stddev):   4.1828/0.01
-e 1512:
    execution time (avg/stddev):   3.7980/0.01

 

[tkaiser]

2 hours ago, balbes150 said:

Khadas VIM2 Basic (S912) Armbian Ubuntu Xenial

 

Thank you. For whatever reason the executing shell seems not to be bash? Anyway, these are the numbers as table focusing on relevant cpufreq OPP:

num-threads=1
 100: execution time (avg/stddev):   43.1555/0.00
 250: execution time (avg/stddev):   38.6359/0.00
 500: execution time (avg/stddev):   36.7715/0.00
1000: execution time (avg/stddev):   36.6605/0.00
1512: execution time (avg/stddev):   25.8857/0.00

num-threads=4
 100: execution time (avg/stddev):   12.2133/0.01
 250: execution time (avg/stddev):   11.1908/0.00
 500: execution time (avg/stddev):   10.4857/0.00
1000: execution time (avg/stddev):   9.1695/0.00
1512: execution time (avg/stddev):   7.5821/0.00

num-threads=8
 100: execution time (avg/stddev):   8.8878/0.01
 250: execution time (avg/stddev):   7.9328/0.01
 500: execution time (avg/stddev):   6.6367/0.01
1000: execution time (avg/stddev):   4.7245/0.01
1512: execution time (avg/stddev):   3.7980/0.01

And this makes absolutely no sense (SoC running at 100 MHz being just half as fast as when on 1.5 GHz, it must be 15 times slower) 

 

Let's compare with the numbers @willmore generated on an ODROID-C2:

num-threads=1
 100:     execution time (avg/stddev):   369.1851/0.00
 250:     execution time (avg/stddev):   146.8992/0.00
 500:     execution time (avg/stddev):   73.3360/0.00
1000:     execution time (avg/stddev):   36.6221/0.00
1536:     execution time (avg/stddev):   24.4123/0.00

num-threads=4
 100:     execution time (avg/stddev):   99.4764/0.02
 250:     execution time (avg/stddev):   37.7647/0.01
 500:     execution time (avg/stddev):   18.6581/0.00
1000:     execution time (avg/stddev):   9.2395/0.00
1536:     execution time (avg/stddev):   6.0117/0.00

And then let's look at what the S912 produces. Keep in mind that a task like this sysbench when running with 100 MHz has to take 10 times longer compared to running at 1000 MHz. But this doesn't happen here, Amlogic's firmware BLOB controls everything in the background and the cpu clockspeed we get displayed and we are setting are plain BS since their firmware is using different values in the background taking into account how many CPU cores are busy and most probably also throttling.

 

That's what sysbench is telling us:

fake      1       4       8
 100     868     744     512
 250     955     812     574
 500    1000     866     686
1000    1000     992     964
1512    1448    1200    1200

So cpufreq OPP below 1000 MHz are usually (way) higher in reality but are adjusted based on $load (how many CPU cores are active). But as soon as there's heavy activity the higher cpufreq OPP are capped, S912 tells you it would be running at 1512 MHz while in reality it's at 1200 MHz. In other words: just like on Raspberry Pis we can not trust in the numbers we get/set which also makes our whole 'adjust cpufreq-utils settings' questionable (since the firmware decides on its own what's happening).

 

Well done, Amlogic (again).

[tkaiser]

@balbes150 did you had a heatsink on the SoC? Since numbers prove that no throttling happened:

• 4 threads at '1.5 GHz' took 7.5821 seconds with a standard deviation of 0.00
• 8 threads at '1.5 GHz' took 3.7980 seconds with a standard deviation of 0.01

The results differ by factor 1.996340179 which is caused by some minor background activity but it can't be throttling since otherwise execution time with 8 threads has to be longer compared to benchmarking just on 4 cores So we're really talking about the firmware controlling the CPU (and most probably also GPU) cores behaviour being driven by some policy to lower max clockspeeds depending on the load profile (count of busy CPU cores).

 

[balbes150]

1 hour ago, tkaiser said:

did you had a heatsink on the SoC?

Yes, I have installed the cooling system (heatsink + fan) which at maximum load when compiling to maintain the temperature above 60 Degrees.

I didn't do any special settings. Copied code into the script and ran. For reference, the system itself Armbian installed in eMMC.

[tkaiser]

29 minutes ago, balbes150 said:

Yes, I have installed the cooling system (heatsink + fan)

 

Is it easily possible to temporarely disable the fan? Just to verify the results and to get another probably very important insight: does the firmware also cheat on us if throttling really happens? If you have another 3 minutes then switching off the fan and trying this script would be great:

#!/bin/bash
echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 1512000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
while true ; do
	read cur_freq </sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
	read cur_temp </etc/armbianmonitor/datasources/soctemp
	echo -e "$(( $cur_freq / 1000)) @ $(( $cur_temp / 1000)): \c"
	sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=8 2>&1 | grep 'execution time'
done

(this time with shebang line forcing bash, now the output should be correct -- my mistake before). As soon as execution time exceeds 5 seconds please stop with <ctrl>-<c> and report results. Thank you so much!

[balbes150]

6 hours ago, tkaiser said:

Is it easily possible to temporarely disable the fan? Just to verify the results and to get another probably very important insight: does the firmware also cheat on us if throttling really happens? If you have another 3 minutes then switching off the fan and trying this script would be great:

Turned off the fan. Launched this version of the script. Waited 30 minutes, the temperature rose slowly during this time to 80 degrees. In all lines the result is around 3.7-3.8 . How long should I wait ?

 

1512 @ 80:     execution time (avg/stddev):   3.8009/0.01
1512 @ 80:     execution time (avg/stddev):   3.8009/0.01
1512 @ 80:     execution time (avg/stddev):   3.8032/0.01
1512 @ 79:     execution time (avg/stddev):   3.8145/0.01
1512 @ 79:     execution time (avg/stddev):   3.7967/0.01
1512 @ 80:     execution time (avg/stddev):   3.8084/0.01
1512 @ 79:     execution time (avg/stddev):   3.7900/0.01
1512 @ 80:     execution time (avg/stddev):   3.8060/0.01
1512 @ 80:     execution time (avg/stddev):   3.8063/0.01
1512 @ 80:     execution time (avg/stddev):   3.8029/0.01
1512 @ 80:     execution time (avg/stddev):   3.8110/0.01
1512 @ 80:     execution time (avg/stddev):   3.8076/0.01
1512 @ 80:     execution time (avg/stddev):   3.7976/0.01
1512 @ 79:     execution time (avg/stddev):   3.8038/0.01
1512 @ 80:     execution time (avg/stddev):   3.7911/0.01
1512 @ 80:     execution time (avg/stddev):   3.8022/0.01
1512 @ 79:     execution time (avg/stddev):   3.7961/0.01
1512 @ 79:     execution time (avg/stddev):   3.8046/0.00
1512 @ 80:     execution time (avg/stddev):   3.8247/0.01
1512 @ 80:     execution time (avg/stddev):   3.8106/0.01
1512 @ 80:     execution time (avg/stddev):   3.7978/0.00
1512 @ 80:     execution time (avg/stddev):   3.8035/0.01

[tkaiser]

12 hours ago, balbes150 said:

Launched this version of the script. Waited 30 minutes, the temperature rose slowly during this time to 80 degrees. In all lines the result is around 3.7-3.8 . How long should I wait ?

 

Hehe, sysbench is obviously too light since temperature remains below throttling treshold. Let's stop since only useful next test would be to remove the heatsink and that's not worth the efforts. Thank you anyway!

 

To really test out the firmware's behaviour we would need also some GPU stuff since I would assume that once one or more GPU cores are busy the CPU cores are downclocked even more (while still reporting bogus cpufreq values through sysfs).

[tkaiser]

13 hours ago, balbes150 said:

Turned off the fan

 

Just remembered what I often did to force throttling while testing thermal issues: putting a pillow on the board. Should work in your setup within minutes  

[balbes150]

1 hour ago, tkaiser said:

Just remembered what I often did to force throttling while testing thermal issues: putting a pillow on the board. Should work in your setup within minutes

The pillow I not used.

When testing I covered the board of a plastic bag (there were no ventilation).

[jeanrhum]

On 10/11/2017 at 1:25 PM, ArtUrlWWW said:

Hello, guys.

I've tried to install Armbian image from Balbes150 - Armbian_5.34_S9xxx_Ubuntu_xenial_3.14.29_mate_20171104.img.xz on Bee-link GT1 Ultimate, and I followed an instruction http://mxqproject.com/tutorial-s905s905xs912-linux-ubuntu-mate-install-tutorial/ . But I got no progress on it - when TV Box boots from sd card, only black screen showed and no boot progress info.

I used gxm_q200_3g.dtb as dtb.img . With gxm_q200_3g.dtb I successfully run LibreElec on Bee-link GT1 Ultimate.

Does anybody tried to start Balbes150's images on Bee-link GT1 Ultimate?

I just made a new test with latest image (xenial_3.14_20171104). I give you a wrong answer, that's my results:

- with gxm_q200_3g.dtb : no hdmi output after beelink logo and not visible on my local network

- without any dtb.img (default one from android rom I think): it boots well, but no wifi

- with khadas vim 2 dtb: it boots well, but no wifi

Since I want to use this box headless with a wired connection, I didn't checked wireless configuration.

This evening, I'll try to make tests for tkaiser.

[jeanrhum]

@tkaiserAfter more than 45 minutes I got this kind of values:

 

-e 1512 @ 53:     execution time (avg/stddev):   3.7886/0.01
-e 1512 @ 54:     execution time (avg/stddev):   3.7963/0.01
-e 1512 @ 53:     execution time (avg/stddev):   3.7880/0.01
-e 1512 @ 53:     execution time (avg/stddev):   3.7933/0.00
-e 1512 @ 54:     execution time (avg/stddev):   3.7865/0.01
-e 1512 @ 54:     execution time (avg/stddev):   3.7899/0.01

I haven't opened my gt1 ultimate.

[tkaiser]

19 minutes ago, jeanrhum said:

I haven't opened my gt1 ultimate.

 

Thank you for testing! I would keep the box closed since it shows excellent heat dissipation (25"C less than VIM2 with same load -- that's really impressive). Out of curiousity: what material is the enclosure made of and does it feel warm(er)?

 

@balbes150: Do you have a pillow at home to throw on the VIM2?  I can't understand that no one is able to get the S912 throttling!  

[balbes150]

10 hours ago, tkaiser said:

Do you have a pillow at home to throw on the VIM2?

I'll look and I'll check with the pillow ...

[jeanrhum]

what material is the enclosure made of and does it feel warm(er)? 

The enclosure is in platic. I will look closer to the enclosure and its temperature next time. Initial temperatures were around 36°C.

I will also try to take more time to run this test, because I think the temperature could have continue to slowly increase but it was too late and I didn't want to let it run like that during night. I also have a H96 pro+ and the gt1 ultimate is much more heavy. I suppose that there is a big heatsink over the soc whereas h96pro+ has nothing (but I didn't succeed in running armbian on it, I suppose due to reboot issues even if I manage to install latest superceleron's rom from freaktab).

[tkaiser]

18 minutes ago, jeanrhum said:

I will also try to take more time to run this test

 

Usually 15 minutes should be sufficient (at least that's my experience). Wrt Beelink B1 heat dissipation forget my question please. Jean-Luc already provided insights over a year ago: https://www.cnx-software.com/2016/09/09/beelink-gt1-4k-tv-box-review-part-1-unboxing-and-teardown/

 

So the heat gets spread to this large metal plate at the enclosure bottom which seems to be rather efficient.  

[balbes150]

Wrapped in a warm hat is one of my TV boxes (Tronsmart Vega S96) .

Run test for a couple of hours. Here is the result at the end of the second hour. Such a conclusion in the console, no change for end hours, so stopped the test.

 

Spoiler

1512 @ 79:     execution time (avg/stddev):   4.1436/0.01
1200 @ 79:     execution time (avg/stddev):   4.0925/0.01
1512 @ 79:     execution time (avg/stddev):   4.1210/0.00
1200 @ 79:     execution time (avg/stddev):   4.1082/0.01
1512 @ 79:     execution time (avg/stddev):   4.0899/0.01
1200 @ 79:     execution time (avg/stddev):   4.1200/0.01
1200 @ 79:     execution time (avg/stddev):   4.0957/0.01
1200 @ 79:     execution time (avg/stddev):   4.1305/0.01
1512 @ 79:     execution time (avg/stddev):   4.1274/0.01
1200 @ 79:     execution time (avg/stddev):   4.0736/0.01
1200 @ 79:     execution time (avg/stddev):   4.1054/0.01
1200 @ 79:     execution time (avg/stddev):   4.1650/0.01
1512 @ 79:     execution time (avg/stddev):   4.0857/0.01
1512 @ 79:     execution time (avg/stddev):   4.0908/0.01
1512 @ 79:     execution time (avg/stddev):   4.1230/0.01
1512 @ 79:     execution time (avg/stddev):   4.1660/0.00
1200 @ 79:     execution time (avg/stddev):   4.0707/0.00
1200 @ 79:     execution time (avg/stddev):   4.1134/0.01
1512 @ 79:     execution time (avg/stddev):   4.1198/0.01
1200 @ 79:     execution time (avg/stddev):   4.0714/0.01
1200 @ 79:     execution time (avg/stddev):   4.1465/0.01
1512 @ 80:     execution time (avg/stddev):   4.0923/0.01
1200 @ 79:     execution time (avg/stddev):   4.0756/0.01
1200 @ 79:     execution time (avg/stddev):   4.2131/0.01
1200 @ 79:     execution time (avg/stddev):   4.1439/0.00
1512 @ 79:     execution time (avg/stddev):   4.0813/0.01
1512 @ 79:     execution time (avg/stddev):   4.1081/0.01
1512 @ 79:     execution time (avg/stddev):   4.1305/0.01
1512 @ 79:     execution time (avg/stddev):   4.0961/0.00
1200 @ 79:     execution time (avg/stddev):   4.1359/0.01
1512 @ 79:     execution time (avg/stddev):   4.1054/0.01
1512 @ 79:     execution time (avg/stddev):   4.0900/0.01
1512 @ 79:     execution time (avg/stddev):   4.0790/0.01
1512 @ 79:     execution time (avg/stddev):   4.0888/0.01
1200 @ 79:     execution time (avg/stddev):   4.0865/0.01
1200 @ 79:     execution time (avg/stddev):   4.1416/0.01
1512 @ 79:     execution time (avg/stddev):   4.1541/0.01
1512 @ 79:     execution time (avg/stddev):   4.0418/0.01
1512 @ 80:     execution time (avg/stddev):   4.1571/0.01
1512 @ 79:     execution time (avg/stddev):   4.1074/0.01
1512 @ 80:     execution time (avg/stddev):   4.1449/0.01
1200 @ 79:     execution time (avg/stddev):   4.1127/0.01
1200 @ 79:     execution time (avg/stddev):   4.1390/0.01
1200 @ 79:     execution time (avg/stddev):   4.1569/0.01
1512 @ 79:     execution time (avg/stddev):   4.1365/0.01
1200 @ 79:     execution time (avg/stddev):   4.0810/0.01
1512 @ 79:     execution time (avg/stddev):   4.1297/0.01
1200 @ 79:     execution time (avg/stddev):   4.0858/0.01
1512 @ 79:     execution time (avg/stddev):   4.0995/0.01
1200 @ 79:     execution time (avg/stddev):   4.1034/0.01
1512 @ 79:     execution time (avg/stddev):   4.0843/0.01
1512 @ 79:     execution time (avg/stddev):   4.1451/0.01
1200 @ 79:     execution time (avg/stddev):   4.1349/0.01
1512 @ 79:     execution time (avg/stddev):   4.1799/0.01
1512 @ 79:     execution time (avg/stddev):   4.1290/0.01
1200 @ 79:     execution time (avg/stddev):   4.2215/0.01
1200 @ 79:     execution time (avg/stddev):   4.1333/0.01
1512 @ 79:     execution time (avg/stddev):   4.1494/0.01
1200 @ 79:     execution time (avg/stddev):   4.1901/0.01
1512 @ 79:     execution time (avg/stddev):   4.1292/0.01
1512 @ 79:     execution time (avg/stddev):   4.1551/0.01
1200 @ 79:     execution time (avg/stddev):   4.2086/0.01
1512 @ 79:     execution time (avg/stddev):   4.1498/0.01

 

[tkaiser]

14 hours ago, balbes150 said:

1200 @ 79:     execution time (avg/stddev):   4.2215/0.01

 

Thank you for the test. So this box starts to throttle around 80°C and reported cpufreq also decreases (when 1512 is shown in reality it's 1200 MHz, the above execution duration indicates ~1080MHz in reality). So numbers still bogus as expected but at least there is an indication that throttling happens through sysfs (Raspberry Pi for example fakes this also: when throttling happens there and the real cpufreq goes below 1200 MHz -- eg. 800 MHz -- sysfs still reports 1200 MHz until 600.1 MHz. Only if throttled down to 600.0 MHz sysfs shows correct values again).

[fossxplorer]

@tkaiser, that just crashed my H96Pro+ remote at home. Let's see if can run this while i'm closer to it

 

 

 

 

[Shimon]

Quoting a certain popular S912 ROM's Changelog:

 

Quote

Added True 8 core ( All cores now work at 1.5ghz )

Does anyone know if this feature could be ported to the Armbian kernel? I'm sure it would solve those weird ramspeed results reported earlier.

[tkaiser]

8 minutes ago, Shimon said:

Does anyone know if this feature could be ported to the Armbian kernel? I'm sure it would solve those weird ramspeed results reported earlier.

 

Ramspeed? Kernel?

 

The issue is that the firmware blob is lying to the kernel wrt cpufreq (not RAM -- testing with sysbench is excluding RAM 100%). How should something in the kernel fix firmware behaviour? What's the proof of 'All cores now work at 1.5ghz'? The fantasy values returned by /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq?

[Shimon]

27 minutes ago, tkaiser said:

 

Ramspeed? Kernel?

Please, read the thread before spouting question marks. I know what the issue is, I originally benchmarked it. The kernel is almost certainly involved in that observed performance drop due to big.little scheduling. 

 

Superceleron's mod is definitely worth investigating.

[tkaiser]

24 minutes ago, Shimon said:

read the thread

 

Of course not. If you can post links to interesting posts somewhere in between this 172 pages (!) thread or a github repo with the changes I'll take a look ASAP. Thanks.

[fossxplorer]

How do i get my H96Pro+ to work with a DVI monitor (it works fine with our Samsung TV, HDMI input)? I've tried to with HDMI-to-DVI adapter (this could be opposite adapter not sure), no signals on the monitor. 

Do i need active HDMI-to-DVI adapter?

 

Will any Orange Pi H3 or H5 boards have the same issues too? I'm planning to buy an Orange Pi board that has accelerated X11/GUI so that i can use it as a simple desktop, mainly to access my KVM VM over SPICE protocol.

 

[jeanrhum]

Maybe it is only for Allwinner SoCs, but you can try (Pine64 doc):

If you use a DVI display don’t forget to define disp_dvi_compat=1 in /boot/armbianEnv.txt (supported starting with 5.21).

 

[willmore]

Data for the Odroid-C2 for 2 threads to fill out the table @tkaiser.

100:     execution time (avg/stddev):   196.7230/0.01
250:     execution time (avg/stddev):   76.9758/0.01
500:     execution time (avg/stddev):   37.5997/0.00
1000:     execution time (avg/stddev):   18.3120/0.00
1296:     execution time (avg/stddev):   14.3056/0.00
1536:     execution time (avg/stddev):   12.0588/0.00
1656:     execution time (avg/stddev):   11.1768/0.00
1680:     execution time (avg/stddev):   11.0148/0.00
1752:     execution time (avg/stddev):   10.5501/0.00