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 3EEA8C2BA4C for ; Wed, 26 Jan 2022 07:20:43 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 2B6328312A; Wed, 26 Jan 2022 08:20:40 +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="Q+frqaY4"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 984C4830F4; Wed, 26 Jan 2022 08:20:38 +0100 (CET) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 697F283325 for ; Wed, 26 Jan 2022 08:20:35 +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-pf1-x42a.google.com with SMTP id v74so18689873pfc.1 for ; Tue, 25 Jan 2022 23:20:35 -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=8r9tD09CuZ8uitnZ6cKZPE/V2qq01SnDxUsymWaYGEQ=; b=Q+frqaY4Dd/tP5iBlCek3KKrjDgbikSP9qOqq43sJCvjcmwJBoIF2JB8Ibfm4b8abI nFUbL7CPfvM/ahkySYw5MRPU8ImbP76YeY+SPXOQw/DwEp+Hw3KyoY/UEi076O7jSom+ q3HLJyLbDbKoMuib6OCMPDLvlRBf6Ivbl3wlf27xO5xI3WNvt0wZ0O34RpSTQX71796W 4ZN7iOdH0fVmcGO0NPJeoLFYOZ2g0mYAzeIUAJg27qyq0WHJ/DVBBzMI4wZyvFNXUQ77 ZAr7zOFhdRISkn0RPAsHrYxiBpNvy4YnW/Hc0ndQXfzlTT8b3+Lpo+XNP9k2lZbmafgW JtCA== 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=8r9tD09CuZ8uitnZ6cKZPE/V2qq01SnDxUsymWaYGEQ=; b=youzDkrHFyYTErWeEdiPOQbbbKzgpPC6GjeUpTt+hYdNToUCFBH7UN0VKK7GLPpRjO g3gtHzP08duXCDPmFznJobJBJEBQWsGVi4qzJCrCOGr+MxXCsGnodzBR5jWPkW+9VaUR oDgwy0zD0MUZ0Npl7HkyuRRB6SXWi6+kqkM4/l4phk9yV6boLcPrlminq8WZ0LxTF3uk ODxcTBlymTami56rMp9SF8QXjZrm+gLhGQElvVbM8a5OVwc0+pI4/IyZcgFG5zqMz9BD NRIuyydDSszw9yLvYKFVeNEDadTPnrAYeEHz/ILAl1qmXvx+OkoUgSqOqKaWUCr6k7ZR p5Dg== X-Gm-Message-State: AOAM531DMekZZwpaQcbWecBJEy61XSLPrBXVrGHvcTmRBA55mZvpEJFH xBLu5YiVmr5I5/dkfY8TDMAeiA== X-Google-Smtp-Source: ABdhPJwFyaNEe4HdtY1zS4WdbizfJDI9jOgFamVcg0kowRgPh0wcjX3GlX9D2IeaVrW/O5ACIvzUFQ== X-Received: by 2002:a63:210d:: with SMTP id h13mr15783555pgh.340.1643181633430; Tue, 25 Jan 2022 23:20:33 -0800 (PST) Received: from laputa ([2400:4050:c3e1:100:a0fa:7b7d:de19:cfca]) by smtp.gmail.com with ESMTPSA id b21sm15679597pgi.51.2022.01.25.23.20.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Jan 2022 23:20:33 -0800 (PST) Date: Wed, 26 Jan 2022 16:20:27 +0900 From: AKASHI Takahiro To: Masami Hiramatsu Cc: u-boot@lists.denx.de, Patrick Delaunay , Patrice Chotard , Heinrich Schuchardt , Alexander Graf , Simon Glass , Bin Meng , Ilias Apalodimas , Jose Marinho , Grant Likely , Tom Rini , Etienne Carriere , Sughosh Ganu , Paul Liu Subject: Re: [PATCH 1/2] EFI: Support CAPSULE_FLAGS_INITIATE_RESET for capsule update Message-ID: <20220126072027.GA56161@laputa> Mail-Followup-To: AKASHI Takahiro , Masami Hiramatsu , u-boot@lists.denx.de, Patrick Delaunay , Patrice Chotard , Heinrich Schuchardt , Alexander Graf , Simon Glass , Bin Meng , Ilias Apalodimas , Jose Marinho , Grant Likely , Tom Rini , Etienne Carriere , Sughosh Ganu , Paul Liu References: <164311027891.175897.14232281505893559986.stgit@localhost> <164311028928.175897.11020560607087529330.stgit@localhost> <20220125124921.GA56019@laputa> 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 Wed, Jan 26, 2022 at 11:29:10AM +0900, Masami Hiramatsu wrote: > BTW, the original code comes from EDK2 implementation. What do you mean by "original code"? > It seems that this INITIATE_RESET flag meaning in EDK2 is a bit different > from what we thought here. Yeah, > The flag is only used for resetting system via > UpdateCapsule() EFI call. The capsule update process itself will be done > at the boot time and warm reset soon after that. EDK2's UpdateCapsule() seems to - immediately process *all* the capsules with !PERSIST_ACROSS_RESET - Set "CapsuleUpdateData" variable with a physical address of capsule data - If some of capsules have INITIATE_RESET, kick in warm restart After restart, - process the rest of capsules with PERSIST_ACROSS_RESET using "CapsuleUpdateData" (?) > (See HandleCapsules()@ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c) > > Is it OK to change the INITIATE_RESET flag means? or should we forcibly > reset the system if we succeeded to update capsule on boot time? > (note that capsule on disk must be done at boot time in U-Boot) Obviously, we are trying to use the flag in a different way; initiating a reset *after* processing a capsule. While I think that the text in the specification is still ambiguous, we should not give the flag a different meaning. In 8.5.5 "Delivery of Capsules via file on Mass Storage device", In all cases that a capsule is identified for processing the system is restarted after capsule processing is completed. So a reset in case of capsule-on-disk seems mandatory. (Personally, I don't like the system to enforce a reset.) The discussion above also indicates that the current efi_launch_capsules() must be reworked so not to use efi_update_capsule() which is to honor the flags in a capsule header. -Takahiro Akashi > Thank you, > > 2022年1月26日(水) 7:31 Masami Hiramatsu : > > > > Hi Takahiro, > > > > 2022年1月25日(火) 21:49 AKASHI Takahiro : > > > > > > Hi Masami, > > > > > > Thank you for this enhancement. > > > > > > On Tue, Jan 25, 2022 at 08:31:29PM +0900, Masami Hiramatsu wrote: > > > > Support CAPSULE_FLAGS_INITIATE_RESET for rebooting uboot soon after > > > > updating firmware. Note that the machine will reboot soon after > > > > applying the capsule file which has CAPSULE_FLAGS_INITIATE_RESET > > > > flag. If there are multiple capsules and one has this flag, the > > > > machine may reboot while scanning the capsule files. > > > > You can control when the machine reboot by renaming the capsule > > > > file because the capsule files will be applied alphabetically. > > > > > > > > Signed-off-by: Masami Hiramatsu > > > > --- > > > > lib/efi_loader/efi_capsule.c | 13 +++++++++++++ > > > > 1 file changed, 13 insertions(+) > > > > > > > > diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c > > > > index 4463ae00fd..24a2a026a9 100644 > > > > --- a/lib/efi_loader/efi_capsule.c > > > > +++ b/lib/efi_loader/efi_capsule.c > > > > @@ -407,12 +407,20 @@ static efi_status_t efi_capsule_update_firmware( > > > > struct efi_firmware_management_protocol *fmp; > > > > u16 *abort_reason; > > > > efi_status_t ret = EFI_SUCCESS; > > > > + bool reset = false; > > > > > > > > /* sanity check */ > > > > if (capsule_data->header_size < sizeof(*capsule) || > > > > capsule_data->header_size >= capsule_data->capsule_image_size) > > > > return EFI_INVALID_PARAMETER; > > > > > > > > + if (capsule_data->flags & CAPSULE_FLAGS_INITIATE_RESET) { > > > > + /* INITIATE_RESET flag requires PERSIST_ACROSS_RESET flag */ > > > > + if (!(capsule_data->flags & CAPSULE_FLAGS_PERSIST_ACROSS_RESET)) > > > > + return EFI_INVALID_PARAMETER; > > > > + reset = true; > > > > + } > > > > + > > > > capsule = (void *)capsule_data + capsule_data->header_size; > > > > capsule_size = capsule_data->capsule_image_size > > > > - capsule_data->header_size; > > > > @@ -498,6 +506,11 @@ static efi_status_t efi_capsule_update_firmware( > > > > out: > > > > efi_free_pool(handles); > > > > > > > > + if (ret == EFI_SUCCESS && reset) { > > > > + log_debug("This capsule has CAPSULE_FLAGS_INITIATE_RESET. Reboot machine.\n"); > > > > + do_reset(NULL, 0, 0, NULL); > > > > > > I don't think this is the right place of calling do_reset(). > > > Whenever you have processed any capsule file, you have to > > > - delete the capsule file, > > > - create/update "CapsuleXXXX" and "CapsuleLast" variables, and > > > - modify ESRT table > > > before initiating a reset. > > > > Oops, indeed. Let me update the patch. > > Thank you! > > > > > > > > -Takahiro Akashi > > > > > > > + } > > > > + > > > > return ret; > > > > } > > > > #else > > > > > > > > > > > > -- > > Masami Hiramatsu > > > > -- > Masami Hiramatsu