Standardise reset request in protocol

[mchack-work]

In Castor device apps are in control of the reset function. They can reset whenever they want. If a client wants the TKey to reset they have to request this from the device app.

In order to create interoperability between any combination of client app and any device app that is running I propose we standardise a way of doing a reset protocol request.

The firmware might also support this protocol request and we may want to at least discuss what should happen when it receives such a request.

What kind of reset intentions do we allow a client to do?

We support these:

1. Start from flash slot 1 (default).
2. Load and start an app from flash slot 1 with a specific app hash.
3. Load and start an app from flash slot 2 with a specific app hash.
4. Load and start a new app from client.
5. load and start an app from client with a specific app hash.

[mchack-work]

Some possible solutions:

• Make it a special treatment of the framing protocol, just like the firmware probe? The firmware probe is a framing header with endpoint 2 (firmware) and all well-behaved apps answer back NOK.
• Add something to the reserved bits in the framing protocol?
• Use something in the app level protocols? Framing header with endpoint either 2 (fw) or 3 (dev app) + RESET_CODE and reserve the reset codes not to be used for anything else.