[PATCH v4 12/12] sandbox: capsule: Generate capsule related files through binman
Simon Glass
sjg at chromium.org
Wed Jul 19 03:08:24 CEST 2023
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'
header file that has all of them? We should also make sure they are in
lib/uuid.c so they can be printed out.
>
> >
> >
> > > + 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
----------------------------------------------------------------------
Ran 522 tests in 1.881s
Regards,
Simon
More information about the U-Boot
mailing list