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.