suspend to ram

[fanoush]

Would it be possible to implement suspend to ram and enter lowest power state possible?
What lowest power draw can be achieved in such mode?
Is the current state after "sudo poweroff" lowest that could be achieved? I hope not, see my measurings in thread https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=73983 - model B draws 15mA when held in reset, also I even measured slight power increase after sudo poweoff

Can following implementation of suspend reduce power consumption?
-saving ARM CPU state and turning it off completely from VC4 side
-turn leds off
-put VC4 to sleep or also turn it off so it is waken by interrupt (timer, gpio)

this would be great for battery powered projects that could sleep most of the time but need to wake up quickly (timelapse videos, wake up by sensor on gpio)

[pelwell]

Is it possible? Yes, probably.

Is it a huge amount of work that doesn't fit with our core goals? You betcha.

Chances of it happening? Zero.

[fanoush]

Yes, Zero based projects would profit the most ;-)

Not the core goal? Huge amount of work? Can you elaborate?

I guess it is e.g. many times less work than opensource VC4 3d driver which is happening.

Can you quantify where you see the most amount od work needed?
Linux device drivers in kernel specific to rpi hardware?
linux supports power management pretty well on many architectures, there are tons of mobile gadgets running linux kernel (including android phones)

VC4 side code?
from discussions in forum I got the feeling that ThreadX RTOS does support power management and can turns off unneened parts if not used.

Can you/someone suggest small steps how to achieve this?

can getting it working in some bare metal example be signifcantly less work? even that would be very valuable for many projects

About the goal:
Kids doing battery based projects and learning about proper power management is not the goal?
Today is the world of mobile devices and IOT do you think it is not educative to teach kids about such concepts they see everywhere around us?

I know this is not exactly trivial task but dismissing it immediatelly like this (huge work, zero chance, not the goal) is really disappointing.

[JamesH65]

The VC4 driver is funded by Broadcom, not the Foundation, and has some
massive benefits to the whole VC4 marketplace which is why they are paying
for it. Power management on a device that is usually plugged in, not so
important. The Foundation themselves has limited SW resource, and its fully
used up on other more important projects, so there simply isn't the staff
effort there to do it.

If this is possible by a community effort, I don't know.

On 4 February 2016 at 11:20, fanoush notifications@github.com wrote:

Yes, Zero based projects would profit the most ;-)

Not the core goal? Huge amount of work? Can you elaborate?

I guess it is e.g. many times less work than opensource VC4 3d driver
which is happening.

Can you quantify where you see the most amount od work needed?
Linux device drivers in kernel specific to rpi hardware?
linux supports power management pretty well on many architectures, there
are tons of mobile gadgets running linux kernel (including android phones)

VC4 side code?
from discussions in forum I got the feeling that ThreadX RTOS does support
power management and can turns off unneened parts if not used.

Can you/someone suggest small steps how to achieve this?

can getting it working in some bare metal example be signifcantly less
work? even that would be very valuable for many projects

About the goal:
Kids doing battery based projects and learning about proper power
management is not the goal?
Today is the world of mobile devices and IOT do you think it is not
educative to teach kids about such concepts they see everywhere around us?

I know this is not exactly trivial task but dismissing it immediatelly
like this (huge work, zero chance, not the goal) is really disappointing.

—
Reply to this email directly or view it on GitHub
#1281 (comment).

[notro]

The C.H.I.P. might be a better fit for a battery powered IoT device when it becomes generally available (this summer?): http://nextthing.co/
It has a PMIC which can also charge a battery and has onboard wifi. It's ARM CPU also has full control unlike the Pi where the GPU is the boss.
Free Electrons are tasked with providing Linux kernel mainline support, so I expect power management to be fully supported.
I don't know about camera support, but it has CSI pins exposed on a header.

[Ferroin]

Going further:
Unless you are taking about a huge % power savings, it's probably not worth it even for that. Nominal power consumption of a Pi 2 IIRC is 10W, and most the time it should be well below that if you're not doing HPC type applications or really complicated DSP type things. I've got a couple running as storage bricks in a distributed file-system with somewhat regular usage, and even during times I hit the performance ceiling on said file-system, the Pi's still rarely go over 2W power consumption, even though I'm using USB storage powered directly from the Pi (FWIW, GlusterFS runs amazingly well on the Pi, so if you want to experiment with distributed storage networks, it's easy to throw something together without much expenditure that will still get somewhat remarkable performance given the hardware).

Going further from this, if you really need maximal power savings on a Pi, try the following:

1. Make sure you have libcofi installed and pre-loaded for everything. Raspbian does this already, and I'm pretty sure many other distros do as well. If you've got Gentoo or Arch though, you will have to install it.
2. Use sysvinit together with something like monit instead of systemd. Systemd can use a lot of excess processor time depending on your configuration, which increases power consumption. Secondarily, the systemd journal eats a lot of processor time as well.
3. Look for lighter weight alternatives to software you're using. For example instead of using postfix for mail, look into nullmailer.
4. USB storage may be faster than the SD card, but it also uses more power, so you can save some significant power just by not using USB storage directly connected to the Pi.
5. Get a good WiFi adapter with an nice antenna. Better antennas mean you need less transmit power to get the same range, and don't use as much power receiving either (although this is not as big of a power savings as it sounds like).

[fanoush]

I am not sure Zero fits in category "device that is usually plugged in" and this is the reason I created this ticket after years of lack of progress in this area. Even if it would benefit the bigger PIs too the Zero is the reason why it matters more now.

So no matter whether foundation has plan or resources to make suspend to ram in linux kernel working or not, questions asked in previous posts remain:
Is the Zero (and A+,2B,B+) board and the BCM2835/6 in it designed so that with proper software it can draw single digit mA or less? And of course still be able to resume from RAM by external trigger or timer?
Can VPU turn off ARM core?
Can it put itself to sleep or off and be woken up on gpio or timer interrupt?

If answers are not even known then maybe trying to optimize the "sudo poweroff" state would answer it and not take such huge amount of work and then community work could follow with bare metal code and later taking care of linux device drivers suspend/resume code?

For others, please keep this on topic (=powermanagement in linux kernel/rpi firmware), this is not https://www.raspberrypi.org/forums/ , thank you.

[popcornmix]

The "sudo poweroff" state is designed to be the lowest power state the Pi can achieve. (But note that low power is not high on the list of Pi design goals, so there may well be better low powered alternatives to the Pi).

It occurs by resetting the SoC (so almost everything is disabled) and then sleeping with very little powered on. We hold the LAN chip in reset as that reduces its power.

If you are able to get a lower power state from linux, then that suggests the "sudo poweroff" state is not optimal. Perhaps the reset state of something is not actually disabled. I'm suspecting the composite or hdmi phy as a possibility as you mentioned "tvservice -o" - but that is just guessing.

[fanoush]

Oh, that would be bad. So could you somehow explain my measurings in that old forum post?
poweron with no card, held in reset (shorted P6 near hdmi connector) 15mA
first 6 seconds after released from 15mA reset - 40mA then it went to 76mA
This was model B measured on 5V power input.
I will re-check with zero and other newer models, but I think I tried with b+ when I got it and didn't get that 15mA in reset.

If at least the Zero board cannot draw less then any suspend to ram efforts are of course useless.

[P33M]

If you hold the SoC in reset, then the oscillator stops. No clocks means that you're just drawing leakage current.

As soon as you release reset, the oscillator starts up and the Audio power domain is automatically powered. This includes the bootrom, VPU, bus matrix and a few select peripherals. Once the 2nd stage is loaded, if you're in the special "poweroff" mode, this stage (on the VPU) sets up an interrupt handler for a GPIO to wake if an edge is detected, then goes to sleep.

In this state there are nontrivial amounts of power consumed because the oscillator clock is being provided to several bits of the chip. If you brought the SDRAM out of reset and somehow put it in self-refresh with meaningful state inside then the power consumed would increase in this case.

[Ferroin]

@popcornmix So does this mean then that 'poweroff' on the Pi behaves differently from almost every other platform where it is either an alias for 'halt' or causes the hardware to cut power? Last I checked it's the same as calling halt on the Pi, you need to power cycle the board to get a usable system again, and there is no state preserved beyond persistent storage.

I don't think the goal is minimizing power consumption to that degree. The point of STR is to be able to enter a low power state and then return to exactly where you were before when you wake up from it. I'm not sure how much we already do to reduce power consumption, but chances are that we could do more. However, I doubt that there is much we could reasonably do as far as STR, as there needs to be some wake up source, and we would need to at least leave the VC partially running to preserve enough state to resume properly. At the very least this would require some VC firmware changes to handle things, and I'm not even sure if it's possible given the hardware design. I don't think that there would be much measurable difference even on the Zero between a system in this state and one just sitting idle, so altogether, I don't think that it is actually worth pursuing STR, and that it would be more worthwhile to look into other ways of reducing power consumption (I listed some above that can be handled without even touching the kernel or VC code, but they do require the user to be smart about it).

[popcornmix]

poweroff does a halt from the linux point of view. Then the Pi gets reset with a special flag that says don't restart.
There is no usable state after a halt or a reboot, apart from a few bits in the reset peripheral than allow us to flag not to restart after the reset.

[fanoush]

I did some measurings with the Zero.
When attaching power without card inserted the board first draws 27mA and then after a couple of seconds it goes up to 56mA (waiting for usb boot?)
When holding board in reset by shorting the RUN pins it draws only 2.7-3mA (!)
When fully booted into raspbian lite with hdmi on it draws 99mA
after running 'tvservice -o' it draws 79mA
after sudo poweroff it draws 22mA

I wonder whether SDRAM keeps its content while the board is held in reset via RUN pins. When googling for random datasheets this one from Samsung http://www.samsung.com/global/business/semiconductor/file/product/APP_061301-1.pdf describes that when RAM is in self refresh it does not need clock to be running, also the power draw of the ram is menioned as 1.5mA which sounds promising. Also here http://cache.nxp.com/files/32bit/doc/app_note/AN4531.pdf?fpsp=1&WT_TYPE=Application%20Notes&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation&fileExt=.pdf it describes similar thing.

So in theory with some extra cirtuits (attiny, pic) the VPU could put sdram to self refresh and signal other cpu and then go to sleep. The other CPU could then keep holding the board in reset to save power until something happens, then after leaving reset the VPU could resume from RAM if data in RAM is still good. This sounds like a bit complicated hack but doable if RAM can keep the data and VPU could execute the resume code after going out of reset, which it hopefully can because that is what current poweroff does (resets, checks some flag and goes to sleep).

[notro]

It's a lot of work to implement suspend/resume.
First the platform has to support it. suspend_set_ops() is used to provide the necessary functions, so you can look at the callers to get an idea of what is necessary. A first step would be to implement PM_SUSPEND_STANDBY.
Next step is to implement suspend/resume in all the bcm2835 specific drivers, none have this support today.

Then there's the issue of wakeup source. The ARM needs way to tell the VPU which interrupt that should wake it up. There is no RTC to wake it up either.

It would be interesting to know the power consumption in the 'halt' state where the cpu is just spinning (machine_halt())

The Pi Zero uses ~3 seconds to boot the kernel and you can run scripts even earlier if you use initramfs.
I don't know if it's possible to use the camera at this point. Sensors that have kernel drivers is available at least.

You mention using a microcontroller which means you can power off the entire board, using (almost) no power at all.

Do you have a specific use case that requires a very short wakeup time?

[fanoush]

specific use case is battery powered device with user interface that can resume on button press or periodically to do some backgroud job and go back to sleep

anyway currently it would be enough if the sudo poweroff would shutdown what it can and put sdram to self refresh and boot code should not clear it so that most of it would be preserved after reboot (minus e.g. 16MB or so for the boot code if needed). If my own kernel.img can boot and finds some specific SDRAM region intact then it is good enough to call it done for now. In fact I have not tried it yet so I'll do it ASAP, maybe it is already the case?

either it will draw those 22mA in such suspended state which is still reduction to 1/4 or it would even survive holding in reset at those 3mA which would mean that it would last weeks on single battery

[fanoush]

so I guess at this stage this is not yet about linux kernel so I'll check ram after reboot in bare metal code and then possibly create ticket in "firmware" issue tracker to preserve SDRAM across reboots