From: Michael Richardson <mcr+ietf@sandelman.ca>
To: David Brown <david.brown@linaro.org>
cc: suit <suit@ietf.org>
In-Reply-To: <20180625211251.GA6063@davidb.org>
References: <20180621172040.GA24927@davidb.org> <31986.1529763789@localhost>
 <20180625211251.GA6063@davidb.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 25 Jun 2018 19:15:05 -0400
Message-ID: <20761.1529968505@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/HxhJ5p9UIN5k5-FqVRKn2encC6M>
Subject: Re: [Suit] SUIT architecture examples
Precedence: list

--=-=-=
Content-Type: text/plain


David Brown <david.brown@linaro.org> wrote:
    >> David Brown <david.brown@linaro.org> wrote:
    >> > ### 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.
    >>
    >> 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?

    > 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.

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.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBWzF3doCLcPvd0N1lAQJYlQgAhAGJsLjDFrewOkj01Jfchzv+J2tz1WY/
DHgvFVP+oZ7uB3fZExEvJ38waj4mYVAfC5JlgLzmKFgVvpPqKzyva63ZlHpdz4+S
zkARiJKdCPJ/leVhZohwcoDVsdGgsM+oRvah7/sPxN6UJZDW4c4wRwG3wx3d4Nj9
/OFcjgjrioWSv0HWY1uxhLOfv2TT+7YAbgr4q+2896roL0/FqSpzatgZpyGIUxSE
WEvKoNLYMmyzrOHWbWhZjuNniqPS+xrDSWuxG+3TQWpUbOleWK+JBR/YUsSHeiKD
Rk6zFge0a6YrV0tzV8V23lSS5Y60mdmQBjWdsY0SKwbbGpv2AIpqHw==
=ZI0+
-----END PGP SIGNATURE-----
--=-=-=--