From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 75277C433F5 for ; Sat, 19 Feb 2022 01:16:07 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id A520683B93; Sat, 19 Feb 2022 02:16:04 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="OhFIvOyX"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 899BB838FC; Sat, 19 Feb 2022 02:16:02 +0100 (CET) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 76F89838FC for ; Sat, 19 Feb 2022 02:15:58 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=takahiro.akashi@linaro.org Received: by mail-pg1-x533.google.com with SMTP id h125so9261982pgc.3 for ; Fri, 18 Feb 2022 17:15:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=N8j0bi6w0jvLiFmccwTQts2MjLJ13h4JfTDfFxRfCg4=; b=OhFIvOyXum8p0t6XM5x9x9HQzFK6sJKJYhx62+Qah+w3pCfbi71JH8TPBhJ3yM7V3J u4kwcmDmrOc2csdiBLSFn7HKhV4n45P9JwMJerg9bkLIEFw3E1boYXufRjClzHagsmxs Lo5qvnDT7QRxM++9awV44NEBmSnSupjTxiF6FBUzZzQCaVyrbo8dbZm4L+eVc5UNLXob +FC540ARNDt6J9P9EKBMAMPmo7UuNT0b6H+2F7Xt/CHvkpCt8qMQubn4dV6nnpwCDoZL VxqMGZbLAv1Dq5RKI3rTUDIbJJRqW83lLH0X4I/hYCCRBaN3muLvXEuhk8W8AaiMl1eF 3MOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=N8j0bi6w0jvLiFmccwTQts2MjLJ13h4JfTDfFxRfCg4=; b=7WlPe5oW0EcEZSRvCpL+Q1V0vDj/QMfCKrrD2Gn+yVc1ZHxC47yrTdr9sT7eZWamGl Kx3FQqqwDFQdO6oOTpSZ03k4L1Gxm6/T4zyjp0k6mlbqIO5o665uv3hMsqG1yRYevSKP U9Wa991Jl8BWybvYEyTpr3tb/mY1gTejJE0uP8CHsopIygGqX26aT+E8L4/8iyt7Nn+e OuaXl/3csZnEhFaxCQFsC78GpILgucMq6PmvyvspwxyArzlmgfefWuCyzcw/g3jqayUJ xCeF4jyiswIx7yYi8Cv7YvNbHnAN8YZEAoJsUxJ4x6ILn6GqYkTb26jSauZDR/84730e /6Sw== X-Gm-Message-State: AOAM532MSLa9nIQ81ndeyPmOLH8CT+uzA0uqN+2CRE5E75BLSXl/0Ueg I9ikbyfw15fzIjgSjHVvGOBZIQ== X-Google-Smtp-Source: ABdhPJzldgq/dNUbRzrbcB+fRiOTDorPe8tZ+Az2ky1ApYsJ+vhYcOQjxaiNn9FVpVuZCX9Uzjd9Ew== X-Received: by 2002:a63:da44:0:b0:362:c3f6:973e with SMTP id l4-20020a63da44000000b00362c3f6973emr8463737pgj.236.1645233356572; Fri, 18 Feb 2022 17:15:56 -0800 (PST) Received: from laputa ([2400:4050:c3e1:100:ac97:9e25:a038:e389]) by smtp.gmail.com with ESMTPSA id w11sm515281pfu.19.2022.02.18.17.15.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Feb 2022 17:15:56 -0800 (PST) Date: Sat, 19 Feb 2022 10:15:50 +0900 From: AKASHI Takahiro To: Heinrich Schuchardt Cc: Masami Hiramatsu , Tom Rini , U-Boot Mailing List , Patrick Delaunay , Patrice Chotard , Alexander Graf , Bin Meng , Ilias Apalodimas , Jose Marinho , Grant Likely , Etienne Carriere , Sughosh Ganu , Paul Liu , Simon Glass Subject: Re: [PATCH] test/py: efi_capsule: Handle expected reset after capsule on disk Message-ID: <20220219011550.GB6672@laputa> Mail-Followup-To: AKASHI Takahiro , Heinrich Schuchardt , Masami Hiramatsu , Tom Rini , U-Boot Mailing List , Patrick Delaunay , Patrice Chotard , Alexander Graf , Bin Meng , Ilias Apalodimas , Jose Marinho , Grant Likely , Etienne Carriere , Sughosh Ganu , Paul Liu , Simon Glass References: <164491595065.536855.9457820061065514578.stgit@localhost> <20220216154642.GA1576803@bill-the-cat> <4ba143f8-6114-db0e-08e2-d97ac9dc6e13@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean 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 : > > > > > > > > Hi Masami, > > > > > > On Wed, 16 Feb 2022 at 18:11, Masami Hiramatsu > > > 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. -Takahiro Akashi > > Best regards > > Heinrich > > > > > Hmm, would you mean adding a runtime flag to sandbox so that > > it will not does real reset but just showing some token on console like > > "sandbox fake reset done." ? > > > > > > > > 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. > > > > > > Indeed. > > > > > > > > > > > If so, I think there are 2 issues to be solved. > > > > 1. change the capsule update testcase runable on Qemu > > > > 2. change my patch to handle the real reset correctly (not only > > > > waiting for the next boot, but also respawn it again) > > > > > > > > Do I understand correctly? > > > > > > I think the best approach is to get your test running on sandbox, with > > > the faked reset. Don't worry about the other cases as we don't support > > > them. > > > > OK. > > > > Thank you, > > > > > > > > Regards, > > > Simon > > > > > > > > > > > > > > Thank you, > > > > > > > > 2022年2月17日(木) 2:53 Simon Glass : > > > > > > > > > > Hi Heinrich, > > > > > > > > > > On Wed, 16 Feb 2022 at 10:50, Heinrich Schuchardt wrote: > > > > > > > > > > > > On 2/16/22 16:46, Tom Rini wrote: > > > > > > > On Wed, Feb 16, 2022 at 04:32:40PM +0100, Heinrich Schuchardt wrote: > > > > > > > > On 2/16/22 16:26, Simon Glass wrote: > > > > > > > > > Hi Masami, > > > > > > > > > > > > > > > > > > On Tue, 15 Feb 2022 at 02:05, Masami Hiramatsu > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Since now the capsule_on_disk will restart the u-boot sandbox right > > > > > > > > > > after the capsule update, if CONFIG_EFI_CAPSULE_ON_DISK_EARLY=y, the > > > > > > > > > > boot with a new capsule file will repeat reboot sequence. On the > > > > > > > > > > other hand, if CONFIG_EFI_CAPSULE_ON_DISK_EARLY=n, the 'env print -e' > > > > > > > > > > command will execute the capsule update on disk and reboot. > > > > > > > > > > > > > > > > > > > > Thus this update the uboot_console for those 2 cases; > > > > > > > > > > > > > > > > > > > > - restart_uboot(): Add expect_earlyreset optional parameter so that > > > > > > > > > > it can handle the reboot while booting. > > > > > > > > > > - run_command(): Add wait_for_reboot optional parameter so that it > > > > > > > > > > can handle the reboot after executing a command. > > > > > > > > > > > > > > > > > > > > And enable those options in the test_capsule_firmware.py test cases. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Masami Hiramatsu > > > > > > > > > > --- > > > > > > > > > > .../test_efi_capsule/test_capsule_firmware.py | 39 ++++++-- > > > > > > > > > > test/py/u_boot_console_base.py | 95 +++++++++++++++----- > > > > > > > > > > test/py/u_boot_console_sandbox.py | 6 + > > > > > > > > > > 3 files changed, 102 insertions(+), 38 deletions(-) > > > > > > > > > > > > > > > > > > We have a means to avoid actually doing the reset, see the reset driver. > > > > > > > > > > > > > > > > The UEFI specification requires a cold reset after a capsule is updated > > > > > > > > and before the console is reached. How could the reset driver help to > > > > > > > > fix the Python tests? > > > > > > > > > > > > > > Is this test going to be able to run on qemu, sandbox, real hardware, or > > > > > > > all 3? The tests may well end up having to know a bit more, sadly, > > > > > > > about the type of system they're testing. > > > > > > > > > > > > > Currently the test will only run on the sandbox in Gitlab (see usage of > > > > > > @pytest.mark.boardspec('sandbox') in test/py/tests/test_efi_capsule/). > > > > > > > > > > Let me know if you need help reworking this patch to operate on > > > > > sandbox without a 'real' reset. > > > > > > > > > > Regards, > > > > > Simon > > > > > > > > > > > > > > > > -- > > > > Masami Hiramatsu > > > > > > > > -- > > Masami Hiramatsu >