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

[Simon Glass]

Hi Heinrich,

On Sun, 27 Feb 2022 at 12:51, Simon Glass <sjg at chromium.org> wrote:
>
> 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?

Also I'd really appreciate it if you could review Takahiro's series
and help get it landed. It has been languishing for ages.

Regards,
Simon