From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [RFC RESEND 1/2] efi: Add ESRT to the EFI system table
Date: Mon, 15 Feb 2021 10:22:53 +0900 [thread overview]
Message-ID: <20210215012253.GB8853@laputa> (raw)
In-Reply-To: <35028b6c-fe0b-7f95-8612-e64c4a55818f@gmx.de>
On Fri, Feb 12, 2021 at 03:17:30PM +0100, Heinrich Schuchardt wrote:
> On 29.01.21 06:26, AKASHI Takahiro wrote:
> > First of all, one comment:
> > It would be nice to have a list of what features are supported
> > and what are not in this patch series.
> > For example, with this patch, I suspect
> > - FwVersion in ESRT entry will never be updated at capsule update
>
> According to the UEFI specification the ESRT should be updated
>
> * at EFI_EVENT_GROUP_READY_TO_BOOT
> * when a device (with a Firmware Management Protocol) is added or removed
> * after Update Capsule
> * at EFI_EVENT_GROUP_EXIT_BOOT_SERVICES
>
> At each of these events we can call the same function collection the
> information for a new ESRT by calling
> EFI_FIRMWARE_MANAGEMENT_PROTOCOL.GetImageInfo() and freeing the memory
> of the old instance.
>
> Monitoring EFI_EVENT_GROUP_READY_TO_BOOT and
> EFI_EVENT_GROUP_EXIT_BOOT_SERVICESs seems redundant if we catch the
> other two.
>
> > - LastAttemptVersion/LastAttemptStatus will not be sustained across reboots.
>
> This information is provided by the Firmware Management Protocol (see
> 23.4.3 Mapping Firmware Management Protocol Descriptors to ESRT
> Entries). Jose's patches can only use the information provided by the
> code that Sughosh and you created.
Right. I have forgot that.
> If update status persistence is missing in the current implementation of
> the firmware management protocol, what are your plans for adding it?
No plan.
Since there is no notion of "versioning" in the current U-Boot firmware,
providing such information would be vendor-specific.
Sughosh may have his own idea relating to A/B update and anti-rollback
protection.
-Takahiro Akashi
> Best regards
>
> Heinrich
>
> >
> > So I'm not sure that the proposed implementation is useful
> > in a practical manner.
> >
>
next prev parent reply other threads:[~2021-02-15 1:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-28 13:29 [RFC RESEND 0/2] Add ESRT and test ESRT creation Jose Marinho
2021-01-28 13:29 ` [RFC RESEND 1/2] efi: Add ESRT to the EFI system table Jose Marinho
2021-01-28 15:29 ` Heinrich Schuchardt
2021-01-29 5:26 ` AKASHI Takahiro
2021-02-12 14:17 ` Heinrich Schuchardt
2021-02-15 1:22 ` AKASHI Takahiro [this message]
2021-01-28 13:29 ` [RFC RESEND 2/2] efi: Add fake FMP instance to test ESRT creation Jose Marinho
2021-01-28 15:02 ` Heinrich Schuchardt
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=20210215012253.GB8853@laputa \
--to=takahiro.akashi@linaro.org \
--cc=u-boot@lists.denx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox