[PATCH] test/py: efi_capsule: Handle expected reset after capsule on disk

[Simon Glass]

Hi Masami,

On Sun, 13 Mar 2022 at 08:00, Masami Hiramatsu
<masami.hiramatsu at linaro.org> wrote:
>
> Hi Simon and Takahiro,
>
> I also would like to know how the UEFI is tested in the U-Boot.
> It seems that we have lib/efi_selftest/ but it seems not unified to
> 'ut' command.

I think it would be good to add it there. There is some init that must
be done, but we do try to use 'ut' for all tests.

> Should I expand efi_selftest for testing capsule update with reset?

Well I think the update could be triggered by a command, so you can
test it without actually doing the reset, at least as a starting
point. We need to write the code with testing in mind.

Regards,
Simon


>
> Thank you,
>
> 2022年3月12日(土) 11:24 Simon Glass <sjg at chromium.org>:
> >
> > Hi Takahiro,
> >
> > On Fri, 18 Feb 2022 at 18:16, AKASHI Takahiro
> > <takahiro.akashi at linaro.org> wrote:
> > >
> > > On Fri, Feb 18, 2022 at 02:48:54PM +0100, Heinrich Schuchardt wrote:
> > > > On 2/18/22 03:16, Masami Hiramatsu wrote:
> > > > > Hi Simon,
> > > > >
> > > > > Thank you for your reply.
> > > > >
> > > > > 2022年2月18日(金) 2:56 Simon Glass <sjg at chromium.org>:
> > > > >
> > > > > >
> > > > > > Hi Masami,
> > > > > >
> > > > > > On Wed, 16 Feb 2022 at 18:11, Masami Hiramatsu
> > > > > > <masami.hiramatsu at linaro.org> wrote:
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > Let me confirm your point.
> > > > > > > So are you concerning the 'real' reset for the capsule update test
> > > > > > > case itself or this patch?
> > > > > > >
> > > > > > > I'm actually learning how the test is working, so please help me to
> > > > > > > understand how I can solve it.
> > > > > > >
> > > > > > > There are 3 environments to run the test, sandbox, Qemu, and a real board.
> > > > > > > If we reset a sandbox, it will continue to run (just restart itself),
> > > > > >
> > > > > > Here you should be able to avoid doing a reset. See
> > > > > > dm_test_sysreset_base() which tests sysreset drivers on sandbox.
> > > > >
> > > > > Would you mean that reset-after-capsule-on-disk itself should not
> > > > > make a reset on sandbox?
> > > >
> > > > We have several tests that do resets by calling do_reset(), e.g. the
> > > > UEFI unit tests. There is nothing wrong about it.
> > > >
> > > > We want the sandbox to behave like any other board where capsule updates
> > > > lead to resets.
> > > >
> > > > >
> > > > > In dm_test_sysreset_base(), I can see the below code, this means
> > > > > sysreset_request()
> > > > > will not execute real reset, but just mimic the reset, right?
> > > > >
> > > > > state->sysreset_allowed[SYSRESET_WARM] = true;
> > > > > ut_asserteq(-EINPROGRESS, sysreset_request(dev, SYSRESET_WARM));
> > > > > state->sysreset_allowed[SYSRESET_WARM] = false;
> > > > >
> > > > > > > but Qemu and real board will cause a real reset and it will terminate
> > > > > > > the qemu or stop the board (depends on how it is implemented). Thus,
> > > > > > > if a command or boot process will cause a reset, it will need a
> > > > > > > special care (maybe respawn?).
> > > > > >
> > > > > > Here you need to worry about the surrounding automation logic which
> > > > > > could be tbot of the U-Boot pytest hooks. I suggest you avoid this and
> > > > > > handle it some other way, without reset.
> > > >
> > > > The sandbox should run through exactly the same code path as all other
> > > > boards to get a meaningful test results. Therefore don't put in any
> > > > quirks on C level. Your Python test changes are all that is needed.
> > >
> > > +1, I have the same opinion here.
> > > To exercise capsule-on-disk code, we need a "real" reset
> > > because pytest/CI loop is basically a black-box test.
> >
> > I don't see why you need the reset at all to test the code. You should
> > be able to run a command to make the update happen. How does the
> > updata actually get triggered when you reset?
> >
> > [..]
> >
> > Regards,
> > Simon
>
>
>
> --
> Masami Hiramatsu