Pine64 ROCK64 is the first maker board based on Rockchip RK3328 processor, and is potentially interesting for various applications including network storage thanks to USB 3.0 and Gigabit Ethernet, multimedia applications with 4K HDR video support, as well as other applications requiring I/Os. I’ve already tested Rock64 board with Android 7.1 operating system, so today I’ll report by finding and experience with Ubuntu 16.04.3 with MATE desktop.
Selecting and Flashing a Linux Image
You’ll find several operating systems in the Wiki, but you’ll also find more cutting edge images in ayufan’s github. But first let me explain some vocabulary used for Pine64 firmware files:
- Engineering version – Becomes with release build based on the stock build develop by Pine64 and the SoC vendor. It’s supposed to be more stable, but get less updates
- Community versions (currently managed via ayufan) are more frequently updates, and comes with more recent features. You’ll find two categories
- Release builds – The current stable version released by the community
- Pre-release builds – Version under test to eventually become the release build
Currently, documentation is still work in progress for the board, so I spent some time on IRC #Rock64 chatting with the helpful community there, and I noticed most of them used the community builds. I’ve also been told there has not been that much work on the Desktop version right now, with most people focusing on NAS support with images such as Debian + OpenMediaVault. But since I wanted to test a desktop image I was recommended the Ubuntu Mate image, and download the pre-release 64-bit version: xenial-mate-rock64-0.4.17-85-arm64.img.xz.
If you’ve read the WIki, you’ll notice all those are “micro SD” images, so since I had a eMMC flash module, I was a little confused at the beginning, but since I have Hardkernel’s micro SD to eMMC flash module adapter, installation was just the same as on a micro SD card with Etcher.
But Pine64 does not sell such adapter, so how are you supposed to do with you bought an eMMC flash module? I’ve been explained you first need to flash a micro SD card with the image, and then interrupt the boot in u-boot (USB to TTL debug board required), remove the eMMC jumper, and continue the boot by typing “boot”. This has be to be done, or you won’t see the eMMC flash module, while booting from a micro SD card.
Now you can download, and flash the firmware to the eMMC flash module with curl:
|
1 |
curl -L https://github.com/ayufan-rock64/linux-build/releases/download/0.4.17/xenial-mate-rock64-0.4.17-85-arm64.img.xz | unxz -c > /dev/mmcblk0 |
Not the most user-friendly method, but it should work. If you don’t have a USB to TTL board, first you should really buy one, but for this specific case, you could remove the eMMC jumper about two seconds after applying power. In that case, your mileage may vary though… Pine64 is working on an easier method of installation to the eMMC flash module.
Rock64’s Ubuntu 16.04.3 MATE Boot, System Info, and Initial Setup
Since I want to get the boot log, I connected the USB to TTL board. There’s no dedicated UART connected on the board, so I download the GPIO pinout charts for Pi 2 Bus and Pi 5+ Bus from the Wiki, amd we’ll use it to test GPIOs later on.
UART Tx and Rx can be found on respectively pin 8 and 10 of Pi 2 Bus header, so I connect the debug board accordingly, together with USB keyboard and mouse, a USB harddrive, Ethernet and HDMI cables.
Finally I put the eMMC flash module into the board, applied power, and after a few seconds, I got to the Ubuntu MATE desktop. however, I only got ribberish in the serial console, which was set to 115,200 8N1, the most common settings “in the universive”. There’s currently no info about serial console setting in the Wiki, but a web search lead me to the right settings: 1,500,000 8N1, which apparently is the default in Rockchip SDK.
This high bitrate may cause troubles with some serial adapter, but after changing minicom settings accordingly, I had no trouble with the serial console. That’s the complete boot log after a reboot:
|
1 |
We can now login with rock64/rock64 credentials in the desktop or the serial console:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
Last login: Sun Aug 6 07:36:04 UTC 2017 on ttyFIQ0 Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.70-rockchip-ayufan-85 aarch64) _ __ _ _ _ __ ___ ___| | __/ /_ | || | | '__/ _ \ / __| |/ / '_ \| || |_ | | | (_) | (__| <| (_) |__ _| |_| \___/ \___|_|\_\\___/ |_| * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage System information as of Sun Aug 6 07:48:04 UTC 2017 System load: 0.0 Processes: 154 Usage of /: 75.2% of 4.80GB Users logged in: 0 Memory usage: 20% IP address for eth0: 192.168.0.113 Swap usage: 0% Graph this data and manage this system at: https://landscape.canonical.com/ 0 packages can be updated. 0 updates are security updates. |
I checkout some infor about CPU, storage, memory usage, and Linux & Ubuntu versions:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
rock64@rock64:~$ cat /proc/cpuinfo processor : 0 BogoMIPS : 48.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 .... Serial : ed973de35684d5e5 rock64@rock64:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 458M 0 458M 0% /dev tmpfs 93M 4.4M 88M 5% /run /dev/mmcblk0p7 4.8G 3.7G 945M 80% / tmpfs 462M 0 462M 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 462M 0 462M 0% /sys/fs/cgroup /dev/mmcblk0p6 100M 50M 51M 50% /boot/efi tmpfs 93M 4.0K 93M 1% /run/user/107 tmpfs 93M 0 93M 0% /run/user/1000 rock64@rock64:~$ free -mh total used free shared buff/cache available Mem: 922M 101M 514M 33M 306M 756M Swap: 0B 0B 0B rock64@rock64:~$ uname -a Linux rock64 4.4.70-rockchip-ayufan-85 #1 SMP Fri Aug 4 08:38:41 UTC 2017 aarchx rock64@rock64:~$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS" |
I have the 1GB version of the board, and the firmware is based on the latest Ubuntu 16.04.3 LTS release with a fairly recent Linux 4.4.70 kernel. However, we can see that with just 4.8GB capacity the rootfs partition has not been automatically resized during the first boot. So let’s run the relevant script, and check again:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
sudo resize_rootfs.sh df -h Filesystem Size Used Avail Use% Mounted on udev 458M 0 458M 0% /dev tmpfs 93M 11M 83M 11% /run /dev/mmcblk0p7 14G 3.7G 9.8G 28% / tmpfs 462M 0 462M 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 462M 0 462M 0% /sys/fs/cgroup /dev/mmcblk0p6 100M 50M 51M 50% /boot/efi tmpfs 93M 4.0K 93M 1% /run/user/107 tmpfs 93M 0 93M 0% /run/user/1000 |
All good, as we now have a 14GB rootfs partition. It’s worth noting the other scripts in /usr/local/sbin too:
|
1 2 3 4 |
ls /usr/local/sbin/ armbianmonitor resize_rootfs.sh rock64_fix_performance.sh install_desktop.sh rock64_diagnostics.sh rock64_health.sh install_openmediavault.sh rock64_eth0_stats.sh |
Modules and GPIOs on Rock64
The next step was to check pre-loaded modules and GPIOs:
|
1 2 3 4 5 6 7 |
rock64@rock64:~$ lsmod Module Size Used by uas 20480 0 usb_storage 61440 1 uas rock64@rock64:~$ ls /sys/class/gpio export gpiochip0 gpiochip32 gpiochip64 gpiochip96 unexport |
Only uas and usb_storage modules are loaded, which shows people are truly focusing on the NAS part right now, or some other drivers are directly built-into the kernel. GPIOs need to be exported manually, and a quick search lead me to that forum post (again no info in the Wiki right now).
You need to convert the gpio pin name as shown in the pinout diagram (e.g. GPIO3_A5) into a raw number using a formula combining bank number (3), pad name (A) and pad number (5). marcushh777, who is also a helpful member on IRC, wrote a Python script to do just that, and you may want to create that script in /usr/local/sbin/name2gpio.sh:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
#!/usr/bin/python3 import sys import string pads={"A":0,"B":1,"C":2,"D":3} def convert(value): value = value.upper() bank_num = int(value[4:5], 10) pad_nam = pads[value[6:7]] pad_num = int(value[7:], 10) gpionum = (bank_num * 32) + (pad_nam * 8) + pad_num return gpionum if __name__ == "__main__": args = sys.argv[1:] if not args: print("Usage: %s <bank_reg> ie; GPIO3_A5" % sys.argv[0]) sys.exit(1) print("%d" % convert(args[0])) |
The file is also on Github so you could use wget or curl instead:
|
1 2 |
sudo wget https://raw.githubusercontent.com/pfeerick/rock64-scripts/master/name2gpio.py -O /usr/local/sbin sudo chmod 755 /usr/local/sbin/name2gpio.sh |
We can now run the script with the GPIO we want to use…
|
1 2 |
name2gpio.sh gpio3_a5 101 |
… switch to root, then use sysfs to export the gpio number and set the direction, and switch the GPIO to high and low levels:
|
1 2 3 4 5 |
rock64@rock64:~$ sudo -i root@rock64:~# echo 101 > /sys/class/gpio/export root@rock64:~# echo out > /sys/class/gpio/gpio101/direction root@rock64:~# echo 1 > /sys/class/gpio/gpio101/value root@rock64:~# echo 0 > /sys/class/gpio/gpio101/value |
I connected a 5V LED to GPIO3_A5 pin via a transistor and could turn it on and off with the last two commands above.
Eventually, a PDF document will be uploaded to the Wiki, but it does not appear to be ready yet. I was unable to find info to use I2C or SPI at this stage.
GPU (OpenGL ES) and VPU (Video Decoding) Testing
GPU and VPU support are often problems in Linux on ARM, and while I had low expectation, I still tried those by installing the usual OpenGL ES demo to test Mali GPU support:
|
1 |
sudo apt install mesa-utils-extra glmark2-es2 |
I ran es2info first, and Mali-450MP GPU support is indeed enabled:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
ock64@rock64:~$ cat gpu es2_info EGL_VERSION: 1.4 Linux-r7p0-00rel0 EGL_VENDOR: ARM EGL_EXTENSIONS: EGL_KHR_image, EGL_KHR_image_base, EGL_KHR_image_pixmap, EGL_EXT_image_dma_buf_import, EGL_KHR_gl_texture_2D_image, EGL_KHR_gl_texture_cubemap_image, EGL_KHR_gl_renderbuffer_image, EGL_KHR_reusable_sync, EGL_KHR_fence_sync, EGL_KHR_swap_buffers_with_damage, EGL_EXT_swap_buffers_with_damage, EGL_KHR_lock_surface, EGL_KHR_lock_surface2, EGL_EXT_create_context_robustness, EGL_ANDROID_blob_cache, EGL_KHR_create_context, EGL_KHR_partial_update, EGL_KHR_create_context_no_error EGL_CLIENT_APIS: OpenGL_ES GL_VERSION: OpenGL ES 2.0 GL_RENDERER: Mali-450 MP GL_EXTENSIONS: GL_OES_texture_npot, GL_OES_vertex_array_object, GL_OES_compressed_ETC1_RGB8_texture, GL_EXT_compressed_ETC1_RGB8_sub_texture, GL_OES_standard_derivatives, GL_OES_EGL_image, GL_OES_depth24, GL_ARM_rgba8, GL_ARM_mali_shader_binary, GL_OES_depth_texture, GL_OES_packed_depth_stencil, GL_EXT_texture_format_BGRA8888, GL_OES_vertex_half_float, GL_EXT_blend_minmax, GL_OES_EGL_image_external, GL_OES_EGL_sync, GL_OES_rgb8_rgba8, GL_EXT_multisampled_render_to_texture, GL_EXT_discard_framebuffer, GL_OES_get_program_binary, GL_ARM_mali_program_binary, GL_EXT_shader_texture_lod, GL_EXT_robustness, GL_OES_depth_texture_cube_map, GL_KHR_debug, GL_ARM_shader_framebuffer_fetch, GL_ARM_shader_framebuffer_fetch_depth_stencil, GL_OES_mapbuffer, GL_KHR_no_error Segmentation fault (core dumped) |
That command ended in a segfault however. Not too reassuring.
So I ran es2gears demo, but could not take a screenshot, as all screenshots were black with only the mouse pointer showing up, so instead I some photos, and it works, but the transparent window is unlikely to be normal.
Performance does not appear to be optimal right now however with just around 35 fps.
glmark2-es2 demo started well too…
… but some features are not supported (maybe normal), and it crashed at the end as shown in full log below:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 |
glmark2-es2 ======================================================= glmark2 2014.03+git20150611.fa71af2d ======================================================= OpenGL Information GL_VENDOR: ARM GL_RENDERER: Mali-450 MP GL_VERSION: OpenGL ES 2.0 ======================================================= [build] use-vbo=false: FPS: 22 FrameTime: 45.455 ms [build] use-vbo=true: FPS: 21 FrameTime: 47.619 ms [texture] texture-filter=nearest: FPS: 23 FrameTime: 43.478 ms [texture] texture-filter=linear: FPS: 33 FrameTime: 30.303 ms [texture] texture-filter=mipmap: FPS: 31 FrameTime: 32.258 ms [shading] shading=gouraud: FPS: 31 FrameTime: 32.258 ms [shading] shading=blinn-phong-inf: FPS: 26 FrameTime: 38.462 ms [shading] shading=phong: FPS: 25 FrameTime: 40.000 ms [shading] shading=cel: FPS: 24 FrameTime: 41.667 ms [bump] bump-render=high-poly: FPS: 32 FrameTime: 31.250 ms [bump] bump-render=normals: FPS: 32 FrameTime: 31.250 ms [bump] bump-render=height: FPS: 26 FrameTime: 38.462 ms [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 24 FrameTime: 41.667 ms [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 21 FrameTime: 47.619 ms [pulsar] light=false:quads=5:texture=false: FPS: 30 FrameTime: 33.333 ms [desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 22 FrameTime: 45.455 ms [desktop] effect=shadow:windows=4: FPS: 27 FrameTime: 37.037 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 24 FrameTime: 41.667 ms [buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 24 FrameTime: 41.667 ms [buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 25 FrameTime: 40.000 ms [ideas] speed=duration: FPS: 27 FrameTime: 37.037 ms [jellyfish] : FPS: 27 FrameTime: 37.037 ms Error: SceneTerrain requires Vertex Texture Fetch support, but GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS is 0 [terrain] : Unsupported [shadow] : FPS: 24 FrameTime: 41.667 ms Error: DistanceRenderTarget::setup: glCheckFramebufferStatus failed (0x8cd6) Error: Failed to set up the render target for the depth pass [refract] : Set up failed [conditionals] fragment-steps=0:vertex-steps=0: FPS: 32 FrameTime: 31.250 ms [conditionals] fragment-steps=5:vertex-steps=0: FPS: 28 FrameTime: 35.714 ms [conditionals] fragment-steps=0:vertex-steps=5: FPS: 26 FrameTime: 38.462 ms [function] fragment-complexity=low:fragment-steps=5: FPS: 25 FrameTime: 40.000 ms [function] fragment-complexity=medium:fragment-steps=5: FPS: 25 FrameTime: 40.000 ms [loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 30 FrameTime: 33.333 ms [loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 31 FrameTime: 32.258 ms [loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 25 FrameTime: 40.000 ms ======================================================= glmark2 Score: 26 ======================================================= [xcb] Unknown request in queue while appending request [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. glmark2-es2: ../../src/xcb_io.c:165: append_pending_request: Assertion `!xcb_xlib_unknown_req_pending' failed. Aborted (core dumped) |
The results are actually better than I expected, but there’s still some work.
I tried to play 1080p60 H.264 Big Buck Bunny video with VideoLAN (VLC) first, and all I got was the first frame with changing artifacts around the bufferfly, and I had somewhat better luck in SMPlayer with the video playing almost smoothly in windowed mode, and some saturated and accelerated audio. Switching to full screen mode would just show a black screen, until I was asked to signing again a few seconds later…
So video playback is basically unusable at this stage in the Ubuntu MATE image, and you’d better go with Android, or potentially LibreELEC currently released as alpha for ROCK64 board. LongChair also told me in IRC that “we have ffmpeg / mpv working on rock64 … we need to do more testing and get a few bugs fixed by rockchip before I finally upstream that to ffmpeg / mpv”, so video support is definitely coming. It’s just not ready yet. Another person informed me that contrary to Amlogic, Rockchip does not use AFBC (ARM Frame Buffer Compression) natively, and the memory bandwidth is critical, 4K H.265 HDR videos may not always play that well in RK3328. I’ve been told it may take one to two more months for 4K support in Linux, and that 1080p is now supported but not released just yet in the Ubuntu image.
Storage and Networking Benchmarks
I’ll skip the Phoronix benchmarks in this review, as we’ve had so many ARM Cortex A53 platform the results won’t be much better, unless there’s a bug, which would eventually be fixed. Instead, I’ll focus on storage and network performance on Rock64, since it may vary between boards.
Those are the results for the 16GB eMMC flash module:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
rock64@rock64:~$ iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.429 $ Compiled for 64 bit mode. Build: linux Run began: Mon Aug 7 07:57:03 2017 Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 102400 kB Record Size 4 kB Record Size 16 kB Record Size 512 kB Record Size 1024 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 3739 3983 13670 13529 10040 3286 102400 16 14691 16617 42836 41817 32541 13525 102400 512 61160 62555 104573 105080 103194 57375 102400 1024 65257 66834 88161 87493 107791 62274 102400 16384 68368 69154 115801 115543 116806 69463 |
Up to ~115 MB/s read speed, and ~69 MB/s write speed, and good random I/O too. For reference, Ubuntu boots in 17 seconds from power on to the login screen.
I then tried to create the iozone test on the NTFS partition of my hardware, but it failed because NTFS is read-only.
|
1 2 3 4 |
/dev/sda3 on /media/rock64/USB3_EXFAT type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2) /dev/sda2 on /media/rock64/USB3_EXT4 type ext4 (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2) /dev/sda4 on /media/rock64/USB3_BTRFS type btrfs (rw,nosuid,nodev,relatime,space_cache,subvolid=5,subvol=/,uhelper=udisks2) /dev/sda1 on /media/rock64/USB3_NTFS type ntfs (ro,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0177,dmask=077,nls=utf8,errors=continue,mft_zone_multiplier=1,uhelper=udisks2) |
That can happen because of file system error, or because the image using the NTFS kernel module that provides read-only access only. So I installed ntfs-3g instead:
|
1 |
sudo apt install ntfs-3g |
and remounted the drive inside the file manager in the desktop.
|
1 2 |
mount | grep sda1 /dev/sda1 on /media/rock64/USB3_NTFS type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2) |
You can see the type is now “fuseblk” instead of “ntfs” – meaning the userspace ntfs-3g driver is used – , and the partition mounted as read/write. So I could run iozone on the NTFS partition:
|
1 2 3 4 5 6 7 8 |
rock64@rock64:/media/rock64/USB3_NTFS$ iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 10370 12576 35152 36719 45856 9476 102400 16 27991 35766 119034 85545 110793 26933 102400 512 63171 69174 218638 277927 278086 60380 102400 1024 36862 73739 220764 271545 273047 60054 102400 16384 55000 67898 248506 271069 270885 56848 |
Something is clearly wrong with the read speed: up 271 MB/S is not right, as it’s much higher than what my USB drive is capable of (~115 MB/s) on my main PC. That means caching must be involved here, so I’ve increased the file size to 500 MB in the test:
|
1 2 3 4 5 6 7 8 |
rock64@rock64:/media/rock64/USB3_NTFS$ iozone -e -I -a -s 500M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 512000 4 11829 13527 32656 56827 1752 1454 512000 16 31523 37165 70412 99561 4798 9507 512000 512 75751 77231 119035 135740 60399 41423 512000 1024 92341 95392 104966 105620 47227 64270 512000 16384 91866 97065 102748 107358 168563 91517 |
and the results are much more realistic, except for the random read with 16384 reclen. It shows up to 119 MB/s reads, and up to 92 MB/s writes, which means everything is working as expected. So I repeated the test with the EXT-4 partition:
|
1 2 3 4 5 6 7 8 |
rock64@rock64:/media/rock64/USB3_EXT4$ iozone -e -I -a -s 500M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 512000 4 8047 10869 11790 13360 439 228 512000 16 29448 36252 40357 41231 1652 1125 512000 512 70047 85427 96046 96639 11018 20149 512000 1024 92463 94148 89365 96762 20271 31251 512000 16384 86057 94764 93612 96066 64444 84218 |
The results are a bit lower at 96 MB/s read and 94 MB/s write, but still pretty good for a mechanical drive over USB 3.0. It should be noted that performance decreases the closer you are from the center of the drive. The NTFS partition in the first quarter, and the EXT-4 in the second quarter of the drive, and I got 108 MB/s with the first partition (NTFS) and 96 MB/s with the second partition (EXT-4) using “Disks” utility in Ubuntu when I first bought the drive. Other people have reached close to 400 MB/s with SSDs over the USB 3.0 port of ROCK64 board, but for most people getting to around 100 MB/s should be enough for their data.
Finally I tested Gigabit Ethernet by doing the usual full duplex test with iperf:
|
1 2 3 4 5 6 7 8 9 10 |
sudo apt install iperf iperf -t 60 -c 192.168.0.104 -d Client connecting to 192.168.0.113, TCP port 5001 TCP window size: 204 KByte (default) ------------------------------------------------------------ [ 6] local 192.168.0.104 port 51540 connected with 192.168.0.113 port 5001 [ ID] Interval Transfer Bandwidth [ 6] 0.0-60.0 sec 3.97 GBytes 568 Mbits/sec [ 4] 0.0-60.0 sec 4.72 GBytes 675 Mbits/sec |
That’s OK, but not overwhelming, maybe it will improve with a more recent kernel as with some other platforms. I also did a download-only test with iperf3, and it could do so at around 933 Mbps:
|
1 2 3 4 5 |
rock64@rock64:~$ iperf3 -t 60 -c 192.168.0.104 -R - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-60.00 sec 6.52 GBytes 933 Mbits/sec 137 sender [ 4] 0.00-60.00 sec 6.51 GBytes 933 Mbits/sec receiver |
No problem here with very good performance.
Pine64 has started to ship the first batch of board, so there will soon be more feedback from users. From my experience with Linux, you should be good to go if you want to build a NAS for example with their Debian OpenMediaVault image with good performance for Ethernet and USB 3.0, and use GPIOs with sysfs. If your project requires I2C & SPI drivers you may want to wait, and for multimedia use in Linux, 1080p support should be mostly ready, but 4K videos support may need a few more weeks or months, and good OpenGL ES performance may take more time too. Documentation is also work in progress right now, as I had search quite a bit to find how to use various features of the board like the serial console and GPIOs, but you can help from the forums, and #Rock64 IRC channel (if you are using an IRC client, disable SSL). I’m expecting things to improve over time as more people get their hands on the boards.
You can purchase ROCK64 board with 1, 2 or 4 GB RAM for $25 and up, as well as accessories directly on Pine64 website. The second batch of board is scheduled to ship on August 30th.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress. We also use affiliate links in articles to earn commissions if you make a purchase after clicking on those links.
