Pinebook Pro Reviewnavigate:backcounter

Overview

Pine64, or more precisely Pine Microsystems, Inc., is producing ARM based single-board computers and laptops. The first laptop was the Pinebook for initially $89 from 2017. An updated version was then sold for $99. The second laptop is the Pinebook Pro for $199 from 2019. Both models are sold "at no cost" with no or minimal profit.

Pine64 is promoting open hardware. The Pinebook Pro's primary audience are people who support Pine64's mission and want to move away from UEFI, Intel Management Machines, closed source drivers and coincidental compatibility with Linux.

Ordering

Pine64 was initially building a first batch of 100 Pinebook Pros (with 10 being reserved for selected developers) scheduled to be shipped early September 2019 and a second batch of 1000 Pinebook Pros scheduled to be shipped early October 2019. Eligibility for one of the first two batches was a forum account created prior to July 1. 2019.

Pre-ordering started on July 25. 2019 5:00am PST. The night before, I set the alarm-clock to 4:50am and watched the count-down ticking on Pine64's website. When the counter reached zero the URL of the pre-order webpage appeared. My password manager was smart enough to fill out the login dialog with my forum credentials. This saved me a few seconds which I lost for reading the small-print. Pine64 sent me a confirmation email at 5:00:43am. The first batch was gone by 05:02:14am and so I made it into the first batch. The second batch was not completely gone by August 25. 2019 when pre-orders for further batches opened for the general public.

From: Pine64 <no-reply@pine64.org>
Date: Thursday, July 25, 2019 at 5:01 AM
To: XXXXXX XXXXXXXXXXX
Subject: Welcome to the Pinebook Pro!

Dear XXXXXX XXXXXXXXXXX, Thank you for your interest in the Pinebook Pro. You have successfully reserved a spot in the priority pre-order system. Please be on the lookout for a member of the PINE64 Sales team to be sending you your Coupon Code.

Please note that this coupon code will be required at time of purchase of a Pinebook Pro. Upon checkout, you must use the same email address which you registered on the PINE64 Forum. You can only buy a Pinebook Pro and Pinebook Pro accessories per coupon. The NVMe M.2 SSD adapter will be available at checkout for $6.99.

Please note that VAT and any types of import duty and taxes have not been added to the total value of all goods in the consignment. Please note that if your shipping address is located in a remote area, there will be a remote area surcharge on the delivery of your item.

If you encounter any problems during your purchase, you are always welcome to contact us by replying to this email pinebook@pine64.org

The Pinebook warranty period is 30 days and all sales are final, meaning a no return policy.

Please let us know if you need further assistance. We will be more than happy to assist you.

Thank you.

Sincerely,
PINEBOOK Team
http://store.pine64.org

I received the coupon code exactly 12 hours later. Folks in the second batch received their coupon code four weeks later.

From: PINE64 - Pinebook <pinebook@pine64.org>
Date: Thursday, July 25, 2019 at 5:01 PM
To: XXXXX XXXXXXXXXXX
Subject: Meet your New 14" Pinebook Pro!

Thank you for your interest in the Pinebook Pro. In this email you will find the coupon code required to complete your pre-order.

Pinebook Pro specifications can be viewed here and we encourage you to review them prior to completing your order.

To place your order please follow this link: https://store.pine64.org/?product=14-pinebook-pro-linux-laptop

Please note that your coupon code listed below will be required to complete the process. Upon checkout, you must use the same email address which you registered with on the PINE64 Forum.

Email : XXXXX@XXX.XXX.XXX
Coupon Code : XXXX-XXXX-XXXX
Expiry Date : 2019-07-31

You can only buy one Pinebook Pro and Pinebook Pro accessories with this coupon. Your order is planned to be shipped around the early of September 2019.

Please note that VAT, relevant import duties and taxes have not been added to the total value of all goods in the consignment. Please note that if your shipping address is located in a remote area, there will be 'remote area surcharge' on the delivery of your item.

If you encounter any problems during your purchase, you are always welcome to contact us at pinebook@pine64.org

The Pinebook warranty period is 30 days. All sales are final, with a no-return policy.

Please let us know if you need further assistance.

We are always more than happy to help.

Thank you.
Sincerely,
PINEBOOK Team
http://store.pine64.org

With the coupon code, I could order the Pinebook Pro. Billing was handled by PayPal. No PayPal account was required; a credit card was sufficient. Ordering the $199 laptop came to a grand total of $255.99 with $199.99 for the actual laptop plus $18.00 CA sales tax, a $5.00 CA e-waste recycling fee (although I never intend to recycle this machine) and $33.00 for shipping with DHL. Pine64's email suggested that there might additional import duties. There have been none for me. We live in such a connected world and so I do not understand why it is not possible to calculate import duties at the time of order.

Contradictory to Pine64's first email, I could not add accessories to my order and needed to open a ticket. My case seemed to have been particularly complicated. The customer service representative acted very professional. I gained the impression this person was genuinely interested in not finding the easiest but best solution. Multiple emails later I could finally order an NVMe M.2 SSD adapter for $6.99 and an eMMC reader for $4.99. These two items raised the total price to $269.05. There are follow up costs for those, who actually want to use a NVMe M.2 SSD. A typical NVMe M.2 SSD costs around $[FIXME]. What I did not know at the time of ordering is that the display is getting initialized in userland and the earliest signs of life from uboot, kernel and very early userland are only available on the serial console. Pine64 sells serial console cables for $6.99. They are a must for debugging boot problems.

Technical reasons delayed shipping the first batch by a month and more. A few Pinebook Pros have been shipped from Hong Kong right before Chinese "Golden Week" on September 30 but the bulk of Pinebook Pros have been shipped a week after "Golden Week" on October 15. The last 15 Pinebook Pros of the first batch have been shipped together with the second batch starting October 29th effectively moving them from the first batch to the second batch. Mine was such a late Pinebook Pro actually shipped on October 30 after some Pinebook Pros of the second batch were already on their way. I received mine on November 1 (see below tracking information). This was finally putting an end to this Odyssey.

Friday, November 01, 2019 Location Time
18 Delivered - Signed for by: company mail-man MILPITAS, CA - USA 14:24
17 With delivery courier FREMONT, CA - USA 13:30
16 Arrived at Delivery Facility in FREMONT - USA FREMONT, CA - USA 10:00
15 Departed Facility in SAN FRANCISCO GATEWAY - USA SAN FRANCISCO GATEWAY, CA - USA 08:08
14 Transferred through SAN FRANCISCO GATEWAY - USA SAN FRANCISCO GATEWAY, CA - USA 07:56
13 Arrived at Sort Facility SAN FRANCISCO GATEWAY - USA SAN FRANCISCO GATEWAY, CA - USA 07:07
12 Departed Facility in LOS ANGELES GATEWAY - USA LOS ANGELES GATEWAY, CA - USA 05:57
11 Processed at LOS ANGELES GATEWAY - USA LOS ANGELES GATEWAY, CA - USA 05:39
10 Clearance processing complete at LOS ANGELES GATEWAY - USA LOS ANGELES GATEWAY, CA - USA 15:53
Thursday, October 31, 2019 Location Time
9 Customs status updated LOS ANGELES GATEWAY, CA - USA 13:58
8 Clearance event LOS ANGELES GATEWAY, CA - USA 03:41
7 Processed for clearance at LOS ANGELES GATEWAY - USA LOS ANGELES GATEWAY, CA - USA 03:41
6 Arrived at Sort Facility LOS ANGELES GATEWAY - USA LOS ANGELES GATEWAY, CA - USA 02:44
Wednesday, October 30, 2019 Location Time
5 Customs status updated LOS ANGELES GATEWAY, CA - USA 17:51
Thursday, October 31, 2019 Location Time
4 Departed Facility in HONG KONG - HONG KONG HONG KONG - HONG KONG 04:04
3 Processed at HONG KONG - HONG KONG HONG KONG - HONG KONG 03:56
Wednesday, October 30, 2019 Location Time
2 Arrived at Sort Facility HONG KONG - HONG KONG HONG KONG - HONG KONG 23:44
1 Shipment picked up HONG KONG - HONG KONG 18:08

A Picture

Pinebook Pro

At a Glance

A deeper Look

The primary audience of the Pinebook Pro are people who see advantages in the next paragraphs on its open architecture, somewhat transparent boot process and full Linux support (albeit with a patched kernel).

The Pinebook Pro is as open as a computer can be in 2019: board schematics are available and the SOC is fully supported by open source drivers. The SOC's wifi/bluetooth block is Broadcom intellectual property and requires closed source firmware, though. Furthermore, the boot-process includes a stage-one boot-loader in ROM and a binary blob for both, the stage-two boot-loader and DRAM initialization.

The Pinebook Pro comes with 4 GB of DRAM. That is the maximum the memory controller can address. The memory controller is a physical block on the SOC and as such can not be replaced with a more capable one. It is unlikely anyone wants to remove DRAM from a 4 GB laptop and so it does not really matter that it is soldered. The effective DRAM is 3.875 GB: the top-most 128MB from 0xF800:0000 to 0xFFFF:FFFF are not addressable as the memory controller maps into this address space the PCI address space, a ROM holding a small boot-loader, some internal SRAM and register sets of various blocks on the SOC.

The eMMC partition layout:

Master Boot Record  offset      0kb   size   0.5kb
                    offset    0.5kb   size  31.5kb [This space seems to be unused]
IDBLoader           offset     32kb   size  8160kb
U-boot              offset   8192kb   size  4096kb
Trusted Firmware    offset  12288kb   size  4096kb
Boot Partition      offset  16384kb   size 65536kb
                    offset  81920kb   size 49152kb [This space seems to be unused]
Linux Root FS       offset 131072kb   size  to end

Upon powering up the SOC, one CPU starts executing at address 0xFFFFF:0000. That is where the memory controller maps a 32 KB small internal boot-rom. The boot-rom loads roughly the first 8 MB from the eMMC flash into an internal SRAM (mapped by the memory controller to address 0xFFFF:????). What resides there is a binary blob provided by the SOC manufacturer to initialize DRAM and load the next 4 MB from the eMMC flash into the just initialized DRAM. What resides there is the open source boot-loader u-boot which loads the kernel and device tree [rk3399-pinebookpro.dts] from the /boot partition into DRAM and passes control to the kernel (first u-boot checks for a /boot partition on a potentially inserted SD card and then on the eMMC flash). Guided by the device tree, the kernel initializes the SOC and board [FIXME: Is this correct? Rockchip's documentation on the boot process is somewhat cryptic]. This is quite elegant compared to how the Intel Management Engine [wikipedia link] or the AMD Platform Security Processor [wikipedia link] boot up modern PCs.

The Pinebook Pro is built around the Rockchip RK3399 SOC. Its Big.Little architecture has two high-end Cortex-A72 cores and four low-end low-energy Cortex-A53 cores. Like all its cousins from Intel, the Cortex-A72 "out-of-order execution" cores are vulnerable to Spectre and Meltdown. Due to its simplicity, the Cortex-A53 "in-order execution" cores are neither vulnerable to Spectre nor Meltdown. More information on the Rockchip RK3399 SOC is available on the manufacturer's wiki page.

The Linux kernel is a tweaked kernel started off Rockchip's github repo. It supports the whole SOC and so there are no problems which plague many laptops running Linux such as unsupported chips or flaky suspend to disk a/o memory [see my Lenovo G510 review link]. That is theory. The first few batches have wacky keyboard and trackpad firmware which got replaced on Nov. 22 2019. Also, suspend to memory and disk has some hick-ups. The kernel version 4.4 is somewhat dated as the current version is 5.3, but by no means obsolete as it is a long-term kernel with support till February 2022. By then the SOC is hopefully supported by the mainline kernel.

The Pinebook Pro comes pre-installed with Debian. As discussed in the previous paragraph, the kernel is a custom kernel. The windowing system is xorg and the filesystem is FAT32 for the /boot partition and EXT4 for the rest. FAT32 does not allow symlinks which I typically use in the /boot directory.

Review

This review was written in November 2019, e.g. during the first month of owning the laptop.

o CPU

I wanted my next laptop to have an alternative CPU architecture and it happened that the Pinebook Pro is built around the Rockchip RK3399 Hexacore ARM SOC. It is fast enough for my type of development work, watching videos and surfing the web. For surfing the web, I use an ad blocker and visit only moderately complex websites such as Heise, Spiegel and Youtube. They all load very quickly. Your mileage will definitely vary.

Some not so scientific bencharks:

o Development (multi-core performance and some ssd i/o): compiling a random linux kernel from the Pine64 git repo [link] via make ARCH=arm rockchip_linux_defconfig && time make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j 6 bindeb-pkg takes 20m49s vs 14m16s on my Lenovo G510 from 2014.

o LaTeX and PDF tools (single core performance and ssd i/o): compiling my PhD thesis takes 27.743s vs 11.856s on my Lenovo G510 from 2014.

# cat /proc/cpuinfo
processor	: 0
model name	: ARMv8 Processor rev 4 (v8l)
BogoMIPS	: 48.00
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 1
model name	: ARMv8 Processor rev 4 (v8l)
BogoMIPS	: 48.00
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 2
model name	: ARMv8 Processor rev 4 (v8l)
BogoMIPS	: 48.00
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 3
model name	: ARMv8 Processor rev 4 (v8l)
BogoMIPS	: 48.00
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 4
model name	: ARMv8 Processor rev 2 (v8l)
BogoMIPS	: 48.00
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd08
CPU revision	: 2

processor	: 5
model name	: ARMv8 Processor rev 2 (v8l)
BogoMIPS	: 48.00
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt lpae evtstrm aes pmull sha1 sha2 crc32
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd08
CPU revision	: 2

Serial		: 0000000000000000

The CPU clock frequencies (caveat, there is more to the performance of a CPU than clock frequency):

# cat /sys/devices/system/cpu/cpu?/cpufreq/cpuinfo_max_freq | tr "\n" "\t"
1512000      1512000      1512000      1512000      1992000      1992000

It is the first time I can toy around with a big.little CPU architecture. Here is an interesting case-study in parallelization. I was compiling a linux kernel with make -jn allowing n compilations to be dispatched in parallel.

j1 real 63m03.721s user 64m20.015s sys 04m34.679s
j2 real 33m28.409s user 64m12.669s sys 04m50.640s
j3 real 27m14.206s user 73m06.491s sys 05m26.390s
j4 real 23m42.549s user 81m01.083s sys 06m02.435s
j5 real 21m58.216s user 88m57.846s sys 06m34.789s
j6 real 20m49.394s user 94m48.045s sys 06m51.734s

The data is very interesting and makes actually sense:

o Operating System

The Pinebook Pro came preinstalled with a custom Debian 9.9 image although Debian 10 was already out for 3 months. When I received the Pinebook Pro, the only other available Linux distribution were two custom Ubuntu 18 images. No other Linux distribution was available let alone a single BSD. A chromium OS and Android 7.1 image were also available.

What came preinstalled on the eMMC flash was a full-blown Debian system with 1360 packages [package list]. I would have prefered going over an installer and choose software packages that are right for me.

The kernel is a 64 bit arm64 image while userland is built as 32 bit armhf binaries. 32 bit binaries tend to be smaller (that is good for a memory constrained system like the Pinebook Pro) but also slower (that is bad for an already slow CPU such as the one in the Rockchip RK3399). The main reason for userland being 32 bit are Google's widevine DRM binary blobs for Netflix and Amazon Prime Video. They are only available as 32 bit armhf binaries.

Almost all software comes from Debian. I verified all package checksums to make sure the installed binaries have not been tempered with. That is difficult to say for files which are only vaguely under apt's control such /etc/.

$ cat /etc/apt/sources.list
deb http://http.debian.net/debian/ stretch main contrib non-free
deb-src http://http.debian.net/debian/ stretch main contrib non-free
deb http://security.debian.org/ stretch/updates main contrib non-free
deb-src http://security.debian.org/ stretch/updates main contrib non-free
deb http://http.debian.net/debian/ stretch-updates main contrib non-free
deb-src http://http.debian.net/debian/ stretch-updates main contrib non-free

There are customizations. They are not nicely integrated and, some may argue, are not trustable:

First, the software development process should be re-thought. The custom kernel repo [link] claims to be a fork of Rockchip's kernel repo [link], but it is just a copy/paste with all of the git history lost. Individual git commits consist of tens of thousands of changes mixing "backports" and custom additions. Commit messages do not follow kernel guidelines let alone any other reasonable guideline. All this makes tracking changes very difficult and one may easily lose trust in the code.

Linux 1.2 introduced loadable kernel modules way back in 1995. The custom kernel does not build Pinebook Pro device drivers as loadable kernel modules but straight into the kernel image. Only device drivers which are not used by the Pinebook Pro are built as loadable kernel modules. With that, hacking a Pinebook Pro device driver requires not only changing the kernel CONFIG from "Y" to "M" but also an unnecessary reboot.

When in comes to the preinstalled Debian image, the custom kernel image is not managed by apt but simply dumped onto the filesystem into /boot/. Some custom scripts and even a dummy file of size zero are also dumped onto the filesystem into /usr/bin/ (mrfixit_update.sh, partbootscript.sh, rockpro_bt.sh and 2parts.touch). I believe /opt/bin/ (and /var/ for the dummy file) are better places for these customizations. The kernel and the scripts are updated via /usr/bin/mrfixit_update.sh by downloading new versions from a github repo. A lot of firmware in /lib/firmware/ comes from an unknown source and is also just dumped onto the filesystem. I believe customizations should not be updated via a script but need to come from a deb repository hosted by Pine64.

The sole purpose of /lib/systemd/system/partition-bootup.service together with /usr/bin/partbootscript.sh and /usr/bin/2parts.touch is expanding the root partition and filesystem to the full size of the eMMC flash upon the first boot. The proper place for this service file is /etc/systemd/system/ but that does not matter as I deleted it together with the accompanying script and dummy file.

I do not feel comfortable giving an individual person full access to my machine as the update script pulls also an arbitrary script from a git repo into /usr/share/mrfixit_updates/*/mrfixit_update.sh, and executes it. Right now, I pull updates manually via svn export https://github.com/mrfixit2001/updates_repo.git/branches/<version>/pinebook where <version> is a version such as v1.0, v1.1 etc and cherry pick what interests me.

I will keep the preinstalled Debian image as my main operating system. If and when a NetBSD port is available I will use that as my main operating system and briefly review it, too.

o Desktop

The default desktop environment is Mate. It came with a Pine64 branding and does not only look slick but is also fast and lightweight on the Pinebook Pro. I keep it, but renamed the default user rock, customized the panel, enabled focus follows mouse and stopped the terminal emulator from interpreting all kinds of key combinations meant for programs running under its control. The window border is only 1 pixel wide thereby making it hard to grab. It seems that Mate does not like custom xmodmaps.

Pinebook Pro Default Desktop Mate

o Stability

Under longer periods of high cpu load, say compilation on multiple cores with make -j5 for 45 min, wifi constantly shuts down:

Nov 11 09:47:39 pinebook-pro kernel: [48295.639926] CFG80211-ERROR) wl_cfg80211_hang : In : chip crash eventing, reason=0x80

The Pinebook Pro crashes every 24 hours or so (5 crashes in the first 5 days and counting). For now, I do not suspect a hardware defect but a kernel crash in Pine64's custom 4.4 kernel. Kernel crashes are hard to debug on the Pinebook Pro:

Update December 2019: The Manjaro folks are porting Rockchip's and Pine64's kernel patches over to the latest mainline kernel 5.4. They are doing a great job. Manjaro + their own kernel is rock stable, there are no crashes and even wifi does not shut down under load. I am running Manjaro from a micro SD card and the uptime is now 7 days and counting.

o Case

The case is sturdy, but also a fingerprint magnet. It is held together by only 10 screws and can be intuitively disassembled. The case should be carefully re-assembled as plastic spacers for some of the screws may easily break.

When I received the laptop, I heard a little piece rolling inside the case. Opening the case, it turned out to be a piece of a plastic spacer. Apparently, manufacturing hastily screwed the case together thereby damaging the spacer.

o Cooling and Noise

The Pinebook Pro is passively cooled. As there are no fans, the laptop is completely quiet. Under high cpu load, feelable heat dissipates on the bottom of the case.

When the screen is turned off, the soc and gpu temperatures are around 31C. With the screen turned on, these two temperatures rise to 41C. A parallel build utilizing all cores pushes these temperatures close to 70C. Here is my kernel patch to export the soc and gpu temperatures to /sys/class/hwmon/ so that libsensors picks them up pinebookpro-thermal001.patch.

o I/O Ports

The Pinebook Pro comes with USB-C (video out), USB 3, USB 2, micro SD card reader, headphone jack and barrel power ports. I severely miss an old fashioned SD card reader for my camera SD cards.

The USB 2 port can supply 500mA, the USB 3 port can supply 900mA and the USB-C port can supply [FIXME]mA. Some USB peripherials draw more than 500mA or even 900mA and so not all USB 2 or 3 pheriperials can be actually used with the Pinebook Pro.

o Storage

My Pinebook Pro came with a 128GB eMMC flash. I do not have any first-hands experience with flash drives and worry about their limited number of erase cycles and associated lack of lifetime.

128GB can store a whole operating system as well as my $HOME directory without pictures and videos (I rsync my desktop's $HOME directory onto my laptops as a secondary backup and permanent access to my data on the go). Here is a df from the first boot showing how much memory is occupied by the preinstalled operating system Debian 9.9:

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       115G  4.7G  106G   5% /
devtmpfs        1.9G     0  1.9G   0% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           1.9G   21M  1.9G   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/mmcblk1p1   63M   50M   14M  79% /boot
tmpfs           388M  4.0K  388M   1% /run/user/109
tmpfs           388M   24K  387M   1% /run/user/1000

The NVMe drive offered in the Pine64 Store is faster, cheaper and larger than eMMC drives, but also power-hungrier. I ordered from the Pine64 Store an NVMe adapter simply because it was quite cheap. For the foreseeable future I will exclusively use the eMMC flash, though.

The Pinebook Pro can also boot from external micro SD cards. Although micro SD cards are slower than eMMC flashes they are quite convenient for trying out new operating systems or booting recovery systems.

Booting from an exteral micro SD card, I measured the through-put of Pine64's own eMMC card by writing 1 GB of zeros into the swap partition and reading them back. The block size should obviously be a multiple of 1k.

# dd if=/dev/zero of=/dev/mmcblk2p4 seek=4  bs=512 count=2097152 ->   4.4 MB/s
# dd if=/dev/zero of=/dev/mmcblk2p4 seek=4 bs=1024 count=1048576 ->  73.3 MB/s
# dd if=/dev/zero of=/dev/mmcblk2p4 seek=4 bs=2048  count=524288 ->  83.4 MB/s
# dd if=/dev/zero of=/dev/mmcblk2p4 seek=4 bs=4096  count=262144 ->  84.9 MB/s

# dd if=/dev/mmcblk2p4 of=/dev/null seek=4  bs=512 count=2097152 ->   103 MB/s 
# dd if=/dev/mmcblk2p4 of=/dev/null seek=4 bs=1024 count=1048576 ->   135 MB/s
# dd if=/dev/mmcblk2p4 of=/dev/null seek=4 bs=2048  count=524288 ->   132 MB/s
# dd if=/dev/mmcblk2p4 of=/dev/null seek=4 bs=4096  count=262144 ->   139 MB/s

o Power Supply

Pine64's own 5V power supply can deliver 3.0A. Alternatively, the Pinebook Pro can be also charged over USB-C. For this, I use my Macbook Pro 2018 USB-C charger.

Under load, the laptop may occasionally draw more power than Pine64's own power supply or the Macbook Pro USB-C charger can supply. Below measurements are on the battery microcontroller under load (make -j5) while the Pinebook Pro was actually running on the power supply.

$ while true; do date +%H:%M:%S | tr "\n" "\t"; cat /sys/class/power_supply/rk-bat/capacity | tr "\n" "\t"; cat /sys/class/power_supply/rk-bat/current_now | tr "\n" "\t"; cat /sys/class/power_supply/rk-bat/voltage_now; sleep 1; done | tee battery.txt

Time       Capacity Current       Voltage   
18:58:13        100       0       4357000
18:58:14        100       0       4357000
18:58:15        100       0       4357000
...
19:31:57        100       0       4203000
19:31:58         91       0       3971000
19:31:59         91       0       3971000
19:32:00         91       0       3971000
19:32:01         91       0       3971000
19:32:02         91       0       4202000

After 33 min the capacity significantly dropped within a split second and so does capacity drop further over time. I assume there was between two measurement points a spike in current as well. I am not a battery expert, but I can not imagine that such drops are good for a battery.

The power supply consists of the actual power-supply and a slide-on plug for, depending on your order, either US or European power outlets. The slide-on plug looks very inexpensive and it is a pitty that not both have been shipped (think of international travel).

[FIXME: measure battery charge time: Pine64's power supply vs Macbook Pro's USB-C charger]

o Battery

As storage is flash and the SOC embeds 4 low energy cores, battery time is phenomenal with around 8 hours for typical use-cases. [FIXME: more precise data]

The battery driver cw2015_battery hardcodes values which are not fixed simply because they are not provided by the (dumb) battery microcontroller cw2015. This hardcoding makes the battery look better to users than it is. The health of the battery is hardcoded to "good", the internal temperature to 18.8C and the last full charge (which degenerates over time) to 98000mAh.

Inside the case is a sticker pointing out that the laptop will not power up on disconnected batteries. This was noticed by Pine64 right before the first batch of laptops was supposed to be shipped. In the last minute, two jumper cables have been soldered onto the motherboard. The soldering job does not look too trustworthy. The jumper cables need to be connected when the battery is disconnected. As the power supply does not provide enough current under load, it is adviced to not remove the battery, anyway. I expect a shutdown [FIXME: try it out: remove the battery and then putting the system under load].

What worries me is Pine64 not offering spare batteries. This is planned obsolescence.

o Wifi and Bluetooth

Wifi works out of the box and the adapter shows up as "wlan0". The signal strength is weaker than on my Macbook Pro 2018, though. [FIXME: get comparable numbers]

[FIXME: try out bluetooth with Bose QC35].

o No Ethernet

The SOC supports 1GB ethernet, but the board design does not make use of it. It is a pity that available functionality is not used, but not many will miss ethernet on a laptop in 2019. Neither do I (yet).

o Keyboard

There are two major types of keyboards: US style ANSI keyboards and European style ISO keyboards. The first two batches came with ISO keyboards. Later batches offer ISO and ANSI keyboards.

The quality of the keyboard is good, every stroke a character :). It is not backlit, though. The third key from the bottom-left corner is the Microsoft key, now called Pine key. It toggles together with F10, F11 and F12 the microphone (F10), bluetooth/wireless (F11) and webcam (F12) on and off when pressed for 3 seconds. The "control key" is in the bottom-left corner - that is exactly where an emacs user expects it. I wish the cursor keys where full sized. There are also no exclusive page-up and down keys. They need to be cumbersomely activated with the Fn + cursor keys slowing down navigating in large amount of text. I doubt keyboard designers actually use keyboards themselves.

The Pine key can be only used together with F10, F11 and F12. It can not be used together with any other key (xev does only detect the Pine key alone). On my other computers and window managers, I always navigate virtual desktops with the Microsoft key together with the cursor keys or TAB and so muscle memory gives me a hard time navigating virtual desktops on my Pinebook Pro.

I was born and raised in an ISO country but never liked ISO keyboards and prefered ANSI keyboards back in the day. Now that I live in an ANSI country, I like ANSI keyboards even more. Pine64 will eventually offer ANSI keyboard replacements and I will definitely order one. I badly wanted the Pinebook Pro since I heard of it in January 2019 and was not willing to wait any time longer for a later ANSI batch. By going with one of the first two batches, I got the free 64GB to 128GB eMMC upgrade which partially offsets the price for the ANSI keyboard replacement.

o Trackpad

The trackpad is of average quality. At home I use an external mouse and on the go the trackpad.

The Pinebook Pro does not have any mouse buttons. The left mouse button works with a one finger tap or click, the right mouse button is emulated by a two finger click and the middle mouse button is, you probably guessed it, emulated by a three finger click. Clicking the trackpad requires a non-trivial amount of force.

Stopping the mouse, the mouse pointer keeps on moving a few more pixels making it difficult to precisely position it on the screen.

o Screen

The screen is a 14" matte 1080p display without any dead pixels. There is not much to say except that it is perfect.

o Video Playback

Chromium can flawlessly render fullscreen 720p HD Youtube videos. Below is the CPU load. Note, only half of the physical memory is actually used.

top - 19:11:53 up  1:27,  2 users,  load average: 3.62, 3.32, 2.21
Tasks: 250 total,   1 running, 249 sleeping,   0 stopped,   0 zombie
%Cpu(s): 30.9 us,  5.0 sy,  0.0 ni, 63.7 id,  0.1 wa,  0.0 hi,  0.3 si,  0.0 st
KiB Mem :  3963184 total,  2326816 free,   776632 used,   859736 buff/cache
KiB Swap:  8589680 total,  8589680 free,        0 used.  3021612 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 5058 sschaeck  20   0  753608 358100 131172 S 153.6  9.0  17:04.85 chromium-browse
 4001 sschaeck  20   0  346344 126856 110284 S  24.5  3.2   5:01.09 chromium-browse
 3957 sschaeck  20   0 1133388 142412  85752 S  19.3  3.6   5:03.17 chromium-browse
  868 sschaeck  20   0 1157612  10132   8052 S   6.9  0.3   0:27.28 pulseaudio
  628 root      20   0  356736 117768  90232 S   3.9  3.0   6:52.02 Xorg

Smplayer can also flawlessly render local 720p HW videos. Below is the CPU load (for another video).

top - 21:38:13 up  3:53,  2 users,  load average: 3.42, 1.62, 1.59
Tasks: 257 total,   2 running, 255 sleeping,   0 stopped,   0 zombie
%Cpu(s): 31.5 us, 16.9 sy,  0.0 ni, 51.6 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  3963184 total,  1449340 free,   468516 used,  2045328 buff/cache
KiB Swap:  8589680 total,  8589680 free,        0 used.  3383652 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
12699 sschaeck  20   0  601608  87556  26252 S 228.1  2.2   1:56.66 mpv
  628 root      20   0  486232 172728 141820 R  44.4  4.4  21:36.25 Xorg
12696 sschaeck  20   0  101856  47084  35976 S   5.2  1.2   0:03.28 smplayer
  868 sschaeck  20   0  895696   9852   7744 S   1.3  0.2   3:19.47 pulseaudio

[FIXME: test playback of 1080p videos].

o Webcam

The webcam supports resolutions from 640x480 to 1600x1200. The frame rate drops significantly with increasing the resolution making playback very choppy. Keeping audio with video in sync required some effort (at least for ffmpeg). Videos and screencaptures are blurry. Here is a test picture which looks like it went through an oil-painting filter [webcam]. Here are videos demonstrating choppiness: [640x480][800x600][1280x720][1600x1200].

The default Debian image bundles smplayer, mpv and ffplay/ffmpeg.

o play (test) webcam

$ ffplay /dev/video0
$ smplayer /dev/video0
$ mpv /dev/video0

o create snapshots [press s]

$ mpv av://v4l2:/dev/video0

o record webcam [press q to stop] [FIXME: how to see and record the webcam at the same time?]

$ ffmpeg -thread_queue_size 16384 -f alsa -i hw:0,0 -itsoffset 1.65 -thread_queue_size 16384 -f video4linux2 -video_size 640x480 -i /dev/video0 -qscale 0 -y webcam.mp4

Note, itsoffsets need to be tuned to video_sizes. 1.65 work for 640x480 and 2.2 works for 800x600.

o Audio

Audio is a little thin and pales in comparison to my Macbook Pro 2018's audio. It is good enough to listen to music on the side, though.

Playing audio comes with a whine. The whine is hear-able when audio is muted, but otherwise barely noticable. Ignorance is bliss - I'm concious of the whine only since I learned about it after three weeks of owning the laptop.

o Microphone

I often record dry runs of presentations and store them with the slides. The microphone is [FIXME].

o Suspend

Suspend to disk and memory have hiccups [FIXME: elaborate].

o Daily Driver

TBD.

Tuning the default Debian Operating System

o Kernel Compilation

Compiling the custom 4.4 kernel requires 8.7GB of disk space (here it pays off that the original git history is lost) and some patience. The Debian way of compiling and installing the kernel follows.

Note, Debian's userland is 32 bit armhf while the kernel is 64 bit aarch64. Debian 9 on armhf does not come with the 64 bit arm cross-compiler gcc-aarch64-linux-gnu and the kernel needs to be cross-compiled from another system, possibly an intel system. Below instructions are for cross-compiling from Debian 9/amd64:

o installing the cross-compiler.

# apt-get install crossbuild-essential-arm64

o get the source code and copy over the .config file from the Pinebook Pro. It is available in compressed form in /proc/config.gz. Here is a local copy of the original .config for 4.4.198 and 4.4.202.

# cd /opt/src
# git clone https://github.com/mrfixit2001/rockchip-kernel.git linux
# cd linux
# # copy here the .config from the Pinebook Pro
# make ARCH=arm64 oldconfig

Note, in recent times, the kernel is based not on https://github.com/mrfixit2001/rockchip-kernel.git but https://github.com/mrfixit2001/rk-kernel-fork.git. Compare the most recent commit messages and make a sophisticated guess which is the git repo du jour.

o update the source code from time to time (not necessary after pulling the source code the first time)

# cd /opt/src/linux
# git pull
# make ARCH=arm64 oldconfig

o build the kernel and modules

# cd /opt/src/linux
# time make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j 4 bindeb-pkg

o build device tree blob (for reasons unknown, it is not built by default)

# cd /opt/src/linux
# make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j 4 rockchip/rk3399-pinebookpro.dtb

The build bundles the kernel and modules into /opt/src/linux-image-*_arm64.deb. Copy this file onto the Pinebook Pro and install it there via:

# dpkg -i --force-architecture /path/to/linux-image-*_arm64.deb.

Option --force-architecture is necessary as Debian expects only armhf packages. The built device tree resides in /opt/src/linux/arch/arm64/boot/dts/rockchip/rk3399-pinebookpro.dtb and needs to be copied into the /boot directory of the Pinebook Pro.

Before installing the kernel, it might be a good idea to backup the old, known working kernel and device tree to /boot/Image.bak and /boot/rk3399-pinebookpro.dtb. Note, /boot parition is quite small and can only hold two kernels and device trees.

Note, to stress-test the system from time to time, I compile a random arm kernel (make ARCH=arm rockchip_aarch32_defconfig). Commit d976b "mrfixit epic update" on Nov 20 2019 broke arm support. Here is my patch to get an arm kernel to build and only to build, again pinebookpro-armbuild001.patch.

Caveat: MrFixIT's update script mrfixit_update.sh takes the liberty to overwrite custom kernels and device trees. With a custom kernel, it is adviced to not call this script but manually merge its changes.

o Filesystem Encryption

The filesystem is not encrypted. This is not a good idea in general and in particular not for a laptop (think of a lost or stolen laptop).

As far as I know, linux filesystem encryption does not allow password changes and so it does not make sense to ship a laptop with a default password. Filesystem encryption is typically set up during installation of the operating system. As Debian came preinstalled, it is up to the user to manually set up encryption. [FIXME: rewrite this paragraph. I was told that Luks allows password changes via adding a new password and removing the old password]

I would have prefered encrypting the root filesystem. Debian's initramfs knows how to unencrypt an encrypted root filesystem but the preinstalled Debian image was set up to boot straight from the root filesystem (/sbin/init). After some back and forth I decided that it is not worth the trouble and went with encrypting the home partition with Luks, only.

First off, what comes preinstalled on the eMMC flash is a 6.5 GB image. On first boot /lib/systemd/system/partition-bootup.service expands the root partition and filesystem to the full size of the eMMC flash. This is not helpful as we need a separate /home partition. To make space for a home partition, the root partition must be shrunk. To shrink the root filesystem, it must not be mounted. There are several ways to get access to the umounted root filesystem, the most obvious are

Choosing the right partition sizes is an art in itself. If you are old school, you may also want to take the chance and create a swap partition at the same time. I chose 8GB for swap, 26GB for root and the rest for home. I kept the tiny boot partition untouched. Note, there is no partition over the first 16 MB of the eMMC flash and 48 MB between the first and second partition. Keep this space untouched - that is the location of the second stage boot loader and uboot.

How to set up filesystem encryption is a matter of personal taste - in particular the cryptsetup options. Below notes assume Linux booted off the external SD card and the eMMC flash is accessible via /dev/mmcblk1.

o Prerequisites: the kernel needs to be recompiled with kernel config DM_CRYPT (either built-in or as a module) and the splash screen needs to be disabled as it would hide the password dialog. How to recompile the kernel is discussed in its own section above and how to disable the splash screen is discussed in the tips and tricks section further down.

o shrink the root filesystem, adjust the root partition size and create a new partition for /home and optionally for swap and expand the root filesystem, again

- shrink root filesystem to its minimum

# fsck -f /dev/mmcblk1p2
# resize2fs -M /dev/mmcblk1p2
resize2fs 1.44.1 (24-Mar-2018)
Resizing the filesystem on /dev/mmcblk1p2 to 1803781 (4k) blocks.
The filesystem on /dev/mmcblk1p2 is now 1803781 (4k) blocks long.

- set partition /dev/mmcblk1p2 to the desired new size (make sure its equal/larger than the shrank root filesystem, here 1803781*4/1024/1024=6.88GB) and create a further partition for the home filesystem and optionally swap.

That is the original partition layout:

# fdisk /dev/mmcblk1

Device         Boot  Start       End   Sectors   Size Id Type
/dev/mmcblk1p1 *     32768    163839    131072    64M  c W95 FAT32 (LBA)
/dev/mmcblk1p2 *    262144 244277247 244015104 116.4G 83 Linux

And that is my new partition layout. Make sure partition /dev/mmcblk1p2 starts at the original offset.

# fdisk /dev/mmcblk1

Device         Boot     Start       End   Sectors  Size Id Type
/dev/mmcblk1p1 *        32768    163839    131072   64M  c W95 FAT32 (LBA)
/dev/mmcblk1p2         262144  54949887  54687744 26.1G 83 Linux
/dev/mmcblk1p3       54949888 227097877 172147990 82.1G 83 Linux
/dev/mmcblk1p4      227097878 244277247  17179370  8.2G 82 Linux swap / Solaris

- expand the root filesystem to fill the whole partition

# resize2fs /dev/mmcblk1p2 
resize2fs 1.44.1 (24-Mar-2018)
Resizing the filesystem on /dev/mmcblk1p2 to 7340032 (4k) blocks.
The filesystem on /dev/mmcblk1p2 is now 7340032 (4k) blocks long.

o encrypt the home partition

# apt install cryptsetup-bin

# cryptsetup -h sha256 -c aes-xts-plain64 -s 512 luksFormat /dev/mmcblk1p3

# cryptsetup luksOpen /dev/mmcblk1p3 homecrypt

o create a new home filesystem

# mkfs.ext4 -m 0 /dev/mapper/homecrypt

o move files from the unencrypted /home directory to the encrypted /home filesystem

# mkdir /mnt/root; mount /dev/mmcblk1p2 /mnt/root
# mkdir /mnt/home; mount /dev/mapper/homecrypt /mnt/home
# rsync -avzH /mnt/root/home/ /mnt/home
# rm -rf /mnt/root/home/

o make systemd services aware of new partitions by adding these lines

/mnt/root/etc/crypttab:
homecrypt    /dev/mmcblk1p3    none    luks,timeout=60

/mnt/root/etc/fstab:
/dev/mapper/homecrypt /home ext4 nodev,nosuid,noatime 0 2

If you created a swap parition, then set up the swap area

# mkswap /dev/dev/mmcblk1p4
and replace in /mnt/root/etc/fstab:
swapfile swap swap defaults 0 0

with

/dev/mmcblk1p4        none  swap sw                   0 0

and delete the swap file

# rm /mnt/root/swapfile

o clean up

# umount /mnt/root
# umount /mnt/home
# cryptsetup luksClose homecrypt

Reboot into the eMMC flash. During boot, you are asked to enter the filesystem encryption password. There is a configurable timeout of 60 seconds after which booting continues without having mounted the home filesystem.

FIXME: encrypt the swap partition with an always random passphrase. I will do this once I have properly set up suspend to disk.

FIXME: move root's $HOME directory from /root into the encrypted partition /home. Besides moving over the contents from /root to /home/root, that is probably just a change in /etc/passwd.

FIXME: consider having /tmp as a tmpfs memory filesystem so that its contents do not survive shutdowns.

Note: the major drawback is that /etc and /var/log can not be encrypted without an initrd.

Update: In the meantime, I was pointed towards ecryptfs. It can encrypt directories and, as such, does not need any repartitioning.

Caveat: MrFixIT's update script mrfixit_update.sh takes the liberty to overwrite custom kernels and extlinux.confs. With a custom kernel, it is adviced to not call this script but manually merge its changes.

o Tips and Tricks

o Keep Debian up to date with

# apt-get update && apt-get dist-upgrade && apt-get autoremove --purge && apt-get clean

o Purge Space: Debian packages in /var/cache/apt/archives/ can be savely deleted via apt-get clean. They accumulated on my system to 1GB.

o Startup: Disable unnecessary startup services by linking them from /etc/systemd/system/ to /dev/null.

o Logging Noise: upowerd logs every minute or two a warning message into /var/log/messages and the systemd journal. Here is my kernel patch to add a sysfs attribute required by upowerd pinebookpro-battery001.patch. The wifi driver logs every two minutes some debug messages, as well. Here is my kernel patch to change the log level to KERN_DEBUG pinebookpro-wlanloglevel001.patch.

o Splash Screen: The splash screen can be disabled by removing from /boot/extlinux/extlinux.conf the tokens "quiet" and "console=ttyS2,1500000n8" and then disabling the systemd service _splash via

# ln -s /dev/null  /etc/systemd/system/_splash.service

o Chromium: Do not let chromium ask for a keyring password on start by using command-line option --password-store=basic. Perhaps add this option to Mate's quicklaunch icon for chromium (right-click -> properties -> command).

o Chromium: Mate's quicklaunch icon for chromium has weird command-line arguments for compatibility with Netflix and Amazon Prime Video (see right-click -> properties -> command) making the settings dialog crash. To edit chromium's settings, start chromium from the command line without any options - at least not with the used by the quicklaunch icon.


Contact

You are welcome to PM me corrections on the Pine64 forum. My user id is 11475.