[PATCH v4 12/12] sandbox: capsule: Generate capsule related files through binman
Sughosh Ganu
sughosh.ganu at linaro.org
Wed Jul 19 10:57:55 CEST 2023
hi Simon,
On Wed, 19 Jul 2023 at 06:41, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Sughosh,
>
> On Mon, 17 Jul 2023 at 05:18, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
> >
> > hi Simon,
> >
> > On Sun, 16 Jul 2023 at 05:12, Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Hi Sughosh,
> > >
> > > On Sat, 15 Jul 2023 at 07:46, 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 V3:
> > > > * Use blob nodes instead of incbin for including the binaries in FIT
> > > > image.
> > > > * Enable generation of capsules with versioning support.
> > > >
> > > > arch/sandbox/dts/u-boot.dtsi | 265 ++++++++++++++++++
> > > > test/py/tests/test_efi_capsule/conftest.py | 127 ---------
> > > > .../tests/test_efi_capsule/uboot_bin_env.its | 36 ---
> > > > 3 files changed, 265 insertions(+), 163 deletions(-)
> > > > delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its
> > > >
> > > > diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
> > > > index 60bd004937..7b0250ac81 100644
> > > > --- a/arch/sandbox/dts/u-boot.dtsi
> > > > +++ b/arch/sandbox/dts/u-boot.dtsi
> > > > @@ -13,5 +13,270 @@
> > > > capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> > > > };
> > > > #endif
> > > > +
> > > > + binman: binman {
> > > > + multiple-images;
> > > > + };
> > > > +};
> > > > +
> > > > +&binman {
> > > > + itb {
> > > > + filename = "/tmp/capsules/uboot_bin_env.itb";
> > > > +
> > > > + fit {
> > > > + description = "Automatic U-Boot environment update";
> > > > + #address-cells = <2>;
> > > > +
> > > > + images {
> > > > + u-boot-bin {
> > > > + description = "U-Boot binary on SPI Flash";
> > > > + compression = "none";
> > > > + type = "firmware";
> > > > + arch = "sandbox";
> > > > + load = <0>;
> > > > + blob {
> > > > + filename = "/tmp/capsules/u-boot.bin.new";
> > > > + };
> > > > +
> > > > + hash-1 {
> > > > + algo = "sha1";
> > > > + };
> > > > + };
> > > > + u-boot-env {
> > > > + description = "U-Boot environment on SPI Flash";
> > > > + compression = "none";
> > > > + type = "firmware";
> > > > + arch = "sandbox";
> > > > + load = <0>;
> > > > + blob {
> > > > + filename = "/tmp/capsules/u-boot.env.new";
> > > > + };
> > > > +
> > > > + hash-1 {
> > > > + algo = "sha1";
> > > > + };
> > > > + };
> > > > + };
> > > > + };
> > > > + };
> > > > +
> > > > +#ifdef CONFIG_EFI_USE_CAPSULE_CFG_FILE
> > > > + capsule1 {
> > > > + capsule {
> > > > + cfg-file = CONFIG_EFI_CAPSULE_CFG_FILE;
> > > > + };
> > > > + };
> > > > +#else
> > > > + capsule2 {
> > > > + capsule {
> > > > + image-index = <0x1>;
> > > > + image-type-id = "09D7CF52-0720-4710-91D1-08469B7FE9C8";
> > >
> > > We seem to have a persistent problem with these appearing in the source code.
> > >
> > > Perhaps you could add them to a header file and use
> > > GUID_MEANINGFUL_NAME here instead (also below).
> > >
> > > In general, GUIDs should not be open-coded.
> >
> > Okay. Will it be okay if I add these to a sandbox_capule.h. Earlier, I
> > had similar GUID macros in the sandbox config header, and you had
> > asked me to move them to the board file.
>
> These are littered all over the place. Perhaps a new 'efi_guid.h'
Okay, I will add these under the efi_guid.h file.
> header file that has all of them? We should also make sure they are in
> lib/uuid.c so they can be printed out.
Please note that these are GUID strings being used here in the
generation of the capsule. What you refer to in lib/uuid.c are the
actual variables of type efi_guid_t.
>
> >
> > >
> > >
> > > > + filename = "/tmp/capsules/u-boot.bin.new";
> > > > + capsule = "/tmp/capsules/Test01";
> > >
> > > There is something odd here. You should not need to specify an
> > > absolute pathname and should not use /tmp
> >
> > The /tmp/capsules/ directory is being used for collating all the
> > capsule testing related files. Both the input files as well as the
> > output capsule files are being put under this directory. Do you see
> > any issue with using this directory for the capsule files?
>
> Yes, the binman tests need to run in the input and output directories
> provided, like all the other tests do. People need to be able to
> inspect those dirs to see what happened.
>
> Please also check test failures:
>
> testtools.testresult.real._StringException: Traceback (most recent call last):
> File "/scratch/sglass/cosarm/src/third_party/u-boot/files/tools/binman/ftest.py",
> line 7012, in testCapsuleGenCapsuleFileMissing
> self.assertIn("Specify the output capsule file",
> File "/usr/lib/python3.10/unittest/case.py", line 1112, in assertIn
> self.fail(self._formatMessage(msg, standardMsg))
> File "/usr/lib/python3.10/unittest/case.py", line 675, in fail
> raise self.failureException(msg)
> AssertionError: 'Specify the output capsule file' not found in
> "Filename 'payload.txt' not found in input path
> (/tmp/binmant.yjusbvaz)
> (cwd='/scratch/sglass/cosarm/src/third_party/u-boot/files')"
>
>
> ======================================================================
> FAIL: binman.ftest.TestFunctional.testCapsuleGenCfgFile
> (subunit.RemotedTestCase)
> binman.ftest.TestFunctional.testCapsuleGenCfgFile
> ----------------------------------------------------------------------
> testtools.testresult.real._StringException: Traceback (most recent call last):
> File "/scratch/sglass/cosarm/src/third_party/u-boot/files/tools/binman/ftest.py",
> line 6958, in testCapsuleGenCfgFile
> self.assertTrue(os.path.exists(self.capsule_fname))
> File "/usr/lib/python3.10/unittest/case.py", line 687, in assertTrue
> raise self.failureException(msg)
> AssertionError: False is not true
I had run my patches through CI before submission, so they work fine
in the CI setup. I believe this could be because of non-existence of
the input files under the /tmp/capsules/ directory. And like I
mentioned in my other reply, this issue would just be with the
testCapsuleGenCfgFile function. The rest of the tests do use the input
and output directories that binman creates for testing.
-sughosh
>
>
> ----------------------------------------------------------------------
> Ran 522 tests in 1.881s
>
>
> Regards,
> Simon
More information about the U-Boot
mailing list