[PATCH 3/8] binman: capsule: Generate capsules through config file

[Simon Glass]

Hi Sughosh,

On Mon, 11 Sept 2023 at 08:13, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
>
> hi Simon,
>
> On Mon, 11 Sept 2023 at 00:44, Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Sughosh,
> >
> > On Fri, 8 Sept 2023 at 06:00, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
> > >
> > > Add support in binman for generating capsules by reading the capsule
> > > parameters through a config file. Also add a test case in binman for
> > > this mode of capsule generation.
> > >
> > > Signed-off-by: Sughosh Ganu <sughosh.ganu at linaro.org>
> > > ---
> > >
> > >  tools/binman/entries.rst                   | 35 ++++++++++++
> > >  tools/binman/etype/efi_capsule_cfg_file.py | 66 ++++++++++++++++++++++
> > >  tools/binman/ftest.py                      | 29 ++++++++++
> > >  tools/binman/test/319_capsule_cfg.dts      | 15 +++++
> > >  4 files changed, 145 insertions(+)
> > >  create mode 100644 tools/binman/etype/efi_capsule_cfg_file.py
> > >  create mode 100644 tools/binman/test/319_capsule_cfg.dts
> >
> > I think we discussed this some time ago. The problem I have with this
> > is that it adds another way of specifying the image description,
> > separate from the binman definition. This introduces all sorts of
> > problems:
> >
> > - the question of where the filenames are located, something which
> > binman tries to handle cohesively
> > - binman has no knowledge of what is being put in the capsules
> > - the resulting fdtmap lacks any information about what is in the capsules
> > - it seems to create two ways of doing the same thing
> >
> > Binman can presumably already create multiple capsule files, just by
> > adding to the description.
> >
> > What need does this feature meet?
>
> We already had this discussion earlier about the need for generating
> capsules through the config file, where I had explained the need for
> this [1]. This is functionality which is supported by the
> specification, and we have folks who are interested in having the
> capsules generated through config file, and also in generation of a
> single capsule file consisting of multiple input payloads.
>
> I understand that this model does not fit with the usual way in binman
> of generating an output image by specifying it's inputs as DT nodes.
> But just because this does not fit or align with the design of the
> tool does not mean that we do not add support for the functionality.
> Why can't we support this in binman as long as it is properly
> documented as to what is being done. Moreover, my initial versions of
> this patchset were attempting to achieve this by adding a make target,
> but you had shot it down [2]. So it either has to be done through
> binman, or through a make target.

We have a lot of balls in the air right now...I would like to pause
this one until we get the other things sorted out:

- simple capsule update in sandbox (see my other email)
- example of how to use all this on a real board (Tom is going to make
a proposal there)
- tidy up the testing so that it is easier to understand and fits
better with the test framework
- figure out the DT story, since we are still struggling to align
there (Binman bindings, removing nodes, etc)

We don't need to get all those done, but we do need to at least agree
on the direction.

Regards,
Simon


>
> -sughosh
>
> [1] - https://lists.denx.de/pipermail/u-boot/2023-July/524849.html
> [2] - https://lists.denx.de/pipermail/u-boot/2023-June/521103.html