Pinebook Pro Reviewnavigate:backcounter

Overview

Pine64, or more precisely Pine Store Ltd. (formerly 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 cost with no 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 quite late in the kernel and the earliest signs of life from uboot and kernel 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. 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
Thursday, October 31, 2019 Location Time
10 Clearance processing complete at LOS ANGELES GATEWAY - USA LOS ANGELES GATEWAY, CA - USA 15:53
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 loadable closed source firmware. One chip or another probably includes non-loadable firmware - possible candidates are the camera and the display port. 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
[Unused?]           offset    0.5kb   size  31.5kb
IDBLoader           offset     32kb   size   160kb
[Unused?]           offset    192kb   size  8000kb
U-boot              offset   8192kb   size  4096kb
Trusted Firmware    offset  12288kb   size  4096kb
Boot Partition      offset  16384kb   size 65536kb
[Unused?]           offset  81920kb   size 49152kb
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 160 kb from the eMMC flash starting at address 32 kb 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 4 MB from the eMMC flash starting at address 8192 kb 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) [uboot log]. 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 during the first month of owning the laptop in November 2019. Pine64 has already experience building laptops and uses the Pinebook Pro's SOC in some of their single board computers. What can go wrong?

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 benchmarks:

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. The same task takes on my 4 core Lenovo G510 from 2014 mere 14m16s.

o LaTeX and PDF tools (single core performance of the big core and ssd i/o): compiling my PhD thesis takes 27.743s. The same task takes on my Lenovo G510 from 2014 mere 11.856s.

We have it that the Pinebook Pro is 57.3% slower on a per core basis than an average 5 year old laptop. The Pinebook Pro has more cores than a typical laptop form this era making it overall 31.5% slower.

# 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

The kernel can overclock the CPU by overwriting the operation points in arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi. Below snippet in arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts would overclock the big cores to full 2 GHz.

&cluster1_opp {
	opp08 {
		opp-hz = /bits/ 64 <2000000000>;
		opp-microvolt = <1300000>;
	};
};

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 Preinstalled 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.

When it 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, some chromium and firefox and these 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.

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.

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.

o Default 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 kept 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. I also compiled a few programs which are not available in Debian; you may recognize the one running in the 4th virtual desktop. Mate sets the window border to 1 pixel thereby making it hard to grab. It appears that Mate does not like custom xmodmaps, either.

Pinebook Pro Default Desktop Mate

o Applications

Most open-source projects do not provide armhf packages and if the application is not packaged by Debian then it needs to be compiled from scratch. When it comes to Debian's package repository, I did not notice any packages not being available for armhf except gcc-aarch64-linux-gnu.

Mathematica for Raspberry Pi checks GPU specifics and refuses to activate on the Pinebook Pro. The license prohibits this, anyway.

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 [repro]. They are doing a great job. Their kernel is rock stable without any crashes and even wifi does not shut down under load. After briefly running Manjaro from micro SD card, I run now vanilla Debian 10 with Manjaro's kernel from eMMC. This setup can be conveniently installed with Daniel Thompson's Debian installer. The new kernel's device tree slightly changes the CPU clock frequencies.

$ cat /sys/devices/system/cpu/cpu?/cpufreq/cpuinfo_max_freq | tr "\n" "\t"
1416000      1416000      1416000      1416000      2000000      2000000

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.

I gain the impression that opening and closing the laptop puts some stress on the hinges. To be on the save side, I carefully open and close the laptop.

o Cooling and Noise

The Pinebook Pro is passively cooled. As there are no fans, the laptop is completely quiet. Under high cpu load, feel-able 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. This patch made it into mainline kernel 5.6 [commit].

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 peripherals draw more than 500mA or even 900mA and so not all USB 2 or 3 peripherals can be actually used with the Pinebook Pro. My external Seagate Expansion+ 2TB drive works like a charm on the USB 3 port.

o Memory

The Pinebook Pro comes with 4GB of soldered LPDDR4 memory clocked at 800Mhz. The memory bandwidth seems to be around 9 GB/sec.

# sysbench --test=memory --memory-block-size=1M --memory-total-size=100G --num-threads=1 run
9118.26 MiB/sec

On every new computer, I run memtest86 for a couple of hours. There is no bootable memtest86 image for the Pinebook Pro, let alone for ARM devices in general. At least, there is the userspace program memtester.

# memtester 3500 1
memtester version 4.3.0 (32-bit)
Copyright (C) 2001-2012 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 3500MB (3670016000 bytes)
got  3500MB (3670016000 bytes), trying mlock ...locked.

Loop 1/1:
  Stuck Address       : ok         
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
  Solid Bits          : ok         
  Block Sequential    : ok         
  Checkerboard        : ok         
  Bit Spread          : ok         
  Bit Flip            : ok         
  Walking Ones        : ok         
  Walking Zeroes      : ok         
  8-bit Writes        : ok
  16-bit Writes       : ok

Done.

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.

The pre-installed Debian operating system has the /tmp directory on the eMMC flash. I mounted in as tmpfs to have writes into this directory go not onto the eMMC flash but into memory. Some programs, like compilers, create there a lot of temporary files. My measurements show that compiling a modern kernel writes 2GB onto the filesystem of which 1.5GB go into the source code directory /usr/src/linux while 0.5GB go into the /tmp directory.

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.

# 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 supply up to 3.0A making it able to provide 15.0W. Measurements with a kill-a-watt [wikipedia] show peaks of up to 15.9W probably due to measure error. The charger cable is quite short barely reaching power outlets. Alternatively, the Pinebook Pro can be charged over USB-C with 13W.

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 pity that not both have been shipped (think of international travel).

o Battery

As storage is flash and the SOC embeds 4 low energy cores, battery time for typical use-cases is phenomenal with around 8 hours [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.

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

o Power Measurements

Below measurements have been conducted with a kill-a-watt [wikipedia] on two Pinebook Pros to rule out defective models.

Base system power consumption is 8.8W (with display off: 4.6W). Base system + mp3 streaming power consumption is 9.2W (with display off: 4.9W). Power consumption over the number of cpus (kernel builds with make -jX):

External power supply

1: 11.1W (with display off: 06.9W)
2: 13.7W (with display off: 08.9W)
3: 14.5W (with display off: 09.8W)
4: 15.0W (with display off: 10.2W)
5: 15.5W (with display off: 10.7W)
6: 15.9W (with display off: 10.9W)

USB-C

1: 11.1W (with display off: 06.5W)
2: 12.8W (with display off: 08.8W)
3: 13.0W (with display off: 09.6W)
4: 13.0W (with display off: 10.2W)
5: 13.0W (with display off: 10.4W)
6: 13.0W (with display off: 10.8W)

When the system is under load for a longer period of time, the power consumption is initially close to 16.0W (13.0W) but eventually starts to alternate among 0 and 2W. At the same time, the power LED is flickering. Not only parallel builds (make -j6) cause this behavior, but every other workload that stresses multiple cpus for longer periods of time such as software rendering of HD Youtube videos.

From where do the required 15.9W (13.0W) come to power the laptop? They can only come from the battery. The battery sensor does not detect a current flow, though. Half an hour later, the battery sensor will notice a sudden drop of 9% in capacity. The battery sensor data can not be right. I expect the capacity to gradually decline to 91% while main power or USB-C provide 0 to 2W.

$ 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

I do not know why the battery takes almost completely over when the system is under load. Pine64 did neither confirm nor deny this bug and whether they will provide a workaround for the current Pinebook Pro boards or revise the board for further Pinebook Pro batches.

[FIXME: put a fan on the SOC and redo above measurements.]

Contrast this with my 5 year old mid-range laptop Lenovo G510. Its power supply can provide up to 65 Watt providing more than sufficient buffer for even the highest CPU loads. This laptop requires 16W when idle and 26W when builds are running on all 4 cores and 8 threads.

A final word about battery charging: when the laptop is turned off, USB-C provides 13.0W to the the battery while the external power supply provides 15.0W to the battery. As far as I can tell, both seem to provide on a running system around 2.0W to the battery and the rest to the operation of the system [FIXME: verify / double check].

o Power Management (Suspend to Memory; Hibernation to eMMC)

Suspend to memory and hibernation have hiccups on the preinstalled Debian. Update June 2020: success depends on uboot and the kernel. Below observations where made in June 2020 with the then latest versions ie., MrFixIT's uboot 2.0 and Linux kernel 5.7 (w/ Manjaro).

Suspend to memory works to some degree on closing the lid as well as with systemctl suspend. These are the caveats:

Although my kill-a-watt measures 0.0W, I believe the power consumption during suspend to memory is around 0.1W. Over 14 hours on battery, the battery charge dropped by 4% and so the power consumption should be 10,000mAh * 4.344V * 4% / 14h = 0.1W (why does the battery sensor show not 5.00V but 4.344V?). The power during suspend to memory can be delivered either by battery or charger.

Hibernation [TODO]. [FIXME: how useful is it having 4GB written onto and read back from the eMMC drive?]

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 Wifi

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].

o Bluetooth

I fail pairing my Bose QC35 headset. Update December 2019: Pairing my Bose QC35 works out of the box on all operating systems which use the 5.x kernel, e.g. Manjaro and Debian 10.

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 cumbersomly 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). This key is often set up to be used together with the TAB and cursor keys to navigate virtual screen. Update January 2020: Jack Humbert revised the firmware to fully support the Pine key [link].

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

Update: It was noticed that the precision of the trackpad can be improved by installing the package xf86-input-synaptics and adding in /etc/X11/xorg.conf.d/10-synaptics.conf Option "MinSpeed" "0.25" to the InputClass section.

When stopping to move the finger on the trackpad, the mouse pointer keeps on moving a few more pixels making it difficult to precisely position it on the screen. The trackpad can be only used to interact with large GUI elements. It is difficult to resize windows or copy-paste text.

o Screen

The screen is a 14" matte 1080p display without any dead pixels. There is light bleed around the corners only visible on a backlit black screen.

I purchased a cheap USB-C to HDMI converter and a HDMI cable to connect the Pinebook Pro to an external monitor (first I tried several USB-C multiport adapters, but none of them worked on the Pinebook Pro). These additional expenses came to around $10 [FIXME be precise].

o Video Playback

On the preinstalled Debian operating system, Chromium can flawlessly render fullscreen 720p HD Youtube videos in software. 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

Also on the preinstalled Debian operating system, smplayer can 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 preinstalled 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 -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.

The speakers are wirered in reverse polarity. This can be fixed in software. Alsamixer has a control element which can be set to either "R invert" or "L invert".

Playing audio comes with a whine. The whine is hear-able when audio is muted, but otherwise barely noticeable. Ignorance is bliss - I'm conscious of the whine only since I learned about it after three weeks of owning the laptop. Pine64 did neither confirm nor deny this bug and whether they will provide a workaround for the current Pinebook Pro boards or revise the board for further Pinebook Pro batches.

o Microphone

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

Tuning the preinstalled 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/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 .configs for 4.4.196 , 4.4.202, 4.4.207 and 4.4.210.

# 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

o optional: add custom configurations. Mine were prior to kernel 4.4.210

# scripts/config --module DM_CRYPT

o optional: add custom patches. Mine are

# wget http://students.engr.scu.edu/~sschaeck/misc/pinebookpro-battery001.patch -O - | git am
# wget http://students.engr.scu.edu/~sschaeck/misc/pinebookpro-thermal001.patch -O - | git am
# wget http://students.engr.scu.edu/~sschaeck/misc/pinebookpro-wlanloglevel001.patch -O - | git am

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 back up the old, known working kernel and device tree to /boot/Image.bak and /boot/rk3399-pinebookpro.dtb. Note, /boot partition is quite small and can only hold two kernels and device trees.

Caveat: MrFixIT's update script mrfixit_update.sh takes the liberty of overwriting 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).

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. I would have prefered encrypting the full disk. There are two obstacles, though. 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). Then the files from the unencrypted filesystem need to make it onto the encrypted filesystem. After some back and forth I decided that it is not worth the trouble and went with encrypting a home partition, only. I chose Luks as I'm most familiar with it. Furthermore, I believe it is the unofficial Linux filesystem encryption standard, as well.

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 have config DM_CRYPT enabled (either built-in or as a module) and the splash screen needs to be disabled as it would hide the password dialog. Since version 4.4.210, DM_CRYPT is enabled by default and no custom kernel is necessary. How to compile a custom 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 partition, 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.

o benchmark without Luks encryption (higher numbers are better)

$ iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

                                                     random   random
    kB  reclen    write  rewrite     read   reread     read    write
102400       4    19575    23219    38260    37039    17624    21826
102400      16    48620    54164    80951    80601    51517    53691
102400     512   134109   136394   143356   145886   138322   133269
102400    1024   140073   142265   151081   154500   149966   140567
102400   16384   149243   149481   164059   164833   166578   149527

o benchmark with Luks encryption (higher numbers are better) [FIXME: How do cryptsetup parameters affect performance?]

$ iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

                                                     random   random
    kB  reclen    write  rewrite     read   reread     read    write
102400       4    12093    16643    25284    25178    13278    15475
102400      16    30080    36604    54044    54185    35683    37089
102400     512    71444    79895    87401    89422    83718    77523
102400    1024    75155    80885    93576    87711    85691    77740
102400   16384   120308   126740   165129   166420   165218   131477

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.

Caveat: MrFixIT's update script mrfixit_update.sh takes the liberty of overwriting 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. This patch made it into Manjaro's Pinebook Pro 5.4 kernel [commit] and eventually into mainline kernel 5.7. 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 ones used by the quicklaunch icon.

o Further Distributions: with the release of the Pinebook Pro not only the preinstalled Debian was available, but also Ubuntu, Chromium OS and Android 7.1. Over time more and more distributions will become available. Trying them out is fun and as they can be conveniently booted from micro SD cards. They all require at bare minimum a 8 GB micro SD card. Larger micro SD cards are not necessary as the home directory on the eMMC can be mounted (either automatically in /etc/fstab or manually later on) and re-used.


Long Term Review 1 from March 1. 2020 after owning the Pinebook Pro for 4 months.

Althought the "Pro" in the product name is misleading, the Pinebook Pro may in deed be sufficient for some users. For me it is a tinkerer and spare laptop but not a daily driver.

The Pinebook Pro is an open laptop but also a black box at the same time. It is not possible to debug early boot problems without a serial console cable. Initially, I contributed a few kernel patches but soon lost interest in helping with the development of the Pinebook Pro.

With all the kernel crashes in the preinstalled Debian operating system, I moved to Manjaro on micro SD card in late November and to vanilla Debian 10 on eMMC in late December. I still have Manjaro on the micro SD card and keep booting it from time to time.

What I did not write about are all the small things that do not work out of the box. Finding workarounds consumes a lot of time and energy. That is one of the reasons why the Pinebook Pro is a tinkerer laptop, only.

The CPU is fast enough for surfing the web and doing light development work but my close to 6 year old mid-range laptop Lenovo G510 is 45.9% faster translating into shorter build times and a snappier web browsing experience.

What concerns me is the battery and that it is used under load when connected to main power. This can not be good for the battery and there are not even replacement batteries available.

The audio whine is annoying and a 14" screen is too small to look at all day long. Both annoyances could be worked around by connecting a modern hdmi monitor on the USB-C port (if there were not these small things that do not work out of the box).

The Pinebook Pro has at least two hardware defects - battery discharge under load and audio whine. That raises two questions. How were prototypes tested? The first batch was sent out more than 5 months ago and prototypes have been used by selected developers for more than 1 year. Why are these defects not addressed and fixed in recent batches?


Long Term Review 2 from July 1. 2020 after owning the Pinebook Pro for 8 months.

Most of the observations from my previous long term review still hold true.

Last year, I was using the Pinebook Pro as a build machine. This year, the Pinebook Pro is placed next to our bed and used in the evenings for listening to internet radio and surfing the web.

As mentioned in the initial review, the battery was taking over when stressing the system. Nowadays, the battery starts to take over almost immediately and randomly charges and discharges between 90% to 100%. I do not have enough data-points to pin-point the root-cause (kernel 5.x + new device tree tweaks? age?). Such trickle charging damages the battery and reduces its lifespan. This trickle charging can be measured with a kill-a-watt, retrieved from the battery sensor or observed on the power LED changing between on and off.

Below graph displays the battery capacity over 25 hours while on main power. The long horizontal bar is the battery recovering over night. Either side of the graph were taken while surfing the web - neither videos have been played nor were other power-hungry tasks ran. The battery should never take over while on main power, in particular not under light work-loads such as web surfing.

Charge/Discharge Curve

Data was collected with

$ while true; do cat /sys/class/power_supply/cw2015-battery/capacity >> charge; sleep 30;

... and visualized with

$ gnuplot -e "set term pngcairo size 1024,120 enhanced font 'Verdana,10'; plot [0:][90:101.9] 'charge' using 0:1" | convert - -transparent white charge.png

I had now my first crash in the 5.x kernel. It started with below oops in mm/page_alloc.c eventually making the kernel so unstable that I had to power-cycle the machine. Ok, technically, it was not a crash.

Jun 18 18:48:13 manjaro kernel: Unable to handle kernel paging request at virtual address fffffe00031c5cf3
Jun 18 18:48:15 manjaro kernel: Mem abort info:
Jun 18 18:48:16 manjaro kernel:   ESR = 0x96000021
Jun 18 18:48:16 manjaro kernel:   EC = 0x25: DABT (current EL), IL = 32 bits
Jun 18 18:48:16 manjaro kernel:   SET = 0, FnV = 0
Jun 18 18:48:16 manjaro kernel:   EA = 0, S1PTW = 0
Jun 18 18:48:16 manjaro kernel: Data abort info:
Jun 18 18:48:17 manjaro kernel:   ISV = 0, ISS = 0x00000021
Jun 18 18:48:17 manjaro kernel:   CM = 0, WnR = 0
Jun 18 18:48:17 manjaro kernel: swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000001596000
Jun 18 18:48:17 manjaro kernel: [fffffe00031c5cf3] pgd=00000000f303f003, pud=00000000f303e003, pmd=00600000f2200711
Jun 18 18:48:17 manjaro kernel: Internal error: Oops: 96000021 [#1] SMP
Jun 18 18:48:17 manjaro kernel: Modules linked in: snd_soc_simple_card snd_soc_simple_card_utils snd_soc_rockchip_i2s [..]
Jun 18 18:48:17 manjaro kernel: CPU: 0 PID: 493665 Comm: kworker/0:0 Tainted: G        WC        5.7.0-1-MANJARO-ARM #1
Jun 18 18:48:17 manjaro kernel: Hardware name: Pine64 Pinebook Pro (DT)
Jun 18 18:48:17 manjaro kernel: Workqueue: events free_work
Jun 18 18:48:17 manjaro kernel: pstate: 80000005 (Nzcv daif -PAN -UAO)
Jun 18 18:48:17 manjaro kernel: pc : is_free_buddy_page+0x234/0x3fc
Jun 18 18:48:17 manjaro kernel: lr : __vunmap+0x180/0x270
Jun 18 18:48:17 manjaro kernel: sp : ffff80001d8f3d40
Jun 18 18:48:17 manjaro kernel: x29: ffff80001d8f3d40 x28: 0000000000000000 
Jun 18 18:48:17 manjaro kernel: x27: ffff000098a14100 x26: ffff8000114efe40 
Jun 18 18:48:17 manjaro kernel: x25: 0000000000000000 x24: ffff0000eef498b8 
Jun 18 18:48:17 manjaro kernel: x23: 0000000000000001 x22: 0000000000000000 
Jun 18 18:48:17 manjaro kernel: x21: 0000000000000000 x20: 0000000000000000 
Jun 18 18:48:17 manjaro kernel: x19: ffff0000cf09ae80 x18: 0000000000000000 
Jun 18 18:48:17 manjaro kernel: x17: 0000000000000000 x16: 0000000000000000 
Jun 18 18:48:17 manjaro kernel: x15: 0000001e2eebff68 x14: 00000000000002a5 
Jun 18 18:48:17 manjaro kernel: x13: 0000000000000000 x12: 0000000000000001 
Jun 18 18:48:17 manjaro kernel: x11: 0000000000000000 x10: 00000000000009e0 
Jun 18 18:48:17 manjaro kernel: x9 : ffff000098a1416c x8 : ffff0000b66b9990 
Jun 18 18:48:17 manjaro kernel: x7 : 0000000000000000 x6 : ffff000058d68290 
Jun 18 18:48:17 manjaro kernel: x5 : fffffe00031c5cf3 x4 : ffff0000b66b99b8 
Jun 18 18:48:17 manjaro kernel: x3 : 0000000000000001 x2 : 000000000000001d 
Jun 18 18:48:17 manjaro kernel: x1 : 0000000000000000 x0 : fffffe00031c5cbf 
Jun 18 18:48:17 manjaro kernel: Call trace:
Jun 18 18:48:17 manjaro kernel:  is_free_buddy_page+0x234/0x3fc
Jun 18 18:48:17 manjaro kernel:  free_work+0x40/0x58
Jun 18 18:48:17 manjaro kernel:  process_one_work+0x1d4/0x3a0
Jun 18 18:48:17 manjaro kernel:  worker_thread+0x14c/0x4d0
Jun 18 18:48:17 manjaro kernel:  kthread+0xf4/0x120
Jun 18 18:48:17 manjaro kernel:  ret_from_fork+0x10/0x18
Jun 18 18:48:17 manjaro kernel: Code: 88047ca2 35ffff84 17ffed26 f98000b1 (885f7ca2) 
Jun 18 18:48:17 manjaro kernel: ---[ end trace 2758041433c5af3a ]---

Selectable by a hardware switch, the audio jack can be either used for audio or serial console. A Manjaro developer pointed out a third hardware bug namely crosstalk between the audio and serial line, e.g. when playing audio on high volume characters are sent to the console:

# systemctl stop serial-getty@ttyS2 
# hexdump -C /dev/ttyS2 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 ff 00  |................|
00000010  00 00 00 00 00 00 00 00  80 00 00 00 00 00 01 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 f0 00 00  |................|
00000040  00 00 00 00 00 00 00 00  51 00 00 00 00 00 ff 00  |........Q.......|
00000050  00 00 ff 00 fe 00 00 00  e0 00 00 00 00 00 00 00  |................|
00000060  00 00 01 00 00 00 00 80  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

When not disabled in the kernel, these characters are interpreted by the kernel as MAGIC SYSRQs and bring down the kernel every now and then.

Recent Pinebook Pro batches received minor hardware improvements:

Pine64 is now selling spare batteries for $19.95 + tax. The batteries are shipped for $11.99 to US addresses, only.

Rarely any USB-C multiport adapter works with the Pinebook Pro. Instead of making the Pinebook Pro work with standard USB-C multiport adapters, Pine64 announced making their own USB-C multiport adapter.

Tweaking the device tree and porting Rockchip's 4.4 kernel patches to mainline Linux is complete. Since version 5.7 the Linux kernel is fully supporting the Pinebook Pro. Power management could be better tweaked, though. Manjaro comes with a slightly patched 5.7 kernel and replaces Debian as the pre-installed operating system. This obsoletes my "Tuning the preinstalled Debian Operating System" section.

There is more to a Linux laptop than full kernel support, such as robust hardware or a fully supported graphics stack and that is where the Pinebook Pro still needs to catch up.


Long Term Review 3 from November 1. 2020 after owning the Pinebook Pro for 12 months.

Stay tuned for a third long term review.


Contact

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