[PATCH v9 08/10] sandbox: capsule: Generate capsule related files through binman

[Sughosh Ganu]

hi Simon,

On Sat, 12 Aug 2023 at 22:33, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Sughosh,
>
> On Sat, 12 Aug 2023 at 09:40, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
> >
> > hi Simon,
> >
> > On Sat, 12 Aug 2023 at 19:55, Simon Glass <sjg at chromium.org> wrote:
> > >
> > > On Fri, 11 Aug 2023 at 23:58, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
> > > >
> > > > The EFI capsule files can now be generated as part of u-boot
> > > > build through binman. Add capsule entry nodes for the sandbox
> > > > architecture for generating the capsules. These capsules are then used
> > > > for testing the EFI capsule update functionality on the sandbox
> > > > platforms.
> > > >
> > > > Remove the corresponding logic in the test setup which was used for
> > > > generation of these capsule which is now superfluous.
> > > >
> > > > Signed-off-by: Sughosh Ganu <sughosh.ganu at linaro.org>
> > > > ---
> > > > Changes since V8:
> > > > * Build the capsules for all sandbox variants.
> > > > * Remove the type property by renaming the capsule nodes as
> > > >   'efi-capsule'.
> > > >
> > > >  arch/sandbox/dts/sandbox.dts                  |   2 +
> > > >  arch/sandbox/dts/sandbox_capsule.dtsi         | 315 ++++++++++++++++++
> > > >  arch/sandbox/dts/test.dts                     |   2 +
> > > >  include/sandbox_efi_capsule.h                 |  21 ++
> > > >  test/py/tests/test_efi_capsule/conftest.py    | 155 +--------
> > > >  .../tests/test_efi_capsule/uboot_bin_env.its  |  36 --
> > > >  6 files changed, 356 insertions(+), 175 deletions(-)
> > > >  create mode 100644 arch/sandbox/dts/sandbox_capsule.dtsi
> > > >  create mode 100644 include/sandbox_efi_capsule.h
> > > >  delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its
> > >
> > > Reviewed-by: Simon Glass <sjg at chromium.org>
> > >
> > > One way to reduce the files is to put all the capsules in the same
> > > binman image. You could have 'size = <0x1000>' so they are all the
> > > same size.
> > >
> > > Then your test could check each one by iterating through the (single) file.
> >
> > This won't work, as the UEFI specification defines a particular format
> > of the capsule file. For multiple capsules, the individual capsule
> > files need to be present under the /EFI/UpdateCapsule/ directory on
> > the EFI System Partition. The spec does define a format in which a
> > single capsule file can have multiple payloads(input binaries). This
> > is planned to be supported once support has been added for generating
> > capsules through the config file.
>
> We continue to have challenges getting confused between testing and real world.
>
> For testing, we can do all sorts of things to make things simpler. We
> don't even need an EFI partition, etc. We can have a test which checks
> that U-Boot can decode an update and apply it, The current tests rely
> far too much on an end-to-end, black-box approach, as I might have
> mentioned.

Okay, but I am stating the constraints on using a single combined file
based on the way the tests work today. So if we were to generate a
single file consisting of all the individual capsule files, that would
break the tests. That was my point.

-sughosh