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

[Tom Rini]

On Mon, Aug 14, 2023 at 04:51:13PM -0600, Simon Glass wrote:
> Hi Sughosh,
> 
> On Mon, 14 Aug 2023 at 02:17, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
> >
> > 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.
> 
> Sure...my point is that the tests could use a bit of rework to make
> them easier and faster to run.

We also need to test them how they're functionally used. At some level
I'd be "fine" if we had "test individual parts of the framework" tests
in sandbox and "test as they're used" tests in QEMU.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230815/f7d2dd5d/attachment.sig>