|Pinebook Pro Review||navigate:back|
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.
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 <email@example.com>
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 firstname.lastname@example.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.
I received the coupon code exactly 12 hours later. Folks in the second batch received their coupon code four weeks later.
From: PINE64 - Pinebook <email@example.com>
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 firstname.lastname@example.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.
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|
|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|
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 [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). 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.
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?
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 vs 14m16s on my 4 core 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.
We have it that the Pinebook Pro is half as fast 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 1/3 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
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.
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. What I miss so far is Waterfox. 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.
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
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.
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.
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, 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.
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.
# 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).
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)
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
Typically after an uptime of multiple hours, the power supply does not provide power for short periods of time even when the system is idle. This can be measured with a kill-a-watt or observed by the power LED being off for several seconds every now and then.
I do not know why the battery takes almost completely over when the system is under load nor do I understand why the battery takes over for short periods of time when the system is mostly idle. 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 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]
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.4 kernel, e.g. Manjaro and Debian 10.
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).
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.
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.
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.
The screen is a 14" matte 1080p display without any dead pixels. There is light bleed around the corners only visible on a 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 $[FIXME].
o Video Playback
On the preinstalled Debian operating system, 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
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].
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.
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.
I often record dry runs of presentations and store them with the slides. The microphone is [FIXME].
Suspend to disk and memory have hiccups [FIXME: elaborate].
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/mmcblk1p4and replace in /mnt/root/etc/fstab:
swapfile swap swap defaults 0 0
/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.
Update: In the meantime, I was pointed towards ecryptfs. It can encrypt directories and, as such, does not need any re-partitioning. It has some minor drawbacks over Luks, though.
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 be sufficient for some users. For me it is a tinkerer laptop and 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 46% faster translating into shorter build times and a snappier web browsing experience.
What concerns me a lot is the battery and that it is used when connected to main power. These permanent discharge/charge cycles 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/charge while on main power and audio whine. That raises two questions. How were prototypes tested? The first batch was sent out more than 5 months ago. 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.
A quick update: Pine64 is now selling spare batteries for $19.95 + $11.99 shipping. The batteries are shipped to US addresses, only. Stay tuned for a major long term review update on July 1.
You are welcome to PM me corrections on the pine64 forum. My user id is 11475.