Power pins, aren't they powered down at poweroff/halt?

[Chris Green]

I'm amazed. It would appear that the power pins (that's pins 1, 2 and
4) remain powered up even when you do 'poweroff -p', that's crazy.

How do you prevent devices squirting 3.3v into the Pi's pins after
power down if there's no way to turn off their power?

The Beaglebone Black has both 5v and 3.3v output power pins that power
down when you shut the machine down.

Have I got this right?

--
Chris Green
·

[Theo]

Chris Green <c...@isbd.net> wrote:
> I'm amazed. It would appear that the power pins (that's pins 1, 2 and
> 4) remain powered up even when you do 'poweroff -p', that's crazy.

Which Pi?

At least on the earlier ones (can't speak for 5) they are a way to
power the Pi from HATs. The Pi doesn't have any means to control its own
power, so 'poweroff' does not in fact turn off the power, it just shuts down
the CPU.

This is quite common for embedded boards, where there's no separate power
management chip to manage 'standby' modes (a lot of embedded gear like wifi
routers are powered 24/7). On the 5 they added this chip, so I think it
does proper shutdowns like a PC.

> How do you prevent devices squirting 3.3v into the Pi's pins after
> power down if there's no way to turn off their power?

You use external power control if you want that.

> The Beaglebone Black has both 5v and 3.3v output power pins that power
> down when you shut the machine down.

The BBB I think powers those from voltage regulators, which stop when the
CPU shuts down. The Pi's power (on the early ones) is bidirectional so
powering it from the GPIO header is a feature.

Theo

[Andy Burns]

Theo wrote:

> At least on the earlier ones (can't speak for 5) they are a way to
> power the Pi from HATs. The Pi doesn't have any means to control its own
> power, so 'poweroff' does not in fact turn off the power, it just shuts down
> the CPU.

I haven't had hands on an rPi5, but yes I understand that for the first
time, powering off should actually remove power, rather than just halt ...

[Andy Burns]

Andy Burns wrote:

> I haven't had hands on an rPi5, but yes I understand that for the first
> time, powering off should actually remove power, rather than just halt ...

Apparently shutdown still doesn't remove power, but there's a new
boot.conf option POWER_OFF_ON_HALT=1 that cuts it down to 100mW or so.

[Chris Green]

Theo <theom...@chiark.greenend.org.uk> wrote:
> Chris Green <c...@isbd.net> wrote:
> > I'm amazed. It would appear that the power pins (that's pins 1, 2 and
> > 4) remain powered up even when you do 'poweroff -p', that's crazy.
>
> Which Pi?
>

A Pi 4 (two of them).

> At least on the earlier ones (can't speak for 5) they are a way to
> power the Pi from HATs. The Pi doesn't have any means to control its own
> power, so 'poweroff' does not in fact turn off the power, it just shuts down
> the CPU.
>
> This is quite common for embedded boards, where there's no separate power
> management chip to manage 'standby' modes (a lot of embedded gear like wifi
> routers are powered 24/7). On the 5 they added this chip, so I think it
> does proper shutdowns like a PC.
>
> > How do you prevent devices squirting 3.3v into the Pi's pins after
> > power down if there's no way to turn off their power?
>
> You use external power control if you want that.
>

How? I.e. if I shut down the PI and there's still power on the
peripherals doesn't it damage the Pi? How then can you do any sort of
shutdown from the Pi without risking its hardware? E.g. wouldn't an
LED operated by the Pi still be pushing (some fraction of) 5v into the
GPIO pin driving it when you shut down the Pi?

It would seem the only safe way to shut down is to pull the power, but
then you risk corrupting software.

> > The Beaglebone Black has both 5v and 3.3v output power pins that power
> > down when you shut the machine down.
>
> The BBB I think powers those from voltage regulators, which stop when the
> CPU shuts down. The Pi's power (on the early ones) is bidirectional so
> powering it from the GPIO header is a feature.
>

The BBB can be powered from it's 'GPIO' header too, it has both 5v in
and 5v out as it were, on different pins.

--
Chris Green
·

[Chris Green]

I'm still confused then.

How does one safely shut down a Pi?

Is it safe to drive GPIO even when the processor is halted? I suppose
it must be, in which case the correct sequence is to stop the
processor with 'shutdown' or 'poweroff' and then to pull the power. Is

[Theo]

Chris Green <c...@isbd.net> wrote:

> Theo <theom...@chiark.greenend.org.uk> wrote:
> >
> > You use external power control if you want that.
> >
> How? I.e. if I shut down the PI and there's still power on the
> peripherals doesn't it damage the Pi? How then can you do any sort of
> shutdown from the Pi without risking its hardware? E.g. wouldn't an
> LED operated by the Pi still be pushing (some fraction of) 5v into the
> GPIO pin driving it when you shut down the Pi?
>
> It would seem the only safe way to shut down is to pull the power, but
> then you risk corrupting software.

'shutdown' or 'poweroff' commands shut down the OS, so the OS flushes disc
caches, puts the CPU into an idle state and then stops executing
instructions. There's no power control, so the board remains powered. The
chip is still 'on', so electrically speaking everything is as it is when the
system is running, just the software isn't doing anything any more.

In the case of an LED on a GPIO, either the pin is still driving low or high
as the last time it was set, or it's turned into a high-impedance input so
no current will flow into/out of the I/O pin. Either way won't cause harm.

The 'shutdown'/'poweroff' procedure will put the software in a safe state so
you can pull the plug, but it doesn't have the hardware to pull the plug for
you.

If you choose to disconnect things, eg unplug a HAT, while the Pi is still
powered that's your lookout. You should physically remove power before
doing so (just like you should work on mains equipment unless physically
unplugged). There are cables for that:
https://thepihut.com/products/usb-c-cable-with-switch

> > > The Beaglebone Black has both 5v and 3.3v output power pins that power
> > > down when you shut the machine down.
> >
> > The BBB I think powers those from voltage regulators, which stop when the
> > CPU shuts down. The Pi's power (on the early ones) is bidirectional so
> > powering it from the GPIO header is a feature.
> >
> The BBB can be powered from it's 'GPIO' header too, it has both 5v in
> and 5v out as it were, on different pins.

OK, so it's not bidirectional, it can turn off the power on the 'out' pin
while being powered from the 'in' pin. The Pi doesn't have such hardware:
there are electrical connections between all of the 5V inputs (via some
limiting for USB, on some boards).

Theo

[druck]

On 04/12/2023 15:48, Chris Green wrote:

> Theo <theom...@chiark.greenend.org.uk> wrote:
>> You use external power control if you want that.
>>
> How? I.e. if I shut down the PI and there's still power on the
> peripherals doesn't it damage the Pi? How then can you do any sort of
> shutdown from the Pi without risking its hardware? E.g. wouldn't an
> LED operated by the Pi still be pushing (some fraction of) 5v into the
> GPIO pin driving it when you shut down the Pi?

If you are putting 5V on a GPIO pin you are going to damage it, all Pis
have 3.3V GPIO. On power off all pins go open collector, so they become
neither inputs or outputs, just as when first powered on. Any connected
LEDs will go off, nothing will be damaged.

> It would seem the only safe way to shut down is to pull the power, but
> then you risk corrupting software.

Nonsense. Do a shutdown from the desktop, or halt from the command line,
wait for the activity LED to stop flashing then it is safe to power off
without any storage corruption.

---druck

[Chris Green]

druck <ne...@druck.org.uk> wrote:
> On 04/12/2023 15:48, Chris Green wrote:
> > Theo <theom...@chiark.greenend.org.uk> wrote:
> >> You use external power control if you want that.
> >>
> > How? I.e. if I shut down the PI and there's still power on the
> > peripherals doesn't it damage the Pi? How then can you do any sort of
> > shutdown from the Pi without risking its hardware? E.g. wouldn't an
> > LED operated by the Pi still be pushing (some fraction of) 5v into the
> > GPIO pin driving it when you shut down the Pi?
>
> If you are putting 5V on a GPIO pin you are going to damage it, all Pis
> have 3.3V GPIO. On power off all pins go open collector, so they become
> neither inputs or outputs, just as when first powered on. Any connected
> LEDs will go off, nothing will be damaged.
>

Yes, sorry, just a slip of the pen/finger! :-) The BBB is just the
same, maximum of 3.3 volts.

> > It would seem the only safe way to shut down is to pull the power, but
> > then you risk corrupting software.
>
> Nonsense. Do a shutdown from the desktop, or halt from the command line,
> wait for the activity LED to stop flashing then it is safe to power off
> without any storage corruption.
>

OK, yes, if you read down the thread I had sort of arrived at this
result. It just feels slightly odd having been used to the BBB for a
long time.

--
Chris Green
·

[Jim Jackson]

You're actually stopping the operating system which puts it into a safe
state so that power can be safely removed.

Not actually sure if the processor is "shutdown" or goes into some sort
of infinite loop after all servidces etc are stopped. Anybody know?

[Martin Gregorie]

Surely any multi-tasking OS never stops: even when all the programs that
are apparently stopped, waiting for input are in fact still polling all
the devices and files it has open.

The only systems that actually stop during normal operation will only be
those running single-tasking operating systems on hardware which does not
use memory-mapped displays and that does use external devices (keyboards,
mice, printers etc.) and that relies entirely on externally generated
interrupts to trigger any activity.

Anything else can't stop because, even when its apparently idle, it must
be actively scanning for interrupts that require handling.





--

Martin | martin at
Gregorie | gregorie dot org

[Jim Jackson]

yawn - I think you miss the point! This is AFTER the OS has shutdown.
Anyway I googled and best I got on a cursory search was ...

https://unix.stackexchange.com/questions/122557/how-does-the-system-shutdown-of-a-linux-kernel-work-internally

which is 9 years old.

Seemingly the the last thing init will do after shutting down all the
services is call the reboot() syscall in the kernel. It appears the name
is misleading - the syscall can do lots of things that are not reboot'ing!

man 2 reboot

should describe what it can do.

LINUX_REBOOT_CMD_HALT
(RB_HALT_SYSTEM, 0xcdef0123; since Linux 1.1.76). The
message "System halted." is printed, and the system is
halted. Control is given to the ROM monitor, if there is
one. If not preceded by a sync(2), data will be lost.

I suspect in the Raspberry Pi <5 the processor will sit in tight forever
loop, given there is no hardware to turn power off, and in a Pi5 it will
turn power off.

Anyway I've learnt something.

[Computer Nerd Kev]

Jim Jackson <j...@franjam.org.uk> wrote:
>
> I suspect in the Raspberry Pi <5 the processor will sit in tight forever
> loop, given there is no hardware to turn power off, and in a Pi5 it will
> turn power off.

I do know that the GPU keeps going. If you set it executing
something on its spare VPU processor then it will continue blindly
after a "sudo poweroff", hence the need for a hard poweroff after
you lock it up. The GPU configures the CPU clock etc., so it might
stop the CPU at power-off. The power consumption goes down a fair
bit on the Pi Zero after power-off one way or other. If you could
figure out how to wake the CPU up again using your own GPU code, it
could even be useful in embeedded applications to use that as a
sort of sleep mode while still running something on the GPU (which
can access GPIOs).

--
__ __
#_ < |\| |< _# | Note: I won't see posts made from Google Groups |

[Ahem A Rivet's Shot]

On Thu, 7 Dec 2023 19:38:35 -0000 (UTC)
Martin Gregorie <mar...@mydomain.invalid> wrote:

> Anything else can't stop because, even when its apparently idle, it must
> be actively scanning for interrupts that require handling.

Until multi-core CPUs became common and kernels became threaded it
was normal for a multi-tasking OS to execute a HALT when there were no
tasks to run and rely on the timer tick interrupt to break it out of the
halted state. Interrupts don't need to be scanned for.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

[druck]

On 07/12/2023 20:41, Ahem A Rivet's Shot wrote:
> On Thu, 7 Dec 2023 19:38:35 -0000 (UTC)
> Martin Gregorie <mar...@mydomain.invalid> wrote:
>
>> Anything else can't stop because, even when its apparently idle, it must
>> be actively scanning for interrupts that require handling.

The whole point of an interrupt is they aren't being actively scanned.
Some external input results in the interrupt controller hardware
changing the state of the processor.

> Until multi-core CPUs became common and kernels became threaded it
> was normal for a multi-tasking OS to execute a HALT when there were no
> tasks to run and rely on the timer tick interrupt to break it out of the
> halted state. Interrupts don't need to be scanned for.

Multi-core CPUs do exactly the same thing, halt each core, and a timer
interrupt will wake up one core. It can then decide to wake up other
cores or not.

---druck

[Theo]

Jim Jackson <j...@franjam.org.uk> wrote:
> Seemingly the the last thing init will do after shutting down all the
> services is call the reboot() syscall in the kernel. It appears the name
> is misleading - the syscall can do lots of things that are not reboot'ing!
>
> man 2 reboot
>
> should describe what it can do.
>
> LINUX_REBOOT_CMD_HALT
> (RB_HALT_SYSTEM, 0xcdef0123; since Linux 1.1.76). The
> message "System halted." is printed, and the system is
> halted. Control is given to the ROM monitor, if there is
> one. If not preceded by a sync(2), data will be lost.
>
> I suspect in the Raspberry Pi <5 the processor will sit in tight forever
> loop, given there is no hardware to turn power off, and in a Pi5 it will
> turn power off.

https://github.com/raspberrypi/linux/blob/rpi-6.1.y/arch/arm/kernel/reboot.c#L108

void machine_power_off(void)
{
local_irq_disable(); // turn off interrupts
smp_send_stop(); // disable other cores
do_kernel_power_off();// call the system's power off handlers
}


At this point we work through a list of power off handlers, but I can't find
where those are registered in the 32-bit ARM tree. Doing the handlers is
the last thing Linux does - the expectation is that they never return.

I would expect ultimately the ARM executes a Wait For Interrupt instruction,
which means it can't be woken since interrupts are turned off. That means
it's in its lowest power state.

It is possible the Pi's GPU does other things like turning off power to
various peripherals, but we don't have visibility of that side of the
firmware.

Theo

[Jim Jackson]

That makes sense. Thanks for the info.

[Computer Nerd Kev]

Theo <theom...@chiark.greenend.org.uk> wrote:
>
> It is possible the Pi's GPU does other things like turning off power to
> various peripherals, but we don't have visibility of that side of the
> firmware.

There are different power states that the GPU can be commanded to
enter:

#define Get_Power_State 0x00020001 // Power: Get Power State (Response: Device ID, State)
#define Set_Power_State 0x00028001 // Power: Set Power State (Response: Device ID, State)

In Linux, the routines for setting power states are in:
drivers/soc/bcm/raspberrypi-power.c
https://sources.debian.org/src/linux/6.5.13-1/drivers/soc/bcm/raspberrypi-power.c

They seem to be called "power domains" in kernel speak, and there's
RPI_POWER_DOMAIN_ARM. That might mean the CPU, but I don't see any
useful comments that state it explicitly.

[Richard Kettlewell]

Martin Gregorie <mar...@mydomain.invalid> writes:
> Surely any multi-tasking OS never stops: even when all the programs
> that are apparently stopped, waiting for input are in fact still
> polling all the devices and files it has open.

Processes are suspended when waiting for input and as others have
pointed out, when there’s no work to do the CPU will be halted until an
interrupt arrives.

It’s possible to write programs that continuously check for some kind of
state change but usually there are better options available.

--
https://www.greenend.org.uk/rjk/

[Martin Gregorie]

On Thu, 7 Dec 2023 20:41:49 +0000, Ahem A Rivet's Shot wrote:

> On Thu, 7 Dec 2023 19:38:35 -0000 (UTC)
> Martin Gregorie <mar...@mydomain.invalid> wrote:
>
>> Anything else can't stop because, even when its apparently idle, it
>> must be actively scanning for interrupts that require handling.
>
> Until multi-core CPUs became common and kernels became threaded it
> was normal for a multi-tasking OS to execute a HALT when there were no
> tasks to run and rely on the timer tick interrupt to break it out of the
> halted state. Interrupts don't need to be scanned for.

Good info. Thanks.

AFAIK my first personally owned system (MC6809 based, running TSC's FLEX
OS) didn't stop: the innermost firmware loop scanned the keyboard for key-
press interrupts. Its display was based on a MC6845 display controller
with a dedicated chunk of RAM. The 6845 scanned this to paint a monochrome
80x24 screen on a portable monochrome TV and code in a chunk of EEPROM at
the top of the memory space was called to update the display.

[Theo]

Computer Nerd Kev <n...@telling.you.invalid> wrote:
> Theo <theom...@chiark.greenend.org.uk> wrote:
> >
> > It is possible the Pi's GPU does other things like turning off power to
> > various peripherals, but we don't have visibility of that side of the
> > firmware.
>
> There are different power states that the GPU can be commanded to
> enter:
>
> #define Get_Power_State 0x00020001 // Power: Get Power State (Response: Device ID, State)
> #define Set_Power_State 0x00028001 // Power: Set Power State (Response: Device ID, State)

Those are the mailbox property interface:
https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface

> In Linux, the routines for setting power states are in:
> drivers/soc/bcm/raspberrypi-power.c
> https://sources.debian.org/src/linux/6.5.13-1/drivers/soc/bcm/raspberrypi-power.c
>
> They seem to be called "power domains" in kernel speak, and there's
> RPI_POWER_DOMAIN_ARM. That might mean the CPU, but I don't see any
> useful comments that state it explicitly.

Device tree usually tells you which power domains need to be up, eg need to
power SD card controller before you can talk to it. But I don't see any
mechanism for the CPU to tell the GPU to turn things off on shutdown -
there's no 'I'm shutting down now' message documented.

Theo

[The Natural Philosopher]

No, but I would like to.

Is there an ARM 'HALT' instruction ?
One thing I have found is this gem

" in the bootconf.txt I changed to:

WAKE_ON_GPIO=0
POWER_OFF_ON_HALT=1"

What this actually means in the context of a Pi is not 100% clear though


--
I would rather have questions that cannot be answered...
...than to have answers that cannot be questioned

Richard Feynman

[The Natural Philosopher]

On 07/12/2023 19:38, Martin Gregorie wrote:

> Anything else can't stop because, even when its apparently idle, it must
> be actively scanning for interrupts that require handling.
>

Ah, I see you do not understand hardware interrupts AT ALL.

Hardware interrupts are not 'scanned' They actually toggle a hardware
pin on the CPU (at leasts conceptually)

That can and sometimes is configured to restart the program counter
altogether as well as set it to the interrupt vector

>
>
>
>

--
"The great thing about Glasgow is that if there's a nuclear attack it'll
look exactly the same afterwards."

Billy Connolly

[The Natural Philosopher]

On 07/12/2023 20:41, Ahem A Rivet's Shot wrote:
> On Thu, 7 Dec 2023 19:38:35 -0000 (UTC)
> Martin Gregorie <mar...@mydomain.invalid> wrote:
>
>> Anything else can't stop because, even when its apparently idle, it must
>> be actively scanning for interrupts that require handling.
>
> Until multi-core CPUs became common and kernels became threaded it
> was normal for a multi-tasking OS to execute a HALT when there were no
> tasks to run and rely on the timer tick interrupt to break it out of the
> halted state. Interrupts don't need to be scanned for.
>

Yup.

Timer tick or any other hardware interrupt.

essentially a 'sleep until()' type state


--
The lifetime of any political organisation is about three years before
its been subverted by the people it tried to warn you about.

Anon.

[Andy Burns]

The Natural Philosopher wrote:

> in the bootconf.txt I changed to:

> POWER_OFF_ON_HALT=1"
>
> What this actually means in the context of a Pi is not 100% clear though

I think that only affects a Pi5

[Martin Gregorie]

On Fri, 8 Dec 2023 14:41:55 +0000, The Natural Philosopher wrote:

> On 07/12/2023 19:38, Martin Gregorie wrote:
>
>> Anything else can't stop because, even when its apparently idle, it
>> must be actively scanning for interrupts that require handling.
>>
> Ah, I see you do not understand hardware interrupts AT ALL.
>
> Hardware interrupts are not 'scanned' They actually toggle a hardware
> pin on the CPU (at leasts conceptually)
>

Agreed. Dunno what I was thinking when I wrote that.

Evidently I confused MC6809 operations, which of course were standard
interrupts, with MC6845 operations, which allowed direct read/write
operations to the address region that delimited video display memory.
Since the 6845's video memory scan was out of phase with the master clock,
there were no problems with access collisions between in and the 6809 MPU.

I handled all display updates by using subroutines in 4 K of EEPROM at the
top of the memory map.

[The Natural Philosopher]

Honestly, I dont know.

The good thing about this group is that the one person who possibly does
may just de-lurk and tell us the definitive answer.


--
“Politics is the art of looking for trouble, finding it everywhere,
diagnosing it incorrectly and applying the wrong remedies.”
― Groucho Marx

[Theo]

The Natural Philosopher <t...@invalid.invalid> wrote:
> On 08/12/2023 15:07, Andy Burns wrote:
> > The Natural Philosopher wrote:
> >
> >> in the bootconf.txt I changed to: POWER_OFF_ON_HALT=1"
> >>
> >> What this actually means in the context of a Pi is not 100% clear though
> >
> > I think that only affects a Pi5
>
> Honestly, I dont know.
>
> The good thing about this group is that the one person who possibly does
> may just de-lurk and tell us the definitive answer.

It affects Pi4 and 400 too:
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#POWER_OFF_ON_HALT

This is a setting for the firmware EEPROM. Pis 0-3 don't have a firmware
EEPROM. It appears 3, 4, 400, CM4 have a PMIC addressable by I2C so in
theory they can turn the power off using it (if I understand the datasheet
right):

https://repair.wiki/w/MXL7704_(Raspberry_Pi)

but I don't know if they all do.

Theo

[Computer Nerd Kev]

Theo <theom...@chiark.greenend.org.uk> wrote:
> Computer Nerd Kev <n...@telling.you.invalid> wrote:
>> Theo <theom...@chiark.greenend.org.uk> wrote:
>> >
>> > It is possible the Pi's GPU does other things like turning off power to
>> > various peripherals, but we don't have visibility of that side of the
>> > firmware.
>>
>> There are different power states that the GPU can be commanded to
>> enter:
>>
>> #define Get_Power_State 0x00020001 // Power: Get Power State (Response: Device ID, State)
>> #define Set_Power_State 0x00028001 // Power: Set Power State (Response: Device ID, State)
>
> Those are the mailbox property interface:
> https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface

Yes, that's the system for talking to the GPU running the
closed-source firmware. My point was that we don't need visibility
of the GPU firmware if we know what commands it's sent and what
it's supposed to turn off as a result.

Thanks for that link though, I'd forgotten that page existed.

>> In Linux, the routines for setting power states are in:
>> drivers/soc/bcm/raspberrypi-power.c
>> https://sources.debian.org/src/linux/6.5.13-1/drivers/soc/bcm/raspberrypi-power.c
>>
>> They seem to be called "power domains" in kernel speak, and there's
>> RPI_POWER_DOMAIN_ARM. That might mean the CPU, but I don't see any
>> useful comments that state it explicitly.
>
> Device tree usually tells you which power domains need to be up, eg need to
> power SD card controller before you can talk to it. But I don't see any
> mechanism for the CPU to tell the GPU to turn things off on shutdown -
> there's no 'I'm shutting down now' message documented.

My implication was supposed to be that Linux would likely set all
the "power domains" to the off state at shut down. Last possibly
being RPI_POWER_DOMAIN_ARM if that means the CPU. To be certain,
you'd have to work out whether from reboot() Linux somehow ends up
calling rpi_firmware_set_power() in raspberrypi-power.c to disable
things.

But it probably does, because the power consumption goes down a lot
after power-off.