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.hirama...@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
signature.asc
Description: PGP signature
