[PATCH 3/5] binman: capsule: Use dumped capsule header contents for verification

Simon Glass sjg at chromium.org
Tue Oct 10 17:14:55 CEST 2023


Hi Sughosh,

On Tue, 10 Oct 2023 at 09:01, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
>
> hi Simon,
>
> On Tue, 10 Oct 2023 at 20:27, Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Sughosh,
> >
> > On Mon, 9 Oct 2023 at 13:41, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
> > >
> > > hi Simon,
> > >
> > > On Mon, 9 Oct 2023 at 23:27, Simon Glass <sjg at chromium.org> wrote:
> > > >
> > > > Hi Sughosh,
> > > >
> > > > On Mon, 9 Oct 2023 at 01:46, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
> > > > >
> > > > > hi Simon,
> > > > >
> > > > > On Sun, 8 Oct 2023 at 04:41, Simon Glass <sjg at chromium.org> wrote:
> > > > > >
> > > > > > Hi Sughosh,
> > > > > >
> > > > > > On Wed, 4 Oct 2023 at 05:27, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
> > > > > > >
> > > > > > > The various fields of a generated capsule are currently verified
> > > > > > > through hard-coded offsets. Use the dump-capsule feature for dumping
> > > > > > > the capsule header contents and use those for capsule verification.
> > > > > > >
> > > > > > > Signed-off-by: Sughosh Ganu <sughosh.ganu at linaro.org>
> > > > > > > ---
> > > > > > >  tools/binman/ftest.py | 95 ++++++++++++++++++++++++-------------------
> > > > > > >  1 file changed, 54 insertions(+), 41 deletions(-)
> > > > > >
> > > > > > This looks good apart from a few nits below. However, the tests fail for me.
> > > > >
> > > > > Can you please specify which tests fail, and the way to reproduce the
> > > > > failures? I ran the tests before sending the patches, and they ran
> > > > > fine, including the coverage which is 100%. Ci too did not complain.
> > > >
> > > > Sure, for example:
> > > >
> > > > $ binman test testCapsuleGen
> > > > ======================== Running binman tests ========================
> > > > /usr/lib/python3.10/os.py:1030: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used
> > > >   return io.open(fd, mode, buffering, encoding, *args, **kwargs)
> > > > /usr/lib/python3.10/os.py:1030: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used
> > > >   return io.open(fd, mode, buffering, encoding, *args, **kwargs)
> > > > F
> > > > ======================================================================
> > > > FAIL: binman.ftest.TestFunctional.testCapsuleGen (subunit.RemotedTestCase)
> > > > binman.ftest.TestFunctional.testCapsuleGen
> > > > ----------------------------------------------------------------------
> > > > testtools.testresult.real._StringException: Traceback (most recent call last):
> > > > AssertionError: '6DCBD5ED-E82D-4C44-BDA1-7194199AD92A' != []
> > > >
> > > >
> > > > ----------------------------------------------------------------------
> > > > Ran 1 test in 0.147s
> > > >
> > > > FAILED (failures=1)
> > >
> > > That is interesting. When I run the tests, they run just fine. I had
> > > tested them before sending the patches. For e.g.
> > >
> > > ./tools/binman/binman test testCapsuleGen
> > > ======================== Running binman tests ========================
> > > .
> > > ----------------------------------------------------------------------
> > > Ran 1 test in 0.375s
> > >
> > > OK
> >
> > Yes, I'm not sure what that is. Perhaps you have a required tool in your path? But in that case I would expect to get some sort of error.
>
> I don't have any special tool in my path. Just that I build tools
> before invoking the tests, since the mkeficapsule tool needs to have
> been present. Moreover, the tests are also passing in the CI run. So
> it seems to be something specific in your setup I guess.
>

Yes, I suppose so...I'll try the new version and try to figure it out.

Regards,
Simon


More information about the U-Boot mailing list