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.
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 ...
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 <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.
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.
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.
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.
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?
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.
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.
Anything else can't stop because, even when its apparently idle, it must
be actively scanning for interrupts that require handling.
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.
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.
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.
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.
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.
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.
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.
Anything else can't stop because, even when its apparently idle, it must
be actively scanning for interrupts that require handling.
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 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.
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
On 07/12/2023 19:38, Martin Gregorie wrote:
Anything else can't stop because, even when its apparently idle, itAh, I see you do not understand hardware interrupts AT ALL.
must be actively scanning for interrupts that require handling.
Hardware interrupts are not 'scanned' They actually toggle a hardware
pin on the CPU (at leasts conceptually)
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
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.
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.
| Sysop: | Xerxes |
|---|---|
| Location: | Azle, Texas |
| Users: | 119 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 139:34:23 |
| Calls: | 3,029 |
| Calls today: | 5 |
| Files: | 156 |
| U/L today: |
0 files (0K bytes) |
| D/L today: |
0 files (0K bytes) |
| Messages: | 294,158 |
| Posted today: | 0 |