WARNING! DO THIS AT YOUR OWN RISK! POSSIBLE BRICKING OF PINEBOOK PRO!

UPDATE 2024-07-24: honestly…. just throw this piece of crap out. 😂 after years of trying to make this thing something that was even worth anything at all it fails miserably. you are better off finding an ancient 2010s macbook pro and installing linux on that.

UPDATE 2022-06-13: had a hiccup on my first day using suspend. seems like samba+winbind+pam+nss did not like coming off the AD network when i started it back up. it wasn’t a complete loss i just had to get back to lightdm and log back in using cached credentials. i am searching for a fix for this now but this is a bit difficult to test without coming off the network then figuring out a way to get back into the state i was in. otherwise, suspend has been a massive improvement on battery life if you are constantly closing and opening the pbp.
—

anybody who has a pinebook pro has probably lost their mind because suspend doesn’t work. this makes having an arm based laptop rather moot. i learned that using levinboot instead of u-boot with the lts linux kernel allows for actual legitimate suspend to ram to work. it still eats up around 2%/hr of battery life but that is still way better than s2idle or just leaving it on. it also means carrying a charger around isn’t as important. sorry but nvme still has its issues. so if you have one, you either have to pull it out or just not do this. i had to yank mine out. serial cable is super duper ridiculously highly recommended.

this was done with manjaro (running xfce) which is what i use day to day on the pbp on emmc. you first have to install linux-lts over linux. this is because there are bugs in the more recent manjaro kernels that prevent it from working. lts is decent and still works (5.15.x). first edit /etc/mkinitcpio.conf and you will see this line…

MODULES=(rtc_rk808 rockchipdrm panel_edp pwm_bl)

change panel_edp to panel_simple so the line looks like this…

MODULES=(rtc_rk808 rockchipdrm panel_simple pwm_bl)

one you do this replace whatever kernel you have with the lts kernel with…

# pacman -S linux-lts linux-lts-headers

it will ask you to remove linux (and linux-headers) for whatever kernel you are running and it will replace them. after you do this you should completely power down and power back up again. this is just to ensure the kernel is functional. you should see something like…

# uname -a
Linux hostname 5.15.43-1-MANJARO-ARM-LTS #1 SMP PREEMPT Wed May 25 13:20:50 UTC 2022 aarch64 GNU/Linux

the reason you reboot is to ensure u-boot still works. using levinboot essentially stops you from using u-boot. it is important to know this because it means that you either need to write u-boot back to emmc or you need to get an img that is made using a levinboot payload.

levinboot uses a partition that you write raw to. unlike u-boot which requires you write two files to /dev/mmcblk2 (or 1 for sd), levinboot just needs one write to the actual device. you then write a payload raw to a partition using a special guuid. to use an analogy related to u-boot: it would be like writing idbloader.img but then writing u-boot to a partition instead of the main device. i probably didn’t explain that properly but you’ll understand once you start doing it.

we want to ensure u-boot can still be brought back to life if necessary. there may be a lot of reasons you may want to do this (mostly because u-boot has active development and cross arch universal appeal). so we are going to ensure that /boot with all the u-boot bits still exists. i accomplished this by moving /boot (which in manjaro has its own partition on mmcblk2p1) to /boot unmounted on /dev/mmcblk2p2. essentially stopping it from having its own partition. in order to do this you need to..

# cd /mnt
# mkdir tmp
# umount /dev/mmcblk2p1
# mount /dev/mmcblk2p1 /mnt/tmp
# cd /mnt/tmp/
# cp -Rvp * /boot
# cd /boot
# umount /dev/mmcblk2p1

you have essentially copied anything u-boot needs to the larger partition on the emmc. now edit /etc/fstab and remove any references to /boot that you see. afterwards edit /boot/extlinux/extlinux.conf and change any references to dirs you see there to /boot/… it will look something like this…

LABEL Manjaro ARM
KERNEL /boot/Image
FDT /boot/dtbs/rockchip/rk3399-pinebook-pro.dtb
APPEND initrd=/boot/initramfs-linux.img console=ttyS2,1500000n8 … other options…

shut it down and start it back up again to ensure u-boot can still function. login and make sure /dev/mmcblk2p1 did not mount under boot. this can be checked quickly with df -h.

next you will need this awesome package created by Venom668 who packaged levinboot and it can be loaded side by side with u-boot.

save the file somewhere and go to the dir it is in and use pacman to install it…

# pacman -U levinboot-0.8.6.1-aarch64.pkg.tar.zst

he was nice enough to add instructions. just a warning. once you write levinboot-sd.img to emmc you have essentially ‘gotten rid of’ u-boot. you can no longer boot u-boot based sds. so this is really something you only do if you only want a functional laptop and do not want to use it as a playground. before doing the writing though you should take a look at cmdline.txt.

# cd /boot/levinboot
# nano -w cmdline.txt

ok. so the easiest way i found to modify the cmdline.txt was to just take the append portion of u-boot extlinux.conf, remove the initrd=linux… portion… and take the remainder and toss it into cmdline.txt. so your cmdline.txt should look SOMETHING similar to this (NOTE: NOT EXACTLY… COPY AND PASTE YOUR OWN PARTUUID FOR root=. I totally screwed myself doing this the first time out). pay close attention to this one and don’t rush it… this is all one line…

console=ttyS2,1500000n8 earlycon=uart8250,mmio32,0xff1a0000 ignore_loglevel no_console_suspend keep_bootcon root=PARTUUID=<YOUR PARTUUID!!> rw rootwait audit=0 plymouth.ignore-serial-consoles ipv6.disable=1

some of the stuff i have there you may not need but this is what i use. like i said. just take whatever is in your extlinux.conf and paste it in other than the initrd=thisstuff portion. after you are done doing this in the /boot/levinboot dir there is a script to update the payload.img. run the script from /boot/levinboot.

# ./update-payload.sh

this script will create a new payload.img that you will write raw to the /dev/mmcblk2p1 partition. now you have to move onto fdisk…

tl;dr…

# fdisk /dev/mmcblk2

> t
> 1
> e5ab07a0-8e5e-46f6-9ce8-41a518929b7c
> x
> A
> 2
> w

just a rundown of this black box stuff… t changes a partition tag, 1 is the partition you are choosing (mmcblk2p1), e5ab07a0-8e5e-46f6-9ce8-41a518929b7c is a special guuid that levinboot uses to know this is the partition that it has a payload on, x swaps you to expert mode, A sets a boot flag to partition, 2 so you can boot u-boot later if you really have to. i am not sure if u-boot needs the boot flag to be set but better safe than sorry. it won’t hurt anything anyways, w write to disk and exit. i did this while everything was mounted because you’re really just toying with the partition table and not doing much by way of resizing partitions.

so at this point your emmc should be good to write levinboot to your emmc and partition. from /boot/levinboot…

# dd if=levinboot-sd.img of=/dev/mmcblk2
# dd if=payload.img of=/dev/mmcblk2p1

for safe measure but probably not necessary…
# sync

you can also add conv=fsync if you are paranoid. it’s a pinebook… just saying. at this point you SHOULD be able to power down. cross your fingers. power it back up. and boot.

if you managed to make the alchemy work then you should see a rather quick booting into manjaro. the real test is making sure suspend to ram works. what you should do first is just hold alt+ctrl and press F2 in order to swing over to a console login (if you have a ui based one like lightdm or gdm running). login as root or as a user who can sudo -s. then sudo -s and become root and do this…

# cat /sys/power/mem_sleep

you should see [deep]. this means that the pinebook pro is set to suspend to ram. if it is not then something is wrong. you can force it but i doubt it would help later when you try to suspend it…

# echo deep > /sys/power/mem_sleep

before the final testing you may want to edit a couple of things…

EDIT: /etc/systemd/login.conf
HandlePowerKey=ignore

EDIT: /etc/systemd/sleep.conf
AllowSuspend=yes
SuspendState=mem

once that’s done your pinebook pro should be sort of all set for sleep mode. you may want to reboot one more time just to ensure these settings are in effect. the first edit is because once you press the power button to turn it back on then once it comes out of sleep mode it will turn off.

once you are set. you are booting levinboot. your /sys/power/mem_sleep says [deep]. you can run this…

# echo mem > /sys/power/state

the second you hit enter your pinebook pro SHOULD go to suspend to ram. it would be easier to confirm this with a serial cable but another easy way is to wait around 20-30s and press the power button on the keyboard for about 2-3s to wake it up. if it comes back to life you are successful and can finally use it how it should be used. i am not sure about other desktop environments (like gnome or kde) but i think they all call systemd in order to control sleep mode so you should be able to set all the settings that you normally do in order to do things like closing the lid to put it to sleep. at least for me in xfce this all seems to function properly. suspend key works and closing the lid puts it to sleep and opening it again wakes it up.

good luck. if you got it to work you can bask in the glory of finally having an arm based laptop that doesn’t get charged like an x64.

got an nvme adapter for the pinebook pro and a patriot P300 (256GB). installation was pretty straightforward. put the nvme on the adapter, screw it down into the case on the bottom around where the trackpad is. connect the included ribbon cable (be careful with this thing) to the connectors. don’t forget to lift the tiny tabs up before trying to shove it into the ports. side note: not sure if this is the same for everybody but my ribbon cable sort of stands up a little. this isn’t a major issue but don’t expect it to sit perfectly flush when you put it in. and be weary of that sticker that’s connected to the “no battery” cabling. it will stick to the ribbon cable. this happened to me so i guess it’s a forever cable because i don’t think i can get that sticker off of it anymore. i should have taken that sticker out when i had the chance but it was connected to the other ribbon cable. whatever.

pretty much worked out the box. the only thing that sort of sucks is that you can’t keep the adapter in the pinebook pro without the nvme on it because it locks into place by using a small golden “nut” by screwing it in from the bottom (trackpad side) up and not downward. so the nvme must go into it prior to mounting it onto the pinebook pro.

another thing discovered is that the nvme can draw too much power and should be power limited. there are instructions on the pinebook pro wiki that explain how to do this. when i have time i’ll see if i can write up how this is added as a service. some nvme can save this onto the drive itself; some cannot. mine cannot. so i need to run a service that does this on boot. i didn’t notice much of a drop in the speed when limiting the power. i have been using it as the /home dir for a manjaro install booting from emmc. (128GB module). works great.

so i have a serial cable now but it wouldn’t work on my macbook air running ubuntu. some brltty thing that was doing something. so i went ahead and did the stuff from this github link and it works. i guess the udev rules are jacked up or something. whatever. just in case someone bumps into this.

this was done with manjaro xfce.

so i went through the process of connecting to an ad in order to have centralized authentication (among a few other things that may be ‘good’ for). but being a laptop i want to make sure that the pinebook pro can still login as an ad user when it isn’t connected to the same network. this seems to work with the common settings found on samba.org which explains how to configure pam and smb.conf to work this way.

what i noticed though is that when i am off the network there is a long delay when trying to login as a cached ad user. i need to investigate this more but it is incredibly annoying. maybe i might move over to sssd but sssd seems a little underbaked in manjaro/arch. it is far easier to configure in debian or ubuntu. manjaro stock image repos are also missing realmd which i guess is a thing. i’ll update here if i find anything that can fix this.

just a note: manjaro instructions are the ‘old school’ way of doing it where you need to set up kerberos, samba / winbind, and pam in order for it to function. some people said they had success with sssd but i didn’t bother with it yet since old school method works for fbsd and it is best to keep that fresh.

so i am sure plenty of people are going through the motions trying to find that perfect distro to set up on their pinebook pro. and are having either good or bad success. i figured i’d post a few notes on the distros i have attempted to try so far.

manjaro plasma – installs, runs, jittery. ran this on emmc without sd installed. it jumps all over the place. you will notice this when under high load.

manjaro gnome – installs, runs, jittery, ran this on emmc without sd installed. it jumps all over the place. you will notice this when under high load.

manjaro xfce – installs, runs, smooth. running this now on emmc with sd installed (512GB samsung EVO A2). seem to be bumping into random freezes. not really sure what’s causing it but i am sure it is related to flakey emmc issues. hopefully i can catch it when it happens.

armbian xfce – does not run on emmc. this may be related to emmc issues with pinebook pro. i somehow managed to get it to run with emmc disabled on a sd. xfce is a bit lacking and you run into weird issues like firefox not being able to ‘save as…’ files. i tried to fix this by removing thunar to use the gnome filemanager instead but thunar had tons of xfce deps attached to it that i thought i could remove as well. that did not work out so well and xfce was wrecked.

armbian gnome – after ruining the xfce install i decided to just go ahead and install gnome on it. this was probably the best ux i had with the pinebook pro but, again, does not boot from emmc. the only way i managed to get this to boot was using tow-boot. also i ran into an issue after an udpate where i HAD to choose “boot from SD” in the boot menu of tow-boot instead of it automatically booting. i never really looked too deep into that since i moved onto manjaro xfce which seems stable and does what i need.

dietpi – just like armbian i could not get this to boot from emmc. this may be related to the emmc issues people are discussing. not sure though. it did boot from sd. it is a very stripped down version of armbian and the install was really nice with console menus to get you started. it is up to you to get a decent setup going though. you are pretty much starting out with the bare minimum which is what this distro attempts to do in order for you to take your own path. apt though so that’s always nice.

openbsd – it managed to boot from sd but needs serial console at this time. i did not get farther than this since i didn’t have a serial cable. maybe i’ll look into this when it is further along or i get my serial cable.

fun fact about armbian.. it is actually more ubuntu than debian. just saying.

maybe this will help someone out.

i have a nextcloud server set up. i am using the manjaro distro which uses xfce (most stable manjaro i have used on pinebook pro so far). so in order to get this working i installed the nextcloud-desktop app. the install is pretty straightforward, just pacman -S nextcloud-desktop then run through the motions of logging in.

i found that every time i login though it was asking me to login again. what a pain. so i used the following steps to fix it.

pacman -S gnome-keyring

afterwards you need to edit /etc/pam.d/lightdm
you’ll notice that there are two options for gnome-keyring that have a “-” (minus sign) next to them.
get rid of the minus sign and try again. i actually restarted the pinebook pro for good measure. upon next login i did not have to go through that convoluted login process. your /etc/pam.d/lightdm should look like this:

/etc/pam.d » cat lightdm jrg@jrpinebookpro

%PAM-1.0

auth include system-login
auth optional pam_gnome_keyring.so
account include system-login
password include system-login
session include system-login
session optional pam_gnome_keyring.so auto_start

thanks to the people who were discussing this on github here.

no matter what you do, or try, or if you pray to the gods of the electric: suspend on pinebook pro will not work. lots of theories and possibilities flying around. levinboot with old kernel may work. tow-boot may work. old or later u-boot may work. not sure about most.

u-boot 21.10 does not work. u-boot 22-04 does not work. tow-boot does not work. so far. been testing most of these with different distros to make sure. no success so far.

UPDATE 2022-06-09

the status so far. newer kernels and multiple styles of uboot have no success. it will just not suspend. there are rumors if you use a bsp u-boot which can be found here and use an older pinebookpro kernel it can suspend. the repo has the older 5.7 kernel. the only drawback is that nvme is not supported (sleep will not function this way either). i would rather take the nvme and use it for something else and have suspend in the pbp than not having suspend. so oh well. going to install dietpi on a 512GB sd, boot it, mount emmc, mount nvme, copy data from nvme to $emmc/home (i use the nvme for /home in manjaro), unmount nvme, image emmc with dd to 512GB sd (for backup), write bsp uboot to emmc, reboot (and pray it actually boots), install 5.7 kernel from manjaro repo, reboot again, test suspend to ram. this is quite ridiculous but if it works it will actually allow me to use my pbp day to day without leaving it on all the time (which is a pain… i got it to use a charger less).

cd ./out/u-boot
 sudo dd if=./idbloader.img of=/dev/sdx bs=512 seek=64
 sudo dd if=./uboot.img of=/dev/sdx bs=512 seek=16384
 sudo dd if=./trust.img of=/dev/sdx bs=512 seek=24576
 sync

these are the commands required to write u-boot bsp to <device> (i think).

downgrading the kernel was a failure. but Venom668 in #pinebook on pine64 irc created an image for testing that uses levinboot and a minimal arch linux install. first attempt went off without a hitch. i left it in suspend to ram for a few minutes and tried again. worked. so the issue lies in u-boot. seems like using levinboot may be a sane option.

1. install a patched kernel
2. make sure you’re using GPT on eMMC
3. remount boot partition somewhere else and move its content to /boot on your root partition
4. change the boot partition GUID to levinboot’s
5. install levinboot, flash the payload

quite the learning curve here. so i’ll work on it and see if i can get rid of u-boot in favor of levinboot on the emmc which already has manjaro installed. this would be the best outcome.

Update 2022-06-12

ok. played it fast and loose without an emmc backup because i just wanted to try it out. so there are quite a few steps in getting it to work but it does indeed seem that levinboot can suspend the pinebook pro. i do not think the nvme can work though. i tested it with the ribbon cable pulled on it but when i reconnected and mounted it it seemed to work (it suspended then came back to life with the power button) but then spat out error messages about nvme io. i also was able to use the 2nd partition (/dev/mmcblk2p1) for the levinboot payload. i moved u-boot related things to p2 (under /boot) so all i really did was unmount /boot, mount p1 elsewhere, copied everything to /boot, removed references to p1 in /etc/fstab, reboot. you also need to edit /boot/extlinux/extlinux.conf and change /whatever to /boot/whatever (everything). after that it will boot with u-boot in case i need to revert back.

i am going to do some more testing of suspend with levinboot and make a more detailed post on how all of this was done in a separate one if things go according to plan. i don’t mind losing the nvme but if you do then i do not think there is a solution for that yet. better off getting a larger emmc like i did or using sd for “permanent” storage and mounting it in fstab. you lose the ability to use the sd slot for hotswapping storage though. just a warning.

unfortunately had to yank the nvme. this still doesn’t seem to work. but i have a 128GB emmc that is in it. that’s fine. nvme isn’t a deal breaker but non-functional suspend is. just tested it with the sleep button (fn+esc) and lid settings enabled in manjaro.

A special thanks to Venom668 and dsimic for walking me through this.

[ 163.124393] PM: resume devices took 1.320 seconds
[ 163.124393] PM: resume devices took 1.320 seconds
[ 163.125310] OOM killer enabled.
[ 163.125310] OOM killer enabled.
[ 163.125902] Restarting tasks … done.
[ 163.125902] Restarting tasks … done.
[ 163.141350] PM: suspend exit
[ 163.141350] PM: suspend exit
[ 224.302491] PM: suspend entry (deep)
[ 224.302491] PM: suspend entry (deep)
[ 224.367101] Filesystems sync: 0.063 seconds
[ 224.367101] Filesystems sync: 0.063 seconds
[ 225.130600] Freezing user space processes … (elapsed 0.004 seconds) done.
[ 225.130600] Freezing user space processes … (elapsed 0.004 seconds) done.
[ 225.136269] OOM killer disabled.
[ 225.136269] OOM killer disabled.
[ 225.136864] Freezing remaining freezable tasks … (elapsed 0.001 seconds) done.
[ 225.136864] Freezing remaining freezable tasks … (elapsed 0.001 seconds) done.
[ 225.302601] LDO_REG2: No configuration
[ 225.302601] LDO_REG2: No configuration
[ 225.303319] LDO_REG1: No configuration
[ 225.303319] LDO_REG1: No configuration
[ 225.451155] PM: suspend devices took 0.310 seconds
[ 225.451155] PM: suspend devices took 0.310 seconds
[ 225.457671] Disabling non-boot CPUs …
[ 225.457671] Disabling non-boot CPUs …
[ 225.461681] psci: CPU1 killed (polled 0 ms)
[ 225.461681] psci: CPU1 killed (polled 0 ms)
[ 225.466308] psci: CPU2 killed (polled 0 ms)
[ 225.466308] psci: CPU2 killed (polled 0 ms)
[ 225.470344] psci: CPU3 killed (polled 0 ms)
[ 225.470344] psci: CPU3 killed (polled 0 ms)
[ 225.474296] psci: CPU4 killed (polled 0 ms)
[ 225.474296] psci: CPU4 killed (polled 0 ms)
[ 225.477945] psci: CPU5 killed (polled 0 ms)
[ 225.477945] psci: CPU5 killed (polled 0 ms)

emmc is a mess. mostly when booting. sometimes it requires a few power cycles to get it to boot an os from emmc. some distros (armbian and dietpi) do not boot at all. suspect is that emmc does not initialize properly prior to attempting to boot os. drops to emergency shell. manjaro uboot does not have usb support baked in so you cannot use the emergency shell (unless you have a serial cable?).

today (2022-05-17) going to try going to older versions of u-boot. dsimic stated that complaints were received around 2021.10. i am going to try 2021.07-3 right now. lets see if the pinebook pro starts back up…

so after using 2021.07-3 the pinebook pro seems to boot far better than before. suspend is still a total mess but at least it can consistently boot without going through the 20 times of power cycling just to get the emmc to boot. i did run into moments where the booting would not work but mostly while trying to get s2idle or deep mem_sleep to work. neither works now. it defaults to deep in /sys/power/mem_sleep. when changing to s2idle manually then going to sleep the mousepad stops working. wtf.

at least it boots better now.

update: so i have been using the pinebook pro normally. it definitely boots better with 2021.07 u-boot but i still ran into a moment where xfce took a while to shut down then when i turned it back on (later in the day) it did not boot properly. it was stuck at a cannot find uuid screen. one reboot had it booting again. not really sure where things are getting lost here but it is happening. dsimic is working on u-boot to see if things can be improved but it is difficult to debug without more information (preferably using a serial cable that is on its way).

just another update: seems like long power off starts cause it to not boot. leaves you at the emergency shell screen being unable to find uuid of emmc partition. not really sure what that’s about. but it seems to occur more often when powered down for a while beforehand. at least with 2021.07 it only takes 1 power cycle to get it going again (unlike newer ones where you can power cycle like 10 times before you can finally boot again).

lots of SD failures with pinebook pro. trying to slow it down to see if it can be made stable. this may also be what is contributing to the “choppy” effects of things. i did not notice this until i looked for it. dmesg and syslog were full of SD errors.

Instructions per Dragan Simic (dsimic) via Pine64 IRC

cp -av /boot/dtbs/rockchip/rk3399-pinebook-pro.dtb /boot/dtbs/rockchip/rk3399-pinebook-pro.dtb.orig
cp -av /boot/dtbs/rockchip/rk3399-pinebook-pro.dtb.orig $HOME

dtc -I dtb -O dts -@ -o rk3399-pinebook-pro.dts rk3399-pinebook-pro.dtb.orig

(please ignore all the warnings you’ll get when running “dtc”) now we need to edit the decompiled .dts file, to make the desired changes

replace “sd-uhs-sdr104” with “sd-uhs-ddr50” in the “mmc@fe320000” node

(you can also replace it with “sd-uhs-sdr50” in the second iteration, if the card still misbehaves)
as a note, this is the above-mentioned “sd-uhs-sdr104” line in the original source code:

https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts#L948

now it’s needed to compile the .dts file back into the .dtb file, using the following commands:

dtc -I dts -O dtb -o rk3399-pinebook-pro.dtb rk3399-pinebook-pro.dts

cp -av rk3399-pinebook-pro.dtb /boot/dtbs/rockchip/rk3399-pinebook-pro.dtb

(again, please ignore all the warnings you’ll get when running “dtc”)
at that point, rebooting the PBP will make the changes take effect, and it will be possible to see how the microSD card performs

as a reminder, please send me the output of “dmesg | grep -i mmc” in the new state
of course, there’s backup in /boot/dtbs/rockchip/rk3399-pinebook-pro.dtb.orig you can always use to revert the changes back

sd-uhs-ddr50 was a fail
sd-uhs-sdr50 was used instead

sd-uhs-sdr50 seems to be working so far. going to test it more in order to ensure that different types of writes work as well as different types of SDs

Testing syntax:
dd if=/dev/zero of=test.001 bs=1M count=16384 oflag=direct status=progress
i only care about write speed. the assumption is read will be faster. writes are where these have been failing anyways.

001: Samsung EVO A2 512GB (original testing) (~36MB/s)
002: Samsung EVO A1 64GB (~17.6MB/s)
003: Sandisk Ultra A1 32GB (~18.6MB/s)
004: Sandisk Ultra HC 1 32GB (~9MB/s)
(004 seems to be especially slow / old this one had the circle with a 10 inside which i vaguely remember being the typical sustained write speed)

those are the only four i had laying around. the change in dtb to limit with sdr50 seems to work so far. i will test with writing a bunch of files to the 512GB (this would fail without doubt).

all files copied without issue. didn’t see anything awkward and data seems ok. last dmesg.

this was booting without sd in slot, then putting it in sd slot. sorry for the double take but it is hard to make it click into place so it jumped out on me.