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

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

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

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 |