Hi Masami,
On Sun, 13 Mar 2022 at 08:00, Masami Hiramatsu masami.hiramatsu@linaro.org wrote:
Hi Simon and Takahiro,
I also would like to know how the UEFI is tested in the U-Boot. It seems that we have lib/efi_selftest/ but it seems not unified to 'ut' command.
I think it would be good to add it there. There is some init that must be done, but we do try to use 'ut' for all tests.
Should I expand efi_selftest for testing capsule update with reset?
Well I think the update could be triggered by a command, so you can test it without actually doing the reset, at least as a starting point. We need to write the code with testing in mind.
Regards, Simon
Thank you,
2022年3月12日(土) 11:24 Simon Glass sjg@chromium.org:
Hi Takahiro,
On Fri, 18 Feb 2022 at 18:16, AKASHI Takahiro takahiro.akashi@linaro.org wrote:
On Fri, Feb 18, 2022 at 02:48:54PM +0100, Heinrich Schuchardt wrote:
On 2/18/22 03:16, Masami Hiramatsu wrote:
Hi Simon,
Thank you for your reply.
2022年2月18日(金) 2:56 Simon Glass sjg@chromium.org:
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.
Would you mean that reset-after-capsule-on-disk itself should not make a reset on sandbox?
We have several tests that do resets by calling do_reset(), e.g. the UEFI unit tests. There is nothing wrong about it.
We want the sandbox to behave like any other board where capsule updates lead to resets.
In dm_test_sysreset_base(), I can see the below code, this means sysreset_request() will not execute real reset, but just mimic the reset, right?
state->sysreset_allowed[SYSRESET_WARM] = true; ut_asserteq(-EINPROGRESS, sysreset_request(dev, SYSRESET_WARM)); state->sysreset_allowed[SYSRESET_WARM] = false;
> 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.
The sandbox should run through exactly the same code path as all other boards to get a meaningful test results. Therefore don't put in any quirks on C level. Your Python test changes are all that is needed.
+1, I have the same opinion here. To exercise capsule-on-disk code, we need a "real" reset because pytest/CI loop is basically a black-box test.
I don't see why you need the reset at all to test the code. You should be able to run a command to make the update happen. How does the updata actually get triggered when you reset?
[..]
Regards, Simon
-- Masami Hiramatsu