mirror of
https://github.com/acidanthera/audk.git
synced 2025-07-22 13:14:26 +02:00
16f26de663
The FDF spec mentions the FvNameGuid statement for [FV.xxxx] sections, but
the detailed description can be found in Volume 3 of the Platform Init
spec (which is at 1.4a currently).
Adding an FvNameGuid statement to [FV.xxx] has the following effects
(implemented by "BaseTools/Source/C/GenFv/GenFvInternalLib.c"):
- The EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset field is set to a nonzero
value, pointing after EFI_FIRMWARE_VOLUME_HEADER itself (although not
directly, see below).
- An EFI_FIRMWARE_VOLUME_EXT_HEADER object is created at the pointed-to
address. This object is not followed by any
EFI_FIRMWARE_VOLUME_EXT_ENTRY (= extension) entries, so it only
specifies the Name GUID for the firmware volume.
The EFI_FIRMWARE_VOLUME_EXT_HEADER for each firmware volume can be found
in the Build directory as a separate file (20 bytes in size):
Build/Ovmf*/*_GCC*/FV/*.ext
- The new data consume 48 bytes in the following volumes: SECFV,
FVMAIN_COMPACT, DXEFV. They comprise:
- 16 padding bytes,
- EFI_FFS_FILE_HEADER2 (8 bytes in total: no Name and ExtendedSize
fields, and Type=EFI_FV_FILETYPE_FFS_PAD),
- EFI_FIRMWARE_VOLUME_EXT_HEADER (20 bytes, see above),
- 4 padding bytes.
(The initial 16 padding bytes and the EFI_FFS_FILE_HEADER2 structure are
the reason why EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset does not point
immediately past EFI_FIRMWARE_VOLUME_HEADER.)
The sizes of the firmware volumes don't change, only their internal
usages grow by 48 bytes. I verified that the statements and calculations
in "OvmfPkg/DecomprScratchEnd.fdf.inc" are unaffected and remain valid.
- The new data consume 0 bytes in PEIFV. This is because PEIFV has enough
internal padding at the moment to accomodate the above structures
without a growth in usage.
In the future, firmware volumes can be identified by Name GUID (Fv(...)
device path nodes), rather than memory location (MemoryMapped(...) device
path nodes). This is supposed to improve stability for persistent device
paths that refer to FFS files; for example, UEFI boot options.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Suggested-by: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>