Search the Community

I have installed open media vault on my rock64 and I have a sata3 disc drive connected to the usb3 port. I have tried both armbian and ayufan firmwares and the speed of the samba shares is 30 MB/sec. I know that the system can do more as with FTP I get 100MB/sec. I have tried many samba tweaks but nothing changes, is this the max I can expect?

Hello all. I've made a video about the Rock64. I've tried different distro's, but Armbian was the best for me. The only problems I've found was that Synaptic Package Manager didn't work. It crashes when I press the search button. And sometimes surfing was extremely slow. Otherwise it did fix all the problems I've had with the other distro's I've tried. Thank you for all the great work. Now I've started my research with the Orange Pi +2, and again Armbian is the best choice. Greetings, NicoD Here is my video.

Hello everybody! I write on this topic because i'm searching for few weeks a solution with dd command to make a disk image backup, but I don't find a conclusive solution, so... Firstly I send dd command. Disque /dev/mmcblk0 : 29,7 GiB, 31914983424 octets, 62333952 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Type d'étiquette de disque : dos Identifiant de disque : 0x53d4dbd7 Périphérique Amorçage Début Fin Secteurs Taille Id Type /dev/mmcblk0p1 32768 10504191 10471424 5G 83 Linux Disque /dev/sdc : 1,8 TiB, 2000398931968 octets, 3907029164 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Type d'étiquette de disque : dos Identifiant de disque : 0xa1be3216 Périphérique Amorçage Début Fin Secteurs Taille Id Type /dev/sdc1 2048 2149556223 2149554176 1T 83 Linux /dev/sdc2 2858452992 3907029163 1048576172 500G 7 HPFS/NTFS/exFAT /dev/sdc3 2149556224 2858452991 708896768 338G 83 Linux Les entrées de la table de partitions ne sont pas dans l'ordre du disque. root@ubuntu:~# dd if=/dev/mmcblk0 of=/media/ubuntu/59C7B06D5FB30054/backup_rock.img bs=4096 conv=notrunc,noerror 7791744+0 enregistrements lus 7791744+0 enregistrements écrits 31914983424 bytes (32 GB, 30 GiB) copied, 428,454 s, 74,5 MB/s All seems to be good! The imaged is saved on my mounting point in /dev/sda2 But after that my SD can't boot like before... I have the following message: Press Control-D to continue I type my password, make a fdisk -l command (see photo) I have new partition disks mmcblk0bootX Moreover I succeed to make disk image just after installing armbian, then I install samba (with all dependencies) and everything go wrong after dd command... However I make my image on other computer (ubuntu) with media unmounted... Which impact this software could cause on this system? I don't understand. I try another tool Rsync. Impossible to copy all data SD card to another SD card same size. When it try to copy some kernel element I had a NOK in red (this tool work perfectly on my old RPI2) I spend a lot of time on my new rock64 and I would be save it for good (if it's possible) ^^ Thanks

Leapo has started porting RPi.GPIO to Rock64 as R64.GPIO, you can find her work in progress at https://github.com/Leapo/Rock64-R64.GPIO Original thread with instructions/updates is here: https://forum.pine64.org/showthread.php?tid=5902 She also made a more simple tool to work with GPIO: https://github.com/Leapo/Rock64-BashGPIO

Nothing like a good weekend challenge to occupy my inner nerd. I love this web interface NODE JS along with this relay plate RELAY PLATE and have it working with Raspberry PI3, but now I want to take advantage of the additional ram I have with Rock64. The process did not go without a hitch. I list the latest version of NPM in my machine and the web interface is working. I don't think the relays are getting triggered even though I painstakingly crossed the power pinouts and the gpio pinouts. Not sure if this can be adapted or if it has been done before. I am good at following those that know more than me, but do not consider myself knowledgeable enough to blaze new trails. Thanks

Hello, I want to build myself a tiny nas. I want to run both Nextcloud and gitea (git server) on it. Which would you prefer? #### ODroid HC1 - Board with power supply = 54,50$ - Case = 4,00$ - Shipping = 17,40$ - Total = 75.90$ Total with german customs fees = 72,85€ #### Rock64 2GB - Board = 34.95$ - Power Supply = 6,99$ - JMS578 USB-to-SATA Cable= 9,99$ - Shipping = 11.99$ - Total = 63.92$ Total with german customs fees = 61,83 € For help i would be grateful. Sincerely, cyagon

Hi everyone. I'm starting a project to learn about Big Data processing. Roughly, I'll be following the example set by Michael at http://diybigdata.net/odroid-xu4-cluster/ . From other posts he has made, some extra RAM could be useful, so I am interested in the 4GB ROCK64. My basic configuration will be ROCK64/64Gb eMMC/Pine USB3-SATA cable/HDD. I'm looking to buy 4 of these to start the project and do my development and testing before adding extra nodes to the cluster. It seems that the Pine USB-SATA cable performs well, but the SD card reader does not. I'd like to configure remote power cycling using GPIO from a monitoring SBC and a relay card, but someone posted on Pine64 forum that the reset button must be pressed to boot the board. Is that so? It's not a show stopper, but I will have to rethink my strategy. In any case, those are the only possible issues I have noticed so far with using this board as a server. Am I missing something important? I'm fairly new to the SBC ecosystem, but not to electronics or Linux. Thanks! Matt.

Current issues with Armbian board support: -U-Boot problems (various) Solutions so far: - fix the method of generating idbloader.bin. <--- update: the "release" and "mainline-master" behave significantly differently. Mainline-master behaves as it should as far as writing the bootloader. Release does not.

Has anyone tried to install PiVPN or EasyRSA on a Rock64? I tried this and had some issues where EasyRSA did not install. No errors were shown on the install or captured in the install log. Took me a while to figure out that EasyRSA was not installed. It even created .opvn files for clients... I finally figured out what happened. Did some research and found a suggestion to manually install some packages BEFORE installing PiVPN. That seems to work, so now I have a working VPN. I just wanted to see if anyone else is having an issue. I will also post on the PiVPN Github site to get their input. Thanks!

I have successfully gotten Armbian to boot from a USB flash drive on the Rock64 board. Followed ayufan's instructions on how to update SPI Flash with his boot code and then wrote the Armbian Rock64 image to a USB flash drive. All worked as expected. Thanks to everyone at Armbian for all the great work!

Hi, I just ordered a Rock64 with 4GB and wanted to hear your recommendations on what image and os I should run it with. I want to use it as my home server with Docker, Samba, Pi-hole, Tvheadend and Tinyproxy. 100 Mbit/s ethernet is enough. What do you recommend?

Hey everybody, First, thanks for Armbian. The Asus Tinkerboard and the ROCK64 both have the same processor. I'm interested why the Asus Tinkerboard gets the mainline kernel, but the ROCK64 only gets the legacy kernel. Why is this?

Hello guys, does anyone activated CVBS output on Rock64 board? After a short look into datasheet Rock64 should support 480i and 576i. Many thanks.

I have some questions about the Linux images that Ayufan built for the Rock64 board. Not really technical issues so I did not think they should go on the Github page. If this is not the appropriate place for these, let me now and I'll remove this post. Also, if this is not the place, where should I be asking these types of questions? I just downloaded the new PRE-RELEASE version of Debian Stretch from the Github page (Yes, I know it's bleeding edge, but just experimenting for now). Specifically the stretch-minimal-rock64-0.6.5-152-arm64 image. I just burned it to my eMMC board. Will boot and see how it all works tomorrow. There are a number of other .deb packages that are on the download list. Do I need any of them? I am specifically talking about these: linux-rock64-package-0.6.5_all.deb linux-rock64-0.6.5_arm64.deb linux-image-4.4.103-rockchip-ayufan-152_0.6.5_arm64.deb or linux-image-4.15.0-rockchip-ayufan-152-ga69162eb_arm63.deb linux-headers-4.4.103-rockchip-ayufan-152_0.6.5_arm64.deb or linux-headers-4.15.0-rockchip-ayufan-152-ga69162eb_arm63.deb linux-firmware-image-4.4.103-rockchip-ayufan-152_0.6.5_arm64.deb Thank you.

Hi there, Trying to build full OS image (or only kernel) to Rock64 in order to add support to AR9271 Atheros chipset. I only managed once to make the board recognize the wlan adapter only after reconnecting it (doesn't survive reboot). any help will be much appreciated.

Hi Guys, I bought a new Rock64 and try to connect a CC1101 FM Transmitter (CC1101 wiring with the Raspberry Pi) which communicates over spi with the Rock64. How can I activate spidev on the Rock64? I tried to add spidev to the armbianEnv.txt: verbosity=1 console=both ethaddr=02:38:a0:82:2d:c0 eth1addr=02:38:a0:82:2e:c1 overlay_prefix=sun8i-h3 rootdev=UUID=52ddb7ff-487f-4f7c-8606-4e27c00ab708 rootfstype=ext4 overlays=spi-spidev user_overlays=spi-spidev param_spidev_spi_bus=0 param_spidev_max_freq=100000000 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u But spidev is not appearing in /dev/ . I only used Raspberry PI's before, that's why I'm new to use Linux Overlays and stuff like that. I hope anyone can help me.

Hi all. I have a Rock64 board with 1GB RAM. I downloaded this image https://dl.armbian.com/rock64/Ubuntu_xenial_default_nightly.7z and I wrote it on the SD card (Samsung EVO 16GB) using both Etcher and dd command. But when I power the board, all 3 leds light up and remains on, nothing else happens. I have the same behaviour with the 0.6.0 stretch-minimal image downloaded here https://github.com/ayufan-rock64/linux-build/releases The only images that works are the 0.5.10 downloaded here https://github.com/ayufan-rock64/linux-build/releases/tag/0.5.10 What's wrong? I can exclude problems with power supply (I bought the one they suggested on their site, 5V 3A) and with SD card because I have no problem with 0.5.10 image. I tested both xenial-mate and stretch-minimal (with the XFCE4 desktop environment installed later) images without problems. Thanks in advance. Matteo

Hello, I was able to overclock the CPU to 1.488Ghz by editing rk3328-rock64.dtb file. But I can not figure out how to set the RAM-clock-speed. Is there any chance to ramp up the RAM clock?

My question to the developer: Is there any probability that the native ethernet (gigabit) connection will be working in the future? I think that's the main advantage of the rock64 board (gigabit ethernet AND usb 3.0). Otherwise many other boards will work as well as NAS as the rock64. Thanks in advance for answers!

I'm trying to get wifi working on my Rock64 running the nightly server image. Is this possible?

Thank's for supporting Rock64! Is there a chance for a debian server image (beta) within the near future? All my boards are running a armbian debian OS and I would like to stay consistent here... Best regards Martin

/usr/lib/dri/rockchip_dri.so just doesn't exist but not really sure if the xorg package is the xenial one or rockchip one. If it is the rockchip one then for some reason rockchip_dri.so isn't being built. On a startx it gives it a good go but always drops out to software rendering because its missing the above.

Hi, do you plan to add Desktop images for Rock64 ? Anyway thanks for your great job. Armbian is wonderful!

Just got a rock64 board and tried the armbian testing image. Is ethernet working out-of-the-box with this image? My ethernet isn't working. Also the normal password didn't work (root / 1234). Would be nice to have some infos about that.

The above thing is a $10 accessory that can be ordered together with ROCK64 (and maybe other Pine Inc. devices like Pine64 or Pinebook?). It's an USB-to-SATA bridge (JMicron JMS578 based) to be used together with 2.5" SSD/HDD or 3.5" HDD. For the latter purpose it's equipped with a separate power jack suitable for the usual 12V 5.5/2.1mm power barrels (centre positive) you find PSUs with literally everywhere. TL;DR: If you want to add storage to your ROCK64 order this cable too. It works great with both 2.5" and 3.5" disks and it's somewhat sad it's not available separately since it's a great storage companion for many other devices too. Basics first: Mechanical quality of USB jack is excellent, Pine folks took care that the jack fits really tightly in USB receptacles so USB3 contact issues should not be an issue here (tested on ODROID-XU4 which is my worst device in this regard. The Pine adapter worked great and these pretty nice XU4 USB3 storage performance numbers were produced with Pine's adapter) The device is not really black but it's just a very dark but translucent plastic. If it's connected to an USB port and thereby powered a solid blue led is shining through. Disk activity is shown with a blinking red led in parallel. If you hate blinking leds like me turning the device 180° over is sufficient JMS578 as USB-to-SATA bridge is an excellent choice since amazingly fast, 'USB Attached SCSI' capable, same with 'SCSI / ATA translation' and even TRIM (though software support for this still missing in Linux) When combined with 2.5" disks the whole power consumption happens through the USB cable. Keep in mind that USB2 ports are rated for 500mA and USB3 ports for 900mA max. ROCK64 AFAIK allows 650mA on the USB2 ports and 950 mA on the USB3 ports. In other words: chances are great to run in underpowering problems when you connect 2.5" disks to the USB2 ports and run heavy loads on it (see below). 3.5" HDDs need not only 5V but also 12V. Usually the motor spinning the platters is on the 12V rail while internal electronics and the stepper motors to move around the head(s) are on the 5V rail. Please always keep in mind that Pine's SATA cable unlike any 'real' 3.5" HDD disk enclosure uses the separately provided 12V only to feed pins 13-15 on the SATA power connector. 5V consumption for the JMS578 and the disk's 5V rail has still to be provided by the device the SATA cable is connected to since coming from the USB power lines. On 'real' disk enclosures the 12V are internally also used to generate the 5V so an external disk is NOT powered in any way by the connected host. With this cable it's different! Below is the standard SATA power connector pinout. 3.3V are usually not used, 12V are needed for 3.5" HDDs and 5V are always required. The JMS578 bridge chip needs some 5V juice too which is also taken from the connected host/board via USB power lines. We already have a lot of performance numbers with fast SSDs connected to JMS578 (see https://forum.armbian.com/index.php?/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=34192 or there for example) so let's focus on real-world use cases this time: A large 3.5" HDD connected to a ROCK64 serving as a NAS or backup disk. Let's start with some consumption numbers with an idle ROCK64. In the meantime I've 3 different ROCK64 generations on my desk (1st dev sample with 2GB and unusable USB3, 2nd gen dev sample with 4 GB and now a production board with 1 GB DRAM and a different Gigabit Ethernet PHY). Measurements done without PSU taken into account: Pre-production board, 4GB, RTL8211E PHY: Idle, Fast Ethernet active, nothing connected: 1100mW Idle, GbE active, nothing connected: 1430mW Production board, 1GB, RTL8211F PHY: Idle, Fast Ethernet active, nothing connected: 1180mW Idle, GbE active, nothing connected: 1300mW Idle, GbE active, JMS578 connected: 1720mW Idle, GbE active, JMS578 with sleeping disk: 2850mW With RTL8211E PHY the difference between GbE and Fast Ethernet was 330mW (on most GbE boards with 8211E it's exactly like this: ~350mW) and now with RTL8211F the difference is just 120mW (difference on ODROID-C2 which also uses 8211F is 230mW). When adding the JMS578 cable w/o connected disk consumption increases by 400mW. In this (rather useless) mode the JMS578 hides itself on the USB bus (lsusb output shows nothing -- interestingly on ODROID HC1 which also relies on JMS578 this is different) and obviously JMS578's USB and SATA PHYs are powered off. As soon as a disk is connected but sent to sleep JMS578 now consumes +1.5W and appears on the USB bus (now JMS578 has to power 2 highspeed PHYs: USB3 and SATA 3.0). So with production ROCK64 boards minimal idle consumption is 1.2W (PSU's own consumption excluded). But as soon as we connect this cable with a disk behind idle consumption more than doubles (+1550mW) even if we send the disk to sleep. That's bad news for use cases that require a connected disk only running from time to time since now the JMS578 consumes more energy than the board itself. Edit: I discovered recently that the HDD I was testing with has a rather high standby/sleep consumption so the +1550mW are not JMS578 alone but maybe even largely the Seagate Barracuda. See here for details but keep in mind that while on ODROID HC2 also a JMS578 is used it runs a different firmware which influences idle consumption behaviour a lot. More details on JMS578 firmwares: https://forum.armbian.com/topic/3317-orange-pi-zero-nas-expansion-board-with-sata-msata/?do=findComment&comment=43735 What are the options? With ROCK64 production boards we're fortunately able to toggle power provided to USB ports: https://forum.pine64.org/showthread.php?tid=5001 So the SATA cable connected to an USB2 port would allow to regain lowest idle consumption since we could unmount the disk when not needed, then send the disk to sleep using 'hdparm -y' (JMS578 fully supports 'SCSI / ATA translation so you can access every disk feature with hdparm or other low level tools!) and finally switch JMS578 off by cutting power on the USB2 port. My personal use case is a ROCK64 with a huge 3.5" HDD to backup various macOS devices in the household. Backup performance is close to irrelevant and the only events needing top 'NAS performance' would be large restores or 'desaster recovery'. In other words: for normal backup operation once a day it would be sufficient to connect the disk to an USB2 port. Nope, doesn't work any more, see below for details. How does performance look like with a 7.2k 3.5" HDD (Seagate Barracuda from a few years ago): The Barracuda is totally empty so able to achieve nice maximum sequential performance scores since testing only on the outer tracks (~170 MB/s): USB3 / UAS (7.9W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 11738 23147 25131 25087 1091 948 102400 16 62218 77830 84257 84768 4246 4136 102400 512 150052 148303 154342 163817 58563 97809 102400 1024 148290 148324 156772 164963 85125 113412 102400 16384 149840 149248 144297 151440 153146 133806 1024000 16384 167750 169544 172970 174205 160859 151406 When connected to an USB2 port performance drops a lot (maxing out at ~37MB/s): USB2 / UAS (6.4W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 7735 7849 6821 7925 998 916 102400 16 17687 19040 20793 19430 3624 4096 102400 512 33472 33662 33738 34329 26020 33683 102400 1024 33836 34030 34855 35505 29941 28791 102400 16384 34294 34373 35599 36694 36174 33714 1024000 16384 33600 34516 36576 36902 36372 34111 I tested backing up the same MacBook Air twice with ~70 GB data using Gigabit Ethernet (the usual Thunderbolt Ethernet adapter) and time difference was negligible comparing HDD connected to USB2 or USB3. When backing up through Wi-Fi there is no difference any more since Wi-Fi is the bottleneck. In other words: from a performance point of view for this use case connecting the SATA cable to an USB2 port and being able to totally cut power to both cable/JMS578 (+1.5W consumption) and a sleeping 3.5" disk (less than 0.1W consumption with almost all disks) is worth the efforts. Once your MacBook gets stolen you simply disconnect the backup HDD from the USB2 and reattach it to an USB3 port and start the restore on your new device with +80 MB/s (Gigabit Ethernet now being the bottleneck) What about power requirements? ROCK64 only provides up to 650 mA on the USB2 ports! I tried to test this precisely with my usual 'monitoring PSU' approach. All I was getting were some nice kernel panics due to UNDERPOWERING. The Banana Pro I used to provide power (and measure consumption) simply does not provide enough current so Linux on ROCK64 started to fail in many funny ways once USB accesses happened. So I had to revert on measuring with PSU included with a cheap powermeter (more realistic but not that precise). When measuring only the 12V rail of my 3.5" Barracuda the disk consumed up to 18W when spinning up. In normal operation (either idle or with any workload) 12V consumption varied between 6W and 8W (12V only needed to spin the platters). The 5V power requirements for JMS578 + 3.5" HDD disk were as follows: USB2: 6.4W vs. 3.3W (full load vs. idle). Numbers with 5V PSU included so we're talking about needed power provided on an USB2 port of approximately ~3W which fits perfectly in the power budget of ROCK64's USB2: 650mA * 5V == 3250mW USB3: 7.9W vs. 3.3W (full load vs. idle). Numbers again with 5V PSU included so we're talking about needed power provided on an USB3 port of approximately ~4W which fits perfectly in the power budget of ROCK64's USB3: 950mA * 5V == 4750mW At least with my 3.5" HDD it worked pretty well to let it operate on both USB2 and USB3 ports when board powering was appropriate (with insufficient powering all weird sorts of issues popped up. My favourite was a kernel panic when issueing 'lsusb' after 30 seconds. Once I powered ROCK64 reliably all these 'software issues' were gone immediately -- again and again: insufficient powering is one of the most severe problem sources)