Re: [Suit] Call for adoption on manifest draft

[Michael Richardson <[e-mail]>]

Michael Richardson <[e-mail]> wrote:
    > Are the problems we are trying to solve so complex, varied and unknown
    > that we need this?

The most complicated situation that I see is one where there are multiple
firmwares images and they need to be upgraded in a particular order, or
things stop working.  The Android case of KERNEL image vs RADIO/BASEBAND
image is perhaps the simplest example of this.  (On some phones, you'll
not just lose LTE if they are mis-matched, but maybe WIFI too, and often
you'll get a kernel panic.)

{At this point, I wandered through the document and then into the
architecture document looking for the terminology for where a firmware image
goes into.  The best I came up was that it was a component.  Above, in my
android case, there were RADIO and KERNEL as slots for firmware}

I can readily imagine Industrial applications where it could even take
multiple passes:
    1) upgrade component A to version 1.99 (which tolerates B being at 2.00)
    2) upgrade component B to version 2.00
    3) upgrade component A to version 2.00

It should, I think be possible to express this process in a single master
manifest (with dependancies, I think) rather than staging it somehow via an operator
action.  It might be that each step takes mulitple hours to days to transfer
the image, and the device needs to be operational the rest of the time
(double-buffering).

I think that the current document can accomplish the above rather simply, but
it seems to go a lot further.  (To infinity... and beyond!... so good work!)

I think that the directives tries to assume some kind of universal firmware
updating system that is identical everywhere, rather than assuming a
universal firmware package format, with firmware updaters in specific to each
device.  Perhaps this comes from being a SoC vendor that is trying to support
customers with a large variability in uses, but wanting to provide them all
with an identical baked-in-internal-flash firmware system.

I would be interested in David Brown's view on this.

ps: I think it's only the directives which are the problem. I think the
SUIT_Conditions are perfect, btw.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-