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

[Tom Rini]

On Fri, Feb 18, 2022 at 02:59:05PM +0100, Heinrich Schuchardt wrote:
> On 2/17/22 18:55, 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.
> > 
> > > 
> > > 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.
> 
> Respawning of QEMU instances after a reset is handled by the scripts in
> https://source.denx.de/u-boot/u-boot-test-hooks.git on Gitlab CI. For my
> local tests I have used:
> https://github.com/xypron/u-boot-build/tree/qemu-arm64/u-boot-test
> 
> If you want to set up an environment for a real board, you have to write
> your own python scripts and make them available over PYTHONPATH. For an
> example see
> https://github.com/xypron/u-boot-build/tree/orangepi-pc/u-boot-test

To be clear, Simon also has a number of physical boards in a CI lab.
Perhaps part of the confusion here is that we're thinking of these tests
as something more special than what we have already, but I don't think
that's the case.  It's just shifting the logic around a little bit in
that today we have "build u-boot, flash u-boot, ensure that version is
now running" and this is "build u-boot, update u-boot, ensure that
version is now running".

-- 
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/cb1a2d18/attachment.sig>