Search the Community

Is it possible to share a board family between Rock64 and RockPro64? If they could use exactly the same kernel source and u-boot source from ayufan... Use armbian-config and switch to nightly build, and you'll get the latest kernel.

This gives an aes-256-cbc score of 274785 at 8k. And this is 368675. Those OpenSSL numbers are great since they do not depend on anything else other than existence of ARMv8 Crypto Extensions so we can draw conclusions from benchmark result to Cortex-A53 clockspeed. Comparison chart: https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829 An Allwinner H5 clocked at 816 MHz scored 380482 back then so the 368675 we get is a clear indication of slightly below 800MHz. Same with the 274785 number --> slightly below 600 MHz. So with 600 settings it's really 600 MHz (~596) and the 1000 settings use a divider that seems to be somewhat off (1000 MHz being 795 in reality). Interestingly in the above result collection there are EspressoBin numbers that indicate that some time ago we were running at close to 1000 MHz (462012). Numbers were generated exactly one year ago with no kernel cpufreq support back then: https://forum.armbian.com/topic/4089-espressobin-support-development-efforts/?do=findComment&comment=37981

I'm not sure whether this is the correct place. Sorry if it isn't and please move it to where it belongs - thanks! The problem is: in our community (forum.iobroker.net) came up problems with mounting to a nas by cifs. ioBroker is a smart home management, and a new module ("adapter") has been designed to provide automated backups to a nas. in most cases this works fine, but on some platforms with armbian it fails with the message: cifs filesystem not supported by the system I'm not that linux crack, but i tried to find out what could cause this, I found at this site https://www.linuxquestions.org/question ... 175593855/ some help. In all versions the message mentioned above occured /proc/filesystems didn't contain cifs in the versions the backup worked, cifs was included. At the moment we have confirmed it at orangePi plus2e (ARMBIAN 5.38 stable Ubuntu 16.04.5 LTS 4.14.4-sunxi) and I could reproduce it on a Rock64 (nightly Ubuntu 16.04.5 LTS 4.4.131-rk3328) ( I know it's nighly!!) The platforms will have different age of images, and the users will not have updated/upgraded It seems that the problem occurs only at Ubuntu based images (cifs-utils already installed and at newest version), not at Debian based. on A Tinkerboard Ubuntu image (Ubuntu 16.04.5 LTS 4.4.120-rockchip) all is ok, so it is not at all ubuntu images. calling: sudo modprobe cifs on my rock64 installation, the response was modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/4.4.131-rk3328/modules.dep.bin' modprobe: FATAL: Module cifs not found in directory /lib/modules/4.4.131-rk3328 Is this a common issue and known? And the more imortant question: What can be done? thanks for every help in advance Rainer

Yep. What happens if you call 'sudo depmod'? If it succeeds then another time 'sudo modprobe cifs' would be interesting. On Rock64 the cifs module should be built as module and therefore modprobe should work. Unfortunately our settings are not consistent accross kernels: macbookpro-tk:kernel tk$ egrep "CONFIG_CIFS |CONFIG_CIFS=" * | grep -v 'CONFIG_CIFS=m' linux-mvebu-dev.config:CONFIG_CIFS=y linux-mvebu-next.config:CONFIG_CIFS=y linux-mvebu64-dev.config:# CONFIG_CIFS is not set linux-mvebu64-next.config:# CONFIG_CIFS is not set linux-odroidc1-next.config:# CONFIG_CIFS is not set linux-qcomlt-default.config:# CONFIG_CIFS is not set linux-rockchip-dev.config:CONFIG_CIFS=y linux-rockchip-next.config:CONFIG_CIFS=y linux-s5p6818-default.config:# CONFIG_CIFS is not set linux-sun4i-default.config:CONFIG_CIFS=y linux-sun5i-default.config:CONFIG_CIFS=y linux-sun7i-default.config:CONFIG_CIFS=y linux-sun8i-default.config:CONFIG_CIFS=y linux-udoo-default.config:# CONFIG_CIFS is not set

Usually you do not want an USB hub between host and disk, especially if disk accesses happen in parallel. Since all RPi just have one single USB2 port there's always one (internal) hub involved if you're not using an RPi Zero. The RPi Trading 'geniuses' when mixing ingredients for their latest update of the platform chose a combined Ethernet/hub thingy (LAN7515) that does not only suck when it's about networking but also contains not just one but two internal hubs in a cascaded fashion. So with your external hub you might already have 3 cascaded hubs between host port and disks. Terrible. Also RPi 3 and 3+ are one of the few 64-bit capable SBC that do not implement ARMv8 Crypto Extensions and therefore suck horribly when it's about AES performance: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md While I personally consider mdraid-1 just a weird waste of disks obviously you want to access your both disks concurrently and fast. As already mentioned: combining any cheap USB3 equipped SBC like Rock64 with the JMS561 thing will work fine with HDDs or you could use an EspressoBin with one disk connected to the SATA and the other to the USB3 port. Or using an PCIe attached SATA controller on those PCIe capable boards. Just a matter of money you want to spend on the setup. Since all HDD suck horribly at random IO I personally would also consider USB3 combined with good UAS capable SATA bridges since... fast enough. But USB3 when you have to use the USB3-A connector can be a real sh*t show since connection issues are quite common with this crappy connector. There was a RK3399 board announced a while ago called Rock960 Pro with an JMS561 on the PCB providing 2 SATA ports suitable for HDDs but no idea what has happened (@hipboi asked me whether I want a developer sample some time ago but we did not succeed for whatever reasons)

I found this thread in LibreElec forum: https://forum.libreelec.tv/thread/12664-a5x-max-rk3328-a53/ And I tried latest image from https://github.com/Kwiboo/LibreELEC.tv/releases At the time of writing that is LibreELEC-ROCK64.aarch64-8.2-devel-20171004193222-r26173-gd404dbb.img.gz zcat LibreELEC-ROCK64.aarch64-8.2-devel-20171004193222-r26173-gd404dbb.img.gz | dd of=/dev/<sd card device> bs=1M Just insert SD card, apply power and you get LibreElec. Well, it is without WiFi at the moment and probably some other things might not work. But it means it is possible to boot from SD card and have linux running on this box. So, little bit of info from that site... bit of tinkering with armbian root image and we should have cheap linux server with 4GB of RAM, running from SD card. I'm not sure I can do it... but I might try. I am very interested in getting headless linux server running on that box. EDIT: Looks like Armbian Rock64 image has hardcoded DTB in bootloader (first 16MB of SD card): fdtfile=rockchip/rk3328-rock64.dtb So that is difficult to change... or you could replace contents of that file... BUT read on... It also looks like DTB is embedded into bootloader part of the SD (starting at ABOUT 0x00A916E8 - not exact number, look there and you see DTB info). So even changing DTB filename or replacing rk3328-rock64.dtb contents with something else will probably have no effect at all. So everthing relating to DTBs is built into bootloader at compile time and altering it is difficult. To build Arbian release for our box we probably have to take full source package, modify it, and build our own image. OR... maybe we can replace DTB embedded into bootloader... I will look into it. If there is (enough) empty space at the end, I will try to overwrite DTB. I have this box sitting on the shelf for at least half a year now... would be nice if I finally can use it for what I wanted it for. Another edit: Maybe Armbian image is not meant to be flashed to SD card but into eMMC. That also might be the reason why it is not working.

pine64 products have sloppy DC connectors. This connector simply detaches from the motherboard. I use in production pine64 pine64-lts pineH64 and rock64. As a result of switching on and off the dc connector, in each case it has peeled off and does not hold power. I've attached the DC connector with glue but that's not what the factory mount. The low price now goes sideways. workmanship worse than nonopi.

I tried compiling Debian 9 Full OS Image with Desktop using BRANCH=next and default kernel configs for * NanoPi K1 * Rock64 * OrangePi Plus 2E And all failed at the end: Errors were encountered while processing /tmp/apt-dpkg-install-LTKPXl/621-numix-icon-theme_0.3+922~201711061547~ubuntu16.04.1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) [ error ] ERROR in function create_rootfs_cache [ debootstrap-ng.sh:213 ] [ error ] Installation of Armbian packages failed [ o.k. ] Process terminated [ error ] ERROR in function unmount_on_exit [ image-helpers.sh:59 ] [ error ] debootstrap-ng was interrupted I am using the 18.04 minimal image in a virtual box. It worked a month ago. It works today for Ubuntu Full OS image with Desktop and BRANCH=next. Thanks.

these photos are pine64-lts ( 1 ) and rock64 ( 2,3). I have to gluted both. Barrel from rock64 was very frequently used. ( year old ). Not good quality from pine.

Can you provide some pictures for your claims? I only had a rock64 in my hands recently.. but the barrel plug looked just like every other barrel plug. Didn't saw something obviously bad.. What part gets detached? the soldering joints or is the plastic part of 'bad quality'?

Ayufan’s Armbian on a V88 Piano or V88 Mini III These two TV boxes seem to be electrically identical except that the V88 Mini III has 2 GB RAM and 8 GB ROM whereas the V88 Piano has 4 GB RAM and 16 GB ROM. They use the same PCB as can be seen from the photos in these FreakTab topics:- - http://freaktab.com/forum/tv-player-support/rockchip-based-tv-players/rk3328-devices/681869-scishion-v88-piano-tv-box-rk3328-4gb-ram-16gb-rom-android-7-1-usb-3-0-fast-lan - http://freaktab.com/forum/tv-player-support/rockchip-based-tv-players/rk3328-devices/663248-scishion-v88-mini-iii-tv-box-rk3328-2-8gb-2-4-wifi-fast-lan I do not have a V88 Mini III to test but I believe that my results for the V88 Piano should also be relevant to it. N.B. many sites claim that the V88 Piano has Gigabit Ethernet (1000 Mbps). It does not: it only has Fast Ethernet (100 Mbps) like the V88 Mini III. One nice thing about these TV boxes is that, unlike many others, they will boot easily from a micro-SD card. Just insert the card and power on My aim was to have Ubuntu running with all version-specific partitions (boot and root) on a USB drive. I wanted to keep Android in the internal eMMC so that I could dual-boot by just inserting or removing the micro-SD card. I wanted to have the root partition on a USB stick for three reasons: 1) A good USB stick is faster than a micro-SD card. 2) This avoids the system writing repeatedly to the micro-SD card because, if the root partition is on the micro-SD card, after a while it gets corrupted and will no longer boot. This happened to me with both a cheap Ansonchina card and also with a Kingston card. Maybe the write timings in the micro-SD card driver are incorrect. 3) Whilst experimenting on Amlogic boxes I have fried two big micro-SD cards. I have read that others have fried cards on Rockchip boxes. Moving the rootfs to a USB stick enables me to use a smaller and cheaper card. (I suspect that they were destroyed by over-voltage due to a badly programmed regulator. With a 5 V USB stick and a 5 V PSU there should be no risk as I don’t think the regulators used can step up the voltage.) I also wanted the boot partition to be on the USB stick so that I could have several GNU/Linux distributions on different USB sticks and boot with the same unmodified micro-SD card containing just the boot loaders. I have deliberately avoided the necessity to have a Linux (or even Windows) PC. N.B. the Ubuntu system will not (yet) have working Wi-Fi. You will need:- - a rooted V88 Piano (mine was sold pre-rooted) - a micro-SD card: mine was 8 GB but 4 GB should suffice - a USB Flash Drive: I have used both 32 GB and 8 GB but 4 GB may suffice for a fairly minimal system - a USB keyboard (and mouse if installing a desktop): I used a wireless mini-keyboard/mouse - a wired (RJ45) Ethernet connection with DHCP and Internet access - an HDMI display WARNING: before using a /dev/ or /dev/block device verify that you are using the correct one, using dmesg for instance. Otherwise you could overwrite precious data. However if you remove all additional USB drives the names below should be correct. The login is rock64 with password rock64 which is also required for sudo. First step – install Ayfan’s Ubuntu Xenial Minimal 0.5.15 on a micro-SD card and prepare 0.6.25 on a USB stick. Boot Android. I installed and used Google Chrome for the following downloads because, with the stock Lightning browser, I couldn’t see when the download had finished. (The busybox wget can't be used because it doesn’t support https.) Open https://github.com/ayufan-rock64/linux-build/releases/tag/0.5.15 in the browser. Download xenial-minimal-rock64-0.5.15-136-arm64.img.xz If you wish to pass directly to Ubuntu Bionic you could use the Bionic 0.6.25 image instead of Xenial below. However this may make it more difficult to update U-Boot later as I think a Xenial environment is expected to compile it. Open https://github.com/ayufan-rock64/linux-build/releases/tag/0.6.25 in the browser. Download xenial-minimal-rock64-0.6.25-193-arm64.img.xz Insert the micro-SD card and the USB stick. N.B. all existing files on both will be destroyed. You will be asked how to use the USB stick: choose "removable storage" and "cancel" if asked whether to format it. Execute the following actions and commands (in the text following the $ or #). Install and start ConnectBot. Open a local shell. Become root. $ su Enter the directory where browsers save downloaded files. # cd /sdcard/Download Decompress the files. # busybox xz -d xenial-minimal-rock64-0.5.15-136-arm64.img.xz # busybox xz -d xenial-minimal-rock64-0.6.25-193-arm64.img.xz Write the 0.6.25 image to the USB stick. # dd if=xenial-minimal-rock64-0.6.25-193-arm64.img of=/dev/block/sda bs=1048576 Write the 0.5.15 image to the micro-SD card. # dd if=xenial-minimal-rock64-0.5.15-136-arm64.img of=/dev/block/mmcblk1 bs=1048576 Ensure everything is written. # sync Power off the box. Second step – boot Ayfan’s Ubuntu Xenial Minimal 0.5.15 and prepare the switch to 0.6.25 on the USB stick. Insert the micro-SD card. Boot and login (rock64/rock64). Become root. $ sudo -s Remove partitions 6 (boot) and 7 (root) from the micro-SD card so that U-Boot and Linux will use the ones on the USB stick next time. Luckily this only deletes their entries so Linux can continue to use them until they are unmounted. Reply "Yes" and "Ignore" to the warnings. # parted /dev/mmcblk1 rm 6 rm 7 q # poweroff Third step - boot Ayfan’s Ubuntu Xenial Minimal 0.6.25 from the boot and root partitions on the USB stick and prepare to update to a recent version. Insert the USB stick in the middle USB slot and insert the micro-SD card. Boot and login. $ sudo -s This DHCP configuration will be necessary for Bionic. # cd /etc/network/interfaces.d # sed s/eth0/eth1/ eth0 > eth1 At the time of writing there are only pre-release versions of 0.6.x but Ayufan has promised an official release shortly after the official release of Bionic due on 24th April. If, in addition to Ubuntu updates, you want to update to Auyufan's pre-release versions with an added risk of instability then: # vi /etc/apt/sources.list.d/ayufan-rock64.list Uncomment the last line # apt update The following lines are necessary if you update to a more recent Ayufan version which will disable eth1: This is needed to re-enable eth1: # apt install device-tree-compiler Make rc.local enable eth1 which is disabled in recent versions and disable eth0 which is not used on the V88 Piano: # vi /etc/rc.local Add these two lines just before the last line (exit 0): enable_dtoverlay eth1 ethernet@ff550000 okay enable_dtoverlay eth0 ethernet@ff540000 disabled # apt dist-upgrade -y If you want a Mate desktop you can: # install_desktop.sh mate This gave me an error which I corrected with: # apt -f install If you wish you can also upgrade from Xenial to Bionic with do-release-upgrade. # reboot You should now be running an up-to-date version with the boot and root partitions on the USB stick. The next step will be to compile and install a more recent U-Boot supporting the USB 3.0 port correctly. To be continued... The procedure above may seem convoluted so here are some additional explanations. 0.5.15 is used for its boot loaders as it is the latest version which will boot directly from a micro-SD card. Unfortunately it does not have working Ethernet and its U-Boot will not load correctly from the USB 3.0 slot. 0.6.25 is used because it has working Ethernet to install device-tree-compiler which is needed to re-enable eth1 on recent versions.

I am a beginner so be carefull to my opinion I see Scishion V88 Piano and V88 Mini III TV boxes work on Kernel 4.4.132 Ubuntu 18.04.1 LTS with https://github.com/ayufan-rock64 ( we boot on sd and after we delete partion 6 and 7 boot on usb stick , because since version 0.5.15-136 it use SPL/TPL instead of Rockchip's loader, big thank's to segv ) This is RK3328 is low price ( begin at 35$ ) and looks like S905 ( same MALI-450MP2 and 4 Cortex-A53) BUT rockchip make mpp dev ... For other the RK3229 ( very low cost begin at 25 $ ) i don't see any linux booting well, does not support 10-bit HEVC, Mali-400 MP2 and 4 ARM Cortex-A7 ) The rk3399 the cost is more tahn 100$ and we have 6 core : 2 Cortex-A72 4 Cortex-A53 and Mali-T860 MP4. Better than the S912 but the cost is important. and the old RK3368, 8 cœurs ARM Cortex-A53 64 Bits, PowerVR SGX6110 but i don't see linux drivers on linux ... So my choice is for all RK3328 for start ... And if you want i can send you one.

so test : Software transcoding /home/rock64/bin/ffmpeg -vcodec h264 -i http://192.168.1.50:8001/+1:0:19:401:4:20FA:EEEE0000:0:0:0 -s 320x240 /tmp/test.avi resut = frame= 507 fps= 16 q=8.6 Lsize= 1058kB time=00:00:22.40 bitrate= 386.8kbits/s dup=0 drop=6 speed=0.703x Hardware Transcoding (only decode ) /home/rock64/bin/ffmpeg -vcodec h264_rkmpp -i http://192.168.1.50:8001/+1:0:19:401:4:20FA:EEEE0000:0:0:0 -s 320x240 /tmp/test.avi error = 0 Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scaler_0' Error reinitializing filters! Failed to inject frame into filter network: Function not implemented tested with some otehr file with ame result OK, i must find ...

For install with etcher write sd card with xenial-minimal-rock64-0.5.15-136-arm64.img.xz (not other ) with etcher write usb stick bionic-minimal-rock64-0.7.9-1067-arm64.img.xz (or better ) boot on sd witout usb stick delete partition 6 and 7 , reboot with usb stick, activate eth1 ( all explain in the post off segv ) i continue ...

Find solution : write in usb stick: bionic-minimal-rock64-0.7.9-1067-arm64.img.xz boot on sd with partion 6 and 7 deleted And ... Boot ok in 18.04.1 LTS

i make the list boot sd ok : xenial-minimal-rock64-0.5.7-101-arm64.img.xz xenial-minimal-rock64-0.5.15-136-arm64.img.xz and after it's stop, so i understand it's : 0.6.0: Use SPL/TPL instead of Rockchip's loaders (supports flashing and booting from SPI), Ok , so i try to find if i cand write it with a spi device

Escuse me (i have V88 mini 3 , 2G ram 8 emc ) , i don't want to use usb stick , only sd. i try Download xenial-minimal-rock64-0.5.15-136-arm64.img.xz and it's booting well on sd. I try lot of other img without sucess We need absolutly an usb stick for newer img ?

Hi, Just wanted to chime in here as I had a similar issue with a wifi adapter bought from Pine64. My issue began with the fact that the aforementioned adapter would just randomly lose connection to my wifi router and at that point I could not even see the device in the USB tree using the 'lsusb -t' command. In my case, I believe there was a hardware issue with the adapter I received so I decided on buying a new one, which used the same Realtek RTL8188EU chipset, namely a COMFAST CF-WU810N which works out of the box with the Rock64 in case anyone needs a compatible wifi adapter not sold by Pine64. More to the point of this thread, the configuration of the wireless interface on Armbian Xenial can also be done without the use of the "NetworkManager" service. Optional Step: I did not want to keep the horrid predictable/unique wireless interface name generated based on the device's MAC address so I added the below line in this file to assign it the name "wlan0". * Please note, you need to change the 'ATTR(address)' field with your device's MAC address and REBOOT your machine so the kernel assigns the new interface name. This change is reboot persistent and may be taken out by removing the "70-persistent-net.rules" file. $ cat /etc/udev/rules.d/70-persistent-net.rules SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="40:a4:3f:98:a1:xt", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="wlan0" $ Mandatory Steps: Configure the wireless interface with a static IP address as below: $ cat /etc/network/interfaces.d/wlan0 auto wlan0 allow-hotplug wlan0 iface wlan0 inet static address 192.168.1.10 netmask 255.255.255.0 #gateway 192.168.1.1 dns-nameservers 192.168.1.1 wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf $ Next, you need to create the "wpa_supplicant.conf" file, where the details of your SSID (wIreless network name) are stored like below. * Please note, you must change the 2 letter "country" code to your specific country, and the "ssid" & "psk" parameters to your network's name and password. $ sudo cat /etc/wpa_supplicant/wpa_supplicant.conf ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev update_config=1 country=<YourCountryCode> network={ ssid="YourWirelessNetworkName" key_mgmt=WPA-PSK psk="YourSecretPassword" } $ The last step implies performing a link down/up of the interface. ip link set interface_name down && ip link set interface_name up

Thanks @tkaiser. You're right, the use would be the same (gitlab-runner), except that it would build 64bits binaries. I also thought of using a S912 based TV Box, but I know nothing about its eMMC performances and it looks like it's a pain to install Armbian on these boxes. I will have a closer look to Rock64, thanks ($35.44 is a nice price tag to start). I will try to find a 2.5' SDD.

Rock64 (but their eMMC is neither super fast nor would I trust too much into it). Based on your other post the obvious choice is still Rock64 + their SATA cable + a great SSD.

I just checked also against RK3399 with A72 cores killed. Below 7-zip MIPS and cpuminer kH/s (all binaries built with GCC 6.3): RK3328: Renegade @ 1380 MHz: 3710, 3.92 kH/s (faster memory than Rock64) Rock64 @ 1380 MHz: 3610, 3.85 kH/s RK3399 (with A72 cores killed): NanoPC T4 @ 1415 MHz: 3920, 4.54 kH/s (way faster memory than the other boards) S905: NanoPi K2 @ 1480 MHz: 3850, 4.61 kH/s (slightly higher cpufreq) ODROID-C2 @ 1530 MHz: 3870, 4.63 kH/s (slightly higher cpufreq) S905X: Le Potato @ 1410 MHz: 3780, 3.92 kH/s (faster memory than Rock64) Unfortunately testing on NanoPi Fire3 with just 4 CPU cores is not possible since when trying to kill CPU cores the system deadlocks. Might need changed kernel config? root@nanopifire3:~# zgrep -i hotplug /proc/config.gz CONFIG_HOTPLUG_CPU=y # CONFIG_ARM_DYNAMIC_CLUSTER_HOTPLUG is not set # CONFIG_CPU_HOTPLUG_STATE_CONTROL is not set cpuminer allows to set CPU affinity but this doesn't work since still firing up 8 threads and then results are lower as expected (3.24kH/s): taskset -c 0-3 ./cpuminer --benchmark --cpu-priority=2 --cpu-affinity=0x15

Someone mentioned that the label "media" in the download image[link] is new. Is this script still required for GPU support? What is the equivalent of lspci for these things [arm sbcs - specifically rock64]. Is there anything like, in pi3, you can adjust the memory dedicated to gpu?

On https://www.aliexpress.com/store/product/Free-shipping-7-Inch-Android-4-4-Fashion-notebook-HDMI-Laptop-inch-Dual-Core-VIA-HDMI/4362013_32893471150.html you can buy a 7 inch display notebook. There is also a 10 inch display version. I am trying to determine which mainboard I would have the notebook to have. If main priorities are free software cf free software foundation's requirements and performance adequate for common debian utilization. To me it is at the same time having a running browser. 5 open tabs. One showing a youtube video. File manager running. Email client running. Running libre office or a media player or photo editor. It seems rk cpus are the ones to select among. If choosing between the rk3288 and rk3328 the rk3328 is the better choice? Can you answer if the free vpu software will work on the rock64 rk3328? the best choice for a notebook?

Just seen that your Rock64 results are with a 2GB. I'll do the same with my 4GB. Just interested if there's a difference with 7zip multicore. It's only 4-cores tho. Now doing Blender bench between Xenial default and nightly. Again just out of curiosity. I red it's now clocked to 1.39Ghz. I'll give you the sbc-bench results later if they're interesting. I don't think they will be. It's already 100%... Eidit : Blender just crashed on 1.39Ghz after 30minutes. At 1.3Ghz no problem : 1h17m55s I'll try again. Maybe it's not stable enough. 2nd try did it. So could be a fluke the crash. Xenial Rock64 4GB results : http://ix.io/1j7d Again very different than other distro's. I'm also wondering if zram would make a big difference with the 8-core 2gb devices? Cheers

Has the rk3328 and rock64 got free vpu software now cf tkaiser's link? What about the rk3399 and rk3288?