The Rock64 doesn't do Neon?  That's a shock. I was trying to build cpuminer https://github.com/pooler/cpuminer

I have it built and running on 2 or 3 Rpi 3's then I turned to the Rock64.  I get the obnoxious message that the compiler cannot create executables, which can mean anything, there was just some error compiling a test program.

This doesn't work on my Rock64 (does on Pis)
./configure CFLAGS="-O3 -mfpu=neon"

If I drop out the neon part so it's just
./configure CFLAGS="-O3"

Then it works.  But you get just compiled C, not the ARM assembly language that Pooler wrote.  So it's slower than a Pi.  I get 0.97 khash/s instead of 1.32 or so.  (Per thread)

If I do cat /proc/cpuinfo that mentions neon on a Pi, not on a Rock64.

I've seen it written each way. For instance, this category is "SOPINE" and the schematics say "SOPINE", but the Armbian welcome message displays "SoPine". The modules themselves say "SOPine". So is it Sopine, SOPINE, SOPine or SoPine?

On the clusterboard v2.2 the reset button won't restart shutdown SOPINE modules - they stay off with a dim PL7 green light. Any suggestions to restart individual SOPINEs? 

I'm leaning toward shorting the VCC and GND on the jumper pins beside each SOPINE. I could rig each set of jumpers with a toggle switch. Any suggestions on the best way to do this without harming my SOPINEs?

Hi all. Archlinux is up and running on the Pine64. Yay has been installed - and in turn used to install the Asterisk phone application.
Can anyone comment in why it will not start? ... please refer to attachment. Any helpful advice on using the new Archlinux also appreciated.

Attached Files

Thumbnail(s)
   

I just purchased another Rock64 to build another NAS using OMV and I decided to get the premium aluminum case this time.  It arrived with no instructions and I have a couple of questions:

1) The kit includes 2 pieces of blue thermal tape and a little packet of thermal compound.  Am I supposed to use all three (stacked) in the assembly?

2) There is a little acrylic light pipe that looks like it should go in a hole near the white and red LEDs but it is too big.  Do I just need to drill the hole in the case out a little?

Thanks for any help from those who've gone before me.

Marc

Does the Rock64 support 10 bit HEVC 1080p and 4K content?

I've heard that LibreELEC for Rock64 does support it, but it's in alpha and seemingly not very reliable. The other option is ayufan's ATV build, but I'm not sure if HEVC 10 bit is supported on this. 

Will I be able to play HEVC 10 bit content on ayufan's ATV build? Also, what is the extent of HDR support on it? I currently only have a 1080p TV but plan to upgrade to a 4K HDR TV in the near future.

Hello, I'm working on a project and I want to power the rock64 board off an external USB battery,
I was thinking about soldering the plus and minus wires from the USB port to the plus and minus of the barrel power jack.
I know I won't get charge information or anything, but will the battery recognize that it's being used and won't automatically shut down?
does anyone have any experience with running the board on battery?
Thanks a lot,
Omer.

Hello dears,
Anyone solve rock64pro output sound ????

Hello everyone I'm thinking of getting a Rock64 single board computer and I'm wondering if it has any type of PCie slot (slot for external gpu) because apparently it's GPU is not that good and I'm getting the 4gb variant of the Rock64 SBC because I want to use it as a mini pc when I'm out and about so please can someone answer?
--Thanks in advance
Prox

Hi forum,

I guess this is more of a suggestion to the release manager for pine64 and less of a question.

While I appreciate the dd image format's simplicity, it would make a lot more sense to distribute images lest wastefully.

Part of the reason I mention that is because the dd image that is distributed has a corrupt partition table, so it can't be copied to an SD card via more efficient means.

I run into this problem regularly and I myself am a fan of a couple of methods:

1) the bash binary

https://www.linuxjournal.com/content/add...ll-scripts

This is more useful if you want to add obscurity (not security) to the images you distribute

2) a zip file, along with 2 bash scripts that implement *an API*

This method is a bit more complex.

script 1: flash.sh

usage: flash.sh [--device|-d <device>] [--tmpdir|-t <tempdir>]

device  - a block device e.g. a default could be /dev/mmcblk0, exported as $DEVICE
tempdir - a temporary directory e.g. see man mktemp, exported as $TMPDIR

in turn, script 1 sources script 2, and script 2 exposes a few shell functions.

script 2: details.sh

fetch(): fetches all source files to $TMPDIR specified by script1
            urls are encoded in the details.sh file
            small files (e.g. patch files) can be stored in the .zip file locally
            large files can be fetched from the internet

prepare(): applies patches
                 partitions device
                 resizes partitions as appropriate
                 a really compact and scriptable way to specify a partition layout that can fill up space to the end of the disk (so you don't need to have 8GB, 16GB, and 32GB files) is using sfdisk
                 https://linux.die.net/man/8/sfdisk
                 http://download.vikis.lt/doc/util-linux-...k.examples

flash(): could use dd, or not
            a more efficient means for Pine64 would be to distribute .ext4 files or .vfat files that can be mounted as loop devices (using losetup)

3) fastboot

This is arguably the standard way of distributing Android factory images and is described in detail at the link below

https://source.android.com/setup/build/running

4) There is always yocto too.. ¯\_(ツ)_/¯

Really, there must be a better alternative than sitting here, waiting for 26 billion zeros to be written to an sd card.


Cheers,

C