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

[Tom Rini]

On Wed, Feb 16, 2022 at 06:45:32PM +0100, Heinrich Schuchardt wrote:
> On 2/16/22 16:46, Tom Rini wrote:
> > On Wed, Feb 16, 2022 at 04:32:40PM +0100, Heinrich Schuchardt wrote:
> > > On 2/16/22 16:26, Simon Glass wrote:
> > > > Hi Masami,
> > > > 
> > > > On Tue, 15 Feb 2022 at 02:05, Masami Hiramatsu
> > > > <masami.hiramatsu at linaro.org> wrote:
> > > > > 
> > > > > Since now the capsule_on_disk will restart the u-boot sandbox right
> > > > > after the capsule update, if CONFIG_EFI_CAPSULE_ON_DISK_EARLY=y, the
> > > > > boot with a new capsule file will repeat reboot sequence. On the
> > > > > other hand, if CONFIG_EFI_CAPSULE_ON_DISK_EARLY=n, the 'env print -e'
> > > > > command will execute the capsule update on disk and reboot.
> > > > > 
> > > > > Thus this update the uboot_console for those 2 cases;
> > > > > 
> > > > >    - restart_uboot(): Add expect_earlyreset optional parameter so that
> > > > >      it can handle the reboot while booting.
> > > > >    - run_command(): Add wait_for_reboot optional parameter so that it
> > > > >      can handle the reboot after executing a command.
> > > > > 
> > > > > And enable those options in the test_capsule_firmware.py test cases.
> > > > > 
> > > > > Signed-off-by: Masami Hiramatsu <masami.hiramatsu at linaro.org>
> > > > > ---
> > > > >    .../test_efi_capsule/test_capsule_firmware.py      |   39 ++++++--
> > > > >    test/py/u_boot_console_base.py                     |   95 +++++++++++++++-----
> > > > >    test/py/u_boot_console_sandbox.py                  |    6 +
> > > > >    3 files changed, 102 insertions(+), 38 deletions(-)
> > > > 
> > > > We have a means to avoid actually doing the reset, see the reset driver.
> > > 
> > > The UEFI specification requires a cold reset after a capsule is updated
> > > and before the console is reached. How could the reset driver help to
> > > fix the Python tests?
> > 
> > Is this test going to be able to run on qemu, sandbox, real hardware, or
> > all 3?  The tests may well end up having to know a bit more, sadly,
> > about the type of system they're testing.
> 
> Currently the test will only run on the sandbox in Gitlab (see usage of
> @pytest.mark.boardspec('sandbox') in test/py/tests/test_efi_capsule/).

OK, I'll leave sandbox commentary to Simon.

> You will not want to update the firmware on real hardware especially if
> there is a rollback protection. But testing on QEMU would make sense.

On QEMU we should be able to since we can turn boards off and on and
would be writing to our emulated flash.  Then on real hardware, we
should be able to do the same tests, or at least the ones involving
"update was successful" ?  We have DFU tests today too, so I'm not
immediately sure why we couldn't (aside from possibly wearing down flash
life, and gating HW tests on emulator tests passing is always a good
idea).

-- 
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/20220216/312c201b/attachment.sig>