The PineNote is the first hybrid notepad computer device combination of notebook, tablet and e-reader using an e-ink panel. It is derived from the Quartz64 model A SBC and powered by a Rockchip RK3566 quad-core ARM Cortex A55 64-bit processor with a MALI G-52 GPU.

Introduction

State of the software

The PineNote is based on the in 2021 released Rockchip RK3566 SoC. The upstreaming status of the SoC functionality can be found on the Quartz64 development documentation page of the Quartz64 single-board computer using the same SoC. In the PineNote development documentation page you’ll find the items specific for the PineNote.

The early adopter’s batch of the PineNote is aimed solely at early adopters - more specifically, the units are solely intended to find their way into the hands of users with extensive Linux experience. If you’re looking to buy a PineNote in the first batch, you must expect to write software for it, not to write notes on it. The software shipping from the factory for the first batch will not be suitable for taking notes, reading e-books, or writing your dissertation. It may not even boot to a graphical environment.

An early version of a GNOME-based Debian image is available for testing, but should not be expected to meet general-user readiness.

Help and support

Still have any questions regarding software, shipping, or ordering after reading the documentation? Please don’t hesitate to contact the community in the bridged community channels for detailed answers or simply to chat with friendly people in the community! See the community page.

Please keep in mind that PINE64 is not like a regular company (see the PINE64 philosophy) and that support resources are limited - the best way to get support quickly is to ask in the community chat. Please only contact the PINE64 support directly if questions couldn’t be solved via the community chat or the documentation.

Getting Started

Important note for buyers after October 2024

What’s inside the PineNote package

Included in the box are:

• PineNote
• Stylus
• USB-C to USB-A cable
• USB-C to Micro-USB cable - specifically for the stylus
• UART Dongle - for UART connectivity
• Foldable cover

Applying the foldable cover

The foldable cover can be applied to the PineNote in these simple steps:

Step 1: Remove the protective plastic from the adhesive strip.

Step 2: The black adhesive strip should now be exposed.

Step 3: Carefully place the PineNote on top of the side with the adhesive strip, ensuring that the corners and edges are properly aligned with the device.

Releases

The following releases are available for the PineNote.

Debian

• A full GNOME-enabled rootfs/disc image is provided under m-weigand/pinenote-debian-recipes/releases. This image can be flashed using rkdeveloptool.

• A Debian-based minimalistic rootfs/disc image can be built using debos using the work from Eugen Răhăian. The GNOME image above is building on this work.

Alpine

See https://github.com/DorianRudolph/pinenotes#alpine

Arch Linux

See https://github.com/DorianRudolph/pinenotes#arch-linux

postmarketOS

See https://wiki.postmarketos.org/wiki/PINE64_PineNote_(pine64-pinenote)

Development

Linux Kernel

• RK3566 EBC Reverse-Engineering for the EBC (eInk Panel) driver.
• PineNote Development/Building Kernel
• BSP Linux SDK version 4.19 for the PineNote and Quartz64 Model A:
  • Direct download from pine64.org (32.67GB, MD5 of the TAR-GZip file 24554419aec29700add97167a3a4c9ed)
  • Mirror by mwfc
  • An unofficial torrent download provided by a community member of the BSP Linux and Android SDKs can be found here (100GB).

Android

Android 11 e-ink SDK for the PineNote and Quartz64 Model A. This is the Android SDK build for 10.3" eink panels on Quartz64 Model A.

Download:

• Direct download from pine64.org (72.88GB, MD5 of the TAR-GZip file 293a550584298de4fb95ceae18103672)
• Mirror by mwfc
• An unofficial torrent download provided by a community member of the BSP Linux and Android SDKs can be found here (100GB).
• Just the boot blobs (<1MB): https://wiki.pine64.org/wiki/File:Rk35-blobs.tar.gz

Notes:

• View Android SDK for RK3566 for more information how to compile an image for the PineNote using this SDK

Development

Sub pages

Mainline development

Status

The following table aims to provide a list of kernel modules required for running the PineNote. It also aims at listing repositories of work in progress. While some overlap with the Quartz64 module list (Development) is expected, only modules relevant to the PineNote hardware should be listed here.

Mainlining notes

Some work happening here: https://gitlab.com/calebccff/linux, the idea is to import the parts of the eink/ebc drivers which are open source and use the downstream u-boot framebuffer driver as a reference to create a basic framebuffer driver.

Currently mainline struggles to boot due to weird issues while probing fixed regulators (?). It also fails to detect eMMC.

Further work is being done here: https://github.com/smaeul/linux/commits/rk356x-ebc-dev. This has a complete device tree, with working eMMC. Pen input also works out of the box. Wi-Fi and BT work with firmware copied from the factory Android image.

How to boot mainline

UART is currently REQUIRED for this to work|We depend on u-boot falling back to console. Once we have a prebuilt u-boot which will use extlinux by default, UART won’t be needed anymore.

You can compile a u-boot that uses extlinux by default by following the instructions here.

Getting to a U-Boot prompt

You can get to a U-Boot prompt by:

1. Holding Ctrl-C while the display panel initializes.
2. Wiping the “boot” partition.

Using sysboot

The extlinux.conf should have the following contents:

timeout 10
default MAINLINE
menu title boot prev kernel

label MAINLINE
  kernel /vmlinuz
  fdt /rk3566-pinenote.dtb
  initrd /initramfs
  append earlycon console=tty0 console=ttyS2,1500000n8 fw_devlink=off PMOS_NO_OUTPUT_REDIRECT

At the U-Boot console, run the following command to boot your mainline kernel:

sysboot ${devtype} ${devnum}:9 any ${scriptaddr} extlinux.conf

Booting with individual commands

Booting with individual commands can be useful when you need to temporarily add some kernel command line arguments. Use these or similar commands at the U-Boot shell:

load mmc 0:b ${kernel_addr_r} boot/Image
load mmc 0:b ${fdt_addr_r} boot/rk3566-pinenote.dtb
setenv bootargs ignore_loglevel root=/dev/mmcblk0p11 rootwait init=/bin/bash
booti ${kernel_addr_r} - ${fdt_addr_r}

Configuration

Firmware for WiFi & Bluetooth and Waveform data

Using Maximilian’s Debian image

If the Android partition (super) and waveform partition (waveform) is left intact the image extracts the WiFi, BT driver and waveform from the partitions on first run.

For instance if you repartitions the userdata partition and installs the image there.

Getting it from the Android install manually

Copy WiFi/BT firmware from Android:

mkdir -p /cache/lib/firmware/brcm
cp /vendor/etc/firmware/fw_bcm43455c0_ag_cy.bin /cache/lib/firmware/brcm/brcmfmac43455-sdio.bin
cp /vendor/etc/firmware/nvram_ap6255_cy.txt /cache/lib/firmware/brcm/brcmfmac43455-sdio.txt
cp /cache/lib/firmware/BCM4345C0.hcd /cache/lib/firmware/brcm/BCM4345C0.hcd

Copy waveform partition (via previously dumped file):

adb root
adb push waveform.img /cache/lib/firmware/waveform.bin

Or via dd within Linux:

dd if=/dev/mmcblk0p3 of=/lib/firmware/waveform.bin bs=1k count=2048

Getting the Wifi and Bluetooth driver blobs from “other” sources

WiFi

The WiFi firmware .bin blob can be obtained by installing the Debian package firmware-brcm80211 (in the non-free section; in Bookworm and later it’s in the non-free-firmware section)

The WiFi brcmfmac43455-sdio.txt file can according to Eugen be sourced from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/brcm/brcmfmac43455-sdio.AW-CM256SM.txt needs a renaming when copying it to /lib/firmware/brcm/brcmfmac43455-sdio.txt). The content of the upstream .txt is different than the Android configuration, but is supposed to work.

As you don’t have WiFi yet you need to get the firmware-brcm80211*.deb and brcmfmac43455-sdio.txt file on the PineNote by other means, for instance using an USB stick

Bluetooth

Once you have WiFi working you can get BCM4345C0.hcd by installing the bluez-firmware:

sudo apt install bluez-firmware

Configuring the E-ink refresh mode

• https://github.com/m-weigand/mw_pinenote_misc/tree/main/rockchip_ebc/patches contains information on how/where to write in /sys to alter the refresh mode
• https://github.com/m-weigand/mw_pinenote_misc/tree/main/gnome_extension contains the gnome extension used in Maximilian image

Touchscreen and Pen In X.org

By default the pen config is flipped 180° (which makes it unusable) and the touchscreen doesn’t work. Placing the following config in /etc/X11/xorg.conf.d/50-touchscreen.conf will fix both problems:

Section "InputClass"
    Identifier "evdev touchscreen"
    MatchProduct "tt21000"
    MatchIsTouchscreen "on"
    Driver        "evdev"
EndSection
Section "InputClass"
    Identifier    "RotateTouch"
    MatchProduct    "w9013"
    Option    "TransformationMatrix" "-1 0 1 0 -1 1 0 0 1"
EndSection

Further information

Notes Written by Some Developers

• https://github.com/m-weigand/mw_pinenote_misc (Not super legible “notes”, but very helpful repo with patches, videos, etc)
  • specifically see this section for helpful install/configure scripts: https://github.com/m-weigand/mw_pinenote_misc/tree/main/rockchip_ebc/patches#compiling.
• https://github.com/0cc4m/pinenote-misc
  • patch for enabling gpu: https://github.com/0cc4m/pinenote-misc/blob/main/mesa-archlinux-arm/mesa/rockchip-ebc.patch
  • prebuilt pkg’s: https://github.com/0cc4m/pinenote-misc/releases
• https://pwarren.id.au/pinenote/build_notes.txt
• https://github.com/DorianRudolph/pinenotes
• https://github.com/tpwrules/nixos-pinenote

Alternative to patching of mesa

Mesa needs to be patched to add the driver entry point. The alternative to this, is the renaming of the ebc driver to an existing mesa driver entry point. A good existing name can be “repaper”. To change the driver name, edit in the kernel tree the following files:

• replace “rockchip-ebc” with “repaper” in the two places in the file: drivers/gpu/drm/rockchip/rockchip_ebc.c
• preventive, replace “repaper” with “repaper-disabled” in the two places in the file: drivers/gpu/drm/tiny/repaper.c

Video of Factory Android OS

PineNote Developer Edition w/Tech Demo Android OS (Video Only)

Informal walkthrough of the factory Android installation on the PineNote Developer Edition, recorded by a community member (Apr 2022). This is useful to look back at the original OS after erasing it from your device, or to get some additional detail before your device arrives.

The video also includes a chapter at the end showing how to enable Android Debug Bridge (“adb”) over USB. Once enabled, keep the device powered and connect a USB cable directly to the PineNote (i. e. no UART breakout) to a computer running adb.

Issues

Resolved issues

The following topics have resolved:

• /documentation/PineNote/Further_information/Closed_Case_UART[PineNote/Hardware Changes/Closed Case UART]
• Could the USB-C port support USB 3.1 5Gbps? Yes and no. The RK3566 only has a host-mode 5Gbps controller, meaning it can only negotiate such a high data rate with a device such as a flash drive. When the RK3566 is acting as a device, it only supports 480Mbps transfer rates. The hardware required to switch between these modes would raise the PineNote’s price unreasonably. Therefore, the USB-C port will remain at USB 2.0 speeds for Host and Device mode.
• Could the USB-C port output DisplayPort? Yes and no. The hardware required to support such a feature would raise the PineNote’s price unreasonably. Therefore, DisplayPort output will not be possible through the USB-C port.
• Where is the microSD card slot? The case design of the PineNote is fixed, making physical changes like adding a microSD card slot would raise the cost unreasonably.
• How will I install software to the PineNote? This is a hardware and software question. If the software on your PineNote is completely broken and cannot boot to a recoverable state, a Hall (magnet) sensor was fitted to the PineTab motherboard as U9009. This sensor is attached to SARADC_VIN0_KEY/RECOVERY on the RK3566. With the device powered off, and screen face down, holding a magnet over U9009 and plugging in a USB-C cable causes the device to boot into “rockusb” flash mode. With proper flashing software and drivers, it should be possible to load a new operating system using rockusb if the system is soft-bricked. Of course, software vendors will need to be more careful with flashing firmware and providing useful “recovery” options on this device due to this process’s relative difficulty to other PINE64 devices.

Unresolved issues

The following concerns have been brought up as open, unanswered topics:

• Does Audio Adapter Accessory Mode work? It appears that the Headphone output of the audio codec was routed to the USB-C audio+USB switch, but it’s unclear whether CC lines are hooked up correctly for detection of such a device. The PineNote hardware team will be testing this functionality soon (as of August 19, 2021). Note that Audio Accessory mode is detectable by reading the I2C registers of the WUSB3801Q. So connecting ASEL to a GPIO would be enough to get this working if it is not working already.
• Why is the Headphone output of the audio codec routed to the speakers? HPL_OUT is routed from the RK817 PMIC and audio codec to U9010 (the USB-C switch) and U6 (the audio amplifier). SPK_OUT is unused. It seems like SPK_OUT should be routed to U6 and HPL_OUT to U9010.
• Nitpick: The cold white charging LED bleeds through the gap between the rear case and the device’s face. It does not bleed onto the screen, but it is jarring in low-light conditions or when the screen is amber. Could be resolved in software by turning off the charge LED when the screen is on.
• Is there any way to indicate when the device is in rockusb mode, such as connecting a certain magic pin to the power LED?
• The modem/4G connector (J6010) has its I2C and UART pins unconnected. Could those be connected to the SoC?

Building Kernel

This page contains information on how to build a linux kernel for the PineNote.

Available Kernel Repositories

The following (incomplete?) PineNote-specific kernel repositories are available:

• https://github.com/m-weigand/linux/ (based mainly on the repository from smaeul, with additional patches pulled in from other sources, Debian packages available)
• https://gitlab.com/pgwipeout/linux-next/
• https://github.com/smaeul/linux/tree/rk35/pinenote-next

Building the kernel

After following Dorian’s directions to get Arch installed you’ve seen someone playing DOOM and you want to learn how to get the features that enable that kind of performance. To get your PN running this smoothly, we’ll need to build our own kernel. There are two kernel efforts underway right now:

1. pgwipeout: https://gitlab.com/pgwipeout/linux-next
2. smaeul: https://github.com/smaeul/linux/tree/rk35/pinenote-next

We’ll be using smaeul’s kernel + some additional patches provided by DorianRudolph, pgwipeout, Maximilian Weigand, occam_razor, and hrdl. Thanks so much to them, and all the other users who have worked on piecing together drivers, twiddling configs, answering questions, and sharing their work in other ways. Brava!

Perhaps the main component of the kernel is the DRM driver. You can read more about the driver by reading Smaeul’s RFC.

A small warning

This guide is completely based off of the scripts provided by Maximilian. We’ll be cloning and running them, but he owns them and he – or others – might change them. It’s smart to have a look at what’s going on, check when this page was last updated vs when his scripts were last updated, etc. Be nimble!

Additionally, as Maximilian warns here, these changes are all experimental and may damage your panel.

What you should have already done

It is assumed you’ve already got an operating system installed on your Pinenote other than the stock Android. Doing this isn’t trivial, but it is well understood - you will be following the footsteps of many others. Dorian Rudolph made a guide for doing this, available here.

Steps to build

1. Clone Maximilian’s scripts:

   $ git clone https://github.com/m-weigand/mw_pinenote_misc.git
   

2. Make a separate directory for patching the kernel. Then run Maximilian’s clone_and_prepare_git.sh. This will clone smaeul’s kernel and a number of patches. Read the script to see which patches it is using. Feel free to open the patches too – it’s helpful to get a slim idea of what’s going on, if only looking at the commit messages in them:

   $ cd ../
   $ sh mw_pinenote_misc/custom_kernel/clone_and_prepare_git.sh
   

3. Compile the kernel:

   $ sh ./mw_pinenote_misc/custom_kernel/compile.sh
   

4. Next we want to perform the work captured in install_to_pn.sh, but the work may vary slightly from person to person. As long as you put them somewhere and configure your extlinux.conf to point at it, things will be okay. Looking at install_to_pn.sh, we can see that there are three pieces to installing the kernel: the kernel image (called Image), the device tree (rk3566-pinenote-v1.2.dtb), and the modules. All of these files have been compiled and placed into the linux/pack folder. The easiest way to send these over is by using scp or rsync - read the script and decide how you would like to get your files in the correct location. You may need to install rsync on your PineNote if it doesn’t already have it.

5. DTB was installed like this: $ scp rk3566-pinenote-v1.2.dtb root@pinenote:/boot/dtbs/rockchip/

6. After installing the DTB as above, the file /boot/extlinux/extlinux.conf may be updated to point to this new file

7. (Perhaps not necessary?) The last step is to generate a new initrd image (see Wikipedia for an explanation about initial ramdisk). This is done on the PineNote itself. Send Maximilian’s installation script over and run it. Then place the generated image (from the last step of the shell script) into your boot partition and update extlinux.conf if needed to point at this new file.

   $ scp initrd/gen_uboot_image.sh root@pinenote:/root # Do this part on local to put script on PN
   $ ssh root@pinenote # Or use UART, the dongle + picocom, and change to root
   $ cd /root
   $ ./gen_uboot_image.sh
   $ mv initrd.img /boot/initrd.img
   $ vim /boot/extlinux/extlinux.conf # Update this to reference this new initrd image
   

8. At this point your kernel is in place!However, there are a few more steps you may need to complete to ensure the display and networking continue to work:

   • For display, you may need to change /lib/firmware/waveform.bin to /lib/firmware/rockchip/ebc.wbf (TODO: is this a difference between PG and smaeul’s kernel or a patch?)
   • For networking, you may need to change /lib/firmware/pinenote.bin to /lib/firmware/pinenote-v1.2.bin

9. This part technically isn’t kernel specific, but we need to install a patched version of Mesa. If you are running an Arch based system, you’re in luck!occam_razor provides prebuilt patched packages (say that 5 times fast) here. Simply extract these files, send them to PN, and install them using the package manager. You can also patch it yourself by looking at Maximilian’s compile_mesa.sh.

1. To ensure the GPU stays on, we need to use Maximilian’s mweigand_eglinfo.service. The Readme.md in that same directory has instructions for how to install this, but basically we need to copy it to /etc/systemd/system/, run sudo systemctl daemon-reload to make sure systemd knows it exists, then execute sudo systemctl enable mweigand_eglinfo.service.

Next steps

Configuring the driver

The driver has several options that can improve performance. These can be read about here. rockchip_ebc.bw_mode=1 rockchip_ebc.default_waveform=1 rockchip_ebc.refresh_threshold=30 rockchip_ebc.auto_refresh=1 may be used to make the image lower quality, but much faster to update. The auto_refresh setting is also essential to clear ghosting which will otherwise accrue on screen. The APPEND line in the extlinux.conf might be added to make sure they are applied on boot.

Fixing suspend

If you’re using a logind system, edit your /etc/systemd/logind.conf config. More information on what to do in Arch’s documentation.

Configuring your apps

See Apps.

Booting Linux instead of Android

PineNote Development/Booting Linux

Fixing Bluetooth

See PineNote Development/Software Tweaks

Flashing

This page contains information on flashing software to the PineNote.

The general process is as follows:

1. Take a backup of all important data on the PineNote
2. Modify the partition layout to make space for your desired Linux distribution
3. Instantiate a root filesystem (rootfs) in the new partition space
4. Install your Linux distribution to the boot partition
5. Modify the boot process to boot the Linux distribution by default

There are multiple possible methods of executing these steps, and this page attempts to document all of them.

You can use:

1. rkdeveloptool, a command line utility for modifying Rockchip devices over USB
2. The UART shell
3. Android Debug Bridge
4. Fastboot

Getting rkdeveloptool

Most flashing operations on the PineNote are done through rkdeveloptool, a command line utility built on libusb. PINE64 maintains its own fork here that you will need to get. The repo’s README contains a list of dependencies (libusb 1.0) and instructions for building the tool.

Installing (not just building) rkdeveloptool will configure PAM to elevate privileges where necessary on your system; you can configure this manually as follows:

sudo cp 99-rk-rockusb.rules /etc/udev/rules.d/
sudo udevadm control --reload

Entering Maskrom/Rockusb mode

Interfacing with the PineNote over USB using rkdeveloptool requires first booting the PineNote into an alternative operating mode called Maskrom or Rockusb mode.

Possible methods

There are three possible methods of entering Maskrom/Rockusb mode:

Hardware magnet switch

1. Connect the PineNote to your computer via USB and boot the PineNote into Android
2. Locate & identify the small circular marking on the back of the PineNote, in the top right quadrant; have the PineNote pen close at hand, or any other small magnet
3. Hold the PineNote power button to bring up the reboot/shutdown menu; select reboot, then place the PineNote face down with the “eraser” end of the pen (or your magnet) resting on the small circular marking

U-Boot terminal

This method requires a UART dongle with passthrough allowing simultaneous UART & USB connections.

It is nice because you can easily switch back & forth between U-Boot and Rockusb without having to physically manipulate the PineNote or its connectors; this is especially helpful when trying to develop U-Boot.

1. Connect to the PineNote via UART and USB simultaneously
2. Interrupt the U-Boot startup using ctrl+c sent over UART
3. In the U-Boot terminal over UART, run rockusb 0 mmc 0

The UART terminal should print RKUSB then a spinner will appear. You can exit back to the U-Boot terminal by sending ctrl+c again.

Shorting test points

If the bootloader is broken/corrupted, you cannot get to Maskrom without opening up the device (it can be opened using spudger and a bit of patience).

Once inside, short TP1301 (GND) and TP1302 (eMMC_D0/FLASH_D0) with a small tweezers, this is how it looks on board view (credit to Caleb):

Success

No matter what approach you take, you can tell whether you succeeded by running the lsusb command on your computer:

• If you find the entry 2207:0018 Fuzhou Rockchip Electronics Company rk3566_eink in the list, the process did not succeed; reboot and retry
• The entry 2207:350a Fuzhou Rockchip Electronics Company will occur if you detach then reattach the USB-C cable while the PineNote is in Maskrom/Rockusb mode; rkdeveloptool won’t work and you will have to do a hard reboot (hold down power button for 30 seconds to shutdown)
• If you find the entry 2207:350a Fuzhou Rockchip Electronics Company USB download gadget then the process succeeded

You can also look at the output of the rkdeveloptool list command:

• If this prints out No devices in rockusb mode found the process did not succeed; reboot and retry
• If this prints out DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=305 Maskrom then you probably detached/reattached the USB-C cable while in Maskrom/Rockusb mode and rkdeveloptool won’t work; perform a hard reboot to fix
• If this prints out DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=303 Loader then the process succeeded

Exiting

You can boot the PineNote back into its normal mode of operation by powercycling the PineNote with its hardware power switch, or running the rkdeveloptool reboot command. If you used the magnetic switch method be sure to remove the pen/magnet before rebooting.

Backup

A backup of the content of the internal eMMC before anything gets messed up is mandatory.

Especially the waveform partition contains data unique to your PineNote and is a prime candidate for backup.

Other partitions like U-Boot (need for any operation of the device) or the un-partitioned space at the beginning containing the GPT partition table (and presumably the VCOM setting for the e-ink display and maybe device mac addresses) contain data you may also wish to backup.

Depending of your personal level of data hoarder you may want to backup more than this or even just everything (the large userdata partition is supposed to be able to be repopulated as empty space by Android)

In any case it is easier to restore/extract data from a backup than not having one if you need one.

This process was developed by Dorian Rudolph, originally described here.

List partitions

First, run rkdeveloptool list-partitions to print out your PineNote’s partitions to get an idea of what you’re dealing with. The stock PineNote has a fairly standard Android partition setup:

Patch U-Boot

Before we can back up our partitions, we have a problem to solve. The version of U-Boot installed on the stock PineNote contains a bug where it can’t dump partitions beyond 32 MB (above that limit all bytes in the dump are just 0xCC), meaning the PineNote must be flashed with a fixed version of U-Boot before it is possible to take a backup of the larger partitions. It is possible to extract and modify the U-Boot image from your PineNote if you’re interested in some light reverse-engineering (following Dorian’s notes), or you can simply download a patched U-Boot image directly here.

Once you’ve acquired a patched U-Boot image, run:

1. rkdeveloptool read-partition uboot uboot_backup.img
2. rkdeveloptool write-partition uboot uboot_patched.img
3. rkdeveloptool reboot

Taking the backup

With U-Boot patched, you can back up every partition except for super and userdata; run:

rkdeveloptool read-partition partition_name partition_name_backup.img

Unfortunately the super and userdata partitions run into a second limitation preventing dumping partitions larger than 2 GB, this time originating in rkdeveloptool itself. This means if you have a large number of documents in the Android userdata partition they might not all make it into the backup. If you don’t have many documents (or don’t care about losing them) this should not be a problem. If you do have a lot of documents, workarounds include:

• A possible patch written by Thomas exists here but has not yet been upstreamed; consider investigating how to get the patch tested & upstreamed, or just apply it to your own local copy of rkdeveloptool
• Use this Python script written by Visti Andresen (talpadk) to automatically backup your entire partition by splitting reads into 2 GB chunks

See instructions on this artifact. It will instruct you on extracting the rootfs into an empty ext4 partition. This can be done from Linux or Android. Further instructions on building your own rootfs can be found here.

Using a user installed Linux

A Linux installed to the cache partition should be able to easily backup everything over WiFi or to a USB stick/disk using dd.

However the user would need to backup the cache partition themself (if they want that).

And more importantly they would only be getting the backup after they started playing with the content of the eMMC.

Side-by-side setup

It is possible to set up a partition for mainline development without disturbing the factory Android installation. This allows updating a mainline kernel, DTB, and initramfs over Wi-Fi until WiFi or USB OTG is working in mainline Linux.

Without Repartitioning

The recommended partition for this is mmcblk0p11 aka /cache. It is large and already formatted as ext4, so it is readable from U-Boot. Here are some general steps:

1. From the UART or adb shell, set up your chroot in /cache. I used the Alpine Linux rootfs tarball.
2. Copy in your kernel and DTB, using for example scp or wget inside the chroot.
3. Finally, create and boot an extlinux.conf as described below.

With Repartitioning

It is possible to shrink the userdata partition, and create a new partition at the end for use with mainline Linux. This provides much more space than cache. However, because userdata is formatted with f2fs, and that filesystem cannot be shrunk, resizing the partition requires wiping userdata.

1. Back up any necessary files from userdata
2. Boot to a mainline kernel from mmcblk0p11, either using that partition as rootfs (see above), or using an initramfs with repartitioning tools
3. Modify the partition table with your favorite tool, e.g. fdisk, gdisk, or parted
4. Reboot into fastboot and wipe userdata.
5. Reboot into Android, where you can now chroot in and install your favorite distribution to the new partition.

Using rkdeveloptool

Building Downstream U-Boot

While in maskrom mode, we need to have a u-boot to download onto the device for any of the other commands to work. To build you’ll also need to install device-tree-compiler.

You also need to install Python and pyelftools.

git clone -b quartz64 https://gitlab.com/pgwipeout/u-boot-rockchip.git
git clone -b rkbin https://github.com/JeffyCN/rockchip_mirrors.git rkbin
cd u-boot-rockchip
# If using Arch Linux, export CROSS_COMPILE=aarch64-linux-gnu-
export CROSS_COMPILE=aarch64-none-linux-gnu-
make rk3566-quartz64_defconfig
./make.sh

In the current version (current as of 2022-01-02), there might have to be made a change to one line to get a clean compilation:

diff --git a/lib/avb/libavb/avb_slot_verify.c b/lib/avb/libavb/avb_slot_verify.c
index 123701fc3b..64a1ce6450 100644
--- a/lib/avb/libavb/avb_slot_verify.c
+++ b/lib/avb/libavb/avb_slot_verify.c
@@ -296,7 +296,7 @@ static AvbSlotVerifyResult load_and_verify_hash_partition(
   bool image_preloaded = false;
   uint8_t* digest;
   size_t digest_len;
-  const char* found;
+  const char* found = NULL;
   uint64_t image_size;
   size_t expected_digest_len = 0;
   uint8_t expected_digest_buf[AVB_SHA512_DIGEST_SIZE];

For systems where the global python executable points to python2, compilation fails with an error related to pyelftools not being installed (even if it is). To fix this:

diff --git a/make.sh b/make.sh
index 2bba05b4e4..cfe5b0afd5 100755
--- a/make.sh
+++ b/make.sh
@@ -758,7 +758,7 @@ function pack_fit_image()
        fi
 
        if [ "${ARM64_TRUSTZONE}" == "y" ]; then
-               if ! python -c "import elftools" ; then
+               if ! python3 -c "import elftools" ; then
                        echo "ERROR: No python 'pyelftools', please: pip install pyelftools"
                        exit 1
                fi

You can now download u-boot onto the PineNote:

./rkdeveloptool boot ../u-boot-rockchip/rk356x_spl_loader_v1.08.111.bin

This should output “Downloading bootloader succeeded”.

We can now verify that this worked using e.g. the “read flash info” command:

./rkdeveloptool read-flash-info

Creating a mainline boot image

You can create a filesystem image that replaces the Android boot or recovery partition by doing roughly the following:

1. Erase boot and dtbo with rkdeveloptool or fastboot (back them up first!!!)
2. Create an ext2 partition image and mount it (fallocate, mkfs.ext2)
3. Build your mainline kernel
4. Copy the kernel, dtb and an initramfs to the root of the mounted image (use any old postmarketOS initramfs)
5. Create a file in the root of the mounted image called extlinux.conf as described below
6. Unmount the image and then use rkdeveloptool to flash it to the “recovery” partition on the pinenote (it’s about the right size until we get around to replacing the partition layout).

Using fastboot

Follow the steps for Creating a mainline boot image, but instead of flashing it with rkdeveloptool, use fastboot. You can enter fastboot in either of two ways:

• Use “reboot bootloader” from adb or a UART console or
• get a U-Boot prompt and run fastboot usb 0.

Booting Linux

To boot Linux, the stock U-Boot has to be patched.

Here the method from charasyn is used, based of work from Dorian as credited in the script. We’ll use the script to pull the U-Boot environment out of the stock U-Boot partition. We’ll then apply the patch, recreate the image, add a configuration file, and flash the new image to the PineNote.

Steps to patch U-Boot

• Get the patch and the Python tool:

  $ mkdir pinenote-uboot && cd pinenote-uboot
  $ curl https://gist.githubusercontent.com/charasyn/206b2537534b6679b0961be64cf9c35f/raw/cc513998a36fac0cea266260e3ca3e64abfe3696/boot-menu.patch -o boot-menu.patch
  $ curl https://gist.githubusercontent.com/charasyn/206b2537534b6679b0961be64cf9c35f/raw/cc513998a36fac0cea266260e3ca3e64abfe3696/pinenote-uboot-envtool.py -o pinenote-uboot-envtool.py
  $ chmod o+x pinenote-uboot-envtool.py
  

• Write your U-Boot partition to an image file: dd if=/dev/mmcblk0p1 of=~/uboot.img

• Extract the environment: ./pinenote-uboot-envtool.py extract uboot.img uboot.env

• Poke around the files (or skip this if you don’t like to learn):

• Open uboot.env – see, it’s just text at this point!

• Open boot-menu.patch to get a feel for how that works

• The boot-menu.patch makes assumptions about where your Linux partition lives. Specifically, it will look at partition 0x11 (which is 17 in decimal). Change this in boot-menu.patch to reflect where your Linux boot partition lives.

• Apply boot-menu.patch: patch uboot.env boot-menu.patch

• Rewrite the new environment to the image: ./pinenote-uboot-envtool.py insert uboot.img uboot.env uboot-patched.img
• Write the image to the boot partition from the PineNote: dd if=~/uboot-patched.img of=/dev/mmcblk0p1
• At this point, restarting your system will boot into Android – this is because the patched U-Boot we’ve just created looks for /boot/which_os.txt to determine whether to boot Android or Linux, and since it can’t find this file (we haven’t made it yet), the bootloader defaults to Android. Create that file on the same boot partition you specified in the boot-menu.patch file, placing an l in the file for Linux.
• Reboot into Linux

Sources and further reading

1. U-boot with rockchip docs
2. Helpful stack overflow to learn a bit about the boot process/terminology
3. This conversation in matrix between pgwipeout, vveapon, and pinenewb about flashing U-Boot.

UART

The USB UART dongle delivered with the PineNote allows you to have access to its serial console via USB-C Debug Accessory Mode (DAM) without having to disassemble the device. The factory-installed operating system runs the serial console at the 1,500,000 bps speed, 8 data bits and 1 stop bit, no parity, and no flow control. The USB-C male end should go into the PineNote and the female end can be connected with a standard USB-C cable to your computer.

It is relatively easy to build your own UART interface with a USB-C breakout board (for example https://www.ebay.com/itm/275407037613), two resistors and a 3.3V USB serial adapter. It is basically just two 1K pull up resistors (R3, R4), the data sheet values of 10K isn’t whats on the real hardware, see the schematic. The pull ups enable the serial output on SBU1 and SBU2 you can use with any 3.3V USB serial adapter.

The UART dongle is not necessary to flash the PineNote, but is essential if something goes wrong to fix it without having to open the case.

This page contains information on creating and using a UART dongle for the PineNote. The PineNote was shipped with a compatible UART dongle, but replacements are not available to order in case of loss or hardware fault. Thankfully it is not difficult to make your own from easily-acquired components and a small bit of soldering.

Fear not if you’ve never soldered anything before! This serves as an excellent first soldering project. Borrow the tools from a friend, local hackerspace, or tool library. Pine64 also makes a nice soldering iron themselves, the Pinecil.

A PineNote UART dongle enables you to:

1. Interact with the system boot menu
2. Read system events in real time as the PineNote is used
3. Fix the PineNote without opening the case if something goes wrong while flashing it

Since the PineNote is an embedded system, interfacing with it during boot is more complicated than with an ordinary computer. The UART dongle enables you to do this.

The PineNote factory firmware runs UART at a baud rate of 1500000 bps, 8 data bits, 1 stop bit, no parity and no flow control. The process by which the PineNote design was modified to include closed-case UART is documented here.

Stock dongle

The stock UART dongle included with the PineNote was a simple device plugging directly into the PineNote’s USB-C port. The dongle exposed a female USB-C port, which the user plugged into to get UART access. This design unfortunately ruled out passthrough USB connections, where the user connects to the PineNote via UART and USB simultaneously. The dongle is not currently available for purchase.

Creating a dongle

A typical self-built PineNote UART dongle design has the following components:

1. A USB-C breakout board with a male connector exposing the 24 pins of the PineNote’s USB-C port
2. A USB-UART adapter, to plug into a USB port of the computer you’ll use to interface with the PineNote
3. Jump wires to connect specific breakout board pins to pins on the USB-UART adapter
4. Two 1,000 Ohm through-hole resistors to splice into the jump wires
5. Electrical tape or heat shrink to wrap connectors and prevent shorts

You will also need the following tools:

1. Soldering iron with solder
2. Wire cutters & strippers

The PineNote’s internal UART system is documented in this schematic. The purpose of all 24 USB-C pins is documented on the USB-C Wikipedia page.

We are interested in three sets of pins:

1. The SBU1 (A8) and SBU2 (B8) side band use pins
2. The CC1 (A5) and CC2 (B5) configuration channel pins
3. The GND ground return pins (A1, A12, B1, and B12)

In the PineNote UART schematic you can see (on the bottom right diagram labeled USB_TYPEC_Male) the side band pins are given the labels UART2_TX_SUB1 for A8 and UART2_RX_SUB2 for B8. The first (TX) is used for transmitting data and the second (RX) is used for receiving data, from the perspective of the PineNote. Also note the configuration channel pins labeled TYPEC_CC1 for A5 and TYPEC_CC2 for B5. The diagram shows they must be connected to a 3.3V source in parallel, mediated by resistors. Per the USB-C standard, when these pins are pulled high this indicates the device should enter Debug Accessory Mode; connecting them to a voltage source & limiting the current with pull-up resistors accomplishes this. The schematic indicates 10,000 Ohm resistors, but community member Visti Andresen (talpadk) experimented and found 1,000 Ohm resistors work better. Our mission is to wire up pins from a USB-UART adapter to a USB-C breakout board following these requirements.

Buying components

There are many possible USB-C breakout board designs available for purchase online. One particularly useful design is a “passthrough” or “intercept” style, with both male and female USB-C ports. This design is more versatile in case you want to reuse it in other projects, and also enables you to connect to the PineNote via UART and USB at the same time. An example of this product can be found here, although you are encouraged to shop around for cheaper options. If you’re fine with a bit more soldering, there is a very cheap one here.

Similarly, there are many USB-UART adapter designs available. These devices plug into your computer and expose a number of pins themselves, connecting to specific pins on the breakout board with jump wires. It is important to get a 3.3V model, or at least a model with the option of 3.3V, as a 5V source might fry the PineNote. Here is one example with jump wires included, although you are again encouraged to shop around for alternatives.

All other necessary components of our UART dongle are readily & cheaply available in many locations.

Splicing resistors

This is the only difficult part of the whole process. Your goal is to create a Y-shaped jump wire with 1,000 Ohm through-hole resistors spliced into each of the twin arms. The solitary leg will connect to a 3.3V source on your USB-UART adapter. The twin arms will connect to the configuration channel pins on your USB-C breakout board. Per the USB-C standard, when these pins are pulled high this indicates the device should enter Debug Accessory Mode; connecting them to a voltage source & limiting the current with pull-up resistors accomplishes this.

For this project you’ll need:

1. A soldering iron with solder
2. Wire cutters & strippers
3. 2x jumper wires, male/female as compatible with your board designs
4. 2x 1,000 Ohm through-hole resistors
5. Electrical tape or heat shrink wrap

Consider buying extra jumper wires and resistors in case you mess up. Also double-check that you have 1K resistors with this color code calculator. Although the PineNote UART schematic says to use 10K Ohm resistors, community member Visti Andresen (talpadk) experimented and found 1K is more appropriate.

Assemble your Y-cable as follows:

1. Graft one jump wire onto the other to form a Y shape using this technique, ensuring solitary leg end is compatible with your USB-UART adapter
2. Splice resistors into the twin arms using this technique
3. Splice remaining jump wire onto the ends of the resistors, ensuring ends are compatible with your USB-C breakout board
4. Cover all exposed wire & resistors with electrical tape or heat shrink wrap

Assembly

Once you have acquired all necessary components, assemble the UART dongle as follows:

1. Connect a jump wire from the GND pin on the USB-UART adapter to any one of the four GND pins on the USB-C breakout board (A1, A12, B1, or B12)
2. Connect a jump wire from the RXD pin on the USB-UART adapter to the UART2_TX_SUB1 SBU1 pin on the USB-C breakout board (A8)
3. Connect a jump wire from the TXD pin on the USB-UART adapter to the UART2_RX_SUB2 SBU2 pin on the USB-C breakout board (B8)
4. Connect your Y-shaped jump wire from the 3.3V source pin on the USB-UART adapter to the CC1 and CC2 pins on the USB-C breakout board (A5 and B5)
5. Wrap all metal connectors in electrical tape or heat shrink to prevent accidental shorts

Be very certain of your connections for the 3.3V source and its cable, as there is a real risk of irreparably frying your PineNote if they’re wrong! Especially be sure you are connecting to a 3.3V source and not a 5V source.

Note that if you mix up the TX/RX pins, it will still work but the USB-C breakout board will just plug into the PineNote upside down. You can therefore choose which orientation you want by swapping the TX/RX pin connections. Experience shows that RX/TX-TX/RX connections will have the PineNote face down while connected, while RX/RX-TX/TX connections will put the PineNote face up.

Using the dongle

First, use your UART dongle to physically connect your PineNote to your computer:

1. Plug the USB-UART adapter into one of your computer’s USB ports
2. Plug the USB-C breakout board into the USB-C port on the bottom of your PineNote; the orientation matters, so try both and remember which one works

Once the hardware is connected, we need some program on your computer to communicate over that connection with 1500000 (1.5 million) bps, 8 data bits, 1 stop bit, no parity and no flow control.

Here’s how you do that:

1. Identify the USB-UART adapter in your /dev directory by running ls /dev with it plugged in, unplugging it, then again running ls /dev and seeing what changed; it is likely to be called /dev/ttyUSB0
2. Check your permissions; run ls -l /dev/ttyUSB0 to see which groups have access to the dongle (probably dialout or uucp), and add your user to that group; remember you need to log out before group changes take effect
3. Install minicom (or some other option, but the instructions below are written for minicom)
4. In a terminal window, run minicom -D /dev/ttyUSB0 -b 1500000 or run minicom --setup to specify these settings by default

Once the software is set up, power-cycle your PineNote; as the system boots you should see text appearing in your terminal window. You can exit the session with ctrl+a x then pressing Enter to confirm. Run man minicom for more details.

Sending commands

Pressing ctrl+a in minicom enables you to send keystrokes to your PineNote. The most important of these is ctrl+c, which if sent during boot will put you in the U-Boot command prompt. You can then type help to list possible commands.

Troubleshooting

If you don’t see any text in your terminal as the PineNote boots, or the text is garbled, try the following:

• Ensure your GND, RX/TX, and CC jump wires are connected to the correct pins on both the USB-UART adapter and the USB-C breakout board
• Connect your USB-C breakout board to your PineNote in the opposite orientation
• Run minicom as sudo in case your user doesn’t have appropriate permissions
• Ensure you are setting the baud rate to 1500000 (1.5 million), and (less importantly because these are probably used by default) 8 data bits, 1 stop bit, no parity and no flow control

If you can see text but are having trouble sending ctrl+c to the PineNote during boot:

• Be sure you’re typing ctrl+a first, or whatever escape sequence your terminal emulator uses
• Send it right as the PineNote is booting, before the loading bar appears on screen
• Double-check your Y-shaped pull-up resistor cable; if this isn’t working properly you’ll probably be able to read text but not send text

USB passthrough

If your USB-C breakout board has a passthrough/intercept design, you can connect to your PineNote over USB and UART at the same time. This can be useful when you’re doing development work on the PineNote boot process so you don’t have to continually reconnect cables. You’ll need a USB-A to USB-C cable, connecting directly from your computer’s USB-A hub to your USB-C breakout board’s female USB-C port. It’s important to connect directly from USB-A, without any intermediate USB-C components. Note that connecting a live USB cable to your USB-C breakout board in this way dramatically increases the danger of frying your PineNote with a short, so you should only do this if all connectors are safely wrapped in electrical tape.

Apps

This page lists applications and tweaks for the PineNote.

Development

Here are some resources you may find helpful in learning to develop on embedded Linux devices:

• Great YouTube series introducing you to the kernel and lower-level components of Linux: https://www.youtube.com/watch?v=WiZ05pnHZqM
• https://embetronicx.com/
• https://bootlin.com/training/
• https://www.nand2tetris.org

Emulator recommendation for developing and testing PineNote apps: https://github.com/michaelshiel/picom-epaper

The PineNote is a specialized device, mainly due to the eink display having unique display and refresh characteristics. Finding and configuring apps that work well sometimes requires a lot of tweaking and a lot exploring, especially for applications containing fast screen updates and animations, as well as depend on a lot of colors.

Here is a video showing the performance of a few applications.

Desktop Environments

Sway

• WinkShell “Collected applications, configurations and scripts for using a wlroots-based compositor with an EPD (aka e-ink display). Currently supports Sway only.”
• 0cc4m’s config

Getting touch + pen working on sway

If you notice that touching the screen works, but when you use the pen the mouse coordinates are inverted, don’t worry! We can fix it! Set rockchip_ebc.panel_reflection=0 on boot (see this page for more info). Add the following line to your sway config:

# This line rotates the mouse input by 180 degrees. See https://wayland.freedesktop.org/libinput/doc/1.11.3/absolute_axes.html
input "type:table_tool" calibration_matrix -1 0 1 0 -1 1

Gnome

Gnome on wayland runs nicely on the PineNote. However, a slightly patched version of mutter is required at the moment.

• See this repository for .deb packages and patch/compile files: Patched Debian Mutter for Bookworm
• The ready-to-use Debian image provides a pre-configured GNOME environment], with specific GNOME configurations found here
• A GNOME extension is being developed that provides access to some of the ebc-specific driver options.
• PNEink is a GNOME Theme for use with the PineNote

GTK3

High contrast style for eink-devices can be found here.

GTK4

High contrast style for eink-devices can be found here.

Application support on the PineNote

System-Control

A rust-based dbus service is being developed to enable easy, system-wide control over some of the PineNote-specific settings by users and programs (e.g., triggering global screen refreshes, changing waveforms, enabling/disabling dithering). Requires this kernel.

Notetaking

Xournal++

Works well. Version 1.2 version offers repainting-related optimisations and supports PDF highlighting as well as links. To remove artefacts from the eraser set the eraser cursor’s visibility to Never via Preferences -> Stylus -> Eraser Visibility. Also, disable GTK3 intertial scroll via Preferences -> Touchscreen -> Touch Scrolling -> Disable GTK’s built-in intertial scroll, as this interferes with Xournal++’s internal touch event handling.

Xournal++ uses anti-aliasing and interpolation, which do not work well for the A1 waveform. Mitigations include using either dithering or black-and-white mode in the ebc driver. https://gitlab.com/hrdl/pinenote-shared/-/blob/main/patches/xournalpp/0001-Disable-anti-aliasing-and-use-NEAREST-interpolation-.patch is an outdated patch that used to work well without changing the bw mode.

Pre-compiled Debian packages with some of the PineNote-related modifications and support for triggering global refreshes after scrolling using the dbus service (see above) can be found here

Obsidian

Works well, EInk-Theme can be found here.

Web Browsing

Firefox

Pretty good experience! Enabling GPU acceleration is helpful.

GPU Acceleration in Firefox

See 0ccam’s notes here.

Cloud

syncthing

High contrast theme can be found here.

Games

Generating crosswords

There are some scripts here for generating crosswords for the Pinenote from IPUZ files.

Software tweaks

Fixing Bluetooth

Some users have noticed instability with their wireless driver. Upgrading the driver to the version provided by LibreELEC may help! To do this, download the BCM4345C0.hcd, brcmfmac43455-sdio.bin, and brcmfmac43455-sdio.txt from the libreELEC repositories and place them in the same location as your previous firmware (/lib/firmware/brmc/). Then rename brcmfmac43455-sdio.{txt,bin} as brcmfmac43455-sdio.pine64,pinenote-v1.2.{txt,bin}. If this doesn’t help, ask about it in the matrix chat!

Preliminary fix for stuttering bluetooth audio

Following a fix used for the Quartz Model A (which uses the same SoC as the Pinenote), we can modify the device tree prior to building the kernel to try to mitigate poor Bluetooth audio streaming. (reference: see https://lore.kernel.org/linux-arm-kernel/20220926055435.31284-1-leo@nabam.net/T/)

Steps:

• Open arch/arm64/boot/dts/rockchip/rk3566-pinenote.dtsi
• Go to line 939, “bluetooth”, under the “uart1” section
• Edit the two lines that read “device-wake-gpios” and “host-wake-gpios”; you want them to read “device-wakeup-gpios” and “host-wakeup-gpios” respectively
• Add the following line to the end of the bluetooth section (under the vddio-supply line in my .dtsi): “max-speed = <3000000>;”
• Count your zeros, don’t forget your punctuation..

Caveats:

This will improve BT audio quality at least when using the AAC codec. In my experience, the quality is more than acceptable, but there are still issues apparent: occasional isolated stutters even on AAC; prohibitively frequent stutters on SBC-XQ remain. Fully resolving BT audio issues might require further changes similar to the one described above, or may alternatively be a matter of audio software settings (e. g., process priority, audio server buffer settings). Investigation ongoing.

libinput Palm Detection

See https://gitlab.com/hrdl/pinenote-shared/-/blob/main/etc/libinput/local-overrides.quirks.

libinput Touch Arbitration

Prerequisites: libinput>1.22.1 and setup touch arbitration via udev: https://gitlab.com/hrdl/pinenote-shared/-/blob/main/etc/udev/rules.d/81-libinput-pinenote.rules

Issues and workarounds

• No resolution reported by touchscreen driver. Workaround: patch cyttsp5.c and device tree: https://gitlab.com/hrdl/linux/-/commit/f1f9eb197d3bd88c9189ab9d8fba2d03d2e13960 or set device quirk AttrSizeHint=210x157.
• Touch screen arbitration is independent of the screen’s rotation. Workaround: use AttrEventCode=-ABS_TILT_X (on older version: AttrEventCodeDisable=ABS_TILT_X) in a libinput quirk matching w9013 2D1F:0095 Stylus. This makes touch arbitration independent of the pen’s location.

Further information

Specification

General Information

• Dimensions: 191.1x232.5x7.4mm
• Weight: 438g

Core

• CPU: RK3566 1.8GHz 64-bit quad-core A55
• GPU: MALI G52 2EE
• System memory: 4GB LPDDR4
• Flash: 128GB eMMC

E-ink Display

• Size: 10.3"
• Resolution: 1404x1872
• DPI: 227
• Grayscale: 16
• Front Light: 36 level cold and warm
• Capacitive multi-touch panel
• EMR pen digitizer

Network

• WiFi: 2.4/5GHz 802.11a/b/g/n/ac
• Bluetooth: 5.0

Audio

• Built in stereo speakers
• 4 x DMIC microphone

Sensor

• G-Sensor for portrait and landscape sensing

Power

• 4000mAH LiPo battery
• DC 5V @ 3A USB-C connector

Accessories

• December 2021 batch: Optional EMR pen with magnetic attachment (included in the first production batch)
• October 2024 batch: Optional passive pen
• Optional Cover (included in the December 2021 and October 2024 batch)

SoC and memory specifications

The PineNote is based on the Rockchip RK3566.

CPU Architecture

• Quad-core ARM Cortex-A55@1.8GHz
• AArch32 for full backwards compatibility with ARMv7
• ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation
• Includes VFP hardware to support single and double-precision operations
• ARMv8 Cryptography Extensions
• Integrated 32KB L1 instruction cache and 32KB L1 data cache per core
• 512KB unified system L3 cache
• TrustZone technology support
• 22nm process, believed to be FD-SOI

GPU (Graphics Processing Unit) Capabilities

• Mali-G52 2EE Bifrost GPU@800MHz
• 4x Multi-Sampling Anti-Aliasing (MSAA) with minimal performance drop
• 128KB L2 Cache configurations
• Supports OpenGL ES 1.1, 2.0, and 3.2
• Supports Vulkan 1.0 and 1.1
• Supports OpenCL 2.0 Full Profile
• Supports 1600 Mpix/s fill rate when at 800MHz clock frequency
• Supports 38.4 GLOP/s when at 800MHz clock frequency

NPU (Neural Processing Unit) Capabilities

• Neural network acceleration engine with processing performance of up to 0.8 TOPS
• Supports integer 8 and integer 16 convolution operations
• Supports the following deep learning frameworks: TensorFlow, TF-lite, Pytorch, Caffe, ONNX, MXNet, Keras, Darknet

System Memory

• RAM Memory: 4GB LPDDR4.
• Flash Memory: 128GB eMMC

Schematics and certifications

PineNote Developer kit version

Version v1.2 is the PineNote production version that was sold through the Pines64 store

• PineNote Mainboard Schematic ver 1.2 20210824 PDF file
• PineNote USB-C Daughter Board Schematic ver 1.0 PDF file
• PineNote USB-C Console UART Breakout Board Schematic ver 1.0 PDF file Note: When building USB-C console breakout board, please be aware 10k CC pin pull-up is too weak to pull CC to logically high level. Replacing it to lower resistance, such as 1k is recommended.

The v1.1 is early release schematic just for reference only and used by developers who received the prototype.

• PineNote early released Schematic ver 1.1 20210726 PDF file
• PineNote early released ver 1.1 20210726 PCB Connector placement PDF file

Certifications:

• PineNote FCC-15C Certificate
• PineNote FCC-15E Certificate
• PineNote CE RED Certificate
• PineNote ROHS Certificate

Datasheets

Rockchip RK3566 SoC information:

• Rockchip RK3566 ver 1.0 datasheet, release permission from Rockchip

Rockchip RK817 PMU (Power Management Unit) Information:

• Rockchip RK817 version 1.01 datasheet

LPDDR4 (200 Balls) SDRAM:

eMMC information:

• Biwin 128GB eMMC model: BWCTASC41P128G

E-ink Panel information:

• E-Ink 10.3" 1872x1404 ED103TC2 Glass Panel Specification
• TPS65185x PMIC for E-Ink Enabled Electronic Paper Display Datasheet

Touch Screen information:

• Cypress CYTMA448 multi-Point Capacitive Touch Controller Datasheet
• Wacom Pen Digitizer Unit Model: SUDE-10S15MI-01X for 10.3" Display Module

WiFi/BT module information:

• Azurewave CM256SM 11AC WiFi + Bluetooth5.0 Datasheet]

G Sensor information:

• Silan SC7A20 3-Axis MEMS Accelerometer

Audio Amplifier information:

• Awinic AW87318 Class-K Audio Amp Datasheet

Closed case UART

Closed case debugging was brought up during a week of community schematic review of the PineNote. This page documents the discussion of this proposed issue and its resolution.

Dates on this page are relative to UTC-5.

Background

When debugging bootloader and kernel initialization on a new hardware platform, a hardware UART is indispensable. The PineNote 1.1 required taking the device apart to access a hardware UART broken out on the motherboard. This did not seem tenable long-term, as developers usually don’t like taking their devices apart to debug bootloaders. Therefore, it is important to provide resources to debug the PineNote’s boot process such as a hardware UART.

Recent PINE64 devices have included a hardware UART connected to their 3.5mm TRRS jacks through a hardware switch. However, the PineNote doesn’t have an audio jack. It also doesn’t have a convenient place to put a hardware switch which is accessible without taking the device apart. The case only has the affordance for a single USB-C port.

Discussion

August 15, 2021

We decided to ask the PineNote product team to explore USB-C Debug Accessory Mode, where the product changes the USB-C port’s personality when both CC1 and CC2 are pulled high. In normal usage, either CC1 or CC2 will be floating since these are the connector rotation pins. When both are detected, there is a very good chance that a debug harness is connected.

This decision requires the PineNote motherboard to be able to detect an AND condition between CC1 and CC2 and connect one of the SOC’s UARTs to pins on the USB-C connector. In all other cases, the UART should be disconnected. It also requires the PINE64 Store ship a simple one-sided (no magical flipping here, sorry) connector board which breaks out USB 2.0 and UART.

August 16-18, 2021

There were concerns that cheap USB-C cables have both CC1 and CC2 shorted together to save a wire. This may cause the PineNote to output 3.3v UART to a device that isn’t expecting it, assuming the two are plugged together with a nonstandard cable. This seems unfounded (or not enough of a problem to worry about on a large scale), since the USB-C specification states in section B.2.3.1, “The general concept for setting up a valid connection between a DTS and TS is based on being able to detect the typical USB Type-C termination resistances. However, detecting a Debug Accessory Mode connection requires that both CC pins must detect a pull-up (Rp) or pull-down (Rd) termination. A USB Type-C Cable does not pass both CC wires so a receptacle to receptacle Debug Accessory Mode connection cannot be detected.”

There were concerns that checking CC1 and CC2 being pulled high was not strictly to USB-C standard, as detecting them being pulled low is mentioned in the standard. However, detecting a pull-up condition is all that is required. According to the USB-C spec, ‘B.2.4.1.5.1 (“UnattachedDeb.SRC Requirements”), a Debug and Test System (DTS) that is a power source must pull CC1/CC2 up, while the Target System (TS) in Unattached.SNK is supposed to pull them low.’ In English, this means that we’d only need to detect a pull-up condition on CC1 and CC2, meaning a logical AND between them is a sane solution.

It should be possible to make the UART connection and breakout cable magically flippable by connecting the UART multiple times to the USB-C port.

Resolution

On August 19, 2021, TL posted the results of the hardware team’s efforts. This includes link::File:PineNote USB-C DAM Schematic Addition.png[], shown on this page, as well as the following additional documentation:

• Datasheet for ON Semiconductor NS5S1153 USB-C USB 2.0 and Audio Switch.

Additionally, the hardware team proposed designing a breakout board with pull-up resistors on CC1 and CC2 and the appropriate UART signals routed to headers on the board. Then a developer can bring their own USB TTL adapter. They almost definitely have at least one, or could access one for a low price.

dsimic commented that this proposed layout meant that a Google-designed SuzyQable would not work for debugging the PineNote. This was deemed acceptable, as long as it is clear to developers that the combination of PineNote and SuzyQable will not result in any useful debugging abilities.

Caleb commented that the Google Pixel series of devices bring out UART over the SB1 and SB2 pins on the USB-C connector. It was surmised that copying this layout would allow reusing hardware that developers already have, however there are no harnesses on the market that directly break out this interface. Instead, it seems that most developers use a USB-C breakout board and stuff wires in the appropriate place when needed[https://github.com/Peter-Easton/android-debug-cable-howto]. A similar approach could be taken with the proposed PineNote solution if someone did not wish to purchase the breakout board.

Press

Vector images and pictures for the PineNote you can freely use for projects and press inquiries. Attribute the author if attribution is required via the license (such as CC BY and CC0).

Backgrounds

Background ideas: