Hi,
I'm making a cluster with three rock64.
Its work well with rock64 power supply.
Now a whant to replace these power supply by an unique one, witch can i use ?

Thanks in advance.

In this guide, I will be going through how to add USB storage to your Board: 

Confirm that the drive is recognized by Linux 

Formatting the drive for Linux use 

Mounting the Partition/FS

Setting appropriate directory and file permissions. 

Greetings,

The purpose of this post is to document the procedure for writing gnu+linux images to the eMMC module on the Rock64 board; the procedure is fairly straight-forward and is not difficult with some small planning and care. First I'll give just a little discussion of the overall theory, then list the materials that you will need, and finally we'll cover the step-by-step detail.

Theory

The overarching goal is to copy the desired image from the network directly to the eMMC module; in order to do this we need to boot-up the Rock64 board from an SD card containing a minimal gnu+linux image -- this is NOT the image that will be written to the eMMC module necessarily, it is only the image that we will use to do the work. Once the Rock64 is booted from SD card, we can then issue the command (or run the automated script) that will download the desired image from the network directly to the eMMC module; then its simply a matter of rebooting the Rock64. The interesting part of the procedure (detailed below) is that the eMMC module needs to be visible to the system AND the system has to be forced to boot from the SD card. This will be explained.

Materials Required

This procedure will require the following bill of materials: 1) Rock64 board, 2) eMMC module, 3) two pin jumper, 4) bootable SD card (gnu+linux), 5) serial console adapter cable, PC or Mac and serial terminal software like minicom, screen, or cu.  For the purposes of this tutorial we assume that you already have the Rock64 board with eMMC module installed, and that you have a bootable SD card (minimal gnu+linux image), also that the bootable SD card has the curl command utility installed.  The two pin jumper can be the standard plastic block two pin header jumper connector, or it can be a six inch jumper wire with standard header female (F-F) connectors both ends. Lastly you will need a serial console ttl to usb bridge cable adapter and serial console terminal software.  This can be any of a number of supported chipsets (cp2102, pl2303hx, ch340g). The challenge is that the standard serial console uart baud rate is 1.5M (1500000 baud, 8n1). Not all combinations of serial bridge adapters and software support 1.5M baud rate. I have tested the cp2102, the pl2303hx;  the pl2303ta does NOT work.  Minicom is the best software for serial terminal;  the reason we need a serial terminal (software and bridge cable) is that we will need to watch the boot sequence so that we can 'stop' the boot-up at the uboot three second timer (described later).

Background

In order to boot-up the Rock64 from the SD card, so that the eMMC module is also available, we have to force the boot-up with a 'jumper' using two special pins on the main board, and we also have to interrupt the boot-up (at the uboot three second timer) so that the SD card system can detect the eMMC module for writing later!  The important things to be aware of are: 1) the jumper shorts the clock signal on the eMMC module to ground (be careful, don't ESD shock it), and 2) the jumper must be removed before the SD image comes up so that the eMMC clock will be active and the linux image on the SD card will "see" the eMMC module;  failure to do this will result in not being able to write the network image to the eMMC module.  Also, if you do not have a serial console active you will not be able to see when the uboot timer is running so that you can interrupt it.  The serial console is very important because the normal display does not show boot-up messages!

Preparation steps

The preparation steps are very important and will setup things so that the main procedure will be successful. Make sure that the preparation steps run smoothly and that they can be repeated easily before moving on to the main procedure:  this is very important !

1) make sure the eMMC module is snapped in place on the Rock64 main board

2  make sure the bootable SD card is installed in the SD card slot;  this should be one of our gnu+linux images containing the curl utility tools;  again, this image is NOT copied to the eMMC and is only used to do the required work.

3)  install the jumper on the two special pins on the Rock64 main board;  these two pins are directly next to the small "recovery button" on the main board. Either a two pin plastic block jumper connector may be used, or a six inch jumper wire with F-F female header connectors on each end.

4) make certain that your serial console works!  Connect the appropriate Tx Rx and Gnd pins of the bridge adapter cable to the uart pins of the Rock64 header (see serial console tutorial) and then plug the other end (usb) into your PC or Mac;  use serial terminal software like minicom, screen, or cu to "talk" to the Rock64 board over the serial connection. While the serial console is connected and "running" boot the Rock64 board;  this is just a test of the serial console... you should see the boot-up messages flying by on the serial terminal software and when fully booted you should see a logon prompt.  Logon to the Rock64 board and then enter the command  sudo halt  and you will see the Rock64 shutdown including the shutdown message stream.

( repeat step [3] a couple of times to make sure that you understand what is happening, and that the serial console is working;  also (important) pay attention to the messages and be looking for the uboot three second timer !  This is the timer that you must interrupt (later) in order to remove the jumper at the right time.  Also, you will need a good ethernet network connection, so make certain your eth cat5 or cat6 cable is plugged into a good router connection. )

Note:  see step (7) of the main procedure (below) because the command sd2emmc.sh  script file needs to be on your SD bootable card in the rock64 home directory.   (important)

Main Procedure

These are the main steps of the procedure that will copy the desired image from the network to the eMMC module;  yes, you will need a good network connection, the faster the better.  We are assuming that the preparation steps are complete and that everything is working; if not, procede no further until the preparation steps are complete.

1)  boot-up the Rock64 (as in preparation) with the jumper in place and the serial console running and prepare to stop (interrupt) the boot-up at the uboot three second timer.  To interrupt boot at the timer, just press a key to stop the timer.

2)  To interrupt the uboot three second timer press a key and the timer will stop;  if this does not work the first time, or you miss it, just shutdown and try try again.  Once the uboot three second timer has been interruped move on to step three (3).

3)  Carefully remove the jumper from the main board;  do not short against any other pins.

4)  Continue with the boot-up by entering the command   boot

5)  Once the boot-up has completed and you have the logon prompt on the serial console, logon to the serial console and prepare to issue the curl command detailed below:

6)  First,  make sure that both of your storage devices are present.  If they are NOT present, then shutdown with  sudo halt  and start over from the beginning (by booting with the jumper in place). To see if the devices are present use the command  sudo fdisk -l

    sudo  fdisk  -l

6b) You should see two kinds of devices in the list:  
        /dev/mmcblk1xx   This is your SD card
        /dev/mmcblk0xx   This is your eMMC module

     If you do NOT see both mmcblk0 and mmcblk1 devices you must start over.  

[  Please read both step(s)  7a  and  7b  before proceding;  ]

7a)  We are now ready to copy the image from the network to the eMMC module;  it is important that you 'know' which image you want to copy from the github site;  the one listed in this example is 0.4.16 ; however, you will want the last stable release ( not pre release ).  Enter the curl command below ( or automated script which does the same thing ) and wait until it is finished;  the command copies the image directly from the network github site to the eMMC module.    (we are working on a port of the install script to automate this step, soon)

sd2emmc.sh

Hi,
Does the Rock 64 support Bluetooth BLE on Android? In some places I can see a reference to a USB with Bluetooth 4 but I can't find it in the store.
Thanks

   


The new Rock64 is running sweet !  

... just doing burn-in now;  got some python procs running;  ssh terminal stuff;  network and serial console right now, very pleased -- second Rock64 and many more to come.


Note:   very interesting;  unlike my pre release board, this production board (running the same image) is running much cooler;  the cpu|gpu is cool to the touch, and the temps idling are in the high 30s ℃  ;  loading the system with my PI routines drove the temps up to high 40s ℃ , and this without even a passive heatsink !

Yes!! I could use the RDP Desktop with Xfreerdp !!

I f you need installing Xfreerdp, please feel free to post here.

OK, my question comes from being very ignorant of Linux and the limits of the Pinebook. My expectation is to use the machine mostly to do writing via Google's Sheets and Docs. Given the availability of largish SD micros and USB sticks, why would I want to upgrade from the 16 to 64 GB eMMC? Would it be like buying a Jeep to drive to work on the freeway and dream of driving over the cars in front of me when traffic stops, but never try?

first of all: i think there should be no throttling on any cpu under full load when testing it to the edge. (never had that my any laptop to be honest).
the pinebook is simply no exception in my opinion, but it throttles under certain loads due to heat.
hmm...
..
..how to tackle this?
EXTRA COOLING!

note: i won't say the pinebook is bad because of the throttling, i just want to mention this could be improved for a tiny bit of money (china is way cheaper than the eu anyway regarding hardware)

since i haven't received my pinebook yet.
but already know some details on how tight extra cooling can be to limit throttling, i thought of a bare bones cooling solution.

i looked at a small heatpipe, a small blower style fan, and copper film, all either too expensive or complicated for my use.
so i had to rethink my plan basically, and came across something very clever.

a material that is basically in almost every home, transfers heat as good as a heatsink (when applied correctly)
i'm talking about aluminum foil (tin foil called in america) which is practically a good heat spreader (because it's aluminum) and is thin, ideal for putting it between the case and the existing pinebook heatspreader

it won't be hard to make it work, just hard to apply (need to keep wrinkles down to a minimum on the SOC area)

a few layers over the soc extending over the battery area and towards the trackpad area should work nicely.
since most hardware is not within the area to cause damage, it should give almost zero risk of a short circuit (when applies correctly).

i'm planning to put in on the main board/keyboard/battery part of the laptop using some artic silver thermal paste i have, with a 1.6mm fully copper clad pcb i have laying around on top.
purely to let it fress nicely against the existing heatspreader when the bottom plate is screwed back on.
all will be secured with the existing case screws.

in total i plan on using 5 layers of aluminum foil of about 20cm x 10cm
costs: less than 2€ in the NL for a whole roll of aluminum (tin) foil of 3000cm x 30cm (30m x 0.3m), some thermal paste, plus a spare piece of (un)etched pcb, shim, spacer or similar (1.6mm x 30mm x 30mm).
imagine if this were done in china, it would cost around 1/5th of the €2 (0,40€), maybe even less

small lessons for this include: extra cooling isn't hard to accomplish, and is VERY cheap if you think clever.
this can be done in the factory as well (a bit more professional by sticking it all to the bottom plate), to prevent thermal throttling at those SOC intensive tasks and extend the lifespan of the device.
(we all know heat degrades devices over time)

i will let you guys know how it went (once i get my pinebook) and post the following thermals: SOC + PMIC.
all tested under these conditions while fully charged, at 50% backlight:
idle (cold start, booted into OS, idle for at least 5 minutes)
10min 4 thread stress test (same requirements as the idle test before this starts)
20min 4 thread stress test (same requirements as the idle test before this starts)
10 min watching youtube at 360p on firefox (same requirements as the idle test before this starts)

all under armbian 9 at room remp of 20 degrees C.

maybe in the future i will repeat the tests at 25 degrees C sometime, not sure

for now, anyone knows a good package for stressing the whole CPU? (where the slight throttling occurs at?)

(this post is merely a global info and placeholder for the final results till i've done this mod, which will described in this post)

maybe pine64 should set a public development goal for new boards.
like $xxxx R&D for a new addon board or seperate dev board.
with a public counter on the website.
with each sold iten, let's say 2% of the paid amount goes to that R&D budget

and let users choose on the forum for which modules needs to be developed first (a thread with poll for example)
this way users get to have more interaction with what they want towards the dev teams and such
it's a win-win: users simply can vote for what they want the most.
and that'll be made first, where pine64 listens to the ideas and makes what the users really want, giving (possible) higher sale numbers.

note that this would be nice to have, and this could pine64 really competetive with other solutions where the ideas are only based on devs.

i am not trying to rework the pine64 business model, but just thinking out loud about a ideal way for customers and devs for pine64.

I've just quickly made the following script for python, only tested with python3, on the stock Mate pinebook install.
Not sure if other installs move around the xinput device for the touchpad (else replace the 8 with the right number)

This script disables the touchpad of the pinebook for 0.5 second whenever a key is pressed, any key, including ctrl/shift/alt/mod.  So it's not perfect and cannot be use for shift/ctrl+click very effectively yet. But the script could be modified for that.

Note that if you google for the touchpad problem, you will find a lot of mentions for "syndaemon", which doesn't work (and exits without a message) The "synclient" command however will tell you why, because our touchpad isn't showing up as a touchpad but as an emulated mouse.
Hench this hacky script.

And I've just typed this post without a single problem while the script is running. Figured I share this ASAP, as the very sensitive touch pad is at the top of the list of things that people find annoying.