On 26/07/2021 16:44, Heinrich Schuchardt wrote:
On 26.07.21 16:12, Grant Likely wrote:
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.lik...@arm.com>
Hello Grant,
could you, please, share which issues have to be solved.
The high level issue is testing with fwupd has only started recently.
For the specific problems, Ilias has been working through them and most
of them may be solved at this point. However, that doesn't do anything
for the folks that are committed to any of the existing release (2021.07
or earlier).
With regard to the SystemReady-IR program, I've received feedback from
vendors that even recent releases will not be able to meet EBBR
compliance without backporting ESRT patches from mainline. v2021.04 and
v2021.01 are both being used in stabilized BSPs from vendors.
I'm comfortable dropping ESRT /for now/ because the integration work
with fwupd and other agents hasn't been done. Even if a platform based
on current released U-Boot provided an ESRT, it is unlikely that it will
work out of the box with fwupd anyway, so the ESRT requirement isn't yet
providing any value.
I suggest that ESRT gets brought back in for the next major release of
EBBR (in approx 1 year) once integration is tested and we have suitable
test cases.
g.
---
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.
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
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.
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
