All of lore.kernel.org
 help / color / mirror / Atom feed
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 1/2] EFI: Support CAPSULE_FLAGS_INITIATE_RESET for capsule update
Date: Wed, 26 Jan 2022 16:20:27 +0900	[thread overview]
Message-ID: <20220126072027.GA56161@laputa> (raw)
In-Reply-To: <CAA93ih3HR+4eCcjzpdvpEo9DhATbyrwx3btsoffhzxAOQVCDCw@mail.gmail.com>

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 <masami.hiramatsu@linaro.org>:
> >
> > Hi Takahiro,
> >
> > 2022年1月25日(火) 21:49 AKASHI Takahiro <takahiro.akashi@linaro.org>:
> > >
> > > 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 <masami.hiramatsu@linaro.org>
> > > > ---
> > > >  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

  reply	other threads:[~2022-01-26  7:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-25 11:31 [PATCH 0/2] EFI: Add CAPSULE_FLAG_INITIATE_RESET support Masami Hiramatsu
2022-01-25 11:31 ` [PATCH 1/2] EFI: Support CAPSULE_FLAGS_INITIATE_RESET for capsule update Masami Hiramatsu
2022-01-25 12:49   ` AKASHI Takahiro
2022-01-25 22:31     ` Masami Hiramatsu
2022-01-26  2:29       ` Masami Hiramatsu
2022-01-26  7:20         ` AKASHI Takahiro [this message]
2022-01-26  8:46           ` Masami Hiramatsu
2022-01-25 11:31 ` [PATCH 2/2] mkeficapsule: Support "--flags reset" option Masami Hiramatsu
2022-02-05  6:47   ` Heinrich Schuchardt
2022-02-06 23:57     ` Masami Hiramatsu

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=20220126072027.GA56161@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.