[Suit] SUIT architecture examples

[David Brown <[e-mail]>]

During today's SUIT meeting, we discussed writing up some known
example architectures of systems requiring firmware updates.  Attached
below is a draft of this writeup.

## Architectural examples

Although these documents attempt to define a firmware update
architecture that is applicable to both existing systems, as well as
yet-to-be-conceived systems; it is still helpful to consider existing
architectures.

### Single CPU SoC

The simplest, and currently most common, architecture consists of a
single MCU along with its own peripherals.  These SoCs generally
contain some amount of flash memory for code and fixed data, as well
as RAM for working storage.  These systems either have a single
firmware image, or an immutable bootloader that runs a single image.
A notable characteristic of these SoCs is that the primary code is
generally execute in place (XIP).  Combined with the non-relocatable
nature of the code, firmware updates need to be done in place.

### Single CPU with secure mode

Another configuration consists of a similar architecture to the
previous, with a single CPU.  However, this CPU supports a security
partitioning scheme that allows memory (in addition to other things)
to be divided into secure and non-secure.  There will generally be two
images, one for secure mode, and one for non-secure.  In this
configuration, firmware upgrades will generally be done by the CPU in
secure mode, which is able to write to both areas of the flash device.
In addition, there are requirements to be able to update either image
independently, as well as to update them together atomically, as
specified in the associated manifests.

### Dual CPU, shared memory

This configuration has two or more CPUs in a single SoC that share
memory (flash and RAM).  Generally, they will be a protection
mechanism to prevent one CPU from accessing the other's memory.
Upgrades in this case will typically be done by one of the CPUs, and
is similar to the single CPU with secure mode.

### Dual CPU, other bus

This configuration has two or more CPUs, each having their own memory.
There will be a communication channel between them, but it will be
used as a peripheral, not via shared memory.  In this case, each CPU
will have to be responsible for its own firmware upgrade.  It is
likely that one of the CPUs will be considered a master, and will
direct the other CPU to do the upgrade.  This configuration is
commonly used to offload specific work to other CPUs.  Firmware
dependencies are similar to the other solutions above, sometimes
allowing only one image to be upgraded, other times requiring several
to be upgraded atomically.  Because the updates are happening on
multiple CPUs, upgrading the two images atomically is challenging.