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 https://github.com/raspberrypi/linux/issues/1281#issuecomment-179779785.

[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

[fanoush]

I did some tests with Zero and u-boot. After attaching power the memory is filled with 55 or AA pattern. I filled memory at locations 0x11000000-0x1b000000 with my own patterns and did two tests

1. run u-boot reset command which reboots the device
2. just shorted RUN pins for 30 seconds In both cases the memory after getting back to u-boot still had my pattern but sometimes intermixed with 55 or AA patterns so maybe SDRAM refresh is momentarily broken by device reset?

I'll do some more tests to see how frequent the corruption is. I'd also want to do proper equivalent of 'sudo poweroff' and wakeup by grounding gpio pin (5?) or 'sudo reboot' and see if it makes difference but I don't know how to call it from bare metal, is this some mailbox call? I did not find it documented at https://github.com/raspberrypi/firmware/wiki/Mailboxes

[notro]

The watchdog is used to reboot/poweroff: http://lxr.free-electrons.com/source/drivers/watchdog/bcm2835_wdt.c#L142 Downstream is still using this: https://github.com/raspberrypi/linux/blob/rpi-4.1.y/arch/arm/mach-bcm2708/bcm2708.c#L822

[P33M]

If you reset 2835 using the watchdog then it's likely that the chip selects and CKE pins on the SDRAM controller go to "default" value, i.e. have the effect of resetting the SDRAM. This will disable any internal self-refresh as the SDRAM is supposed to go into a minimal-power state when reset.

Practically, most of the bits in dynamic RAM will hold their value for up to a couple of seconds without any refresh - this grace period will vary dramatically with temperature.

If there is any suspend-to-ram feature implemented, it must not involve the watchdog or run pin.

[popcornmix]

The GPU's L2 cache will be lost on reset. Pi0 and Pi1 use that cache from the arm, so expect recent sdram writes to be missing after a reset.

[Ruffio]

@fanoush has your issue been resolved? If so, please close this issue. Thanks.

[fanoush]

No, it was not, why do you think so? Suspend to ram is still not working. I'd prefer to keep this open. But if it is breaking any statistics or something it can be closed.

Currently there is quite promising way how to test lowest power states possible and try some suspend to ram proof of concepts - the minimal opensource firmware https://github.com/christinaa/rpi-open-firmware that runs on VPU and can turn SDRAM on/off (and ARM core on, and maybe even off?) this leads to implementing bare metal arduino style environment running from bootcode.bin in cache/sram so experimenting with low power modes, putting sdram to self refresh, turning on/off ARM is possible. I plan to test it with Zero and A+ and measure power draw when ARM and SDRAM is still off at boot time and see how far I can get with this.

BTW, I wonder if boot ROM cleans up after itself and turns off SD,USB or whatevever hardware it is using to load bootcode.bin and if the SoC start with most stuff powered down or it needs to be put to low power states explicitly by additional code.

[ghollingworth]

We're not going to be implementing a suspend to RAM feature within the standard firmware. It sounds like the open source firmware may be able to achieve this.

[elektrinis]

This issue is still actual. I am doing a car head unit project and the fact that I need to wait for it to boot each time I start the car is just ridiculous. Note that "very small" draw of 100mA will run a healthy car battery flat in just over a week. This needs to be solved NOW. I can't stress this enough.

[JamesH65]

We are not working on this and are unlikely to start working on it. Sorry.

[ghost]

This is actually something I have been wanting for a while. Use case are battery powered devices running on rpi zero. Even with hdmi turned off, not having hibernate and/or suspend to RAM requires external hardware to control the power to the rpi, shutting it down after some inactivity period and then powering it up again in regular intervals. Also has previously mentioned, pressing a button and having to wait 30 seconds is far from ideal user experience.

[DRosky]

Sorry to bump, but I'm interested in this capability as well, though it seems "off the table". The reality is that the ecosystem of use cases has changed in the 8 years or so since the first Pi was released. One of the biggest shifts has been toward power management to support use cases like battery operation for IoT and other portable applications. "Always plugged in" is still a common use case for sure, and there are still plenty of Pis sitting there running LibreELEC or controlling webcams, but it's by no means as near-universal as it was 8 years ago and many people now want to use tools like the Pi to address more modern applications. Moreover, as someone mentioned, if one of the primary goals of the Pi is educational, then the changing landscape will soon make it so that lack of any meaningful power management will become a huge hole in the educational cred of the Pi, limiting it's overall educational utility for a large wave of more modern use cases. As important and universal as power management is becoming, it's a bit surprising that the Pi development team wants to purposefully decide to be left behind in this area.

[elektrinis]

In a long search I have actually found several alternatives, for example OrangePi, which is also cheaper. The main issue with this, I believe, is that devs are unfamiliar with power management techniques, which I see very often in various fields. I myself work in battery-driven industry and a LOT of development revolves around power management, all kinds of sleep modes and little tricks that can make your system both very quick to respond and draw less than 100μA in standby. While this capability very much depends on hardware implementation, I hope the Pi foundation will hear us and start working on it future releases.

[DRosky]

Yes, my first assumption was that the Raspberry Pi is a fairly modern device, and although I hadn't needed it for past use cases, I assumed there was some sort of true power management and I just needed to go online and look up how to use it. Instead, I found several Rube Goldberg-ish contraptions like the Sleepy-Pi, and threads like this one where the devs have highlighted their strong disinterest in addressing power management. Since my project has a low wake-up rate, and I have a lot of learning invested in the Pi ecosystem, I may just design my own simplified version of the Sleepy-Pi and go that route. Nevertheless, if the Pi wants to stay relevant, especially in formats like the Zero, this should be addressed as a core goal, IMHO.

I'm also in the semiconductor industry, as an analog IC designer, and I agree with your analysis; the last chip I worked on with no power management designed in was quite literally 30 years ago. I'm going out on a limb here, because I'm not 100.000% certain, but almost for sure the SoC and Wifi chips used in the Pi have advanced power management capabilities since it would have been almost unthinkable to not design them in, but they are being ignored and aren't being leveraged in firmware and software.

EDIT: BTW, thanks for pointing out the OrangePi. I'll take a look at that. If it does have better power management, it might be an alternative that allows leveraging existing Pi development work without resorting to a kludgy Sleepy-Pi approach.

[JamesH65]

The main problem is the huge amount of work required (couple of man years at a guess - you have to sell a LOT of Pi's on the back of it to make that sort of investment back) to make the GPU firmware 'sleepable'. There is power management in there for power optimisation whilst in use (blocks turned off when not used etc), but fixing the firmware to go fully to sleep and be able to recover to pre-sleep state is a huge amount of work we simply don't want to do. I'm not even sure its technically possible given the architecture we have.

As we move away from firmware to fully ARM side drivers the problem is reduced, but that is still years away.

I disagree that this is a vital to keep the Pi relevant. It's a minor use case compared with our overall marketplace. Nice to have, but not essential.

[DRosky]

Fair enough. We can agree to disagree on a few things. I can understand that perhaps the project was initially worked out in such a way that locks in a design paradigm which makes it difficult to move in certain new directions without a disproportionate amount of work. I've certainly seen that sort of thing happen, especially when such new directions weren't anticipated at the outset, which for the Pi is nearing a decade ago. Moreover, it sounds as though you are working on a redesign that will make this easier but that it will take several more years to fully implement. Given that such an effort is already underway, I can understand the reluctance to spend a lot of time backing in a temporary solution.

Where I somewhat disagree is on the issue of relevance. I suppose it depends on how one measures relevance. If it is measured by the number of "always plugged in" use cases that still exist, then I agree it could be argued that the Pi should still be considered relevant. If, on the other hand, it is measured by the ability to take on the the emerging spectrum of new and more modern use cases which are evolving in an environment increasingly dominated by portability and inexpensive wireless connectivity, then the Pi will increasingly become less relevant as a tool or learning platform to address these newer, more modern use cases until such a time as its power management capabilities can be brought up to modern standards. I will leave it at that since it's not within my abilities to measure how minor the proportion of these use cases is in relation to all use cases. My observation is that they are becoming significant as witnessed by the continual selling out of products like the "Sleepy Pi".

So I agree it's not a simple black-and-white answer.

[elektrinis]

Is there data about Pi use cases? What are the top 10?

[JamesH65]

Nothing official, but I would guess at, in no particular order:

Education General purpose desktop Hobby programming Hobby electronics Digital signage <-- Huge - street signs, museums, offices etc NAS Media centre Internet gateway/firewall Industrial monitoring Industrial machine interface ie providing GUI's to equipment.

All attached to the mains. Yes, there is an 'increasing' market for IoT type stuff, but the Pi in general is not suited to it - just not power efficient, even with the sort of power management being talked about here. Of course, the Pi is still more power efficient than an always on laptop or PC which is why is good already in many of the areas above. Spending $0.5M on sleep functionality would be a lot of money that we would not make back.

[DRosky]

Just a few additional comments. Firstly, any individual product will invariably see a selection bias in its use cases, whereby the types of uses you will see for it are the types to which the device is inherently well matched. What really need to be measured are the overall trends in the market toward small, low-power, easily programmable SoC-based devices. I haven't researched that specifically, so I won't try to throw out numbers, but what I see when I attend industry conferences and such is that, overall, the portable, disconnected-from-the-mains applications are a rapidly growing segment.

Secondly, I would admit that it's fine for product designers to choose a target market and accept that the resulting product doesn't address other cases very well. While many long-time Pi users may view this as a deficiency since we love our Pis and wish to stick with them, the reality is that there are many other options which are more well-suited to portable, battery-powered operation. In the big picture, such diversity in the market is actually a good thing.

Nonetheless, there is also a growing conviction that even devices connected to the mains should be as power efficient as possible. I have two applications, which while mains-connected, require periodic, and not continuous, data gathering and could benefit from power management. To that end, while the current applications may not absolutely require it, at least a long-term move in the direction of modern power management is a good idea, IMHO.

[tegan-lamoureux]

This also came up on my radar recently as I was looking to use a CM3+ for a mobile platform. The foundation's pure refusal to consider it, especially while simultaneously offering industrial-focused hardware, is pretty disappointing.

As others have stated, we are not in the same technological landscape we were 10 years ago, and many many applications are moving to low power, mobile, and IoT applications where power considerations often drive design more than any other factor.

Yes, there is an 'increasing' market for IoT type stuff, but the Pi in general is not suited to it - just not power efficient, even with the sort of power management being talked about here.

I also disagree with this statement. The compute modules are capable of running in the 100mA range. If we were given a low power standby in the 25mA range with <1s wakeup from GPIO it would be a game changer for the types of applications this could be applied towards. You don't need microamps of standby current to be competitive, especially with such a robust and powerful platform.

It just needs to sleep, like nearly every other arm based platform. But as others have said there's alternative platforms to consider, so it's ultimately up to the foundation.

[DRosky]

I also disagree with this statement.

I did too at first, but after a bit, I began interpreting @JamesH65's statement to mean that even with power management, the Pi is overpowered for many/most IoT use cases. There might be some truth to that, which is why I started to soften my stance a bit. For example, the project currently in front of me, and the reason I began searching for this, is fairly simple signal detection and sensor telemetry, and even the smaller Pis are significant computational and system level overkill. I wouldn't use one in the final product, but what I was hoping to do was to use a Pi to produce functioning field integration prototypes in very short order due to the ease of development and past experience. There are some other options that can also provide fairly rapid proto development, and I'll switch to one of those, but my goal of having it in a day or two using a familiar platform that I have at my disposal won't be achieved.

I think the same thing applies to educational use, another big use for the Pi. While the Pi might not be well-suited to final deployment of IoT devices in many cases, it might still be well-suited for educational use for these types of applications as well as prototype development were it not for the lack of power management.

[lategoodbye]

I followed the whole discussion here and I agree with the reasoning of the Raspberry Pi people regarding suspend to RAM too. But in times of the climate crisis no one can claim power management is just for battery powered devices. Many consumer devices like Bluray players have power saving modes, so why not the Raspberry Pi?

Suspend to RAM is not the only energy saving mode. As a compromise, I suggest we should start to implement suspend to idle first. In principle, this should not need any changes to the Raspberry Pi firmware.

[timg236]

Updating the Linux drivers to support idle is worthwhile and maybe slightly easier now that full KMS is in the pipeline e.g. sorting out KMS/X to tear down the display and turn off the pipeline instead of blanking would help.

Powering off USB ports could help, can't remember whether the Ethernet PHY can be turned off via MDIO but I don't think wake-on-lan can be supported on the current hardware.

The lowest power state on Pi4 ModelB right now would be during HALT (with WAKE_ON_GPIO=1) where pretty much the only thing running is the VPU off the OSC. I suspect you won't get much lower than 150mA even in that state.

[ghollingworth]

Agree, working to support an idle state is something that would be required in the long term to implement a proper suspend state. So try to get to the point where we fully suspend the ARM (with all state saved in SDRAM)

[lategoodbye]

Just a short explanation for the difference between suspend to RAM / suspend to idle from userspace PoV:

# suspend to RAM
echo mem > /sys/power/state

# suspend to idle
echo freeze > /sys/power/state

[DRosky]

The past few posts are interesting. It's encouraging there could be an intermediate solution. My background is primarily analog, so from a user perspective, can you briefly explain the differences between these modes and the HALT mode that already exists (I don't have experience with a Pi 4 yet)? Approximately what current consumption levels could be expected in each. I'm a little surprised that a full halt would still require 150mA. Does that mean other things are still powered up such as the ethernet PHY? There's probably something I don't understand. Does the vc4 not have the ability to turn off the vpu (most remote, power-critical applications are headless anyway)? Regarding WOL, most applications where WOL would be useful are probably mains-connected, so can support somewhat higher sleep/idle current. For remote, battery-operated devices, where sleep/idle current needs to be as low as possible, WOL wouldn't generally be required. Thanks..

Just a short explanation for the difference between suspend to RAM / suspend to idle from userspace PoV:

# suspend to RAM
echo mem > /sys/power/state

# suspend to idle
echo freeze > /sys/power/state