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.likely@arm.com
Hello Grant,
could you, please, share which issues have to be solved.
Best regards
Heinrich
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