[PATCH v6 9/9] sandbox: capsule: Generate capsule related files through binman

[Simon Glass]

Hi Sughosh,

On Thu, 3 Aug 2023 at 05:18, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
>
> hi Simon,
>
> On Wed, 2 Aug 2023 at 18:23, Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Sughosh,
> >
> > On Tue, 1 Aug 2023 at 11:41, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
> > >
> > > The EFI capsule files can now be generated as part of u-boot
> > > build. This is done through binman. Add capsule entry nodes in the
> > > u-boot.dtsi for the sandbox architecture for generating the
> > > capsules. Remove the corresponding generation of capsules from the
> > > capsule update conftest file.
> > >
> > > The capsules are generated through the config file for the sandbox
> > > variant, and through explicit parameters for the sandbox_flattree
> > > variant.
> > >
> > > Also generate the FIT image used for testing the capsule update
> > > feature on the sandbox_flattree variant through binman. Remove the now
> > > superfluous its file which was used for generating this FIT image.
> > >
> > > Signed-off-by: Sughosh Ganu <sughosh.ganu at linaro.org>
> > > ---
> > > Changes since V5:
> > > * Use the public key ESL file and other input files from the tree
> > >   instead of the /tmp/capsules/ directory being used in previous
> > >   version.
> > > * Use macros for other input files and certs.
> > >
> > >  arch/sandbox/dts/u-boot.dtsi                  | 347 ++++++++++++++++++
> > >  test/py/tests/test_efi_capsule/conftest.py    | 128 +------
> > >  .../tests/test_efi_capsule/uboot_bin_env.its  |  36 --
> > >  3 files changed, 348 insertions(+), 163 deletions(-)
> > >  delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its
> > >
> >
> > I want to get the binman stuff right before diving into this, but the
> > binman stuff seems fairly close, so I'll just mention...do you really
> > need all these combinations of tests? It seems to me that one test is
> > enough. You know that the binman tests will protect the code there, so
> > why test it all over again here?
>
> These are capsules that are needed for testing the EFI capsule update
> functionality. Currently, the capsules used for testing the feature
> are generated after u-boot has been built. Same for embedding the
> public key in the dtb. I think it is better to have the same flow of
> generating capsules and the associated logic(public key embedding)
> that is being supported in u-boot rather than having two divergent
> flows. This also serves as an example for potential users who would
> want to generate capsules as part of the build flow.

But my question was why you need more than one test here? Are you
testing that U-Boot can decode a capsule file of various types? That
should be done in unit tests.

Now I see the tests you are referring to in
test_capsule_firmware_signed_raw.py  (please shorten the name!)

These tests all have the reboot problem we need to fix, but anyway, at
least I understand it.

It looks like you are writing the test files into the source tree?
They should be written to the output tree.

Regards,
Simon