qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emulation of 'System OFF' mode in ARM nRF51 SoCs


From: Peter Maydell
Subject: Re: Emulation of 'System OFF' mode in ARM nRF51 SoCs
Date: Mon, 19 Jun 2023 13:03:46 +0100

On Wed, 14 Jun 2023 at 14:02, Chris Laplante <chris@laplante.io> wrote:
>
> Hi all,
>
> I am working on improving nRF51 emulation. Specifically I want to implement 
> the special "System OFF" mode. System OFF is a power saving mode. In this 
> mode, the system can only be woken up by a reset or a handful of peripherals 
> (most notably, GPIO via high/low level detection on configured pins). System 
> reset is triggered upon wakeup.
>
> I've been digging into the QEMU mailing list and source code and have come to 
> the conclusion that deep sleep and low power modes are not implemented. There 
> seems to be support for turning off ARM CPU cores, e.g. as used by 
> imx6_src.c. But that doesn't apply here because I only have one CPU.

For QEMU, "power saving" is pretty irrelevant. We have a
couple of different modes:
 * CPU is executing instructions (i.e. it is powered on)
 * CPU is not executing instructions because of some sort of
   "halt" or "wfi" type instruction that means we should pause
   until the next incoming interrupt
 * CPU is not executing instructions because it is powered
   off. When some external device in the system powers it on,
   it will start up from reset.

The powerctl APIs work fine for single CPUs. Of course
the external power controller device in the system which
is calling the "power off" APIs needs to arrange to also call
"power on" again later.

> So ultimately what I think I will try to implement is what the nRF51 
> reference manual calls "Emulated System OFF mode". From the reference manual:
>
>     If the device is in debug interface mode, System OFF will be emulated to 
> secure
>     that all required resources needed for debugging are available during 
> System OFF...
>     Since the CPU is kept on in emulated System OFF mode, it is recommended
>     to add an infinite loop directly after entering System OFF, to prevent 
> the CPU from
>     executing code that normally should not be executed.

The reference manual is very unclear about what this "emulated
system off" mode actually does. I think that implementing
real "system off" is probably simpler. For that you should be able
to implement it something like this:

 (1) the power management device implements the SYSTEMOFF register
     to call arm_set_cpu_off() when a 1 is written
 (2) make sure the GPIO device implements DETECT as a GPIO output
     signal, ie an outbound qemu_irq (if we don't do this already
     the functionality will need to be added to the device model)
 (3) similarly for ANADETECT from the LPCOMP device
 (4) Wire those qemu_irq GPIO outputs up to inputs on the
     power management device. When the power management device
     sees those signals go high and the CPU is in system off mode,
     it should trigger the reset of the CPU by calling
     arm_set_cpu_on_and_reset().

NB: this doesn't exactly model the defined system-off behaviour,
but it's probably close enough. Specifically, it will only reset
the CPU itself -- all other devices in the SoC will retain their
state across the power down. If you needed to implement the
hw exact behaviour (only "retained registers" keep their state,
others are reset, watchdog gets disabled, etc) you'd need to have
the power management device tell the other devices to do a
system-off reset in addition to dealing with powering the CPU
off and on. It's probably not worth looking at this extra
complication unless you really need it.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]