summaryrefslogtreecommitdiff
path: root/src/soc/intel/tigerlake/lockdown.c
diff options
context:
space:
mode:
authorSergii Dmytruk <sergii.dmytruk@3mdeb.com>2024-05-06 15:02:50 +0300
committerMartin L Roth <gaumless@gmail.com>2024-08-30 15:48:25 +0000
commitbd9370d775ccc982ba54424f272deaef997f80bc (patch)
tree8cdd04e99e41c30dae1b944eedf5b059bbc036a7 /src/soc/intel/tigerlake/lockdown.c
parent42c8ae73a3e9bea2d050b05f00a2639ebd21a61a (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 'src/soc/intel/tigerlake/lockdown.c')
0 files changed, 0 insertions, 0 deletions