Pinebook pro review and notes

Why the PBP?

Lately I’ve been thinking a lot about power consumption when it comes to computing. Intuitively, I know that arm devices pull significantly less power than amd64 machines but I’ve never really tested this in the real world. So, some preliminary power consumption stats:

big amd64 laptops (thinkpad x220 and t490) pull at most 65 watts
small arm SOCs typically pull at most 15 watts
most android phones pull at most 18 watts
Pentium 4 pulls at most 250 watts

These numbers are fairly easy to find: just look at the power supply for a MAXIMUM OUTPUT value or something similar. This is the point at which the power supply fails so we can safely assume this is the maximum power draw for any given computer. Of course, this is DC output and not AC output and anyone who knows anything about electricity knows that converting AC to DC is expensive but these values are useful as a general estimate. I wrote something similar about computer power consumption some time ago

My goal in all of this was to find a self contained computer that runs UNIX, doesn’t take much power, isn’t a consumption rectangle (smartphone), and can be charged from both AC with a rectifier and stored DC without an inverter. Charging from existing stored power was probably the most novel consideration. Everything else is a given.

A few obvious answers come to mind:

Raspberry Pi 4 is not self contained and using a pitop in public is a good way to get the bomb squad called on you
beaglebone black is good too but neither self contained nor popular enough for wide OS support
Pinebook Pro is self contained and is supported by some of the operating systems I’d like to run

The PBP is an obvious choice. It’s an open hardware ARM laptop that can be charged via a barrel cable (AC->DC) or via USB-C. Charging from USB-C is a very useful feature because it means I can easily choose between charging from the mains where efficiency loss is acceptable and charging from a DC source where efficiency loss is unacceptable.

The actual use case is “what computer can I run off of a old car battery or the alternator in my car without burning power with an inverter?”. I’ll revisit this use case in a later section.

Initial notes

I took these notes immediately upon opening the PBP. They remain unedited because I want to be honest on the first impressions.

shipping

I was worried about DHL dropping my package out of a plane. Or leaving it out in the rain. Or having one of the employees use it as a soccer ball. Or having the thing get stuck in customs. It ended up arriving safely and was packaged well. Two boxes within a padded envelope within another envelope. Surprising for DHL.

hardware impressions

Touchpad sucks and trackpad scrolling sucks (it’s probably just KDE). Installing synaptics drivers allegedly fix this problem.
keyboard is comfortable, clickly, full sized despite being a chicklet keyboard. I don’t like that the <ctl> and <fn> keys are backwards when compared to a thinkpad. I really like the thinkpad keyboard layout.
Shift+enter seems to type the M character. My muscle memory for key chording is now broken. This appears to be a fundamental design flaw with KDE.
Passively cooled, gets a bit warm.
display is sharp (IPS) and almost too high resolution for my eyes (1920x1080 instead of 1366x768). I can fix this in software.
enabling/disabling mic/wifi/camera through the keyboard is confusing and (seemingly) does not perform the “kill switch” via hotplugging like the Thinkpad X220’s wifi kill switch.
Charger comes with both US and EU prongs.

software impressions

it’s manjaro :(
it’s KDE :(
it comes with mpv :)
bluez instead of bluetoothd :(
firewalld instead of UFW <3
no vim, no vi, and no ed on the standard installation so this is completely useless and unusable.
firefox config uses google as the default search engine
It didn’t come with RHEL7 or so obviously I hate it
It didn’t come with BSD so obviously I hate it
Terminal color scheme is one of the worst I’ve seen in my life

Secondary notes

From my next available free day, largely unedited:

software

I still don’t like manjaro. I still don’t like pacman.
On the default manjaro installation, the manjaro-arm-flasher tool seems to create bootable SD cards (nice for the insurance policy)
when updating (lots of network IO throughput), the wireless card seems to stutter.
I Can’t boot another OS using the stock firmware. I need to flash the “SPI flash” (fancy ARM guy terminology for nvram) with newer versions of u-boot that are more hacker friendly (ie the ones that don’t require a serial display).

hardware

The emmc is toggable with a DIP switch on the mainboard. My mainboard looks slightly different than the images on the wiki but all of the components are generally in the same location

Technical stuff

upgrading the u-boot on storage devices

It seems that the PBP has three possible locations for the bootloader: nvram, EMMC, and sd card. The boot process is something like:

load bootloader from nvram
query storage device
if the storage device has it’s own bootloader, chainload that
otherwise, use the bootloader from nvram

It’s u-boot soup but upgrading the bootloader on the storage device seems to marginally increase stability.

$ sudo pacman -Syuu
$ sudo pacman -S uboot-pinebookpro
$ sudo dd if=/boot/idbloader.img of=/dev/mmcblk2 seek=64 conv=notrunc,fsync
$ sudo dd if=/boot/u-boot.itb of=/dev/mmcblk2 seek=16384 conv=notrunc,fsync
$ sudo sync
$ sudo reboot

Flashing u-boot externally and buying more stuff

I found some fedora specific instructions that are actually just PBP specific Using the u-boot and idb from fedora, The screen flashes with garbled nonsense when loading a kernel but at least I can see the output from u-boot. Different kernels show different garbled nonsense so it’s a bit of fun. The keyboard does not work in u-boot. The system will now also boot from the SD card (although it seems the system will always boot from EMMC once before allowing booting from the sd card).

Armbian and NetBSD seem to boot just fine from the sd card. I’m keeping a sd card with the stock Manjaro image as an insurance policy.

Because the keyboard does not work in u-boot, I ordered the pine64 serial over 3.5mm audio jack cable so that I can (hopefully) fix this in the future. The system still boots automatically but I’d really like to pass options to my bootloader to do things like enter single user mode, run an fsck at boot time, boot various versions of kernels, etc.

OS Support

I will not use Arch. You cannot force me. You cannot coerce me. You cannot even bribe me. I will use anything other than Arch as long as it’s not ubuntu.

Sadly, BSD is not “super easy” on the PBP like most other SBCs but I’ve never stepped down from a challenge. Even sadder, no Plan 9 ported to PBP either. Running a “distro based on a distro based on a distro based on arch” is the antithesis of my computing philosophy. Luckily enough, there is a big list of operating systems that run on the PBP. Most of these are distros based on distros based on distros. OpenBSD instantly appeals to me but there is no support for graphical TTYs as of yet (installation must be performed over serial) so this is a non-starter. NetBSD also appeals to me but no wifi in 9.x, only in -CURRENT. A wide selection of actually usable software, take your pick.

Official Manjaro images with a variety of DEs also exist for when you lost (or corrupted) your insurance policy SD card.

android boot loops, my experience with booting Manjaro from an SD card

NetBSD

NetBSD seems to work just fine but 9.x doesn’t yet ship the broadcom drivers. These drivers are present in the -CURRENT branch but the issue with -CURRENT is that it’s not entirely stable. Additionally, the bootloader does not come with the system.

u-boot from pkgsrc

aarch64 build of NetBSD

To get around the no wifi issue, a dongle is required. I use an Atheros AR9271 USB->WiFi dongle. To get around no RJ45 port, I use a USB->RJ45 adapter. I have an ASIX ax88772 dongle (UGREEN branded but I’m not sure that matters). Both of these dongles seem to work with every single operating system and hardware configuration I’ve tried them with.

Arm is strange, so we must boot from an SD card (running any OS, in my case NetBSD) in order to burn an image to the internal storage.

From a separate machine, the options passed to dd are important.

$ wget https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.3/evbarm-aarch64/binary/gzimg/arm64.img.gz
$ wget http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/x86_64/.9.0_2022Q2_pkgbuild/All/u-boot-pinebook-pro-2022.01nb1.tgz
$ gunzip ./arm64.img
$ tar xzf ./u-boot-pineboo-pro-2022.01nb1.tgz
$ sudo umount /dev/sdx*
$ sudo dd if=./arm64.img of=/dev/sda status=progress conv=fsync bs=1M
$ sudo sync
$ sudo dd if=./u-boot-pinebook-pro-2022.01nb1/share/u-boot/pinebook-pro/rksd_loader.img of=/dev/sda seek=64 conv=sync status=progress
$ sudo sync
$ sudo eject /dev/sda

And, to install NetBSD to the internal EMMC, the process is similar. NetBSD’s version of dd varies slightly but the options passed are important.

# ftp https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.3/evbarm-aarch64/binary/gzimg/arm64.img.gz
# gunzip ./arm64.img
# dd if=./arm64.img of=/dev/rl0d conv=sync bs=1m
# sync
# PKG_PATH="http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/aarch64/9.3/All/" pkg_add pkgin
# pkgin install u-boot-pinebook-pro
# sudo dd if=/usr/pkg/share/u-boot/pinebook-pro/rksd_loader.img of=/dev/rld0 seek=64 conv=sync
# sync
# reboot

And, some more desktop centric things after booting from EMMC:

# passwd
# echo "postfix=NO" >> /etc/rc.conf
# echo "xdm=NO" >> /etc/rc.conf

Installing pkgin (and some packages):

# PKG_PATH="https://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/aarch64/9.3/All/" pkg_add pkgin
# sed -i'' -e 's/9.0/9.3/g' /usr/pkg/etc/pkgin/repositories.conf
# pkgin install vim git mozilla-rootcerts mozilla-rootcerts-openssl

The rest is NetBSD specific and I’ve avoided getting into it here because it doesn’t have anything to do with the PBP.

Performance

The PBP has 6 cores (2 fast, 4 slow) and 4gb ram. The cpu is fairly slow but entirely usable. On large procedural jobs like software compilation, it’s painful. For concurrent jobs, it’s mostly fine.

Compiler performance

As expected, the PBP is slower when it comes to compilation than a standard amd64 machine. Surprisingly enough, NetBSD was significantly slower than Manjaro. This is likely due to the Linux kernel knowing how to better handle multiple CPUs with varying speeds.

sequential jobs

I used plan9port because it’s a fairly large but portable project. Compilation is largely sequential, invokes many standard shell utilities, and involves extra preprocessor steps to convert 9 C into something a standard UNIX compiler like GCC or Clang can compile.

On a T490 - 8th gen Core i8 (4 cores, 8 threads, 4.8GHz, vPro for maximum thermal output):

real    232.51 (~4 minutes)
user    188.07
sys     65.01

On an X220 - 2nd gen Core i5 (2 cores, 4 threads, 2.6GHz, vPro for maximum thermal output):

real    249.98 (~4 minutes)
user    220.33
sys     65.52

On the PBP (2 2.0GHz cores + 4 1.5GHz cores, no CPU fan for maximum thermal output) (running stock Manjaro image):

real    1355.27 (~22 minutes)
user    1178.47
sys     347.71

On the PBP (2 2.0GHz cores + 4 1.5GHz cores, no CPU fan for maximum thermal output) (running NetBSD):

real    3715.24 (~60 minutes)
user    1946.84
sys     3435.29

concurrent jobs

I used vim because it can be built in parallel without causing any issues.

Same 8th gen Core i8 (make -j7):

real    27.36
user    170.21
sys     11.30

Same 2nd gen Core i5 (make -j7, approaching the exponential decay of marginal returns on concurrent processing):

real    77.07 
user    292.46
sys     10.00

On the PBP (make -j7) (running stock Manjaro image):

real    220.60
user    1145.40
sys     59.90

On the PBP (make -j7) (running NetBSD):

real    319.30
user    1560.87
sys     255.33

Web browser testing

Because the PBP has similar hardware specifications to the adware subsidized craptops sold by google, I thought it would be a good idea to compare web browser performance on these systems as well.

I found a few web browser benchmark tests at browserbench.org. They’re probably snakeoil but running JS tests is a good way to put a number on how performant $browser on $hardware is.

Scores from the JetStream2 test

JetStream 2.1 is a JavaScript and WebAssembly benchmark suite focused on the most advanced web applications. It rewards browsers that start up quickly, execute code quickly, and run smoothly. For more information, read the in-depth analysis. Bigger scores are better.

Thinkpad T490   79.555
Thinkpad X220   39.983
PBP (manjaro)   19.148

I don’t have an chromesumption book to test against, so all I can say is that the PBP is slower than a workhorse amd64 machine when it comes to interpreting javascript.

Conclusion

Did the PBP fulfil it’s needs?

The intended use case was “UNIX machine I can charge from an existing battery or alternator”. This immediately invokes ideas of “why would I even need wifi support?”

Ultimately, I ended up flashing a bad image to the SPI flash chip and I cannot get the system to boot (or even show signs of life). I have attempted to enter maskrom mode to re-flash the SPI but I am unsuccessful. There are a few other things I need to try. I’ll update this if I ever get it functional again.

I did not have the opportunity to test the machine in the exact environment I got it for but it was fun before I bricked it. Again, a place for updates.

Who is the PBP for?

HACKERS!

Obviously, the types of people who are interested in pine64 devices and similar SBCs are already computer owners (if not computer hoarders). It’s unlikely that the PBP will become my (or anyone’s) primary computer but that doesn’t mean that it’s useless. The entire point of arm SBCs is to have fun so why not have fun?

Just don’t flash your SPI if you want it to work as expected.

Some final thoughts on open hardware

Oftentimes, before purchasing freedom centric hardware, I search for a few reviews so that I can set my expectations correctly. Oftentimes these reviews are very epidermal: they’re not even skin deep. These reviewers are consumers producing reviews for a consumer audience, not hackers producing in-depth reviews for hacker audience. These types of reviews are frustrating for me but fundamental flaws seem to shine through the lack of thoroughness.

I think that the general negative reviews on open hardware largely stem from unrealistic expectations. The community seems to over-hype many of these devices out of ignorance, stating that $freedomDevice is the $proprietaryAlternative killer, the end all be all device that will usher in the year of the Linux $deviceCategory. Oftentimes, it seems like the high expectations fall flat when confronted with the reality of open hardware: it’s either way too expensive or way too experimental.

It seems like many of these devices are lacking both developer time and users who are both enthusiastic and knowledgable. Pitfalls of mobile UNIX include bad power management, difficulty hotplugging wireless chipsets, graphical interfaces attempting to cope with the fact that they don’t have a physical keyboard, etc. There is still much work to be done. As for users, it seems that the most enthusiastic users always have the impression that $linuxDevice will have 1:1 feature parity with $proprietaryDevice. Maybe it’s just that the loudest users are heard or that we only want to hear utopian dreams of a free software future.

A prime example of this conflict between expectations and reality: Linux smartphones. It doesn’t help when many linux smartphones over the years were advertised as a viable android competitor rather than anything other than what they actually were: an arm board attached to a touch screen and a modem.

I oftentimes ask myself “what is open source worth?”. How much money are you willing to throw at an idea you like? Surely, money thrown at an idea you like is being used better than money thrown at an idea you don’t like. In many cases, it seems like open hardware devices are more expensive than their proprietary counterparts for a few reasons. The two largest reasons are small batch manufacturing and the fact that open hardware isn’t subsidized by pre-installed adware (in the case of nearly every device that comes pre-loaded with proprietary software).

What is open source worth? A few extra dollars, a few extra hours of configuration, a few extra papercuts, and a clean conscious knowing that I didn’t pay for yet another windows license I will never use and will never get a refund for. Open source is worth investing in because the, albeit slow, improvements to open hardware and software have wider implications than just “buying a laptop with Linux pre installed”.

Future projects

~~something with the raspi~~
NetBSD in depth
“why is my lightbulb running android?” and other Internet-Of-Terror ideas
turning a router into a general purpose computing device (probably MIPS because where else am I going to find a MIPS CPU? Might as well do something novel instead of $arm-project-1209)