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.
Hi
Following a discussion with Civil Infrastructure Project TSC, there is
a watchdog protection issue with EFI: the time between the call to
ExitBootService and Linux kernel takes over watchdog service is not
covered by any watchdog protection.
The EFI specification for BS.SetWatchdogTimer is very flexible as it
states "perform a platform specific action that must eventually cause
the platform to be reset.".
So we could naively implement a solution that would arm platform
hardware watchdog in addition to EFI timer. Assuming watchdog period
is long enough that it cover the time for Linux to take over the
hardware watchdog, there is nothing to be done in EFI Stub to benefit
from the new protection.
But this scheme fails to handle FF-A update capsules which can take a
long time. So either the period is long enough to support that or we
need a FF-A watchdog service. Based on Siemens feedback, time to
update can last 20 minutes. StandAloneMM may also need such a
protection so FF-A watchdog service seems desired.
I'd be happy to receive feedback on the problem itself (watchdog in
EFI) and on the possible solution (FF-A based).
Cheers
FF
All,
Sorry but I am out on training tomorrow so I am going to cancel the call.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hi all,
I don't have an agenda for today and I didn't send out a reminder on
Friday, so I'm cancelling for today.
There are outstanding patches adding RISC-V support that still need to
be reviewed and/or merged. Hopefully I'll be able to process those this
week. I'll post any status updates to this mailing list
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.