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

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.

You use external power control if you want that.

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

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.

A Pi 4 (two of them).

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 BBB can be powered from it's 'GPIO' header too, it has both 5v in and 5v out as it were, on different pins.

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?

'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:

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

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.

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

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

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.

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

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.

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.

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

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.

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

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

That makes sense. Thanks for the info.

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

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.

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