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

[Tom Rini]

On Thu, Feb 17, 2022 at 10:55:58AM -0700, Simon Glass wrote:
> 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.
> 
> > 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.

Well, tbot and uboot-test-hooks implement the abstractions we have for
things like "reset the target".

> > Since the capsule update testcase only runs on sandbox, it will not
> > cause real reset. But maybe it is possible to support running on Qemu.
> 
> Maybe, but I don't think you should worry about that, at least for
> now. The sandbox test is enough.
> 
> >
> > Current my test patch (and capsule update testcase itself) doesn't
> > handle the real reset case correctly even on Qemu. The Qemu needs
> > spawn a new instance and re-connect the console when the reset
> > happens.
> 
> Indeed.
> 
> >
> > If so, I think there are 2 issues to be solved.
> > 1. change the capsule update testcase runable on Qemu
> > 2. change my patch to handle the real reset correctly (not only
> > waiting for the next boot, but also respawn it again)
> >
> > Do I understand correctly?
> 
> I think the best approach is to get your test running on sandbox, with
> the faked reset. Don't worry about the other cases as we don't support
> them.

I don't think we need to test qemu/real hardware to start with.  I think
we should be testing real hardware in the near future however.  Flash
this U-Boot and confirm it's running is the point of the "version" test.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220218/fb47e6bb/attachment.sig>