Q1: Is it possible to realize the claimed current draw of "about 3 mA" in any inactive state?
A1: No - at least not with the tools covered in the "Official Documentation".
To frame this question in the larger context of energy efficiency, let's consider the modes in which the RPi may operate, and the energy requirements of those modes. This has implications for the RPi's suitability for certain classes of applications (e.g. battery-powered, or off-grid applications), and potentially for the ecological/regulatory regime.
Modes of Operation for RPi 4:
In the interest of clarity, let's define some terms:
(In)Active mode: In the Active mode, the RPi is running & able to process command inputs. The RPi enters an Inactive mode following a
shutdown or a
poweroff command issued under user control while in the Active mode. No processing is done in inactive mode. The power that's consumed in this mode may heat the room a bit, but there's no useful purpose beyond that. So despite the fact that the Red Power LED is illuminated, some oscillators may be running and regulated voltages are being maintained - the RPi is doing zero "computing" - one might say, "the lights are on, but nobody's home." It may also be noted that the Inactive mode for the RPi fails to meet the 1999 One Watt Initiative1, 2. A bit odd since the UK's Enforcement Authority3 was designated by the EU to assess compliance with regulation 1275/20084, and now enforces a similar UK regulation5. I am not a proponent of regulations, per se, but the principle of the One Watt Initiative seems practical and common sense: "Don't waste energy".
Sleep mode: No Raspberry Pi, currently designed or built, has any Sleep mode available - at least not one that functions. The situation AIUI is that while various sleep modes are defined and implemented for the Linux kernel, and in
systemd, they are not implemented in the RPi. AFAIK, the absence of this mode has never been explained by the RPI's designer/manufacturer. Most commercial computers offer a Sleep mode that: 1.) saves machine state to non-volatile memory for user convenience by avoiding a reboot, and 2.) reduces power consumption through a variety of means.
Low Power mode: I'll use this ad hoc term here to cover the available option for reducing power consumption while the RPi is in the Inactive mode. The official documentation states that this (LPM) is the " lowest possible power state" for the RPi 4. Still, it's unclear that this Low Power mode meets the One Watt Initiative. Like most broad-scope initiatives, there are vagaries in the One Watt Initiative, yet the gist of it seems clear enough. For example, "standby power", a.k.a. "leaking electricity" is defined as follows:
Leaking electricity is often described as the electricity consumed by appliances when not performing their primary purpose.
Of course partisans can make all sorts of arguments, but it does seem safe to say that incorporation of an autonomous sleep mode could reduce energy consumption in the RPi below current norms. It also seems a stretch to consider any inactive mode - LPM included - as part of the RPi's "primary purpose".
Q2: What is the minimum power draw for an inactive state & how is that realized?
AFAIK, the lowest power consumption in inactive mode you can get from the RPi 4 today is 30-40mA. Getting down to that level requires that the bootloader firmware in the EEPROM be modified - two parameters must be changed, and the EEPROM must be re-flashed. Here's how to do that:
Procedure to Configure RPi 4 to enter LPM after
The RPi 4B represents a break from previous models in that bootloader code is stored in EEPROM - the boot code is now resident in the hardware instead of in the
/boot/bootcode.bin file on the SD card. With this change came a new set of configuration parameters, and new software tools to assist managing the bootloader. Most of the "official documentation" on the EEPROM-based bootloader is in two locations:
The "Low Power Mode (LPM)" is not the default bootloader configuration. However, reviewing the referenced documents above tells us what we need to know to re-configure the system. As you will see below, making this configuration change is fairly simple:
NOTE: Review the "official" documentation to confirm these instructions remain valid.
Open the bootloader configuration file for editing:
$ sudo -E rpi-eeprom-config --edit
Change two (2) parameters (
POWER_OFF_ON_HALT) in the editor as follows:
# WAKE_ON_GPIO: CHANGE FROM: 1 TO: 0
# POWER_OFF_ON_HALT: CHANGE FROM: 0 TO: 1
Save changes & re-boot
# Save the changes, and exit the editor.
# After the editor closes, you'll be prompted to reboot into the new configuration
$ sudo reboot
Configured in this way, you will see a marked reduction in power consumption (and current draw) the next time you issue a
poweroff command - or shut down your system using the desktop. Following are my results:
While up and running: approx 2.0 - 2.5 Watts; 400mA - 500mA
Inactive mode with default bootloader configuration: approx 1.35 Watts; 270mA
Inactive w/ Low Power Mode bootloader configuration: approx 0.15 - 0.20 Watts; 30mA - 40mA
Lite distro for RPi, no monitor, bootloader ver: 4/29/2021, quiescent/idle compute load, CPU governor:
NOTE 2: No differences in power consumption noted between
Are there downsides to LPM?
If you are using the "One Button Startup/Shutdown" feature enabled by the
dtoverlay REF, you will find this no longer works. As The Foundation currently has things jiggered, the only way to reboot the RPi (other than "pulling the plug") is to pull down & release the
GLOBAL_EN node (see figure below). For now, this will require adding a separate switch/button tied to
GLOBAL_EN, or to retain the convenience of a single button, some additional hardware may be required - as in this example.
ALSO: For reasons that are not entirely clear, the "low power configuration" outlined here cannot be used with the
/boot/config.txt. IOW: You may use the "low power configuration" described here, OR the gpio-poweroff overlay BUT NOT BOTH. AIUI, a solution for this issue has been identified, and will be merged in an upcoming release of the bootloader.
1. See the GitHub recipe for details & updates:
A more extensive version of this answer, and any updates or changes are located on GitHub.