Subject: [Suit] SUIT architecture examples

From: David Brown <[email-masked]>
Date: Thu, 21 Jun 2018 11:20:40 -0600

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.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 23 Jun 2018 10:23:09 -0400

> 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.

Is there sometimes an ordering constrained between images?
I.e. upgrade CPU-A to version X, before you upgrade CPU-B to version X?

Does the Manifest need to specify this constraint, or would it be implied?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: David Brown <[email-masked]>
Date: Mon, 25 Jun 2018 15:12:51 -0600

>Does the Manifest need to specify this constraint, or would it be implied?

The current requirements as I am aware of them, only require the two
images either be updated independently, or both be updated atomically.
But, maybe it is worth being able to specify a one-directional
ordering.  In fact, a one-directional ordering could be used for the
atomic case by just having each image specify a dependency on the
other image at that version.

David

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Jun 2018 19:15:05 -0400

> other image at that version.

The specific case I am painfully familiar with is on many Qualcomm based
Android devices, where a particular main-CPU ROM images requires an baseband
RADIO image at least as new as X, or stuff seriously fails.
And sometimes a ROM image of Y, must have a RADIO image <= Z.