Author Topic: Linux SBCs and suspend-to-RAM (or other low-power states)  (Read 2208 times)

0 Members and 1 Guest are viewing this topic.

Offline WhalesTopic starter

  • Super Contributor
  • ***
  • Posts: 2009
  • Country: au
    • Halestrom
Linux SBCs and suspend-to-RAM (or other low-power states)
« on: January 08, 2021, 01:13:19 am »
Is anyone aware of a single board computer (or anything similar) that has a working low-power suspend mode (ie <1W) in any form of OS, preferably Linux?  I want to (messily) adapt an off-the-shelf SBC to fit in an experimental laptop, for fun as a one off.

Specifically I want a suspend/halt state that takes only a second or so to resume from.  Intended use case: suspending when laptop lid closed and waking when laptop screen opened.  The alternative of suspend-to-disk ('hibernation') works on pretty much anything but is far too slow for this unless you have a very fast bootloader, customised kernel and very very fast disk IO (especially for an SBC).

Research so far

Raspberry pi series: nope, recommendations are suspend-to-disk and then use a wakeup pin to boot up again.  Closed-source bootloader takes a few seconds to complete + then your kernel needs to extract + time resuming from disk = quite a lot longer than what I want, probably most of a minute by my estimates.

Pine64 boards: difficult to find info on.  Apparently the Rock64 might?.  There laptop boards must have some sort of support so I think my best bet will be to start there.

Odroid series: doesn't look like it has such a feature.

x86 based SBCs like the AtomicPI: I can't find any info about suspend-to-ram :(

Frustratingly I suspect that all or most of the SOCs on SBCs out there support some form of lower-power RAM-saving halt states, but no one has a working software (kernel) implementation for them.  I tried looking up register docs for the Raspi 4's processor only to be reminded that only so much is publicly available  >:(  I suspect this is the case for basically all ARM SOCs out there (please correct me if I'm wrong!).

Background

I've been mulling the idea of a one-off DIY laptop for years.  Interesting points:
  • 30pin edp (used on many laptop screens) & actual DP being somewhat similar (docs seem thin on eDP, but I'm going to give this a try with a custom cable and my desktop graphics card)
  • If finding an SBC with native displayport support fails: most have HDMI outputs and there are a variety of (poorly documented and probably power-hungry) monitor chipsets that output eDP, with all sorts of pre-made boards available from greymarket sources
  • Off-the-shelf SBC adapted to main board duties (ie connectors removed & replacing with remote ones)
  • Various crazy case ideas using folded sheet aluminium.  Not groundbreaking weight/strength/performance but it will work and look tidy enough.
  • Any old micro taking the traditional laptop role of an 'Embedded Controller' (ie keyboard controller & external power management & lid switch)
  • Homebrew hinges made of much bigger parts than off-the-shelf ones.  Adjustable friction screws
  • Off-the-shelf laptop keyboards (Aliexpress has a lot of different ones listed cheaply).  Eventually one of them is going to be native PS2/similar; or I'll end up having to make my own matrix scanning firmware on a micro (I think I've found other people's stories of this, so I won't be totally stabbing in the dark, and there are a lot of different keyboard models to try).

So far all of the 'raspi laptop' creations I have seen have not looked that practical.  I don't expect mine to be miles better, but I have a few areas I think I can try to do better in.


Working suspend-to-ram support is the biggest issue left in my plans.  Other things (like eDP screen driving) have messy workarounds but workarounds nonetheless.

I might end up having to settle for something like sleep to idle and then use the EC micro to turn off as many external parts as possible.  This might get me over the line in terms of power consumption, but I'm sure it's still going to be an adventure with lots of gotchas.

Any comments and all tangents welcome :)
« Last Edit: January 08, 2021, 01:41:17 am by Whales »
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15104
  • Country: fr
Re: Linux SBCs and suspend-to-RAM (or other low-power states)
« Reply #1 on: January 08, 2021, 02:11:33 am »
Regarding eDP, the only small SBC I could find (I was also interested in this) a year ago was one from Friendly Elec.
https://www.friendlyarm.com/
The boards are actually not bad. The one I got was a NanoPC-T4, also has a M2 connector and supports NVME. Of course not as cheap as a RPi. I can't tell whether it supports suspend-to-RAM. I'd have to test that.

Problem is software wise. At least when I tested, no Linux distribution was supporting the eDP output... (this may have changed), IIRC only the Android OS supported it.
And I'd say this will be your biggest issue there. The OS. Unless you're ready (and knowledgeable) to add support yourself.
 
The following users thanked this post: Whales

Offline WhalesTopic starter

  • Super Contributor
  • ***
  • Posts: 2009
  • Country: au
    • Halestrom
Re: Linux SBCs and suspend-to-RAM (or other low-power states)
« Reply #2 on: January 08, 2021, 03:46:23 am »
Problem is software wise. At least when I tested, no Linux distribution was supporting the eDP output... (this may have changed), IIRC only the Android OS supported it.
And I'd say this will be your biggest issue there. The OS. Unless you're ready (and knowledgeable) to add support yourself.

Eek, thankyou for that warning.  That's important.

Adding support probably requires knowledge of what registers to set to activate a whole bunch of things, including the DP CRTC (or whatever it's called these days).  Given the closed documentation for many of these SoCs: that probably means reverse engineering the drivers in the Android release :o nope!

Some interesting boards with DP or eDP I've found: Rockpi N10 (about 100USD) and the Rockpi model 4 B C (about 70USD).  The pre-made SOM format of the former could potentially be a good thing for me, letting me do something a bit neater than some hacked cables for my own IO connectors.  It seems to have mainline uboot support and at least some PDFs of documentation, but I'm still reading in.

I might end up having to settle with suspend-to-idle or similar; as it's pretty much guaranteed to work on any choice of SBC and will still probably save notable power (if only by stopping currently running processes from chewing circles).
« Last Edit: January 08, 2021, 04:05:09 am by Whales »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf