Zephyr: introduce bootloader requests

[tomchy]

In some cases, a Zephyr platform is not able to use the RAM-based retention subsystem. This results in no ability to communicate with the bootloader to:

• Request the recovery mode from the main application
• Request the firmware loader mode from the main application

The other case in which the application wants to communicate with the bootloader are platforms that want to have the active slot configured as read-only. In such case, the following flow can be introduced to mitigate this restriction:

• The main application sends a request to the bootloader informing which image should be confirmed.
• The main application reboots the device.
• The device reboots and resets memory permissions so that the bootloader can perform the updates.
• In the permitted state, the bootloader processes the confirmation requests, before analyzing the state of the slots.
• The bootloader continues the logic as if the application had confirmed the slot.

There is also a third use case for the application requests in the Direct XIP mode:

• Currently, the decision of which slot to boot is based only on the version number.
• Even if there are two valid slots on the device, a user cannot request a temporary rollback to the previous firmware.
• By introducing a request for slot preference, the slot selection logic may be extended with custom logic that runs as part of the main application and sends such a request to the bootloader to alter the default behavior.

This PR introduces an API that can be used to collect all of the above requests in a single module.
The Kconfig to select or extend the boot request format is located in the configuration file of the mcuboot module in the Zephyr repository.
In addition, a simple integration with bootutil library is included, allowing this feature to be used with an existing MCUmgr implementation.

[nordicjm]

this is not how common code should work, bootutil is a common file for any RTOS, any zephyr specific code goes in boot/zephyr, and there should be no checking of e.g. Kconfigs in common code

[tomchy]

this is not how common code should work, bootutil is a common file for any RTOS, any zephyr specific code goes in boot/zephyr, and there should be no checking of e.g. Kconfigs in common code

Is there a place for a code that is zephyr-specific, yet should be shared between the app and bootloader?

Honestly, I had an impression that the shared code/library problem is not fully resolved in the MCUboot ATM, so we are seeking for good ideas here 🙂

Side note: that's one of the reasons why this is a draft PR.

[nordicjm]

this is not how common code should work, bootutil is a common file for any RTOS, any zephyr specific code goes in boot/zephyr, and there should be no checking of e.g. Kconfigs in common code

Is there a place for a code that is zephyr-specific, yet should be shared between the app and bootloader?

Honestly, I had an impression that the shared code/library problem is not fully resolved in the MCUboot ATM, so we are seeking for good ideas here 🙂

Side note: that's one of the reasons why this is a draft PR.

Depends what it is, if it's zephyr centric then it can go into zephyr itself (e.g. boot mode is in zephyr and used in apps and mcuboot), I'm not sure what this code really does or what part is meant to be shared

[tomchy]

this is not how common code should work, bootutil is a common file for any RTOS, any zephyr specific code goes in boot/zephyr, and there should be no checking of e.g. Kconfigs in common code

Is there a place for a code that is zephyr-specific, yet should be shared between the app and bootloader?
Honestly, I had an impression that the shared code/library problem is not fully resolved in the MCUboot ATM, so we are seeking for good ideas here 🙂
Side note: that's one of the reasons why this is a draft PR.

Depends what it is, if it's zephyr centric then it can go into zephyr itself (e.g. boot mode is in zephyr and used in apps and mcuboot), I'm not sure what this code really does or what part is meant to be shared

Sine the boot request API is used by the bootutil logic, I decided to move it into the MCUBoot include directory.
That way the header is common, but the implementation is platform-specific (just like the security counter API).
There is still one Kconfig left: the CONFIG_MCUBOOT as it was already there for changing the implementation, based on the context (app vs bootloader). If there is a MCUboot-centric way to do that, let me know, I'll be happy to replace it.

If you agree on the current split, I'll add a note about the new configuration option inside the MCUboot docs.