The ESRT support in U-Boot is immature and not ready for mainline.
Temporarily remove the ESRT requirement so that platforms can meaningfully
conform to EBBR. When ESRT functionality has matured this requirement will
can be brought back in.
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
Hi all,
As described above, I'm proposing ESRT gets dropped for v2.0.x series of
EBBR, with the plan to add it back in ebbr-next. Once there are U-Boot
releases that have a solid ESRT implementation that works for fwupd,
mender.io and possibly Windows Update then I would like to bring it back
in. Here's the pull request for the change in github:
https://github.com/ARM-software/ebbr/pull/86
Thoughts?
g.
source/chapter2-uefi.rst | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst
index 092fd1d..4c4cacb 100644
--- a/source/chapter2-uefi.rst
+++ b/source/chapter2-uefi.rst
@@ -467,9 +467,7 @@ EBBR platforms are required to implement either an in-band or an out-of-band fir
If firmware update is performed in-band (firmware on the application processor updates itself),
then the firmware shall implement the `UpdateCapsule()` runtime service and accept updates in the
"Firmware Management Protocol Data Capsule Structure" format as described in [UEFI]_ § 23.3,
-"Delivering Capsules Containing Updates to Firmware Management Protocol. [#FMPNote]_
-Firmware is also required to provide an EFI System Resource Table (ESRT). [UEFI]_ § 23.4
-Every firmware image that can be updated in-band must be described in the ESRT.
+"Delivering Capsules Containing Updates to Firmware Management Protocol."
If firmware update is performed out-of-band (e.g., by an independent Baseboard
Management Controller (BMC), or firmware is provided by a hypervisor),
@@ -477,7 +475,6 @@ then the platform is not required to implement the `UpdateCapsule()` runtime ser
`UpdateCapsule()` is only required before `ExitBootServices()` is called.
-
.. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar problem
regarding secure storage.
OP-TEE's chosen solution is to rely on an OS supplicant agent to perform
@@ -488,11 +485,3 @@ then the platform is not required to implement the `UpdateCapsule()` runtime ser
during runtime services.
https://optee.readthedocs.io/en/latest/architecture/secure_storage.html
-
-.. [#FMPNote] The `UpdateCapsule()` runtime service is expected to be suitable
- for use by generic firmware update services like fwupd and Windows Update.
- Both fwupd and Windows Update read the ESRT table to determine what firmware
- can be updated, and use an EFI helper application to call `UpdateCapsule()`
- before `ExitBootServices()` is called.
-
- https://fwupd.org/
--
2.20.1
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
All,
It appears we do not have quorum today so I will cancel.
I am thinking of sending a doodle poll for a new time for this call.
What are peoples thoughts?
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
>
> Thank you all for your feedback.
>
> It appears that in theory we are all happy with using bloblist with few
> implementation details which needs to be taken care of during
> implementation.
>
Just to clarify: are you using "bloblist" as a general term for the concept
of a simple linked list of tagged data blobs, or to refer specifically to
the U-Boot implementation with that name? The existing TF-A implementation
(bl_aux_params) is basically identical in concept to the U-Boot bloblist,
but not binary compatible. Are we talking about just keeping that, or
throwing it away in order to reimplement the exact structure U-Boot is
using? (I would prefer to keep the bl_aux_params as they are to avoid
disrupting existing uses, of course. Making backwards-incompatible changes
to an interface that passes across multiple repos and firmware components
is always a big pain.)
I'm out on annual leave. There will be no EBBR biweekly meetings for July.
g.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.