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

[Philippe Mathieu-Daudé]

Hi Chris,

On 14/6/23 04:27, Chris Laplante 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.

What problem are you getting with a single CPU?
The "arm/arm-powerctl.h" API should work well.
If you scheduled a timer, I expect it to awake
your CPU on expiration. You can also use a QMP
command to toggle a GPIO and trigger an IRQ.

You can use the qtest API to test your code,
see some tests in tests/qtest/ using:
- qtest_set_irq_in()
- qtest_qom_set_bool() for GPIO

Regards,

Phil.

> 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.
>
> Does anyone have any guidance on how to implement this? I don't particularly 
> care about fidelity. As long as a GPIO level trigger can break the CPU out of 
> the infinite loop (which the reference manual tells users to add) and jump into 
> the reset vector, it will be good enough for my use. I don't really care about 
> masking out other interrupt sources, for example.
>
> Thanks,
> Chris