Pinebook Pro Sleep/Resume bug: The (Kinda sorta) Good, The Bad, and the (Very) Ugly.

[feoh]

Hi all.

After sharing the same experience that @EverythingIsInput @tiagoespinha @Eight Bit @Abandoned Brain @axel and no doubt countless others have had. I joyously unboxed my shiny new Pinebook Pro a couple weeks back, spent a delicious evening enjoying that new laptop glow, closed the lid and went to bed happy.

Only to wake the next day to find in utter dismay that the battery was totally dead. Utterly. Drained. Had to do a full recharge cycle, which, even with the barrel plug takes quite a long time.

Lather, rinse, repeat until I checked here and figured out that sleep / resume just doesn't work and that many others have felt this pain.

So I went on a bit of a quest to try to understand the problem and see if I could discern a fix or at least a usable work-around.

So let's start with:

The (Kinda Sorta) Good

At least now I understand the problem

First, I tracked down Strit, the Manjaro-ARM release manager who was incredibly helpful, informing me that he'd heard that the bug was actually a bug in the Trusted Firmware, and that he'd heard this on the Pinebook Discord/Matrix.

So, I went there and started asking around, and @CrystalGamma said that he understood the issue, but that he's working another project, and if the fix isn't in in about a month when his project completes, he'll dive in and help make that happen. He mentioned that @theotherjimmy had been the one working the fix but that he hadn't been around in about a month.

At that point @theotherjimmy popped up and very helpfully explained that yes, he's been stuck on the latest suspend/resume bug but in fact there are actually *4* related bugs that would need to be solved before end users can get this to work.

He also explained that the bug is in RockChip's vendor code and that he likely wouldn't have time for it for a while since his employer has him working other issues.

They both pointed out that the Git repository containing the firmware is here
but CrystalGamma pointed out that debugging these issues requires the audio jack to USB adapter from the Pine store, but also that this adapter *appears* to have the wrong voltage (5v as opposed to 3 and change volts) and as a result could damage your Pinebook Pro if you try to use it, so there goes any thoughts I had about trying to fix this myself

The Bad

So, the bottom line is, for us end users, we essentially should abandon any hope that suspend/resume as we know and expect it will work anytime soon on the Pinebook Pro. We're talking at *least* months. Possibly longer.

Ultimately, Pine64 made it very clear that we were buying into an open source experiment here, not a polished product, so I bear no ill will against them in this, but I can't lie - I'm extremely disappointed. This situation diminishes the usefulness of the PBPro for me tremendously  - it means I have to shut down and power up from cold boot every single time I want to use the laptop.

At least, for the moment, I have figured out a really UGLY work around that makes me incredibly sad but at least keeps me from forgetting and draining my battery every time I walk away from the laptop for the day.

The (Very) Ugly

So, what I have done in order to semi-mitigate the situation is to configure KDE to shut the laptop down whenever the lid is closed. To say this isn't ideal is the understatement of the century, but what else am I going to do?

In order to do this, click the Manjaro button in the lower left or hit the Pine logo key on your laptop, and type "Energy Saving".

This will bring up a dialog with three 'tabs': "AC Power", "Battery" and "Low Battery".

Under "Button Events" I simply changed "Sleep" to "Shut down" for each of these categories, and that seems to the needful and at least keep the laptop from bleeding out overnight when its lid is closed.

In Closing - Just To Be Perfectly Clear

I knew I was taking a risk when I bought this laptop. Pine said in no uncertain terms that it was selling these at cost and that returns were only allowed for drop dead problems like a totally DOA unit.

I also recognize that this entire venture is an experiment in the spirit of open source - let's take some high value low cost hardware, assemble it in innovative ways and see what the community does with it.

All the people I spoke to about this were incredibly friendly, helpful and forthright. They've all poured blood, sweat and tears into this project and others, and I would ask that anyone who uses this to contact them please treat them with the utmost respect and deference.

I can't lie, I'm disappointed in a number of ways, but I continue to be on board with the experiment and will keep trying to use this hardware until I come to the conclusion that I am absolutely unable to do so.

[KC9UDX]

Pop your display bezel off and move the magnet. Instructions are in the wiki. Problem solved.

[feoh]

Pop your display bezel off and move the magnet.  Instructions are in the wiki.  Problem solved.

So the firmware author who claims there are 4 bugs keeping suspend/resume from working is incorrect?

Also, were the magnet the problem my shutdown on lid close work-around would in fact not work, and it does, so, I don't mean to speak in absolutes but I think you're off base on this.

[wdt]

Three distros have sleep, really "suspend 3" working, and this with mrfixit's uboot on emmc
manjaro, fedora32, elementry, I have not tested other uboots, have tested several other distros
So far, only those 3 work well, all others 60-90% / day
I use pwr button to enter/leave suspend
If the magnet is out of place, don't close lid, at least for overnight
For traveling, yes, indeed a problem
suspend 3 is about ~7% /day
in /etc/systemd/sleep.conf,,,, SuspendState=mem
(mrfixit uboot is updated to most recent BTW)
If you want to know how to get mrfixit's uboot on emmc, I can repeat, on request
--edit--
Checking my pbp, I see that lid close is flaky too
editing logind.conf ,,, HandleLidSwitch=ignore was NOT enough, still flaky
systemsettings5 -> Power Management -> Button events handling -> when laptop lid closed -> Do nothing
When power button pressed -> Prompt log out dialog
When I use pwr button, lid switch seems to be disabled, which was why I never saw flaky behavior
I have no idea how to do this with xfce or gnome, anyone else?
And, BTW if you have a nvme, none of this will work, that still needs fixing

[xmixahlx]

works fine on debian with pbp-tools.

[wdt]

Well good, that's 4 then
But I am a bear of little brain, it is not clear to me, at all
what order to do things, not to end up in dependency hell
I do prefer debian

[Arwen]

I'd like to see hibernate function. That takes no extra power. Yes, maybe you would need a swap partition, verses a swap file. But, I always have preferred swap partitions.
Plus, un-hibernating from an eMMC or NVMe would be fast. Much faster than booting.

Hibernate does not work on any distro as far as I know. Something about restoring the SoC control registers, before starting up the restored image.

[moonwalkers]

Yes, maybe you would need a swap partition, verses a swap file.

Nope, you don't need swap partition for hibernation, you can have hibernation working with swap file too, though that does require a bit of extra setup with file offset in the kernel command line.


Running Debian Sid with 5.8 kernel and v2.0 mrfixit's U-boot, suspend-to-ram works fine, battery does lose a little bit of charge overnight but not much. I probably have a batch where the magnet is aligned correctly, because for me closing the lid works correctly too.

[rik-shaw]

Just adding a comment that I am trying armbian focal with the 5.8.6 kernel and xfce as the desktop. My experience matches the OP's observations, namely that the magnet seems to work because the screen will black out when closing. It may even be suspending, but I still hear a slight "hum" from the board when I hold it up to my ear. But resume from suspend seems to be the "broken" part. Have to hard reset the device after it enters suspend by closing the lid OR by manually selecting suspend from the menu.

Sorry I haven't quite been able to internalize all the comments about mrfixit's u-boot or xmixahlx's pbp-tools being able to address the issue. I'm just a casual reader of the forums and am hoping the centralized wiki can address a standardized way to get suspend working.

Thanks to all working on the pbp: I know in the end we all are indebted to your work!

[xmixahlx]

if you can hear anything from the pbp during suspend it is not going into deep sleep. you probably consume 5% battery per hour. deep sleep to mem consumes 0.1% per hour.

you need:
5.7+ manjaro kernel
bsp-based uboot -- still recommend mrfixit 2.0
systemd configuration for mem suspend and disable hibernate (and disable power button...)

read the various scripts in pbp-tools for how these are configured:
pbp-install-linux
pbp-install-boot
pbp-config-systemd