Hi Heinrich, On Sun, 27 Feb 2022 at 12:51, Simon Glass <s...@chromium.org> wrote: > > Hi Heinrich, > > On Sun, 27 Feb 2022 at 12:21, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > > > > > > > > Am 27. Februar 2022 20:11:01 MEZ schrieb Simon Glass <s...@chromium.org>: > > >Hi Tom, > > > > > >On Sun, 27 Feb 2022 at 11:14, Tom Rini <tr...@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.g...@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.hirama...@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.hirama...@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