[PATCH v5 3/4] test/py: Handle expected reboot while booting sandbox

[Simon Glass]

Hi Heinrich,

On Sun, 27 Feb 2022 at 12:21, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
>
>
> Am 27. Februar 2022 20:11:01 MEZ schrieb Simon Glass <sjg at chromium.org>:
> >Hi Tom,
> >
> >On Sun, 27 Feb 2022 at 11:14, Tom Rini <trini at konsulko.com> wrote:
> >>
> >> On Sun, Feb 27, 2022 at 08:39:30AM -0700, Simon Glass wrote:
> >> > Hi Heinrich,
> >> >
> >> > On Sun, 27 Feb 2022 at 01:22, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >> > >
> >> > > On 2/26/22 19:37, Simon Glass wrote:
> >> > > > Hi Masami,
> >> > > >
> >> > > > On Tue, 15 Feb 2022 at 23:16, Masami Hiramatsu
> >> > > > <masami.hiramatsu at linaro.org> wrote:
> >> > > >>
> >> > > >> Add expected_reset optional argument to ConsoleBase::ensure_spawned(),
> >> > > >> ConsoleBase::restart_uboot() and ConsoleSandbox::restart_uboot_with_flags()
> >> > > >> so that it can handle a reset while the 1st boot process after main
> >> > > >> boot logo before prompt correctly.
> >> > > >>
> >> > > >> Signed-off-by: Masami Hiramatsu <masami.hiramatsu at linaro.org>
> >> > > >> ---
> >> > > >>   Changes in v5:
> >> > > >>    - Rename parameter to expect_reset and update the description to clarify
> >> > > >>      the reset will happen between main boot and the command prompt.
> >> > > >> ---
> >> > > >>   test/py/u_boot_console_base.py    |   48 ++++++++++++++++++++++---------------
> >> > > >>   test/py/u_boot_console_sandbox.py |    7 ++++-
> >> > > >>   2 files changed, 33 insertions(+), 22 deletions(-)
> >> > > >>
> >> > > >
> >> > > > Didn't I already comment on this patch? Why did it come back?
> >> > >
> >> > > Dear Simon,
> >> > >
> >> > > The discussion is in
> >> > > https://patchwork.ozlabs.org/project/uboot/patch/164491595065.536855.9457820061065514578.stgit@localhost/
> >> > >
> >> > > You suggested: "We have a means to avoid actually doing the reset, see
> >> > > the reset driver."
> >> > >
> >> > > We need a real reset on the sandbox and no fake reset as already said in
> >> > > the referenced thread.
> >> >
> >> > Why?
> >> >
> >> > The fake reset is there for use by tests. We don't need this load of
> >> > Python code at all for sandbox. We should worry about it later.
> >>
> >> Well, isn't this going to make the tests more sandbox-centric then, and
> >> then need changes later to be able to test on real hardware?
> >
> >Yes, but it keeps the sandbox case simple. At present the sandbox
> >tests can run within U-Boot (see the 'ut' command) and I very much
> >want to keep it that way. That is, after all, why I wrote the reset
> >driver.
> >
> >While tests on real hardware have value, I hope that all logic bugs
> >are found on sandbox.
>
> How does this relate to your thoughts about this patch?
>
> The patch enables testing capsule updates including resets. This does not stop running the tests on the sandbox.
>
> Why do you suggest sandbox specific quirks in capsule updates?

sandbox-specific but in any case I find the tone of that statement
offensive and misleading. I have asked you before to avoid this sort
of thing on the mailing list. Sandbox is what we use for unit tests.

How is the test run at present on sandbox? My understanding is that
you want sandbox to rely on the pytest framework to work...do I have
that wrong?

Regards,
Simon