Hi,

I'm about to order the Rock64 for a NAS project.
I'm going to build the Rock64 inside a 4bay case (like Chenbro SR30169 or similar).
I made a schematic how I thought to build it.

Here is my community build. Kernel is build as 64bit with 32bit Userspace. It means you can use 32bit armhf packages. I've been doing these builds for a while now for Odroid C2, WeTek.Hub and WeTek.Play2. The benefit in using 32bit packages with an aarch64 kernel is we can use retroplayer emulators that only compile for armhf and we can use precompiled libwidevine to play DRM protected content with Kodi through inputstream.adaptive.

Special thanks go to @peak3d for implementing the great inputstream plugin that makes DRM work with kodi.
Also special thanks to @Kwiboo, @longchair and @omegamoon for the great Rockchip work. These builds are based on kwiboo's LE tree.
And last but not least thanks to @tllim for providing me a Rock64 developer sample.


DISCLAIMER: This is a community build of LibreELEC. USE AT YOUR OWN RISK!

Tar upgrade from "pure" aarch64 builds might work. Use the following steps:

Hello,
I noticed that on Q4OS the touchpad is much less jumpy, and managed to find the config in question and copy it over to my own install.

unfortunately, this still does not solve 1 problem:
the bottom part of the touchpad, where the 2 buttons are, is also sensitive to touch and movement.
pressing a button, one always also moves the pointer a little.
so i would like to disable the bottom 1-2 cm of the touchpad.

is that possible?

afaiu the touchpad is NOT a synaptics device.
entering 'xinput list-props 8' i can see its properties.
anybody have an idea how to disable the bottom part of the touchpad?

also see: http://dt.iki.fi/pbhacks/

Hello, everyone.

I have two questions. I am using the Android Image 7.1.2 but it has only the patchlevel April 2017, is it planned to be updated?

Second question. I've seen that there's a linux kernel here:

https://github.com/ayufan-rock64

Do I have to install the firmware, as with the raspberry pi? If so, how?
Or is it enough to just take the current image?

Thank you very much!

So I've played with Ubuntu, I've played with Android and I've played with Bliss, and I'm just not feeling the value in my pinebook, I know it's a tinker device, I love the look and feel (Keyboard excluded...ugh) but the more I plug away at it, the more I think "Damn, This thing needs ChromeOS/ChromiumOS" Having run a Samsung ARM Chromebook for a while, I know the feel of ChromeOS on ARM, and I think it could be a good match for the Pinebook.

I had high hopes for Bliss though, while I was hoping for a good RemixOS port, with that dead in the water, Bliss is my only hope for a desktop based Android.

But yeah, A Chromium build on this beast would be awesome.

Hello everyone,

I just ordered a rock64 and I want to use the spdif port for audio out. As I have no need for the DAC or the 2nd eth port I don't want to use the DAC board.
Can I wire an fiber optic transmitter (like TOTX147) directly or do I need some buffer/driver like the inverters used
on the DAC board?

Thanks!

I've been toying around with my Pinebook now for a few weeks, off and on.

What I'm concerned about is the low level of activity on this forum. Unless I am missing something, this is the obvious hub for Pinebook news and discussion, yet it is not very popular.

I've tried most of the OS images available for Pinebook, including Android, Q4OS as well as the Ubuntu Mate and Armbian distros - various versions of each.

None have yet worked well enough to provide a reasonable desktop experience  - i.e. no GPU accelerated compositor... unless the very slow performance I was seeing when I did enable GPU composition was just how slow the Mali GPU really is??

I expected at or near RPi 3 performance - perhaps that was optimistic of me.

Maybe Pinebook is not for me. I'm not a hardcore Linux user, but I think I'm a step or two ahead of an average Ubuntu newbie. I've used Linux, if infrequently, for around 20 years. I don't get down an dirty with core OS development though.

I thought having an expectation of a well performing desktop environment would be easily met. Rough edges I'm used to - there's not been a Linux distro I've used that hasn't had a lot of rough edges, but 3D acceleration and fast 2D desktop composition have been reliable keystones for many years.

Am I really missing something that I should be doing? I must have read through 80% of all the forum posts.

Hi,
thanks to the great Q4os developers I now have a quite decent Debian Stretch system running.  After I managed to flash the eMMC with Q4os I simply editet sources.list to point to Stretch instead of Jessie and did a dist-upgrade.   I needed to fiddle a bit with the graphics since X was lost but rebuilding libump and xf86-video-fbturbo under Stretch did the trick.  (I'm a Debian developer and might consider creating at least an official libump package - need to check the license of fbturbo whether it is acceptable in Debian.)
I installed XFCE4 which I prefer over the desktop choice of the Q4os developers.  So far my desktop now looks quite similar to my Intel based laptop. :-)
However, I came across two problems:

1. Xfce4-battery plugin always shows an empty battery even if onscreen notification says "battery full" when plugging in power adapter (I tried do fix this by an acpi dkms kernel module which unfortunately does not build with the current kernel)
   
2. I wanted to use cryptmount which issues an error that lets me assume that loading a certain kernel module is a problem (sorry, I do not have my pinebook at hand to be more precise)
   

Not sure where this should go. Searched old posts. There was one from 11/2016 referring to writing one SD card's contents to another but didn't go very far. I didn't find much more info.

Step 1: Customize a mainline Debian Stretch build (or any build of choice).
Step 2. Save that customized build to an image on an external USB drive (or HDD)
Step 3. Test software installation, performance, try and break it.
Step 4: If build gets broken, restore the saved image without having to re-customize the mainline build.
Step 5: Rinse, repeat.

What I gather so far.
1. Can't use Clonezilla - it's for AMD64 or i386 and can't boot the Rock64 board to usb like a conventional "PC." Bummer but understandable.
2. Use partclone.dd (with extreme caution)?
3. Will partclone.dd image all 7 of the base Rock64 partitions? (I don't see an option for loader1, loader2 in the partclone usage info.
4. Do I need to retain all 7 of the base Rock64 partitions? Just partclone the fat16 boot partition and the ext4 root partition?

I'm guessing there are others that have spent many hours tweaking builds only to make a mistake and have to start over. I'm looking to be able to save time by getting back to a car that already has the engine humming before I soup it up, so to speak.
I don't have the serial cable (yet) so can't write the SD to an EMMC chip. Will eventually do that, from what I gather, the performance gain & longevity compared to SD is worth the price of the EMMC.
Thanks

Hi all,

I've submitted requests on the BTO booking for the 14" Pinebook twice now (once about three weeks ago and again last week) but haven't received any email instructions on how to place the order.

Is there someone who can check on this? Am I just that far on the end of the queue?

Thanks,
Dane