| Age | Commit message (Collapse) | Author |
|---|
|
How it approximately works:
(During a normal system run):
1. OS puts a capsule into RAM and calls UpdateCapsule() function of EFI
runtime
2. If applying the update requires a reboot, EFI implementation creates
a new CapsuleUpdateData* EFI variable pointing at the beginning of
capsules description (not data, but description of the data) and does
a warm reboot leaving capsule data and its description in RAM to be
picked by firmware on the next boot process
(After DEV_INIT:)
3. Capsules are discovered by checking for CapsuleUpdateData* variables
4. Capsule description in memory and capsule data is validated for
sanity
5. Capsule data is coalesced into a continuous piece of memory
(On BS_WRITE_TABLES via dasharo_add_capsules_to_bootmem() hook:)
6. Buffer with coalesced capsules is marked as reserved
(On BS_WRITE_TABLES via lb_uefi_capsules() hook:)
7. coreboot table entry is added for each of the discovered capsules
(In UEFI payload:)
8. CapsuleUpdateData* get removed
9. coreboot table is checked for any update capsules which are then
applied
Change-Id: I162d678ae5c504906084b59c1a8d8c26dadb9433
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83422
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Krystian Hebel <krystian.hebel@3mdeb.com>
|
|
EFI System Resource Table (ESRT) is an informational structure that
reports basic details about current system or device firmware. This is
chiefly used to perform firmware updates.
New CONFIG_DRIVERS_EFI_FW_INFO is off by default, enabling it adds
DRIVERS_EFI_FW_{GUID,VERSION,LSV} to be used to specify firmware
version/update information.
Existing forms of versions wouldn't be sufficient because there is no
universal way of converting string versions to 32-bit unsigned integers
and there are no GUIDs or lowest supported versions.
Change-Id: Ic1b768d7bed43edf7ca8e41552087734054de033
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/83421
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: coreboot org <coreboot.org@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Change-Id: Ib27894f0f1e03501583fffb2c759b493d6a7b945
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80588
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add a driver to read and write EFI variables stored in a region device.
This is particularly useful for EDK2 as payload and allows to reuse
existing EFI tools to set/get options used by the firmware.
The write implementation is fault tolerant and doesn't corrupt the
variable store. A faulting write might result in using the old value
even though a 'newer' had been completely written.
Implemented basic unit tests for header corruption, writing existing
data and append new data into the store.
Initial firmware region state:
Initially the variable store region isn't formatted. Usually this is
done in the EDK2 payload when no valid firmware volume could be found.
It might be useful to do this offline or in coreboot to have a working
option store on the first boot or when it was corrupted.
Performance improvements:
Right now the code always checks if the firmware volume header is valid.
This could be optimised by caching the test result in heap. For write
operations it would be good to cache the end of the variable store in
the heap as well, instead of walking the whole store. For read
operations caching the entire store could be considered.
Reclaiming memory:
The EFI variable store is append write only. To update an existing
variable, first a new is written to the end of the store and then the
previous is marked invalid. This only works on PNOR flash that allow to
clear set bits, but keep cleared bits state.
This mechanisms allows a fault tolerant write, but it also requires to
"clean" the variable store for time to time. This cleaning would remove
variables that have been marked "deleted".
Such cleaning mechanism in turn must be fault tolerant and thus must use
a second partition in the SPI flash as backup/working region.
For now to cleaning is done in coreboot.
Fault checking:
The driver should check if a previous write was successful and if not
mark variables as deleted on the next operation.
Tested and working:
- Enumerate all existing variables
- Read variables
- Write variables
Change-Id: I8079f71d29da5dc2db956fc68bef1486fe3906bb
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52564
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
