diff options
author | Sergii Dmytruk <sergii.dmytruk@3mdeb.com> | 2024-05-06 15:02:50 +0300 |
---|---|---|
committer | Martin L Roth <gaumless@gmail.com> | 2024-08-30 15:48:25 +0000 |
commit | bd9370d775ccc982ba54424f272deaef997f80bc (patch) | |
tree | 8cdd04e99e41c30dae1b944eedf5b059bbc036a7 /Documentation/contributing/gsoc.md | |
parent | 42c8ae73a3e9bea2d050b05f00a2639ebd21a61a (diff) |
drivers/efi/uefi_capsules.c: coalesce and store UEFI capsules
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>
Diffstat (limited to 'Documentation/contributing/gsoc.md')
0 files changed, 0 insertions, 0 deletions