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
·

Chris Green <cl@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

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 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.

Theo <theom+news@chiark.greenend.org.uk> wrote:
> Chris Green <cl@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
·

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
this right?

--
Chris Green
·

Chris Green <cl@isbd.net> wrote:
> Theo <theom+news@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

On 04/12/2023 15:48, Chris Green wrote:
> Theo <theom+news@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

druck <news@druck.org.uk> wrote:
> On 04/12/2023 15:48, Chris Green wrote:
> > Theo <theom+news@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
·

On 2023-12-04, Chris Green <cl@isbd.net> wrote:
> 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
> this right?

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?

On Thu, 7 Dec 2023 18:04:58 -0000 (UTC), Jim Jackson wrote:

> On 2023-12-04, Chris Green <cl@isbd.net> wrote:
>> 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 this
>> right?
>
> 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?

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

On 2023-12-07, Martin Gregorie <martin@mydomain.invalid> wrote:
> On Thu, 7 Dec 2023 18:04:58 -0000 (UTC), Jim Jackson wrote:
>
>> On 2023-12-04, Chris Green <cl@isbd.net> wrote:
>>> 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 this
>>> right?
>>
>> 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?
>
> 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.

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.

Jim Jackson <jj@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 |

On Thu, 7 Dec 2023 19:38:35 -0000 (UTC)
Martin Gregorie <martin@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

On 07/12/2023 20:41, Ahem A Rivet's Shot wrote:
> On Thu, 7 Dec 2023 19:38:35 -0000 (UTC)
> Martin Gregorie <martin@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

Jim Jackson <jj@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

On 2023-12-07, Theo <theom+news@chiark.greenend.org.uk> wrote:
> Jim Jackson <jj@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.
>

That makes sense. Thanks for the info.

Theo <theom+news@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.

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

Martin Gregorie <martin@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/

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 <martin@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.

--

Martin | martin at
Gregorie | gregorie dot org

Computer Nerd Kev <not@telling.you.invalid> wrote:
> Theo <theom+news@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

On 07/12/2023 18:04, Jim Jackson wrote:
> On 2023-12-04, Chris Green <cl@isbd.net> wrote:
>> 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
>> this right?
>
> 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?
>
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

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

On 07/12/2023 20:41, Ahem A Rivet's Shot wrote:
> On Thu, 7 Dec 2023 19:38:35 -0000 (UTC)
> Martin Gregorie <martin@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.

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