Low power mode actually increases power consumption after sudo halt !?

[seamusdemora]

This repository tracks bugs for the Raspberry Pi 4 bootloader EEPROM and Linux update scripts.

• If you suspect a hardware problem then please read the Boot Problems post first before contacting the reseller.
• Support questions or should be posted on the Raspberry Pi General Discussion**

Mandatory information

• Raspberry Pi model: RPi 4B
• Board revision (cat /proc/cpuinfo | grep Revision): Revision : b03111
• Operating system version . Raspbian GNU/Linux 10 (buster)
• Details of any hardware attached e.g. links to USB : none while testing this
• Photo of the HDMI diagnostics screen, UART trace. N/A - running "Lite"/Headless

Describe the bug
A clear and concise description of what the bug is.

• Configure for "low power mode"; WAKE_ON_GPIO=0, POWER_OFF_ON_HALT=1
• While operating, RPi draws 500mA. After sudo halt, RPi draws 630mA
• Previous testing in July 2020 w/ 2020-06-15 firmware reduced current from 500mA to 40mA

To Reproduce
Steps to reproduce the behavior:

1. vcgencmd bootloader_config reports
   [all]
   BOOT_UART=0
   WAKE_ON_GPIO=0
   POWER_OFF_ON_HALT=1
   DHCP_TIMEOUT=45000
   DHCP_REQ_TIMEOUT=4000
   TFTP_FILE_TIMEOUT=30000
   ENABLE_SELF_UPDATE=1
   DISABLE_HDMI=0
   BOOT_ORDER=0xf41

2. $ vcgencmd bootloader_version reports:
   Sep 3 2020 13:11:43
   version c305221a6d7e532693cc7ff57fddfc8649def167 (release)
   timestamp 1599135103
   update-time 0
   capabilities 0x00000000

3, Measure current into RPi
4. sudo halt
5. Measure current into RPi

Expected behaviour
A clear and concise description of what you expected to happen.

Current consumption after sudo halt should have decreased from 500mA to 40mA - as it did w/ 2020-06-15 firmware

Bootloader version and configuration
If you have modified the default bootloader release or configuration then please attach the bootloader configuration vcgencmd bootloader_config and version (vcgencmd bootloader_version)

See above

SD card boot (please complete the following information):

• SD card type: 32GB SanDisk
• Partition information (sudo fdisk -l) if you are able to obtain this from another computer.

Network boot (please complete the following information):
Network boot bug normally require one or more of the following log types. PiServer is the officially supported network boot server.

• DHCP server configuration files e.g. dnsmasq.conf
• Wireshark binary packet capture
• UART logs

N/A - boot from SD card

USB boot (please complete the following information):
Verify that the the USB device works correctly when hot-plugged under Linux and attache the output of 'lsusb -vvv'

Additional context
Add any other context about the problem here.

The Bootloader configuration page describes how to enable UART or NETCONSOLE logs. For complex USB boot issues NETCONSOLE logs are recommended.

[pelwell]

The whole point of the gpio-poweroff driver and overlay is to get the ARMs to a point where the power can be safely removed then signal an external agent to do so. If you aren't actually removing the power at that point then you are breaking the contract.

[timg236]

I've just tried this on a Pi4B 0xc03111 with the latest 2021-03-08 and it worked as expected i.e.

• sudo halt
• Linux shutdown
• Activity LED displays HALT pattern
• Measure 3V3 - off

Please can you verify that you see the last two steps, if not, then I suspect the Linux halt sequence did not complete. Bootloader UART traces will also indicate whether the PMIC outputs are being turned off.

[lurch]

@seamusdemora I think by "breaking the contract" Phil was implying that the expectation is that if you're using gpio-poweroff then you'll be removing the external power to the Pi after GPIO26 goes high, in which case the "high power consumption" shouldn't matter because you've removed the power-supply anyway? 🤷

[pelwell]

The contract is with the kernel - failure to remove the power in the allowed time (3 seconds, I think) will result in a kernel panic.

This usage pattern is erroneous, and the issue should be closed.

[pelwell]

The standard Linux gpio-poweroff driver prevents a poweroff reset - this is by design. You are free to enable the hard poweroff in the boot configuration, but it will never be used because the board will only reset to reboot, at which point you don't want it to switch off.

[pelwell]

Here's a preview of the updated gpio-poweroff documentation:

Info:   Drives a GPIO high or low on poweroff (including halt). Using this
        overlay interferes with the normal power-down sequence, preventing the
        kernel from resetting the SoC (a necessary step in a normal power-off
        or reboot). This also disables the ability to trigger a boot by driving
        GPIO3 low.

        Users of this overlay are required to provide an external mechanism to
        switch off the power supply when signalled - failure to do so results
        in a kernel BUG, increased power consumption and undefined behaviour.

[lurch]

@pelwell Is it possible to "remove" or "disable" the effect of the gpio-poweroff dtoverlay at run-time? Or is that only possible by editing /boot/config.txt and rebooting?
If it is possible at run-time, I wonder if that might fulfil Seamus's desire to support both the "Zero Power" and "Low Power" modes that he refers to? (although I have to admit that wanting to support both at the same time seems like somewhat of an edge-case, and it seems that most applications would only use one or the other.)

[pelwell]

Is it possible to "remove" or "disable" the effect of the gpio-poweroff dtoverlay at run-time?

No, that's not possible - installing the gpio_poweroff driver disables the usual poweroff handler, but removing it doesn't restore it, leaving the device with no way to power off normally.

[pelwell]

removing it doesn't restore it, leaving the device with no way to power off normally.

This doesn't have to be the case, though. Although gpio-poweroff is a common Linux driver, we are already using a patched version to allow it to be installed on a system that already has a poweroff handler.

The updated version proposed in raspberrypi/linux#4309 remembers the original poweroff handler for two reasons:

1. so that it can be restored when the module is unloaded, and
2. as a fallback in the event that the power is not withdrawn before the timeout expires.

[lurch]

Nice, it sounds like 2. will solve all of Seamus's concerns? (when it eventually filters through to a packaged kernel of course)

[lurch]

If all of that's true, then perhaps another bootcode config (5VBUS_OFF ?) variable would solve my problem.

AFAICT from looking at https://www.raspberrypi.org/documentation/hardware/raspberrypi/schematics/rpi_SCH_4b_4p0_reduced.pdf the 5V rail from the USB-C power-input is directly connected to the GPIO header, and therefore it's not possible to "turn off" the 5V bus? 🤷