Posted on by Jean-Luc Aufranc (CNXSoft) - 25 Comments on ROCK64 Board Review – Part 2: Quick Start Guide with Ubuntu 16.04.3 MATE, Multimedia Features, Some Benchmarks

ROCK64 Board Review – Part 2: Quick Start Guide with Ubuntu 16.04.3 MATE, Multimedia Features, Some Benchmarks

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:

  1. 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
  2. Community versions (currently managed via ayufan) are more frequently updates, and comes with more recent features. You’ll find two categories
    1. Release builds – The current stable version released by the community
    2. 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.

Top to Bottom: ROCK64’s 16GB eMMC flash Module, Hardkernel adapter, and micro SD card reader

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:


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.

Pi 2 Bus – Click to Enlarge

 

Pi 5+ Bus – Click to Enlarge

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.

Click to Enlarge

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:

We can now login with rock64/rock64 credentials in the desktop or the serial console:


I checkout some infor about CPU, storage, memory usage, and Linux & Ubuntu versions:


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:


All good, as we now have a 14GB rootfs partition. It’s worth noting the other scripts in /usr/local/sbin too:

Modules and GPIOs on Rock64

The next step was to check pre-loaded modules and GPIOs:


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:


The file is also on Github so you could use wget or curl instead:


We can now run the script with the GPIO we want to use…


… switch to root, then use sysfs to export the gpio number and set the direction, and switch the GPIO to high and low levels:


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:


I ran es2info first, and Mali-450MP GPU support is indeed enabled:


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…

Click to Enlarge

… but some features are not supported (maybe normal), and it crashed at the end as shown in full log below:


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:


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.


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:


and remounted the drive inside the file manager in the desktop.


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:


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:


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:


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:


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:


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.

 

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK 5 ITX RK3588 mini-ITX motherboard

25 Replies to “ROCK64 Board Review – Part 2: Quick Start Guide with Ubuntu 16.04.3 MATE, Multimedia Features, Some Benchmarks”

  1. @cnxsoft:
    Wrt HDD performance: “It should be noted that performance decreases the further away you are from the center of the drive” — it’s the opposite, the outer tracks are usually faster since more data can be read during one one rotation due to more sectors on the outer tracks than on the inner ones.

    When using FUSE/ntfs-3g iozone’s -I parameter is obviously ignored: -I –> Use DIRECT IO if possible for all file operations. Tells the filesystem that all operations to the file are to bypass the buffer cache and go directly to disk so all numbers are heavily affected by caching/buffering.

    BTW: I don’t think that current ROCK64 development really focuses on NAS/OMV use cases, it’s just that we’ve reached in this area already 99% of what’s possible with the hardware (there are one or two minor USB3 quirks that need a fix but besides that ROCK64 as ‘single disk NAS’ performs as fast as any beefy x86 box or any other ARM NAS device limited by Gigabit Ethernet). I’m really looking forward to be able to use RK3328 as media player too but as far as I understood (being a total noob here) this will still take some time until all issues are resolved.

    Reply

  2. Current LibreELEC work is aimed more generally at RK3328 support (not specifically Rock64 or the Tinkerboard) with the intention of having something sorted for Kodi Leia in ~6 months time. Development so far has been done with Krypton, but a rebase against Leia is now starting. So far progress has been rapid thanks to diligent work from LongChair/Kwiboo and great support from a small group of RK staff who feed them weekly updates against an evolving issue list. Current state is still closer to “technical proof of concept” than “alpha” and definitely not “beta” which implies a completed codebase with minor finishing required. We expect the next phase to go slower; complex code needs to be written and multiple efforts from AML, RK, FFmpeg, Kodi, etc. need to be aligned as we push onwards towards mainline kernels and V4L2 support (SoC vendors need to get their arses about V4L2 drivers). Fun times are ahead 🙂

    Reply

  3. @tkaiser
    Yes correct. Linear speed increase further from the center with a constant angular speed. This reminds of when I got my first CD writer, as the writing speed was not constant over time. I’ve updated the post accordingly.
    About NAS cases, I was told in IRC that not much had been done on the desktop side. So let’s say the focus was on server / headless use cases first. But many people are working on the board in parallel, so everything is moving in the right direction.

    Reply

  4. Rock64 is good competitor at this price to H6 device :

    Gigabit + Fast ethernet.
    USB3 for fast storage.
    H264/H265 hw encoder (for cam ip recording and displaying remotely).
    If the mali 450 driver will be handle (webkit hw acceleration) by icecat or chromium, maybe a good desktop…

    I think i wiil buy this board instead waiting next H6 or RK3399 dev board

    Reply

  5. the board has 100 MB efi partition, half full already, and still uses uboot. what’s in those 50MB? Is Rockchip working on edk2 porting?

    Reply

  6. Is it possible to install the Rock64 Ubuntu or Debian Linux images on TV boxes such as the Z28 or A95X R2 which also use the RK3328?

    Reply

  7. The “efi partition” is EFI in name only (partition type). As noted, the board uses Uboot, not EFI. The partition appears only on the community image. Rockchip typically use MTD instead of GPT to define partitions. It is simply a way of expressing reserved system space (kernel, device tree) that is compatible with other systems. MTD is suitable for fixed media devices like tablets, phones, etc. However, for a removable SD card, a common partition table such a MBR or GPT allows other devices to easily read/write it.

    TL;DR = the EFI partition is a “convenience” feature, not a system feature.

    Reply

  8. The crappy glmark2-es2 scores are currently common to all Rockchip platforms using X11. The reason is two-fold: The images usually 1) have compositing enabled and 2) use a Rockchip customized X11 server with glamour rendering. In my experiments, I was able to achieve 160fps+ in glmark2-es2 using a customized X11 driver with compositing disabled.

    I am actually fond of the ROCK64 board. It has a lot of potential. There is also community engagement from the vendor (Pine) responding to issues developers face. This places it above “something Pi” boards flooding the market like orphan tribbles. The board is genuinely “fun” for development because there is a great deal of lower level documentation from Rockchip’s open source efforts.

    (Disclaimer: I received an evaluation board)

    Reply

  10. cortex-a72 :
    the board has 100 MB efi partition

    To quote Kever, the responsible RK engineer being in touch with open source community: ‘what we are actually after is UEFI boot’. There’s a sufficient amount of SPI NOR flash on the board and final goal is to have all the necessary bootloader stuff there in (SPL, FIT, ATF, U-Boot/Tianocore, DT) to be able to boot any device agnostic 64-bit ARM image out there.

    I believe you know ARM’s André? If so you should drop him a short note and ask about progress and implementation ideas.

    Reply

  11. tkaiser :
    U-Boot/Tianocore

    Huh? Cut&paste leftover from an essay I tried to write just to give up on it since it’s better to ask @apritzel instead 🙂

    Reply

  12. I just got a test version for a RK miniloader that supports u-boot on SPI flash for RK3328. A while back I added support for the SPI flash to the Rock64 BSP devicetree and kernel to start some early experiments for booting from SPI, which would enable more flexible handling of eMMC and SD-Cards as well as new features like booting from network and USB. I will continue now with that and see if we have all of the pieces to move to SPI as a primary boot option, probably also using mainline u-boot. Last info I got from RK on an open u-boot SPL was that it should be ready for release by end of August, so this miniloader based approach is probably only a short term stopgap measure.

    Reply

  13. this is very interesting news, thank you for sharing your experiences – I’m after a small profile board which will support hardware accelerated 1080p video playback from a few different streaming IP cameras, so I can monitor hard to see spots in my business (and check if people are shoplifting). Potentially I’d also like to use it to run Chrome and watch youtube 1080p videos to replace my desktop. I’ve been trialling an Amlogic S905X chipset media player running Armbian, but there is no desktop video acceleration support as yet.

    Reply

  14. @gizmomelb
    If you want video acceleration in a desktop OS, you may want to check out ODROID-C2 board. YouTube videos may be a separate issue.
    For your use case, it might be better to just buy an NVR system.

    Reply

  15. @gizmomelb
    I would suggest an Odroid XU4. It has a hardware accelerated X11 driver. It also has a hardware accelerated video decoder and hardware accelerated video scaler (both through V4L/Gstreamer).

    With any ARM board, I doubt you will find anything that does exactly what you want “out of the box”. Some research and effort will likely be required. This is mainly due to the state of graphics on Linux. I do not use Android so I can not comment on what features/software is does or does not support.

    Reply

  18. @cnxsoft
    Yes, this Transformer can be used as a normal Android TV box, a performant Linux NAS or Nextcloud box and most probably also something in between, be it an Android box that does perform well as NAS (settings matter) or a Linux box with KODI on top.

    I don’t follow progress closely but AFAIK it looks pretty promising wrt KODI/Linux on RK3328 devices (people should search for LongChair/Kwiboo efforts on the subject) and it’s also easy to tweak the NAS part when running Android. Most simple approach would be to use ayufan’s community Android builds since they contain the necessary tweaks like better cpufreq and IRQ affinity settings and of course the few Samba config tweaks to let GbE boxes exceed +100MB/s with SMB traffic between Windows clients and the ‘NAS’:

    Reply

  20. @blu
    Hmm… but everything you can do with the Transformer you can also do with a ROCK64 (or any RK3328 device with same features eg. Alfawise Z28 Pro). The main differences are simply that the Transformer has been built based on community feedback/experiences somewhat focusing on the NAS use case eliminating the most common hardware issues users run into. IMO that’s the whole list of Transformer features:

    – Avoiding USB3 cable/contact hassles by putting the USB-SATA bridge on the PCB
    – Choosing a good and UAS capable USB-SATA bridge so both great performance and no troubles with storage access
    – Avoiding underpowering issues by bundling an appropriate PSU with reasonable ratings (3A)
    – Hacking friendly by allowing all possible boot sources
    – Hacking friendly by being 100% compatible to ROCK64 so all community based OS images will run here too
    – Enclosure providing excellent heat dissipation though that’s IMO not a problem with RK3328 anyway

    Reply

  22. @tkaiser
    From my perspective, it’s the community OS support, functional GPU & nice amount of RAM, and the good usb-sata bridge that make the greatest difference; the good enclose thermals being a bonus.

    Reply

  24. Pine64 – rockpro64 default user and login – I was just in my Armbian OS and did a reboot and at the pre-login it is asking for a Login and Password and the info I createed for Armbian is NOT working. Does anyone know what the default login and pw is for the RockPro64 4TB board running Armbian OS…..???

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Boardcon Rockchip and Allwinner SoM and SBC products
Boardcon Rockchip and Allwinner SoM and SBC products