Signal intention of system reset to firmware

[mchack-work]

Firmware is getting the possibility to load a preloaded app from flash. See #215

We need a way to indicate to the firmware the reason the running app want to do a reset.

Nota bene: This issue only covers hardware changes for how to send the intention to the firmware.

We should be able to signal a couple of intentions from the running app device to firmware:

1. Reset, load and start a new app from client.
2. Reset, load and start a new app from flash.
3. Reset, load and start an app from client with a matching app hash.
4. Reset, load and start an app from flash (where on flash?), matching an exact app hash.

Number 3 & 4 here means we need to communicate the app BLAKE2s hash of the next stage to the firmware.

If we want to be able to have general support for chaining apps and sharing data between them we also need to discuss how that sharing should be done. One idea is to reserve some RAM that won't get overwritten by firmware when resetting.

Also, see the investigation in docs/tkey_client_reset.md in internal repo about the bigger picture and threat model about how to initiate a reset signal from the client, which is orthogonal to this issue.

[mchack-work]

Decision on meeting on 2024-05-16 to try to use a touch hold for this function. See attached PR.

Needs a software test. See #223

[dehanj]

Started to investigate this, the touch sensor have a ~300 ms start up time, see attached picture. During this time the output from the touch sensor will be high, regardless of a touch or not. It seems to go low when it is ready.
This is most likely some power up sequence the touch IC needs, maybe calibration, maybe something else.

On top of this, the sensor is not registering a touch that started before the end of these 300 ms, meaning holding on the touch area and powering up the device, will not register a touch. The touch needs to start when the touch IC is ready.

[SallSim]

We will implement this with a protocol.

[mchack-work]

Our UX spec says we will use a client/app protocol request to ask for a system reset to load a new app from the client. The hardware support for system reset already exist (TK1_MMIO_TK1_SYSTEM_RESET).

However, we still have no way of communicating the device app's intent with a system reset to the firmware. The intent might be to just do a system reset because it's finished with it's work and start everything again, but it might also mean that the device app is calling system reset because the client asked it to, in order to load a new app from the client.

This means that, right now, the firmware will happily just start the preloaded app again and again. Clearly we need some way of communicating this intent to the firmware.

A couple of options:

1. Extend the hardware system reset API to include the intent.
2. Use some part of RAM to indicate intent.
3. Use touch and finger detected instead, even though we have to wait until the sensor is ready and probably blink until a timeout, waiting for a touch.

For 2 above we might want to use some reserved way of doing this, like calling another system call in the firmware, and store the intent in FW_RAM instead, but that needs analysis.

Any more options? What's a good way forward? What are the threats, if any?

[mchack-work]

Updated main issue text.