Search the Community

Yes, I have Rock64 working with I2C and a 20x4 LCD display like this one Aliexpress and the dbrgn/RPLCD under Python 3.6.6 (Ubuntu Bionic 18.04) : git clone https://github.com/bazooka07/RPLCD.git -b test-entrypoint-1811 ( I fix a little bug for the test ) I have too an ESP8266 (Nodemcu) and a OLed 0.96" display. I'm trying for running Oled with Rock64. The following library is working but don't keep the display on when I leave my script pip3 install luma.oled My script : #!/usr/bin/env python3 from luma.core.interface.serial import i2c, spi from luma.core.render import canvas from luma.oled.device import ssd1306 serial = i2c(port=1, address=0x3C) device = ssd1306(serial) with canvas(device) as draw: draw.rectangle(device.bounding_box, outline='white', fill='black') draw.text((30, 40), 'Hello World', fill='white') Don't forget to connect on i2c-1 pin #27 (sda) and pin #28 (scl) unlike RPI3

Sorry to resurrect an old thread! As a new Armbian user on Rock64, I found this thread while searching for a guide on how to boot from a usb device. After playing around with partitions and the armbian-config utility, I realized that after copying rootfs to the usb device, the board will still read from the /boot partition on the sd card, then will load rootfs from the external drive. If the board is powered on without the sd card, boot will fail. This method works fine for my purposes. If there is a way to configure the rock64 to read from a /boot partition on a usb device, I haven't found one. I hope this helps any other new folks like myself who want to run Armbian from usb/ssd on Rock64. Cheers!

5.67 20181117 seems to run better for me, let's see how it goes Put the opp-1512000000 section from rock64 into evb, managed to get cpufreq-info to show 1.51GHz but sysbench does not show any improvement. DEV_NEXT with rk3328-rock64.dtb boots to desktop but no ethernet. Tried replacing eth sections from evb into rock64, eth was not even detected.

Hi, Have you managed to use I2C with Rock64 ? I will soon have to port part of a project under ESP8266 to Rock64, and I need to use I2C with an Oled SSD1306 controller, thanks in advance for sharing your experience.

Added to the site a test version of the image 20181117 with the addition of a number of WiFi modules (dir 5.67/WIFI). I'm not sure it will work, this way on my MVR9 WiFi stopped working. Anyone can try on their models. The test image on the basis of the kernel of 4.19 (dir DEV_NEXT). On MVR9 with dtb "rock64" in the settings, the system starts from the SD card, there is HDMI (output to the monitor), a wired network and USB. Thus, there are all the minimum elements necessary for the initial work.

Thanks for that response TonyMac. Great information. The Armbian team does some GREAT work, and I really appreciate what they do. I am FAR from a programmer or developer so cannot assist there. Once I get all my RPi's replaced with Rock64's and Armbian, I shall try to assist as you recommend.

Useful doc here : http://synfare.com/599N105E/hwdocs/rock64/index.html I am trying with Ayufan distribution : https://github.com/ayufan-rock64/linux-build/releases/download/0.7.9/bionic-minimal-rock64-0.7.9-1067-arm64.img.xz I have connecting i2c on P27 (i2c1-sda) and P28(i2c1-scl) and 3.3volts and the display is found with "i2cdetect -y 1" on 0x3f. Now, I have to install lcdproc

Hello. I bought a Rock64 and I have a lot of errors. Im using a eMMC 32GB Storage with Armbian 5.65 stretch 4.4.162 Desktop, Ethernet connection with TP-Link switch, a Wireless Keyboard with touch pad and the original 5V 3A Power Supply. HDMI is connect to a HDMI Splitter/Switch. The Rock64 is placed in the Aluminum casing. Full-Log: http://ix.io/1rce The system is reboot very often before i see the Desktop. Sometimes only after several resets. Can someone help me?

Renegade has the wiring on board for UHS-I. SDR104 works great for me. rock64 doesn't support UHS-I from what I read. Not sure about rock64pro.

does anybody here know if this has been implemented for RockPro64? I asked at the irc, but nobody seems to know. I suspect the answer is "no" (the same as with Rock64, that also should have a UHS-I capable SD host controller), but the certain answer would be better than guesses.

really? 50MHz? sounds fishy.. did you have a look into this one: https://github.com/ayufan-rock64/linux-u-boot/blob/d646df03ace3bd191e24361944ce1c7ef3c8744c/configs/rockpro64-rk3399_defconfig#L16 e.g. upstream u-boot points to a python script, which is not board but soc specific: https://github.com/u-boot/u-boot/blob/master/configs/evb-rk3399_defconfig#L16 not sure if we knock out it fully when we write u-boot... this one may also be interesting.. https://github.com/ayufan-rock64/linux-u-boot/blob/rockchip-master/board/rockchip/rockpro64_rk3399/rockpro64-rk3399.c

tkaiser, DDR50 is not the "slowest SD mode". It's a mandatory UHS-I mode, capable of delivering up to 50 MB/s. So it's fast, but it uses the lower frequency (50 MHz) giving power saving. SDR104 runs at 208 MHz. In the above quote, pre UHS-I are DS and HS 3.3V modes. DS is "the slowest". DDR50 is a thing in fact - fast and power saving at the same time. Unlike SD104 it should be supported by every UHS-I card. This UHS-I "problem" is really bugging me. How messy it is on SBCs. I am happy to finally hear that Odoroid does support UHS-I modes. And Tinkerboard - I actually suspected that Asus could not just f&ck up such a good feature as UHS-I, which is already there in the SoC, and just waits for the proper implementation on the board side. But what about RockPro64? Do you know of whether the board lets the SoC's SD controller to do UHS-I? Even Rock64's rk3328 should be able of doing so. Heck, even Allwinner's A20 (!), R40, A64, and I am sure H2/H3/H5 too all claim UHS-I support... But what boards have implemented it properly?

My video about benchmarking CPU`s of SBC`s. Here all my data gathered Reasons why benchmark tools can give different results ------------------------------------------------------ throttling 32-bit/64-bit Difference in cores A53/A7/A15/A72 distro (ubuntu/debian...) distro version kernel version driver versions compiler version software version/outdated repositories desktop Mate/Xfce/LXDE/... display resolution/headless background processes cpu clockspeed ram clockspeed/latency ram useage/swap/zram process sheduler optimizations for the system/distro crypto engine for encryption Undervoltage config settings Wifi dongle uses recources 7-zip works a bit better on 32-bit vs 64-bit, it doesn't use all cores at 100% in multi-core scores. The percentage differs with different distro's and boards. So it's not completely exact. Blender works a lot better on 64-bit than on 32-bit. Older versions are faster. It uses 100% of the cores. Sysbench works 10x better on 64-bit, different versions give different results. Version 1.xx does the test 10s and gives the amount of events. GIMP only uses 1 core, works better on 64-bit. GTKPerf tests desktop speed. It only uses 1 core. CPU Miner only works on 64-bit. Works better in Ubuntu Bionic than in Debian Stretch/Ubuntu Xenial. Blender : BMW render @ 1080p Gimp : BMW render result 1080p Filters -> Artistic -> Van Gogh -> ok Sysbench : sysbench --test=cpu --cpu-max-prime=20000 --num-threads="number of threads" run 7-zip : Numbers are average of 3 of decompressing only All tests are done with a fan when necessary so no throttling occurs. 64-bit SBC's NanoPC T3+ |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Armbian Bionic http://ix.io/1iRJ 10.99kH/s 1290 10254 1h10m25s 1m24s 10.11s 21692 Arbmian Stretch http://ix.io/1qiF 8.55kH/s 1275 10149 1h13m55s 1m32s 11.06s 3.2s NanoPi M4 |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Armbian bionic http://ix.io/1nLh 10.23kH/s 1335 2005 8352 1h13m50s 0m29s5 5.06s 26763 Armbian bionic nightly http://ix.io/1pDo 10.24kH/s 1329 1990 8292 1h13m28s 0m29s 5.12s 26733 Armbian stretch desktop http://ix.io/1odF 8.66kH/s 1350 1977 8400 1h14m12s 0m31s 5.24s 3.1s Armbian stretch dsk nightly //ix.io/1pM0 8.80kH/s 1359 1993 8500 1h15m04s 0m31s 5.32s 3.3s Armbian stretch core no fan //ix.io/1pKU 8.80-8.65kH/s 1353 1989 8461 Armbian stretch core //ix.io/1pL9 8.76kH/s 1354 1988 8456 Armbian stretch core nightly //ix.io/1pLf 8.82kH/s 1357 1994 8494 Lubuntu Bionic arm64 http://ix.io/1oGJ 9.24kH/s CPU Miner 1056 1551 6943 1h28m13s Lubuntu Bionic armhf http://ix.io/1pJ1 1111 1769 7705 2h02m54s 0m57s 6.97s 1666 32-bit Lubuntu Xenial armhf http://ix.io/1oCb 989 1507 6339 2h20m51s 0m59s 49.77s 49.7s 32-bit Khadas Vim2 Max |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Ubuntu Xenial http://ix.io/1qkA 6.86kH/s 823 1134 6682 1h14m39s 1m53s 16.26s 3.8s Armbian Bionic http://ix.io/1qnY 8.55kH/s 921 1272 7464 1h17m52s 1m32s 12.54s 19035 Odroid C2 |SBC bench result |CPU Miner |7-zip big core |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Armbian Stretch Core http://ix.io/1pZu 4.65kH/s 1390 5342 Armbian Stretch Core Nightly //ix.io/1pZJ 4.66kH/s 1391 5340 Armbian Stretch Desktop http://ix.io/1q1C 4.65kH/s 1394 5363 1m23s 11.66s 5.96s Armbian Stretch Desktop NGHT //ix.io/1p02 4.59kH/s 1394 5356 2h38m18s 1m23s 12s 6.0s Ubuntu Mate Bionic http://ix.io/1q2S clocked to 100Mhz 2h35m10s 1m17s 10.01s 12026 Ubuntu Mate Bionic OC Doesn't work/Clocked to 100Mhz 1607 5960 2h10m21s 1m09s 8.94s 13755 Rock64 |SBC bench result |CPU Miner |7-zip small core |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Armbian Stretch 1.5Ghz http://ix.io/1nCj 4.06kH/s 1406 5407 3h00n32s 1m39s 15.91s 7.0s OLD Armbian Stretch 1.3Ghz //ix.io/1iHB 3.80kH/s 1211 4904 Armbian Bionic 1.5Ghz core //ix.io/1qbK 5.00kH/s 1384 5379 10.0s Armbian Bionic 1.5Ghz dsk //ix.io/1qcb 4.94kH/s 1379 5326 2h55m56s 1m31s 15.00s 10172 32-bit SBC's Odroid XU4 |SBC bench result |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Debian Jessie http://ix.io/1q6X 950 1653 8823 1h12m19s 1m08s 18.53s 41.3s Ubuntu Bionic http://ix.io/1qbL 1219 2094 9395 1h44m19s 1m10s 14.36s 2200 Underclocks above 75°C Asus Tinker board |SBC bench result |7-zip big core|7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Tinker OS 9.5 Stretch http://ix.io/1pRN 1983 7536 2h55m00s 1m19s 189.82s 63.7s Raspberry Pi 3B+ |SBC bench result |7-zip small core |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Raspbian Default no fan http://ix.io/1q10 1471 5027 2m09s 9.85s 88.2s Raspbian Default http://ix.io/1q1Q 1411 5371 5h47m31s 2m09s 10.04 79.5s Raspbian OC http://ix.io/1q5J 1591 6141 1m55s 8.81s 70.8s Ubuntu Mate Xenial http://ix.io/1q65 7-zip didn't work 2m17s 11.71s 90.5s Raspberry Pi 3B |SBC bench result |7-zip small core |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Raspbian Stretch : http://ix.io/1qob 1220 4681 2m31s 10.97s 93s Orange Pi+2 |SBC bench result |7-zip small core |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Armbian Bionic http://ix.io/1qtf 1050 4121 2m56s 19.07s 773 Software versions ----------------- GIMP Blender GTKPerf SysBench SBC-bench NanoPC T3+ : Armbian Bionic : 2.8.22 2.79b 0.40 1.0.11 0.4.6 Armbian Stretch : 2.8.18 2.79b 0.40 0.4.12 0.6.2 GIMP Blender GTKPerf SysBench SBC-bench M4 : Lubuntu Xenial armhf 2.8.18 2.79b 0.40 0.4.12 0.6.1 Lubuntu Bionic armhf : 2.8.22 2.79b 0.40 1.0.11 LuaJIT 2.1.0-beta3 0.6.1 Armbian Stretch desktop 9.5 : 2.8.18 2.79b 0.40 0.4.12 0.6.1 Armbian Bionic : 2.8.22 2.79b 0.40 1.0.11 LuaJIT 2.1.0-beta3 0.6.1 Khadas Vim2 Max : Ubuntu Xenial : 2.8.16 2.76b 0.40 0.4.12 0.6.2 Armbian Bionic : 2.8.22 2.79b 0.40 1.0.11 0.6.2 Odroid C2 : Armbian Stretch 9.5 : 2.8.18 2.79b 0.40 0.4.12 0.6.1 : Ubuntu Mate Bionic : 2.8.22 2.79b 0.40 1.0.11 LuqJIT 2.1.0-beta3 0.6.1 Doesn't work clocks to 100Mhz Rock64 : Armbian Stretch 9.5: 2.8.18 2.79b 0.40 0.4.12 0.6.1 : Armbian Bionic : 2.8.22 2.79b 0.40 1.0.11 0.6.2 Odroid XU4 : Debian Jessie : 2.8.14 2.72b 0.40 0.4.12 0.6.1 7-zip doesn't work : Ubuntu Bionic : 2.8.22 2.79b 0.40 1.0.11 0.6.2 Tinker : TinkerOS 9.5 Stretch : 2.8.18 2.79b 0.40 0.4.12 0.6.1 RPi 3B+ : Raspbian Stretch 9.5 : 2.8.18 2.78a 0.40 0.4.12 0.6.1 Ubuntu Mate Xenial : 2.8.16 0.40 0.4.12 0.6.1 RPi 3B : Raspbian Stretch 9.5 : 2.8.18 2.78a 0.40 0.4.12 0.6.2 Orange Pi+2 : Armbian Bionic : 2.8.22 0.40 1.0.11 0.6.2 CPU Clocks ---------- NanoPC T3+ : Armbian Bionic : 8x1.4Ghz 64-bit NanoPi M4 : Armbian Bionic/Stretch : 2x2Ghz + 4X1.5Ghz 64-bit Lubuntu armhf/ARM64 : 2x1.8Ghz + 4X1.4Ghz armhf 32-bit / ARM64 64-bit Khadas Vim 2 : Xenial/Bionic : 4x1Ghz + 4x1.5Ghz 64-bit Odroid C2 : Armbian Stretch : 4x1.5Ghz 64-bit Ubuntu Mate Bionic : 4x1.5Ghz RAM 912Mhz 64-bit Ubuntu Mate Bionic OC : 4x1.75Ghz + RAM 1104Mhz 64-bit Rock64 : Armbian Stretch : 4x1.5Ghz 64-bit Armbian Bionic : 4x1.5Ghz 64-bit Odroid XU4 : Debian Stretch : 4x1.4Ghz + 4x1.9Ghz 32-bit : Ubuntu Mate Bionic : 4x1.5Ghz + 4x2Ghz Underclocks when above 75°C 32-bit Tinker Board : TinkerOS Stretch : 4x1.8Ghz 32-bit RPi 3B+ : Raspbian Stretch : 4x1.4Ghz no fan 4x1.2Ghz above 60°C 32-bit Raspbian Stretch OC : 4x1.570Ghz over_voltage=4 core_freq=500 sd_freq=510 32-bit Ubuntu Xenial : 4x1.4Ghz 32-bit RPi 3B : Raspbian Stretch : 4x1.2Ghz 32-bit Orange Pi+2 : Armbian Bioic : 4x1.3Ghz 32-bit Some benchmark tools can give an estimate of the performance. But they are never an exact reflection.

https://botland.com.pl/akcesoria-odroid/6537-konwerter-usb-audio-jack-karta-dzwiekowa-do-odroid.html I have only one sound card. It works with other SBC i have. Rock64 Ubuntu bionic kernel 4.4 does not recognize it.

And it became a great board. Tried it again a few days ago. It's now really at 1.5Ghz and stable. Also great youtube playback. It's gotten almost as fast as the Odroid C2(when it's not overclocked) Great job! I didn't think this would ever be such a good board. Only thing that was a minor was the slow cpu. For $35 there's the NanoPi Fire3. An octa-core. But only 1GB ram. I've got the T3+, same SoC. Good board. Fastest of all. An awesome board is the NanoPi Neo4. A RK3399 board. Super fast. With heatsink $50. Those with the Rock64 are the best value boards I think. Just tried my OPi+2 again. It's slower than the RPi 3B. Not a pleasant experience. But it depends on the use case of course. There's going to be La Frite for $10. Seems decent.

prices even for those el cheapo orangePi's increased in the last year.. You should't go by price but by needs. If your PiPC does the job well, just buy another H2+/H3 based.. OPi PC, One, Zero etc. If you need something more, you should have a look for Rock64, actually quite cheap for what you get. 15$ for a board which doesn't do the job, is 15$ too much. Buy by use-case not price only.

Have you tried with pulseaudio? I'll start my Rock64 to check.

I've just finished Benchmarking most of my sbc's. This is done to see how well benchmark tools perform. Conclussion is that I've found no perfect cpu-benchmark tool. With every tool there is a problem. 7-zip does good in single core tasks(100%) but with multicore tasks it doesn't use 100% of all cores. This percentage also differs from distro and from sbc to sbc. It also does a little bit better on 32-bit systems. With blender different versions perform different. Older versions are faster. It also performs a lot better on 64-bit. Sysbench does different tasks with different versions. It performs about 10x better on 64-bit systems. CPU-Miner only works on 64-bit systems. It performs best on Bionic. Gimp only uses 1 core. Performs better on 64-bit. GTKPerf tests desktop speed. It only uses 1 core. It doesn't give reliable information. Here all my results. I'll make a video about it by the end of the week. If anyone has suggestions. Please let me know. Reasons why benchmark tools can give different results ------------------------------------------------------ throttling 32-bit/64-bit Difference in cores A53/A7/A15/A72 distro (ubuntu/debian...) distro version kernel version driver versions compiler version software version/outdated repositories desktop Mate/Xfce/LXDE/... display resolution/headless background processes cpu clockspeed ram clockspeed/latency ram useage/swap/zram process sheduler optimizations for the system/distro crypto engine for encryption Undervoltage config settings Wifi dongle uses recources 7-zip works a bit better on 32-bit vs 64-bit, it doesn't use all cores at 100% in multi-core scores. The percentage differs with different distro's and boards. So it's not completely exact. Blender works a lot better on 64-bit than on 32-bit. It uses 100% of the cores. Sysbench works 10x better on 64-bit, different versions give different results. Version 1.xx does the test 10s and gives the amount of events. GIMP only uses 1 core, works better on 64-bit. GTKPerf tests desktop speed. It only uses 1 core. CPU Miner only works on 64-bit. Works better in Ubuntu Bionic than in Debian Stretch/Ubuntu Xenial. Blender : BMW render @ 1080p Gimp : BMW render result 1080p Filters -> Artistic -> Van Gogh -> ok Sysbench : sysbench --test=cpu --cpu-max-prime=20000 --num-threads="number of threads" run 7-zip : Numbers are average of 3 of decompressing only All tests are done with a fan when necessary so no throttling occurs. 64-bit SBC's NanoPC T3+ |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Armbian Bionic http://ix.io/1iRJ 10.99kH/s 1290 10254 1h10m25s 1m24s 10.11s 21692 Arbmian Stretch http://ix.io/1qiF 8.55kH/s 1275 10149 1h13m55s 1m32s 11.06s 3.2s NanoPi M4 |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Armbian bionic http://ix.io/1nLh 10.23kH/s 1335 2005 8352 1h13m50s 0m29s5 5.06s 26763 Armbian bionic nightly http://ix.io/1pDo 10.24kH/s 1329 1990 8292 1h13m28s 0m29s 5.12s 26733 Armbian stretch desktop http://ix.io/1odF 8.66kH/s 1350 1977 8400 1h14m12s 0m31s 5.24s 3.1s Armbian stretch dsk nightly //ix.io/1pM0 8.80kH/s 1359 1993 8500 1h15m04s 0m31s 5.32s 3.3s Armbian stretch core no fan //ix.io/1pKU 8.80-8.65kH/s 1353 1989 8461 Armbian stretch core //ix.io/1pL9 8.76kH/s 1354 1988 8456 Armbian stretch core nightly //ix.io/1pLf 8.82kH/s 1357 1994 8494 Lubuntu Bionic arm64 http://ix.io/1oGJ 9.24kH/s CPU Miner 1056 1551 6943 1h28m13s Lubuntu Bionic armhf http://ix.io/1pJ1 1111 1769 7705 2h02m54s 0m57s 6.97s 1666 32-bit Lubuntu Xenial armhf http://ix.io/1oCb 989 1507 6339 2h20m51s 0m59s 49.77s 49.7s 32-bit Khadas Vim2 Max |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Ubuntu Xenial http://ix.io/1qkA 6.86kH/s 823 1134 6682 1h14m39s 1m53s 16.26s 3.8s Armbian Bionic http://ix.io/1qnY 8.55kH/s 921 1272 7464 1h17m52s 1m32s 12.54s 19035 Odroid C2 |SBC bench result |CPU Miner |7-zip big core |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Armbian Stretch Core http://ix.io/1pZu 4.65kH/s 1390 5342 Armbian Stretch Core Nightly //ix.io/1pZJ 4.66kH/s 1391 5340 Armbian Stretch Desktop http://ix.io/1q1C 4.65kH/s 1394 5363 1m23s 11.66s 5.96s Armbian Stretch Desktop NGHT //ix.io/1p02 4.59kH/s 1394 5356 2h38m18s 1m23s 12s 6.0s Ubuntu Mate Bionic http://ix.io/1q2S clocked to 100Mhz 2h35m10s 1m17s 10.01s 12026 Ubuntu Mate Bionic OC Doesn't work/Clocked to 100Mhz 1607 5960 2h10m21s 1m09s 8.94s 13755 Rock64 |SBC bench result |CPU Miner |7-zip small core |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Armbian Stretch 1.5Ghz http://ix.io/1nCj 4.06kH/s 1406 5407 3h00n32s 1m39s 15.91s 7.0s OLD Armbian Stretch 1.3Ghz //ix.io/1iHB 3.80kH/s 1211 4904 Armbian Bionic 1.5Ghz core //ix.io/1qbK 5.00kH/s 1384 5379 10.0s Armbian Bionic 1.5Ghz dsk //ix.io/1qcb 4.94kH/s 1379 5326 2h55m56s 1m31s 15.00s 10172 32-bit SBC's Odroid XU4 |SBC bench result |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Debian Jessie http://ix.io/1q6X 950 1653 8823 1h12m19s 1m08s 18.53s 41.3s Ubuntu Bionic http://ix.io/1qbL 1219 2094 9395 1h44m19s 1m10s 14.36s 2200 Asus Tinker board |SBC bench result |7-zip big core|7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Tinker OS 9.5 Stretch http://ix.io/1pRN 1983 7536 2h55m00s 1m19s 189.82s 63.7s Raspberry Pi 3B+ |SBC bench result |7-zip small core |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Raspbian Default no fan http://ix.io/1q10 1471 5027 2m09s 9.85s 88.2s Raspbian Default http://ix.io/1q1Q 1411 5371 5h47m31s 2m09s 10.04 79.5s Raspbian OC http://ix.io/1q5J 1591 6141 1m55s 8.81s 70.8s Ubuntu Mate Xenial http://ix.io/1q65 7-zip didn't work 2m17s 11.71s 90.5s Raspberry Pi 3B |SBC bench result |7-zip small core |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench Raspbian Stretch : http://ix.io/1qob 1220 4681 2m31s 10.97 93s Software versions ----------------- GIMP Blender GTKPerf SysBench SBC-bench M4 : Lubuntu Xenial armhf 2.8.18 2.79b 0.40 0.4.12 0.6.1 Lubuntu Bionic armhf : 2.8.22 2.79b 0.40 1.0.11 LuaJIT 2.1.0-beta3 0.6.1 Armbian Stretch desktop 9.5 : 2.8.18 2.79b 0.40 0.4.12 0.6.1 Armbian Bionic : 2.8.22 2.79b 0.40 1.0.11 LuaJIT 2.1.0-beta3 0.6.1 Tinker : TinkerOS 9.5 Stretch : 2.8.18 2.79b 0.40 0.4.12 0.6.1 Odroid C2 : Armbian Stretch 9.5 : 2.8.18 2.79b 0.40 0.4.12 0.6.1 : Ubuntu Mate Bionic : 2.8.22 2.79b 0.40 1.0.11 LuqJIT 2.1.0-beta3 0.6.1 Doesn't work clocks to 100Mhz Rock64 : Armbian Stretch 9.5: 2.8.18 2.79b 0.40 0.4.12 0.6.1 : Armbian Bionic : 2.8.22 2.79b 0.40 1.0.11 0.6.2 RPi 3B : Raspbian Stretch 9.5 : 2.8.18 2.78a 0.40 0.4.12 0.6.2 RPi 3B+ : Raspbian Stretch 9.5 : 2.8.18 2.78a 0.40 0.4.12 0.6.1 Ubuntu Mate Xenial : 2.8.16 0.40 0.4.12 0.6.1 Odroid XU4 : Debian Jessie : 2.8.14 2.72b 0.40 0.4.12 0.6.1 7-zip doesn't work : Ubuntu Bionic : 2.8.22 2.79b 0.40 1.0.11 0.6.2 NanoPC T3+ : Armbian Bionic : 2.8.22 2.79b 0.40 1.0.11 0.4.6 Armbian Stretch : 2.8.18 2.79b 0.40 0.4.12 0.6.2 Khadas Vim2 Max : Ubuntu Xenial : 2.8.16 2.76b 0.40 0.4.12 0.6.2 Armbian Bionic : 2.8.22 2.79b 0.40 1.0.11 0.6.2 CPU Clocks ---------- NanoPi M4 : Armbian Bionic/Stretch : 2x2Ghz + 4X1.5Ghz 64-bit Lubuntu armhf/ARM64 : 2x1.8Ghz + 4X1.4Ghz armhf 32-bit / ARM64 64-bit Tinker Board : TinkerOS Stretch : 4x1.8Ghz 32-bit Odroid C2 : Armbian Stretch : 4x1.5Ghz 64-bit Ubuntu Mate Bionic : 4x1.5Ghz RAM 912Mhz 64-bit Ubuntu Mate Bionic OC : 4x1.75Ghz + RAM 1104Mhz 64-bit Rock64 : Armbian Stretch : 4x1.5Ghz 64-bit Armbian Bionic : 4x1.5Ghz 64-bit RPi 3B+ : Raspbian Stretch : 4x1.4Ghz no fan 4x1.2Ghz above 60°C 32-bit Raspbian Stretch OC : 4x1.570Ghz over_voltage=4 core_freq=500 sd_freq=510 32-bit Ubuntu Xenial : 4x1.4Ghz 32-bit Odroid XU4 : Debian Stretch : 4x1.4Ghz + 4x1.9Ghz 32-bit : Ubuntu Mate Bionic : 4x1.5Ghz + 4x2Ghz Underclocks when above 75°C 32-bit NanoPC T3+ : Armbian Bionic : 8x1.4Ghz 64-bit Some benchmark tools can give an estimate of the performance. But they are never an exact reflection.

I see multiple projects on GitHub for getting RTL8812AU devices working on Armbian. Right now, I'm working with a NanoPi M1 while I wait for a rock64 to arrive in the mail. I can get a driver to build, make and make install, but I cannot get the device recognized. The last project I tried was this: https://github.com/diederikdehaas/rtl8812AU

Hi Balbes Like nytoc, during boot it could not find rootfs This is a H96Max+ ,, board labeled RK3328_8D4_V1.1 It has sv6501P wifi About 1/2 the dtb don't even start to boot, evb-android, both rock64, roc-cc, box-liantong The rest, evb, box, box-z28, box-trn9, rockbox, all have no mmc (ls /dev/block} They will all boot with rootfs on usb stick obviously uboot can read mmc, since uinitrd gets loaded (and kernel) Once or twice, booted only with usb, I'm not sure which, maybe box or rockbox The next update, please compile ssv6051 module I tried to strip the dtb out of resource.img, doesn't boot (mmcblk2p5) Maybe there was more in that 8M partition, the dtb <60K The android on it (8.1) is 4.4.140 (and rooted, that's how I got resource.img) thanks for the work --more-- There was no way I could make it go to maskrom with the button, maybe there is a trick,, also could not do adb with usb,, lsusb never showed it Had to use wireless adb

there have been VLAN CVE, rather encounter a security issue down the road - eliminate the problem with separate NICs. simple is always best Mainline kernel has support. You may lose some HW features but patching is not too hard, fortunately I only need firewall and QoS so that shouldnt be an issue. yup it was the the last board I ever helped kickstart. Now I wait to see if a board survives to mass production - like the Pi. I did back Parallella and was pleasantly surprised but that speaks to the caliber of the people working on the project. The founder is now a DARPA AI/compute project lead. I am pretty excited about the Ryzen V1000 boards coming out. if you look at the "companies" releasing the boards, you'll see its the same people under a different "brand" name. If you have lots of money to burn and want to encourage more bad boards, sure buy them all. I'll wait and see what survives. The smaller companies have to make a profit to survive unless they have tons of investment or are part of a much larger company. I mean look at Asus Tinkerboard, it still has issues and it used a few year old SoC and was made by a Tier 1 x86 motherboard manufacturer. Yes, have given up on any type of router boards - looking at the block diagrams and datasheets will reveal numerous issues.. Old x86 server I have around, it E3 Xeon uses ~25W since its server hardware. You can get older Xeons on ebay for very cheap.. But thats still 5x more vs a typically router ~5W. I forgot I also got a Linksys AC1200 refurb for $USD 40 which has an A385 . Was testing LEDE and ZFS on it. Will be putting debian on it now and will likely meet my needs. Yes, that's why industrial boards are expensive in addition to better spec-ed components. But I'm not looking for an industrial board - just one that has proper hardware at least, the software I can be fix. However, the NXP board I mentioned has an EXCELLENT BSP and hardware and support and its $50.. perhaps its subsidized as NXP to sell more chips since NXP is usually pretty expensive SoC-wise. I'd like to see any other manufacturer come out with something of comparable quality. Thank you for sharing. Most people don't know the difficult to bring a physical product, much less consumer electronics to market. Fortunately, one of my advisors helps manage supply chain for a certain fruit company. Their advice and experience was invaluable. After being burdened by one investor, I have learned to CAREFULLY read the legal and informal obligations of any contract/partnership and look for potential pitfalls, lest I be shackled again. One SoC vendor wanted free reign over our IP as they could be "independently" developing similar products and they had already released a similar product with a competitor. I declined. It sucked having to search for a new SoC vendor but it worked and we sold a good product. A year later we started talking again for a new project and they are more flexible having seen our success. Its unfortunate you couldn't manufacture in China, because then you could also do the regulatory testing/certifications in the area (HK, Taiwain or Shenzhen). The same testing/certification facilities used by Tier 1 motherboards manufacturers will provide testing services including the one you mentioned for USD $5K - $15K depending on what all you need. RF products will cost more. Glad to hear that you had an exit. Congrats Yes, out of all the community boards the EspressoBIN seems OK. The Marvell chips are fairly robust and the capabilities/performance aligns with the datasheet specs. However, after discussing the boards with GlobalScale I got an errie feeling similar to working with other SoC manufactures so I backed out and wanted to wait until launch. It was delayed over half a year and the end result is what you have now. They did release some Google Compute related boards so perhaps they are more focused on that but I got the sense they didn't really care about the community version board. I mean everyone wants Raspberry Pi level success and they seem to think the form factor is what does it, when its the fact they to long term support and committed part of their team to continue improving the BSP. "More wood behind fewer arrows". Rock64 says the same thing but shows different results. Releasing multiple boards with different SoCs with a small team will spread any small company too thin. Current SBC methodology is fire and forget and see what sticks. That generally works with software products but definitely not with hardware. Hence the bucket of EoL ARM devices that I and many others have sitting in the corner collecting dust. Hence why I refuse to support anymore campaigns without showing substantial thought into the product. Things do seem to be getting better as a couple mfgs are joining mainline kernel development and submitting patches and supporting projects like armbian. Just wish it didnt take companies 5 years to realize this.. The first "SBC" MK802 with Allwinner A10 was what changed the game back in 2012 and kicked off this SBC revolution and helped create a space which eventually gave us the Pi though the story with the Pi is it was built to get kids back into computers. Anyway I'm confident things will get better one way or another!

Actually you can always use VLAN to implement such firewall or router, combined with a switch which supports 802.1q aka VLAN tagging. The drawback is that you can only have 1Gbps in a single direction. BTW, internal GbE on devices like ROCK64 don't do well in these scenarios, because when running Ethernet in full duplex, its CPU reaches 100% (single core), and the full duplex throughput is only around ~400Mbps. An RTL8153 attached to the USB3, however, does this job quite well. The CPU consumption stays very low even when stress testing full duplex. However Ethernet over USB sometimes has stability issues. I think these issues are the ones that could not be avoided when evaluating cheap devices. It's a trade off.

Gah - watched the video - and a lot of problems across the board (pardon the pun). Different kernels, built with different versions of GCC, userland (for example, Raspbian userland is all ARMv6 with exception of the kernel for the A7/A53 boards).... (I wouldn't have included the any of the Pi's in the set of boards being evaluated because of the userland - <soapbox> nothing against Pi's in general, one must appreciate that 35M+ boards means they're doing something right, and they've spawned an entire HW/SW ecosystem around their platform, that's ok - and that ecosystem has in turn made affordable ARM boards available for hobbyists, makers, and developers - before Pi, if one wanted to do development around ARM, boards were expensive, and SW support was very limited to the vendor BSP - these days, it's a lot more open - not perfect, but much better than it was</soapbox>) Rock64 vs Odroid XU4 - Quad A53 vs A7/A15 big.LITTLE - the big.LITTLE is a challenge for the scheduler, and depending on the BSP from the OEM, it's easy to get wrong, where threads can land on the lesser preferred core, this is an issue even on Android, where much work has been done outside of the mainline kernels (ARM and Qualcomm, I know they've done a lot of research there, but much of that has not been pushed back to mainline). In my experience, with supported boards (for me this is Tinker and NanoPi NEO), Armbian is generally faster than the vendor's images - and that's doing Byte-Unixbench, which is discounted because it is compiler sensitive - that being said, it's still a useful tool when comparing apples to apples (e.g. tweaking settings on the same OS/Platform, but comparing Platform A to Platform B, one has to take the results with a grain of salt) I haven't found a lot of evidence of cheating by any of the SBC vendors - it's really hard to do with FOSS, compared to Android, where cheating has occurred with certain OEM's and specific benchmark APK's - Android has enough hooks to enable this kind of cheating in any event. sbc-bench, in my humble opinion, is a good benchmark for supported boards - as long as the boards being compared are all on the same version of Armbian - and this is made clear in the script comments (please review the script on github, and @tkaiser has been pushing updates, so if one has cloned the repo, it's worthwhile to do a git pull to get the latest revision. To answer your question about the different versions of Cortex... Small Cores - A7, A53 are the low power cores focused on efficiency Big Cores - A15, A12(A17), A72 - big cores... Think of it like Atom (Small Core) vs Core i3/i5/i7 (Big Core) - even at the same clock, the big core is going to get more work done, but perhaps at the cost of heat, so thermal solution needs to be considered.

The BPi R1, R2 and W2. All above $50. But you've got to pay what it costs, manufacturers aren't going to change prices. No idea about the software support for them. EspressoBin is a good choice. https://www.amazon.com/ESPRESSObin-SBUD102-Single-Computer-Network/dp/B06Y3V2FBK You can also buy a Rock64 and add USB3 network adapters. Enough choice, you only have to make it work...

@tkaiser Hi Thomas. I'm planning to make a video about the use/uselessness/problems of benchmarking SBC's. Today I got a message from a subscriber about the Odroid H2, where he claimed the XU4 was a very slow SBC. His claim was backed up by "benchmarks" from ExplainingComputers. Here are those results. Video ExplainingComputers : &nbsp;Six SBC Benchmark: ODROID XU4, ROCKPro64 & More! Here the ROCK64 seems to outperform the XU4. We all know that's not right. I would use SBC-bench if ok for you and Blender to show the difference in results using different platforms, kernels and settings on the same SBC. I think with the M4. Lubuntu xenial armhf vs Lubuntu bionic armhf vs Lubuntu bionic arm64 and Armbian stretch vs bionic. Those differences are big. And the Raspberry 3B+ with ram overclock and without to show importance of ram+cpu. I would make different subjects. Of which : Problems with Benchmarks and sollutions SBC-Bench (how does it work, what does it do) Differences between different cortexes A7, A53, A72, ... (I'll need to do a lot of homework for that, if you could elaborate on it, please do) Importance of RAM speed with CPU speed, and other parameters Cheating manufacturers (Amlogic with C2, Raspberry Pi with 3B+, any others I should mention?) Conclusion... So with this I ask your permission to use SBC-bench, and quote you out the readme.md and eplanations and insights in the results.md file. And if you would like me to mention something, please tell me. Or if you want you could record an audio/video file with your words to add in the video(just a thought) Did you start a draft for the "Interpreting results" part yet? I'll be busy for at least another week gathering information. When done I'll share my results, and I''ll say what I'm going to use from your texts in the video. Sorry for the long post. Greetings.