From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Cc: u-boot@lists.denx.de,
Patrick Delaunay <patrick.delaunay@foss.st.com>,
Patrice Chotard <patrice.chotard@foss.st.com>,
Heinrich Schuchardt <xypron.glpk@gmx.de>,
Alexander Graf <agraf@csgraf.de>, Simon Glass <sjg@chromium.org>,
Bin Meng <bmeng.cn@gmail.com>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Jose Marinho <jose.marinho@arm.com>,
Grant Likely <grant.likely@arm.com>,
Tom Rini <trini@konsulko.com>,
Etienne Carriere <etienne.carriere@linaro.org>,
Sughosh Ganu <sughosh.ganu@linaro.org>,
Paul Liu <paul.liu@linaro.org>
Subject: Re: [PATCH v2 2/2] efi_loader: Reset system after CapsuleUpdate on disk
Date: Thu, 3 Feb 2022 10:24:40 +0900 [thread overview]
Message-ID: <20220203012440.GA46235@laputa> (raw)
In-Reply-To: <164381008301.420956.13884226784193349269.stgit@localhost>
On Wed, Feb 02, 2022 at 10:54:43PM +0900, Masami Hiramatsu wrote:
> Add a config option to reset system soon after processing capsule update
> on disk.
We no longer have a new config option :)
> This is required in UEFI specification 2.9 Section 8.5.5
> "Delivery of Capsules via file on Mass Storage device" as;
>
> In all cases that a capsule is identified for processing the system is
> restarted after capsule processing is completed.
>
> This also reports the result of each capsule update so that the user can
> notice that the capsule update has been succeeded or not from console log.
>
> Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
> ---
> Changes in v3:
> - Log succeeded capsule update in info level.
> - Use sysreset if possible.
> - Use do_reset() and hang() instead of panic().
> Changes in v2:
> - Remove kconfig option to disable this feature.
> - Use panic() instead of do_reset() so that if the reset fails,
> the machine halt.
> - Log the result of each capsule update always.
> ---
> lib/efi_loader/efi_capsule.c | 22 ++++++++++++++++++++--
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> index 1ec7ea29ff..ade9155042 100644
> --- a/lib/efi_loader/efi_capsule.c
> +++ b/lib/efi_loader/efi_capsule.c
> @@ -14,9 +14,11 @@
> #include <env.h>
> #include <fdtdec.h>
> #include <fs.h>
> +#include <hang.h>
> #include <malloc.h>
> #include <mapmem.h>
> #include <sort.h>
> +#include <sysreset.h>
> #include <asm/global_data.h>
>
> #include <crypto/pkcs7.h>
> @@ -1120,8 +1122,11 @@ efi_status_t efi_launch_capsules(void)
> if (ret == EFI_SUCCESS) {
> ret = efi_capsule_update_firmware(capsule);
> if (ret != EFI_SUCCESS)
> - log_err("Applying capsule %ls failed\n",
> + log_err("Applying capsule %ls failed.\n",
> files[i]);
> + else
> + log_info("Applying capsule %ls succeeded.\n",
> + files[i]);
>
> /* create CapsuleXXXX */
> set_capsule_result(index, capsule, ret);
> @@ -1142,6 +1147,19 @@ efi_status_t efi_launch_capsules(void)
> free(files[i]);
> free(files);
>
> - return ret;
> + /*
> + * UEFI spec requires to reset system after complete processing capsule
> + * update on the storage.
> + */
> + puts("Reboot after firmware update");
> + if (CONFIG_IS_ENABLED(SYSRESET)) {
> + reset_cpu();
> + } else {
> + do_reset(NULL, 0, 0, NULL);
> + hang();
> + }
> + /* not reach here */
Despite the code that I proposed, I have a few concerns:
1) warm or cold reset
Now that we are updating firmware, we may have to initiate
a cold reset in some cases.
(That's why I used 'sysreset(WARM)' to raise a question.)
From the viewpoint of UEFI specification,
* A type of reset can be determined per capsule by calling
QueryCapsuleCapabilities API.
(The spec said, "Returns if the capsule can be supported via
UpdateCapsule()" and Capsule-on-disk might be out of scope?)
* There exists ResetSystem API and it takes a *reset type*
as a parameter.
2) ResetSystem at boot time
So we may want to internally make use of efi_reset_system() following
capsule-on-disk processing.
The current implementation, however, does not utilize SYSRESET drivers,
but call do_reset(). This should be changed (as I suggested above?).
-Takahiro Akashi
> +
> + return 0;
> }
> #endif /* CONFIG_EFI_CAPSULE_ON_DISK */
>
next prev parent reply other threads:[~2022-02-03 1:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-02 13:54 [PATCH v2 0/2] EFI: Reset system after capsule-on-disk Masami Hiramatsu
2022-02-02 13:54 ` [PATCH v2 1/2] efi_loader: use efi_update_capsule_firmware() for capsule on disk Masami Hiramatsu
2022-02-02 13:54 ` [PATCH v2 2/2] efi_loader: Reset system after CapsuleUpdate " Masami Hiramatsu
2022-02-03 1:24 ` AKASHI Takahiro [this message]
2022-02-03 4:34 ` Masami Hiramatsu
2022-02-03 6:35 ` Masami Hiramatsu
-- strict thread matches above, loose matches on Subject: below --
2022-02-01 8:32 [PATCH v2 0/2] EFI: Reset system after capsule-on-disk Masami Hiramatsu
2022-02-01 8:33 ` [PATCH v2 2/2] efi_loader: Reset system after CapsuleUpdate on disk Masami Hiramatsu
2022-02-01 11:38 ` AKASHI Takahiro
2022-02-02 1:53 ` Masami Hiramatsu
2022-02-02 4:15 ` AKASHI Takahiro
2022-02-02 7:06 ` Masami Hiramatsu
2022-02-03 17:32 ` Heinrich Schuchardt
2022-02-05 12:33 ` Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220203012440.GA46235@laputa \
--to=takahiro.akashi@linaro.org \
--cc=agraf@csgraf.de \
--cc=bmeng.cn@gmail.com \
--cc=etienne.carriere@linaro.org \
--cc=grant.likely@arm.com \
--cc=ilias.apalodimas@linaro.org \
--cc=jose.marinho@arm.com \
--cc=masami.hiramatsu@linaro.org \
--cc=patrice.chotard@foss.st.com \
--cc=patrick.delaunay@foss.st.com \
--cc=paul.liu@linaro.org \
--cc=sjg@chromium.org \
--cc=sughosh.ganu@linaro.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.