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

    From Theo@3:770/3 to Chris Green on Mon Dec 4 14:17:54 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to All on Mon Dec 4 13:41:14 2023
    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
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to Theo on Mon Dec 4 14:32:22 2023
    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 ...

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to Andy Burns on Mon Dec 4 14:42:14 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Chris Green on Mon Dec 4 16:33:40 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to Chris Green on Mon Dec 4 20:59:34 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Green@3:770/3 to druck on Mon Dec 4 21:21:40 2023
    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
    ·

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim Jackson@3:770/3 to Chris Green on Thu Dec 7 18:04:58 2023
    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?

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to Jim Jackson on Thu Dec 7 19:38:34 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim Jackson@3:770/3 to Martin Gregorie on Thu Dec 7 20:03:42 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to Jim Jackson on Fri Dec 8 06:47:02 2023
    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 |

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to Martin Gregorie on Thu Dec 7 20:41:48 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to Ahem A Rivet's Shot on Thu Dec 7 21:23:14 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Jim Jackson on Thu Dec 7 22:06:10 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jim Jackson@3:770/3 to Theo on Thu Dec 7 22:38:42 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to Theo on Fri Dec 8 10:07:42 2023
    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 |

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Richard Kettlewell@3:770/3 to Martin Gregorie on Fri Dec 8 08:23:24 2023
    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/

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to Ahem A Rivet's Shot on Fri Dec 8 13:56:10 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to Computer Nerd Kev on Fri Dec 8 14:00:14 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Martin Gregorie on Fri Dec 8 14:41:54 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Jim Jackson on Fri Dec 8 14:39:04 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Fri Dec 8 14:44:10 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to The Natural Philosopher on Fri Dec 8 15:07:32 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Martin Gregorie@3:770/3 to The Natural Philosopher on Fri Dec 8 16:25:20 2023
    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.

    --

    Martin | martin at
    Gregorie | gregorie dot org

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Andy Burns on Fri Dec 8 16:35:10 2023
    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.


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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to The Natural Philosopher on Fri Dec 8 21:56:10 2023
    The Natural Philosopher <tnp@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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to Theo on Sat Dec 9 09:04:06 2023
    Theo <theom+news@chiark.greenend.org.uk> wrote:
    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

    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)