Hello.

We ordered four of these, and have tested two of them so far and them seem to be having locking up issue. After about three days of running, the units will freeze up, and need to be rebooted. Will be testing the other two soon. One of the two tested has a CPU heatsink.

Anyone else having issues with that?

Hi, I am new owner of Rock64 4GB powered by genuine 3A psu and storage on Samsung MicroSDHC 32GB EVO Plus UHS-I U1 card.
I will try to share all my findings about this interesting board.
My goal is to achive stable h265 htpc for my old samsung tv.

First of all I was very disappointed how unstable is the stock board. I have tryed Android 7.1 TV, Android 7.1, Bionic minimal linux, Android 8.1, LibreElec and Recalbox. All systems except Android 8.1 and Bionic minimal were randomly freezing or crashing even with heatsinks on cpu and mem.

I have managed to install Kodi 17.6 on Android 8.1, but h265 hd iptv stream was choppy.

Then I reached recalbox installation and was impressed how seamless kodi worked, untill crash.
I suspect overheating to be main problem on my board. Maybe it's bad soldering, design or initial setup. It looks like most systems are crashing above 60'C
I have managed to reach console through ssh and lowered cpu frequency by setting governor to powersave.
Cpu frequency has been reported about 400MHz, I dont remember exact value, and temperature mostly did not exceeded 60'C. 
System was stable for at least 20 minutes and h265 playback was perfect.

I have few questions.

1/ Why the temperatures were so high even on powersave governor (cpu usage was low (top )) ?
2/ Can we lower voltage to cpu, mem and default cpu frequency to lower overheating ?
3/ Is genuine aluminium casing effective against overheating problem ?

Meanwhile I will try to use active cooling and test if my system is stable enough.

I have got a showstopper and I am not sure where to place the fault, but maybe someone has some insight as I am sure there have to be several builds similar to mine. Using the NAS Case set up all bought from the store. Ayufan’s OMV (armhf) for the NAS with NFS and SMB shares and Raspi with the LibreElec flavor of Kodi. Videos start good but will randomly stop after some time. OMV is fine, but Kodi locks up. Oddly it plays fine through WMP on a Win10 machine (smb obviously). I tagged onto this post, but the OP says he thinks it is hardware. I also saw this bug report but it isn’t a memory issue that I see through HTOP (although the MEM bar does seem to fill up some and never go back down). I am not an advanced Linux user, but am smart enough to search and follow directions. Any help would be appreciated.

Where can I find a US distributor?

AmeriDroid carries the full line of Pine64 products except Pinebook.
see... https://ameridroid.com/collections/singl...and_pine64

I bought the "clusterboard" and I want to use the Pinebook to develop for it.

Hola. me gustaria que se abriera un hilo en español para los usuarios de pinebook que tengamos uno y asi poder compartir con mas facilidad todos los aspectos del mismo. Gracias al administrador del foro si lo tiene en cuenta.

I've got a Clusterboard and 7 SOPine modules sitting in my cart with the excitement of thinking I will run Mesosphere DC/OS and/or Kubernetes on it to build out, literally on my desk, a fully elastic containerized microservices orchestrated backend (FECMOB) for my mobile/web app. And then in theory once I've written it all down from a composer and orchestrator perspective I could seamlessly play the whole systematized symphony out on the global cloud providers.  (I think of it as going from "hyperlocal fog" to "global cloud") 

But then I have a huge question; is the performance of this hardware gonna make it unusable for doing such a thing?  Is a single-board-computer-cluster (SBCC) just a geek toy or is it performant enough for a developer to actually use in building a real cloud application? I know any containers I run on this thing will be be slower than the running them on the "real" thing (actually they're all containers though too aren't they) but the question is how slow? Does anybody have a sense if this would work or if the whole system will just be so slow and frustrating given the inherent performance of the Cortex A53 with 2GB of RAM that I shouldn't even attempt this to avoid the disappointment? On spec it looks like this board gives you hardware that roughly equivalent to 28 t2.nano instances but they're ARM vs XEON.

Thanks

Is the PI-2 bus compatible with the Raspberry Pi GPIO connector with respect to IO levels for the UART, e.g. will a FTDI Friend! from AdaFruit work on the ROCKPRO64?

Is the serial console configured on UART2_DBG when using this Linux image: https://github.com/ayufan-rock64/linux-b...m64.img.xz  ?

My Rock64 is currently running:

Ubuntu 16.04.5 LTS (GNU/Linux 4.4.132-1075-rockchip-ayufan-ga83beded8524 aarch64)

I see that Ubuntu 18.04.1 is ready for upgrade but when I started the upgrade I was cautioned about doing this via SSH. Since my use is exclusively Samba & FTP, is there a really good reason to upgrade at this time? I probably should have gone with a simple Debian build in the first place but I have little interest in starting over.

What is the likelihood that the distro upgrade via SSH will crash? How stable is 18.04 LTS?

Any thoughts will be greatly appreciated.

Best,
Tom

Hi,
I'm trying to use my Rock64 board to automate astronomical observations, I mainly use an ASI camera (https://astronomy-imaging-camera.com/pro...m-pro-mono) and a filter wheel.
The camera is USB3, and provides its own USB2 hub to attach other peripheals (like the filter wheel). The camera USB hub can be externally powered (and it currently is), so current shouldn't be an issue.

I tried different configurations for the ubuntu images (both armbian and ayufan):
 - 18.04 32bit: worked pretty fine at some point, but with some instabilities here and there while shooting. The latest installation though seems to fail pretty much consistently after circa 17 shots, I'm seeing lots of these messages on my kernel log:

Someone has build kernel 4.18.8

https://github.com/ddimension/linux-mainline-kernel