Search the Community

Hi. I have a Odroid XU4 with Ubuntu Bionic latest release (5.60), powered with this UPS: APC SmartUPS 750 VA. Apcupsd doesn't work. The problem seems related to the missing /dev/usb/hiddev0. After searching on Google, I found that apcupsd requires this feature enabled in the kernel. CONFIG_USB_HIDDEV=Y I build my own kernel enabling it, but no change. Here the output of the command # dmesg | grep Smart [ 4.125553] usb 1-1.2: Product: Smart-UPS 750 FW:651.13.I USB FW:7.3 [ 4.205622] hid-generic 0003:051D:0002.0001: hidraw0: USB HID v1.10 Device [American Power Conversion Smart-UPS 750 FW:651 On the Rock64 board it works without problem. Here the output of the command # dmesg | grep Smart [ 2.175796] usb 3-1: Product: Smart-UPS 750 FW:651.13.I USB FW:7.3 [ 3.719981] hid-generic 0003:051D:0002.0001: hiddev0,hidraw0: USB HID v1.10 Device [American Power Conversion Smart-UPS 750 FW:651.13.I USB FW:7.3] on usb-ff5d0000.usb-1/input0 As you can see, on the Rock64 board there is hiddev0 hid-generic 0003:051D:0002.0001: hiddev0,hidraw0 and /dev/usb/hiddev0 exists. In the Odroid forum, I found only this post about CONFIG_USB_HIDDEV https://forum.odroid.com/viewtopic.php?f=93&t=28978 Thanks in advance.

Nope, everything as expected. The M4 number in the list https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md has been made with mainline kernel which shows way higher memory bandwidth on RK3399 (check the other RK3399 devices there). Cpuminer numbers differ due to GCC version (Stretch ships with 6.3, Bionic with 7.3 -- see the first three Rock64 numbers with 1400 MHz in the list -- always Stretch but two times with manually built newer GCC versions which significantly improve cpuminer performance) If you love performance use recent software...

I guess this script will never work on rock64: it has a RK3328 SoC and Mali-450 GPU. This script instead installs drivers for RK3288 which has a totally different and not compatible Mali-760 GPU

Hello everyone, got a question regarding the rock64 and the HDMI output. I installed armbian recently with the media test script provided in this board, but everytime I run xrandr, I get this: rock64@rock64:~$ sudo xrandr --listproviders Can't open display rock64@rock64:~$ xrandr --props Can't open display Xorg logs correctly identify that no display is enabled, also noted that glamor failed to start: [ 12.505] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 12.908] (II) Module glx: vendor="X.Org Foundation" [ 12.908] compiled for 1.19.2, module version = 1.0.0 [ 12.908] ABI class: X.Org Server Extension, version 10.0 [ 12.926] (II) LoadModule: "modesetting" [ 12.938] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [ 12.968] (II) Module modesetting: vendor="X.Org Foundation" [ 12.968] compiled for 1.19.2, module version = 1.19.2 [ 12.968] Module class: X.Org Video Driver [ 12.968] ABI class: X.Org Video Driver, version 23.0 [ 12.968] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 12.979] (II) modeset(0): using drv /dev/dri/card0 [ 12.979] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 12.979] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 12.979] (**) modeset(0): Option "AccelMethod" "glamor" [ 12.979] (==) modeset(0): RGB weight 888 [ 12.979] (==) modeset(0): Default visual is TrueColor [ 12.979] (II) Loading sub module "glamoregl" [ 12.979] (II) LoadModule: "glamoregl" [ 12.994] (II) Loading /usr/lib/xorg/modules/libglamoregl.so [ 13.270] (II) Module glamoregl: vendor="X.Org Foundation" [ 13.270] compiled for 1.19.2, module version = 1.0.0 [ 13.270] ABI class: X.Org ANSI C Emulation, version 0.4 [ 13.270] (II) glamor: OpenGL accelerated X.org driver based. [ 16.509] (II) glamor: EGL version 1.4 (DRI2): [ 16.509] EGL_MESA_drm_image required. [ 16.518] (EE) modeset(0): glamor initialization failed [ 16.518] (II) modeset(0): ShadowFB: preferred NO, enabled NO [ 16.518] (II) modeset(0): Output HDMI-1 has no monitor section [ 16.518] (II) modeset(0): EDID for output HDMI-1 [ 16.518] (II) modeset(0): Output HDMI-1 disconnected [ 16.518] (WW) modeset(0): No outputs definitely connected, trying again... [ 16.518] (II) modeset(0): Output HDMI-1 disconnected [ 16.518] (WW) modeset(0): Unable to find connected outputs - setting 1024x768 initial framebuffer [ 16.518] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0) [ 16.518] (==) modeset(0): DPI set to (96, 96) [ 16.518] (II) Loading sub module "fb" I am a bit at loss since I wanted to use my rock64 as a headless server with nomachine and would love to use 1920x1080 as with ayufan builds. As expected, display info is empty on XFCE: I would really love to stay with armbian since ayufan releases are usually very experimental and armbian looks pretty stable. Is there anyone facing the same issue?

Thank you for pointing that out. I finally found it. Now I'm having a new problem. When I was using an older version of MySQL, I was able to change the datadir to a new location, reset the server, and it would load the databases in the new location. Now when I change the location of the datadir, I'm getting a bunch of errors: For example, I change this: user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql/ tmpdir = /tmp lc-messages-dir = /usr/share/mysql skip-external-locking To this: user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /New_Directory/mysql/ tmpdir = /tmp lc-messages-dir = /usr/share/mysql skip-external-locking and I get this error: Job for mariadb.service failed because the control process exited with error code. See "systemctl status mariadb.service" and "journalctl -xe" for details. Running "systemctl status mariadb.service" returns this: ● mariadb.service - MariaDB database server Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: Active: failed (Result: exit-code) since Wed 2018-09-26 13:17:36 UTC; 1min 6s Process: 3642 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_STAR Process: 3638 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUC Process: 5747 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WS Process: 5655 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR Process: 5649 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START Process: 5643 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/ru Main PID: 5747 (code=exited, status=1/FAILURE) Status: "MariaDB server is down" Sep 26 13:17:35 rock64 systemd[1]: Starting MariaDB database server... Sep 26 13:17:36 rock64 mysqld[5747]: 2018-09-26 13:17:36 548003549184 [Note] /us Sep 26 13:17:36 rock64 mysqld[5747]: 2018-09-26 13:17:36 548003549184 [Warning] Sep 26 13:17:36 rock64 systemd[1]: mariadb.service: Main process exited, code=ex Sep 26 13:17:36 rock64 systemd[1]: Failed to start MariaDB database server. Sep 26 13:17:36 rock64 systemd[1]: mariadb.service: Unit entered failed state. Sep 26 13:17:36 rock64 systemd[1]: mariadb.service: Failed with result 'exit-cod lines 1-19/19 (END) I'm seriously at a loss here, so I would really appreciate if someone could point me in the right direction. Or even send me to a tutorial that would actually work. Things I've done so far: copied the contents of the original database director to the new one using rsync tried reinstalling and starting over from scratch tried changing the location of the .pid and .sock files done a chown mysql on all files and directories concerned created new .pid and .sock files

Thanks very much for your guidance on this. I can explain the log entries above regarding ethernet connectivity. The first entry was me having had to connect the rock64 directly to one of the fast ethernet ports on my router downstairs, which is located near the TV, as I needed the TV and a keyboard hooked up to work through the initial install process via local login. The entires you see where the ethernet port negotiates at 1Gbps is where I have now moved the rock64 to my comms cupboard upstairs and have connected it to my server LAN switch which has 1Gbps ports. Thanks for the tip regarding nmtui, I never knew this existed to be honest, as I have never really used NetworkManager as I do not run a desktop on any of my linux devices & servers, they all run headless and I manage them via ssh. I usually configure all my linux devices/servers with static IP addressing and if it is a debian based distro, then I set this via /etc/network/interfaces as suggested by the debian wiki. One other quick query if I may, what is the most elegant way for me to remove the desktop and associated packages from my current rock64 armbian install? Am I best to simply autoremove a package in xserver-xorg and hope that it then removes all associated dependencies? (Am not experienced in linux desktop configuration so am not familar with the package dependencies etc) Thanks again for all your help and support.

Hi, I received my new rock64 today and I downloaded this image https://dl.armbian.com/rock64/Debian_stretch_default_desktop.7z I used Etcher as recommended to create the SD card and booted off of it with just power and network connected as I assumed it would boot, assign a dhcp address and bring up sshd so I could remote onto it. I scanned my network to see if any new devices had been added with dhcp, but couldn't see anything new so I connected the rock64 up to a TV and then booted it up, connected up a keyboard and noticed it ran through an install process on first local login. I followed all the directions and a desktop appeared on screen. However, there was no network connectivity so I had a look at /etc/network/interfaces and could see that nothing at all had been set for eth0. Only the loopback interface was defined. I manually edited /etc/network/interfaces and added my eth0 static IP config in there and rebooted and the eth0 network came up as expected. source /etc/network/interfaces.d/* # Network is managed by Network manager auto lo iface lo inet loopback allow-hotplug eth0 iface eth0 inet static address 10.0.0.42/24 gateway 10.0.0.2 dns-nameservers 10.0.0.2 Is this expected behaviour for the rock64 Debian image? In that, you have to manually configure eth0 after running through the install process or is this a bug? Thanks very much for your help and for maintaining a distribution for the rock64.

I have been going over forum after forum trying to figure out how do this, and nothing seems to match up. I just downloaded MySQL on my new Rock64. The OS is installed on a 32GB eMMC, and I have a 1.5GB USB 3 HDD installed for my home folder and all the user data. I bought this to be set up as a LAMP server, and have installed Apache and PHP, which are working well. I haven't had any luck with MySQL though. It seems that nothing matches the documentation. All the documentation and forums say that the configuration file is located at /etc/mysql/my.cnf In that configuration file, there's supposed to be DB location settings, but it's not there. This is all I have in the my.cnf file: The MariaDB configuration file # # The MariaDB/MySQL tools read configuration files in the following order: # 1. "/etc/mysql/mariadb.cnf" (this file) to set global defaults, # 2. "/etc/mysql/conf.d/*.cnf" to set global options. # 3. "/etc/mysql/mariadb.conf.d/*.cnf" to set MariaDB-only options. # 4. "~/.my.cnf" to set user-specific options. # # If the same option is defined multiple times, the last one will apply. # # One can use all long options that the program supports. # Run program with --help to get a list of available options and with # --print-defaults to see which it would actually understand and use. # # This group is read both both by the client and the server # use it for options that affect everything # [client-server] # Import all .cnf files from configuration directory !includedir /etc/mysql/conf.d/ !includedir /etc/mysql/mariadb.conf.d/ Could anyone please help me figure out how to change the main database directory? Thank you!

Rock64 uses the same eMMC module as the Odroid's. These are among the best eMMC's. Very fast. I don't think they easily break. They do cost a bit. And the lower capacity ones are a bit slower. I've got 3 of them. 32GB, 64GB and 128GB. Haven't had any problem. Thumb drives I've had much trouble with. Many die quickly. Run too hot. As @tkaiser said. You have to look out very well not to buy crap. But they are cheaper in lower capacity. Make backups if you choose to use flash-drives. Another informative link to a post of tkaiser. The C2 eMMC's are the ones for you.

Well, there are some kernel configs in the first commit referenced here, that we are not enabling. They may very likely be the cause for the board not booting when you enable vcc_sdio. I think it is worth giving a try. But someone else will have to test it in a Rock64 to make sure these configs don't affect it, since I only have the Renegade.

Trying to choose between an eMMC module or a USB Flash drive for the boot volume on a Rock64. I have a few Rock64's that I'm building as various services (Nextcloud, Pi-Hole, VPN, OMV, and/or Netatalk Backup). None of these devices will need large boot volumes as the data will be in secondary (Hard or SSD) Drives or will require VERY little data storage. On the RPi's that the Rock64's are replacing, I've been using USB Flash drives for booting. I get the feeling that an eMMC module is a better choice, but do have any real knowledge. Are the eMMC modules more reliable and less prone to corruption that USB Flash Drives? I do have some 32GB and 64GB eMMC models from Pine64 and am going to try them out shortly. Any thoughts and advice? Thank you all in advance. Armbian ROCKS!

Hi! I've been reading a lot about iptables in last few days but I can't get my head around the configuration that I need. I'm still learning and this is beyond my scope. I've set the Rock64 as an access point connected to a vpn server. I need to access any devices that are connected to my main router in 192.168.10.1. My wlan access point is in 172.24.1.1. eth0 and wlan0 are always tunnelled through tun0 and it must stay that way. Connected from wlan0 I can ping 192.168.10.176 (eth0) but not 192.168.10.1 (Internet router) or anything else outside wlan0 subnet. My aim is to access smb servers, nfs servers and ssh to any ip in this subnet 192.168.10.x from wlan0 while connected to the vpn and viceversa. Is this even possible? This is my ip route output: ip route 0.0.0.0/1 via 10.8.8.1 dev tun0 default via 192.168.10.1 dev br0 10.8.8.0/24 dev tun0 proto kernel scope link src 10.8.8.55 128.0.0.0/1 via 10.8.8.1 dev tun0 169.254.0.0/16 dev wlan0 scope link metric 1000 172.24.1.0/24 dev wlan0 proto kernel scope link src 172.24.1.1 185.44.76.118 via 192.168.10.1 dev br0 192.168.10.0/24 dev br0 proto kernel scope link src 192.168.10.176 output of ip addr: ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000 link/ether 9e:0d:db:d2:f9:a1 brd ff:ff:ff:ff:ff:ff 3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 9e:0d:db:d2:f9:a1 brd ff:ff:ff:ff:ff:ff inet 192.168.10.176/24 brd 192.168.10.255 scope global br0 valid_lft forever preferred_lft forever inet6 fd7c:b18a:e451:0:9c0d:dbff:fed2:f9a1/64 scope global mngtmpaddr valid_lft forever preferred_lft forever inet6 fe80::9c0d:dbff:fed2:f9a1/64 scope link valid_lft forever preferred_lft forever 4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 08:10:7b:15:4a:31 brd ff:ff:ff:ff:ff:ff inet 172.24.1.1/24 brd 172.24.1.255 scope global wlan0 valid_lft forever preferred_lft forever 6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 10.8.8.55/24 brd 10.8.8.255 scope global tun0 valid_lft forever preferred_lft forever and this is my iptables: # Generated by iptables-save v1.6.0 on Thu Sep 20 11:15:24 2018 *raw :PREROUTING ACCEPT [6734:463678] :OUTPUT ACCEPT [6489:2129649] COMMIT # Completed on Thu Sep 20 11:15:24 2018 # Generated by iptables-save v1.6.0 on Thu Sep 20 11:15:24 2018 *mangle :PREROUTING ACCEPT [6734:463678] :INPUT ACCEPT [6730:463225] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [6489:2129649] :POSTROUTING ACCEPT [6571:2139731] COMMIT # Completed on Thu Sep 20 11:15:24 2018 # Generated by iptables-save v1.6.0 on Thu Sep 20 11:15:24 2018 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] -A POSTROUTING -o tun0 -j MASQUERADE COMMIT # Completed on Thu Sep 20 11:15:24 2018 # Generated by iptables-save v1.6.0 on Thu Sep 20 11:15:24 2018 *filter :INPUT ACCEPT [10:1262] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [16:2170] -A FORWARD -i tun0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i wlan0 -o tun0 -j ACCEPT COMMIT # Completed on Thu Sep 20 11:15:24 2018 This is my /etc/network/interfaces: # Network is managed by Network manager auto lo iface lo inet loopback auto br0 iface br0 inet dhcp bridge-ports eth0 wlan0 And finally my hostapd.conf just to show that I've commented br0 in order to be able to tunnel wlan0 traffic throug the vpn. If I uncomment it I can access the other devices but wlan0 stops being tunneled # # armbian hostapd configuration example # # nl80211 mode # ssid=ARMBIAN interface=wlan0 #bridge=br0 hw_mode=g channel=40 driver=nl80211 logger_syslog=0 logger_syslog_level=0 wmm_enabled=1 wpa=2 preamble=1 wpa_psk=66eb31d2b48d19ba216f2e50c6831ee11be98e2fa3a8075e30b866f4a5ccda27 wpa_passphrase=12345678 wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP rsn_pairwise=CCMP auth_algs=1 macaddr_acl=0 noscan=1 Many thanks for any help given!

IMO push them to open the repo immediately only to tell them after its: well no mainline no armbian is a bit.... questionable. You knew exactly before that there won't be a mainline kernel, you knew that the only efforts in mainlining the SoC is done by Andreas Färber and not Realtek and that he as a 'lone survivor' will probably not be ready to deliver a mainline (based) linux soon. Assuming you would be a copyright holder (for parts of the kernel) and we take https://github.com/torvalds/linux/blob/master/Documentation/process/kernel-enforcement-statement.rst as a baseline for 'being good' (at least a bunch of kernel developers signed it) you informed them on September 4th that they have a GPL violation and on September 19th they released the sources (15 days). Assuming you're the first one who noticed the GPL violation, the majority of the kernel developers would agree that they act as they should. For sure someone more experienced in kernel-development and bsp kernel-quality would have to check it first. But as said a full check of the BSP kernelsources was (until yet) never a prerequisite for provide Armbian with BSP-kernels. It's also obvious that this SoC is far away from mainline support and that some of the interesting features will probably never run in mainline (e.g. the whole encoding and decoding stuff cause it is partly, as far as I understand, behind some blobs e.g. 'bluecore.audio'). But as an other example, pinebook is marked as 'supported'. 3.10 got EOL a year ago (and was likely never fully reviewed too) and mainline has (as far as I know) issues with the PMIC (which will be important for a 'notebook') and only marked as beta. By those standards Pinebook should go back to wip or CSC. I completely agree that at least a headless usable mainline based linux should be available before we start to support a new SoC. I also agree that support SoCs which have only one available board is questionable (the efforts maintaining just a new set of kernels BSP/Mainline is just too much for one board - expect the MT7623 for which I might prepare a PR as soon as we reach the next LTS kernel, it works without major issues on mainline without patching, so it's only an adjustment of the config file, something I think isn't that much work I may write a THS patch cause those settings are IMO a bit conservative). But a full check of the BSP kernel as prerequisite is IMO double standard - we didn't do it for any BSP kernel in the past and this should be IMO discussed in the developer subforum first before we define it as a new standard - in this case we had to drop a bunch of 'suggested' images from the download page (e.g. RK3399, RK3328 Rock64/Renegade, A64 Pine64 et al, ). For all those boards we suggest to use the BSP kernel..

Ok, I'm halfway through setting my vpn router, I still need to change the iptables rules so I can access the local network devices through the armbian access point. I've got some interesting results after enabling the access point and routing all my traffic through tun0. My first surprise was that without implementing any of the jmandawg suggestions about isolating core 2, from my laptop. Connected to the ARMBIAN access point and routing the traffic through tun0, I ran speedtest and I got constant speeds of 72mbit/s which is almost the maximum I can reach from my connection, pings were 28ms, the minimum I reach even without the vpn, directly from my router. I'm very pleased with this performance and I wasn't expecting it. I suppose the fact that the Rock64 only job in this scenario is to encrypt and the run of the tests, web browsing and any other processing is done by my laptop shows the real encrypting potential of the openvpn running in the rock64 without any tweaking. The next step was to test the speedtest from the Rock64 directly, results: 25mbit/s speeds and pings of 40ms. Expected Then I implemented jmandawg suggestions the results from my laptop didn't vary a bit, they were excellent before and stayed the same. The results from the Rock64 directly varied greatly. When I ran the tests with "taskset -c 1 speedtest-cli" the results are 68mbit/s and ping 28ms. Same test, this time only "speedtest-cli" and the speed went down to 23mbit/s or maximum 30mbit/s I don't fully understand why if I've isolated a core for openvpn, I still need to isolate another core to run another program in order to achieve good performance with openvpn. Shouldn't it be enough to have core 2 isolated? Another thing is I didn't have "/etc/systemd/system/openvpn.service" The only other place where I found openvpn.service and where I made the changes is "/etc/systemd/system/multi-user.target.wants/openvpn.service" Could this be affecting anything? I don't run my openvpn through the network manager but by the openvpn command

Honestly: I think you're the only one doing this The reasons to specify these settings are as follows: CPUMIN: Some kernels/settings define awfully low cpufreq OPP that result in no further consumption savings but crappy IO performance (e.g. Tinkerboard: the default kernel defines lowest cpufreq as low as 100 MHz which makes zero difference to 600 MHz from a consumption/heat point of view but destroys IO performance with ondemand governor since clockspeeds do not ramp up quickly enough) CPUMAX: Sometimes used to allow users who know what they do to enter experimental area while keeping safe defaults (e.g. allowing Rock64 to clock up to 1.5GHz by patching DT but since we had some reports about instabilities at 1.5 GHz defining CPUMAX still as 1.4GHz -- for an experienced user it's a lot easier to adjust a config file than to deal with overlays on most platforms or playing around with dtc binary) I agree that current situation with overwriting /etc/default/cpufrequtils with board support package updates is not ideal. But no idea how to improve situation. My personal workaround is two lines in /etc/rc.local overwriting /etc/default/cpufrequtils contents and reloading the daemon.

Boot priority with Rockchip boards is AFAIK always eMMC first then SD card. So once RK3399 finds a bootloader signature on the eMMC it will boot from there even if a bootable SD card is inserted. If you want to reflash eMMC in this situation you either need to use Maskrom mode (or how it's called exactly) which requires another host and USB delete the bootloader on the eMMC (can be done from the running system: 'dd if=/dev/null of=/dev/mmcblk1 bs=1M count=64 ; sync') I successfully bricked my NanoPC-T4 while developing with nand-sata-install and now have working bootloader on the eMMC that is not able to boot a kernel so I'm locked out and would need to try variants 2) or 3) here: http://wiki.friendlyarm.com/wiki/index.php/NanoPC-T4#Flash_Image_to_eMMC (which is not that easy since my physical x86 machines all run macOS and my Linux boxes are all ARM based -- I might try a VM with USB pass-thru soon) I asked @mindee for help but his advice to boot an eflasher image from SD card doesn't work since I have a working bootloader on the eMMC (but an otherwise bricked system). Would be great to temporarily disable the eMMC as it can be done on Rock64 and RockPro64 (a jumper allows the eMMC to be grounded or something like that so you can boot with this jumper set from a bootable SD card inserted and if you remove the jumper within 2 seconds after boot you can even access the eMMC afterwards to flash a new image)

It's not that I'm fighting for seconds. It was more curiosity. If i can use this thing after ~30 seconds everything is OK. My TV or satellite receiver are slower :D I will buy a Rock64 next month for another use case (surveillance cam display h265) and then i will see how the boot time is there. And if there is no difference in boot time between SD and eMMC i now know i don't need a eMMC there.

Well, don't think so. You asked another entirely different question: And... Rock64 will boot way faster than your outdated Banana Pi regardless of the boot media. But as already said: if you're interested in a specific use case IMO you should look also at this use case. Stop watch waiting for login prompt is pretty much irrelevant for 'wireless NAS being ready to serve' Check your own armbianmonitor -u output for 'link becomes ready' occurrences then you know how much time it already takes since the kernel has started for the wireless link to come up. I've seen quite some delays with some USB wireless dongles in the past so this is something at least I would take care of.

Ref: https://www.cnx-software.com/2017/11/27/amlogic-s905x-vs-rockchip-rk3328-vs-allwinner-h6/ CPU wise roughly: RK3399 > Amlogic S912 > Allwinner H6 > Amlogic S905X = RK3328 On the other hand, there are very few H6 based TV Box and majority of them are based on S912/S905W and RK3328. Some of the RK3328 based boxes have the advantages of higher memory and storage) (4GB/64G) compared to S912 based (usually 3GB/32GB) and S905W based (usually 2GB/16GB). I like my recently bought X96 Mini but I also ordered Rock64 and RK3328 based box (H96 Max 4GB/64GB) and S912 based box (H96 Pro Plus 3GB/32GB) to play with Android and follow the Armbian development here. The RK3328 based TV box is actually more expensive than S912 based because of the higher memory/storage.

I'm building a portable battery powered NAS because syncing and having everything multiple times on all my Android devices sucks. I took my old Banana Pi connected a SSD to the SATA port and made it a access point (no Samba yet installed). Booting from the 16GB SanDisk Ultra A1 is 27 seconds. Moving everything to the SSD in armbian config is also 27 seconds (no difference?) I know the Banana has not the fastest SATA and NIC and that USB 3 on the Rock64 is faster. But i don't copy tons of gigabyte to the device everyday and for streaming over the WiFi stick it's fast enough. I'm interested on the boot time of the Rock64 (eMMC or USB/SSD). If its not much faster then i see no reason to by a Rock64 for that. Also the Banana has the advantage that you can solder a battery to it.

I've done what you suggested and the result has dramatically improved the speed: from 21 mbit/s to 50-55mbit/s I thought that by having the crypto extensions enabled in ARMv8 the performance of Openvpn would automatically rocket compared to the raspberry pi for instance without need to alter anything. This the output, I've noticed that the ping is 55% higher through connections from the Rock64 than from my laptop, that could be interfering with the speed: WITH VPN AND CORE 2 ISOLATED FOR OPENVPN_____________ Linux 4.4.152-rockchip64 (rock64) 09/15/2018 _aarch64_ (4 CP$ avg-cpu: %user %nice %system %iowait %steal %idle 0.28 0.00 0.25 0.02 0.00 99.45 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mtdblock0 0.00 0.01 0.00 108 0 mmcblk1 0.39 16.28 0.22 242009 3240 zram0 0.11 0.05 0.38 736 5584 zram1 0.02 0.08 0.00 1196 4 zram2 0.02 0.08 0.00 1196 4 zram3 0.02 0.08 0.00 1196 4 zram4 0.02 0.08 0.00 1196 4 avg-cpu: %user %nice %system %iowait %steal %idle 11.94 0.00 0.70 0.00 0.00 87.36 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mtdblock0 0.00 0.00 0.00 0 0 ping -c 5 185.44.76.118 PING 185.44.76.118 (185.44.76.118) 56(84) bytes of data. 64 bytes from 185.44.76.118: icmp_seq=1 ttl=49 time=25.5 ms 64 bytes from 185.44.76.118: icmp_seq=2 ttl=49 time=24.6 ms 64 bytes from 185.44.76.118: icmp_seq=3 ttl=49 time=24.7 ms 64 bytes from 185.44.76.118: icmp_seq=4 ttl=49 time=26.1 ms 64 bytes from 185.44.76.118: icmp_seq=5 ttl=49 time=24.9 ms --- 185.44.76.118 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 24.633/25.221/26.146/0.572 ms WITHOUT VPN AND CORE 2 ISOLATED FOR VPN ------------------------Linux 4.4.152-rockchip64 (rock64) 09/15/2018 _aarch64_ (4 CP$ avg-cpu: %user %nice %system %iowait %steal %idle 0.30 0.00 0.27 0.02 0.00 99.42 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mtdblock0 0.00 0.01 0.00 108 0 mmcblk1 0.39 16.06 0.24 242009 3608 zram0 0.10 0.05 0.37 736 5584 zram1 0.02 0.08 0.00 1196 4 zram2 0.02 0.08 0.00 1196 4 zram3 0.02 0.08 0.00 1196 4 zram4 0.02 0.08 0.00 1196 4 avg-cpu: %user %nice %system %iowait %steal %idle 13.59 0.00 2.14 0.00 0.00 84.27 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mtdblock0 0.00 0.00 0.00 0 0 ping -c 5 86.158.85.129 PING 86.158.85.129 (86.158.85.129) 56(84) bytes of data. 64 bytes from 86.158.85.129: icmp_seq=1 ttl=63 time=2.46 ms 64 bytes from 86.158.85.129: icmp_seq=2 ttl=63 time=6.16 ms 64 bytes from 86.158.85.129: icmp_seq=3 ttl=63 time=2.82 ms 64 bytes from 86.158.85.129: icmp_seq=4 ttl=63 time=6.07 ms 64 bytes from 86.158.85.129: icmp_seq=5 ttl=63 time=4.89 ms --- 86.158.85.129 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 2.462/4.484/6.167/1.575 ms If there aren't any further improvements that can be implemented to improve the performance of openvpn, I will try to use wireguard, it sounds like the ideal solution for devices like ours. If anyone thinks that the openvpn performance should be better than what we've seen in this post, I'm all ears. Thanks all for your answers

I would use something a little more reliable than speedtest.net, try using curl. Here are my results using my renegade (almost same hw as rock64): Without vpn (direct connection): root@renegade:~# curl -L http://www.gtlib.gatech.edu/pub/ubuntu-releases/18.04/ubuntu-18.04.1-live-server-amd64.iso > /dev/null % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 812M 100 812M 0 0 2948k 0 0:04:41 0:04:41 --:--:-- 4202k With openvpn: root@renegade:~# curl -L http://www.gtlib.gatech.edu/pub/ubuntu-releases/18.04/ubuntu-18.04.1-live-server-amd64.iso > /dev/null % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 812M 100 812M 0 0 1758k 0 0:07:52 0:07:52 --:--:-- 1856k This is using windscribe vpn. I think the only way to truly test openvpn speed would be on your internal network. I may try it when i have time.

I guess you are right, at least for what I tried with Rock64 and Armbian I have USB3.0 problems mentioned elsewhere on this forum and on https://forum.pine64.org/showthread.php?tid=5137&pid=37535#pid37535 I used tips above for an el cheapo USB3.0 JMS597 SATA adapter cable 0x152d:0x0578 In Armbian 5.59 I had read/write speed around 80MBps ish using samba (varying between 109 and 70) But with read, after a few seconds full speed, it froze for 10-15 sec, no errors in the transferred data, but with "ERROR Transfer event for disabled endpoint or incorrect stream ring" in dmesg every time it froze. With above tips I don't have freezes anymore, and using samba as server and W10 client, write speed still 80MBps ish, but read speed down to 50MBps. And as you predicted, I have now another error : "reset SuperSpeed USB device number 3 using xhci-hcd" But not in red :-) and without any noticeable delay. Hopefully the USB "ERROR Transfer event for disabled endpoint or incorrect stream ring" gets solved soon. Ill do some more testing on Pine and Armbian. Also always interested if you have better fixes.

Hi! I'm trying to create a vpn access point with a Rock64. I'm receving a low speeds with openvpn but the openssl tests show that there is crypto acceleration. I'm new to all of this. I assume the vpn speeds would be much higher since crypto extensions are enabled in armbian, that's why I choose the Rock64 and Armbian. This is the openssl test: openssl speed -evp aes-256-cbc Doing aes-256-cbc for 3s on 16 size blocks: 14416568 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 10625804 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 4907054 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 1594735 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 218375 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 16384 size blocks: 109757 aes-256-cbc's in 3.00s OpenSSL 1.1.0f 25 May 2017 built on: reproducible build, date unspecified options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/aarch64-linux-gnu/engines-1.1\"" The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-cbc 76888.36k 226683.82k 418735.27k 544336.21k 596309.33k 599419.56k My internet speed is around 76 MB download and 19 MB upload. The rock64 without a vpn connection is capable of reaching those speeds but with the openvpn connected and using the same cipher aes-256-cbc these are the results: speedtest-cli Retrieving speedtest.net configuration... Testing from Zare (185.44.76.118)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by fdcservers.net (London) [0.96 km]: 38.804 ms Testing download speed................................................................................ Download: 20.42 Mbit/s Testing upload speed.................................................................................................... Upload: 17.88 Mbit/s I've been reading posts from other people talking about speeds of 60 or 80 MB/s through openvpn connections. Is 20MB the maximum speed I will achieve with the Rock64? If not, what should I do? As I said, I'm new to this and I don't know how to proceed, my ideas are that perhaps openvpn is not compiled to use the crypto engine but maybe I'm just talking nonsense. I'm using Armbian Stretch with desktop legacy kernel 4.4.y Thank you very much for your help

Hi everybody, I recently set up a small server with the Rock64 booting armbian stretch 5.59 stable directly from a 120 GB SSD attached via USB3. Booting is handled with U-Boot from ayufan on the SPI flash. The Rock64 is board revision 2.0, the power supply is the original Pine64 one for the Rock. Besides the SSD, there are no other peripherals connected. The board often (3 out of 4 times) hangs when booting. In this case, all LEDs are lit, the orange network LED will flash and the board is not reachable by SSH and not pingable. My impression is, that it is stuck because the SSD either powered up too late or the USB connection is delayed. However, I cannot confirm my suspicion, because the board also does not output any HDMI signal to my monitor (even if it boots up correctly). If I cut power, re-power and give it another try, it will boot at some point and everything (except the HDMI) will work perfectly. My issue seems to identical to the one described here for the ayufan build. It is noted in that thread, that an external power supply for the SSD might mitigate the problem. I did not have a chance to test this, yet. But I also hope that you guys have a better insight into this and might catch a bug in the armbian image.