Power consumption and suspend to ram

[mamboman777]

The battery life of my PBP is really good, I get 8+ hours with my usage (browsing, bit of vnc, paying attention to brightness levels).

However, I have some problems with suspend to ram.
First, it wasn't always going into suspend to ram, though since some updates yesterday, this seems to have been fixed.

Second, when suspending to ram, after 2.5 hrs the battery still lost about 13% (82% to 69%), so that's barely better than keeping it running.

Is that normal?

The reason I ask: I have a Huawei tablet (M5 Lite) which runs seemingly forever, but also when just leaving it, it does fetch update information (so at some point wifi and other stuff is somewhat active), but otherwise it will lose about 20% in a week or more. I unplugged it this morning and it just sat idle all day, and just now it still has 100% charge...

Then another question: is it possible to do a suspend to disk? Or are there special reasons why that isn't recommended?
On my commute, there's a crap data connection, so I'd like to load a bunch of webpages at home or at work, then read on the go. With suspend to ram consuming a lot of battery, esp. when forgetting about it at work, I'll be stuck with a dead battery...

Any thoughts?




[Edit 2020-06-21 after getting proper suspend to ram working]

I got my Pinebook Pro in May 2020, these fixes are therefore for an ootb Manjaro 19 PBP.
With the guidance in this thread below I managed to get to where I'm at now.

My PBP is up to date in terms of software updates, so it already runs kernel 5.7.0-1-MANJARO-ARM. Kernel 5.6+ is one of the prerequisites for proper suspend to ram.

With dmesg and journalctl -f I could figure out that the sleep mode (closing the lid or Fn+ESC = Zz) was indeed not really suspend to ram.

I modified /etc/systemd/sleep.conf
#SuspendState=freeze
SuspendState=mem
and disallowed any Hibernate lines, not sure if that would be necessary, so just in case.

I installed bsp uboot, package name and version: uboot-pinebookpro-bsp (1.5-7), which tells me this at the end of the installation:
A new U-Boot version needs to be flashed our install drive. Please use lsblk to determine your drive, before proceeding.
You can do this by running:
# dd if=/boot/idbloader.img of=/dev/mmcblkX seek=64 conv=notrunc
# dd if=/boot/uboot.img of=/dev/mmcblkX seek=16384 conv=notrunc
# dd if=/boot/trust.img of=/dev/mmcblkX seek=24576 conv=notrunc
Transaction successfully finished.

lsblk outputs this:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk2 179:0 0 58.2G 0 disk
├─mmcblk2p1 179:1 0 213.6M 0 part /boot
└─mmcblk2p2 179:2 0 58G 0 part /
mmcblk2boot0 179:32 0 4M 1 disk
mmcblk2boot1 179:64 0 4M 1 disk
zram0 252:0 0 5.6G 0 disk [SWAP]

So then I had to do this:
# dd if=/boot/idbloader.img of=/dev/mmcblk2 seek=64 conv=notrunc
# dd if=/boot/uboot.img of=/dev/mmcblk2 seek=16384 conv=notrunc
# dd if=/boot/trust.img of=/dev/mmcblk2 seek=24576 conv=notrunc

after which a reboot got me to functional suspend to ram - I can see that the CPUs are put to sleep with journalctl, and overnight, the battery lost less than 3%.

I'm trying to figure this out. I am using an spiflash.bin and booting directly from an NVME drive. How will the procedure be different? Has anyone successfully implemented boot from NVME and suspend to ram?