Help: Pinebook Pro will not enter sleep [Manjaro 20.04]

[sleepingsysadmin]

No, not sure what I did wrong. SD and USB both dont work. The green power light just never flicks on. My theory is SPI flash soft locked but then reset/recovery buttons also do nothing.

It likely isn't SPI, unless you tried writing a bootloader to it. SPI is empty OOTB.

Luckily, your PBP probably isn't bricked, but there may be a problem with eMMC or install on it. Have you checked to make sure the eMMC is fully seated on the board? Sometimes, they can get jostled and unseated, causing sporadic issues in booting. You can also try to boot from an SD if you use the internal switch to disable the eMMC. If you can do that, you're certainly not bricked. Once booted through SD you can use the switch to enable the eMMC again, and use a few commands (in the wiki) to rebind the eMMC for writing.

If after restoring or reinstalling to the eMMC, if you'd like to use BSP uboot to get s3 sleep, I'd suggest using pcm720's u-boot with ArgleBargle's script, as outlined in the previously linked wiki section.

Well, it was definitely SPI. if=/dev/zero of=/dev/mtd0 saved my bacon. Also discovered the recovery button for sure doesnt work and i did have to bridge the 2 pins myself. Even more dumbly, I was bridging the 2 wrong pins.

To top off the whole fun event. The metal cover, as I was putting it back on, gave me a paper cut.

I am in need of a vacation, problem is that i cant go anywhere because the damned virus.

Of note: it was PCM's nvm uboot that I did. The final line for spiflash was probably what got me.

[tophneal]

Well, it was definitely SPI. if=/dev/zero of=/dev/mtd0 saved my bacon. Also discovered the recovery button for sure doesnt work and i did have to bridge the 2 pins myself. Even more dumbly, I was bridging the 2 wrong pins.

To top off the whole fun event. The metal cover, as I was putting it back on, gave me a paper cut.

I am in need of a vacation, problem is that i cant go anywhere because the damned virus.

Of note: it was PCM's nvm uboot that I did. The final line for spiflash was probably what got me.

Ah! Ok, I didn't see that you had written that to the SPI. That u-boot has a history of a better success rate flashing to SPI than the mainline u-boot that is included with most mainline distros for the PBP.

Yes, the case edges can be very sharp. After a few similar instances, I've resorted to only removing it with the use of a spudger.

Glad you're back up and going, again!

[BBreeziN]

I am unable to suspend on my new Pinebook Pro also. Running Manjaro from a WD Black SN750 NVMe SSD. I am on Manjaro arm-testing branch running the 5.7.0 kernel.

Per a previous recommendation, I commented out "SuspendState=freeze" in the /etc/systemd/sleep.conf file to enable S3 deep sleep. I seem to get a mix of the "pcie" and "gpu" inhibiting sleep.

Code:

[ 1610.911075] PM: suspend entry (deep)

Code:

[ 1610.921946] Filesystems sync: 0.010 seconds

Code:

[ 1610.924627] dwmmc_rockchip fe310000.mmc: pre_suspend failed for non-removable host: -38

Code:

[ 1610.924650] Freezing user space processes ... (elapsed 0.004 seconds) done.

Code:

[ 1610.929525] OOM killer disabled.

Code:

[ 1610.929529] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.

Code:

[ 1610.931611] printk: Suspending console(s) (use no_console_suspend to debug)

Code:

[ 1611.126907] busb rockchip_usb2phy_exit

Code:

[ 1611.285566] LDO_REG2: No configuration

Code:

[ 1611.285583] LDO_REG1: No configuration

Code:

[ 1611.402455] busb rockchip_usb2phy_exit

Code:

[ 1611.402660] busb rockchip_usb2phy_exit

Code:

[ 1611.402811] vdd_log: Entering suspend 3, enabling forcibly, was on

Code:

[ 1611.443374] busb rockchip_usb2phy_exit

Code:

[ 1611.471685] vbus_5vout: Entering suspend 3, disabling forcibly, was off

Code:

[ 1611.471708] vcc5v0_otg: Entering suspend 3, disabling forcibly, was on

Code:

[ 1611.471737] vcc3v3_panel: Entering suspend 3, disabling forcibly, was on

Code:

[ 1611.471758] vcc3v0_sd: Entering suspend 3, disabling forcibly, was on

Code:

[ 1611.471791] vcc5v0_usb: Entering suspend 3, disabling forcibly, was on

Code:

[ 1617.011153] rockchip-pcie f8000000.pcie: PCIe link enter L2 timeout!

Code:

[ 1617.011188] PM: dpm_run_callback(): rockchip_pcie_suspend_noirq+0x0/0x140 returns -110

Code:

[ 1617.011200] PM: Device f8000000.pcie failed to suspend noirq: error -110

Code:

[ 1617.041588] PM: noirq suspend of devices failed

It appears to try to enter s2idle sleep after s3 sleep fails:

Code:

[ 1618.653324] PM: suspend entry (s2idle)
[ 1618.660561] Filesystems sync: 0.007 seconds
[ 1618.661405] dwmmc_rockchip fe310000.mmc: pre_suspend failed for non-removable host: -38
[ 1618.663689] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[ 1618.876130] mmc_host mmc1: Bus speed (slot 0) = 100000000Hz (slot req 100000000Hz, actual 100000000HZ div = 0)
[ 1619.291618] dwmmc_rockchip fe320000.mmc: Successfully tuned phase to 207
[ 1619.291971] Freezing user space processes ... (elapsed 0.006 seconds) done.
[ 1619.298316] OOM killer disabled.
[ 1619.298321] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
[ 1619.301230] printk: Suspending console(s) (use no_console_suspend to debug)
[ 1619.303434] PM: dpm_run_callback(): pm_runtime_force_suspend+0x0/0xe8 returns -16
[ 1619.303445] PM: Device ff9a0000.gpu failed to suspend: error -16
[ 1620.345824] PM: Some devices failed to suspend, or early wake event detected

[pining_for_the_fjords]

Same problem here, really hoping there's a solution to this :/

[feoh]

AFAIK, it's one of the last real 'known issue' bugs waiting to be put to rest. Usually sleep works only once for me... the first time I use it. After waking up the PBP, it won't go to sleep, usually with the `ff9a0000.gpu` device waking it up again/preventing it from sleeping. I haven't seen the `fe310000.mmc` one before, which IIRC is the WiFi card. I haven't tried repeatedly putting it to sleep, so I don't what if there are other tricks like killing pulseaudio, etc. that will make it more likely to behave. So rest assured, it's not just you, and it's not a new behaviour! I think the Manjaro guys were a bit naughty, it was a known issue in 19.12 (Suspend does not work on the Pinebook Pro), and fell off the list in the 20.02/20.04 release notes, even though it still isn't stable/reliable.(seemingly)

Hi! Just got my PBPro yesterday and thus far I am super delighted!

I have one small suggestion though - the Pinebook Pro comes with a sheet of printed paper welcome the user and directing them to the wiki and forums.

Why not mention that this is a known issue on that sheet? When I finished up last night and closed the laptop lid, I assumed it would sleep, and then waking up this morning to find the battery totally dead was an unpleasant and ultimately unnecessary surprise.

IMO clicking on Sleep/Suspend is hardly a big deal, but it helps to know


Thanks for making such an outstanding laptop!

-Chris

[feoh]

When I configure for Deep suspend to ram (which is the ideal option) it does seem to go into deep suspend; but then I cannot unsuspend and similarly need to hold power button to shutdown.

To get s3 to work correctly, replace the mainline u-boot on your install with the BSP u-boot from mrfixit's v2 branch. There's a link in the wiki to the files.

Hi. I did a bunch of hunting around and couldn't find anything like this.

To be honest, the fact that I have to full shut down and cold boot this laptop really reduces its utility.

Could you please provide a link to what you're talking about? Or to anything that will let me shut the lid and not have my battery dead when I come back in the morning?

Thanks in advance

[tophneal]

Hi. I did a bunch of hunting around and couldn't find anything like this.

To be honest, the fact that I have to full shut down and cold boot this laptop really reduces its utility.

Could you please provide a link to what you're talking about? Or to anything that will let me shut the lid and not have my battery dead when I come back in the morning?

Thanks in advance

https://github.com/mrfixit2001/updates_r...filesystem

you need trust, uboot, and idbloader. you can also use the last section of the update script to write it to you emmc.

[feoh]

Hi. I did a bunch of hunting around and couldn't find anything like this.

To be honest, the fact that I have to full shut down and cold boot this laptop really reduces its utility.

Could you please provide a link to what you're talking about? Or to anything that will let me shut the lid and not have my battery dead when I come back in the morning?

Thanks in advance

https://github.com/mrfixit2001/updates_r...filesystem

you need trust, uboot, and idbloader. you can also use the last section of the update script to write it to you emmc.

Thanks a bunch for the reply. Much appreciated. I think I'll try the SleepMode=mem trick and see if that works, and if it doesn't I'll consider this approach. I'd want to get cozy enough with the various firmware utilities and the like that I'd be confident I could get back to a working state if something went wrong.

[rjraymond]

To get s3 to work correctly, replace the mainline u-boot on your install with the BSP u-boot from mrfixit's v2 branch. There's a link in the wiki to the files.

Aw, hell naw. After Gentoo, there's no way I'm messing with u-boot. Thanks, though.

[wdt]

@BBreeziN
None of the "sleeps" work with a nvme
It's a lot easier to use your smallest cheapest uSD (8G or up) and make
a "recovery" SD , with mrfixit's distro on it,, don't forget to update (mrfixit update)
Then, save mbr, dd first 16M SD->emmc, restore mbr
Unless you reboot, hard to screw up,, well , you have to know how to use dd and get right blk #