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.hiramatsu@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".