tyler.durden
/
audk
mirror of https://github.com/acidanthera/audk.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
audk/OvmfPkg/VarStore.fdf.inc

116 lines
3.8 KiB
PHP
Raw Normal View History

OvmfPkg: extract varstore-related FD Layout Regions to an include file This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:56:53 +02:00
## @file
# FDF include file with Layout Regions that define an empty variable store.
#
# Copyright (C) 2014, Red Hat, Inc.
# Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.<BR>
#
OvmfPkg: Replace BSD License with BSD+Patent License https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 01:06:33 +02:00
# SPDX-License-Identifier: BSD-2-Clause-Patent
OvmfPkg: extract varstore-related FD Layout Regions to an include file This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:56:53 +02:00
#
##
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@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>
2017-04-29 03:37:41 +02:00
!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
OvmfPkg: extract varstore-related FD Layout Regions to an include file This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:56:53 +02:00
0x00000000|0x0000e000
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@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>
2017-04-29 03:37:41 +02:00
!endif
!if $(FD_SIZE_IN_KB) == 4096
0x00000000|0x00040000
!endif
OvmfPkg: extract varstore-related FD Layout Regions to an include file This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:56:53 +02:00
#NV_VARIABLE_STORE
DATA = {
## This is the EFI_FIRMWARE_VOLUME_HEADER
# ZeroVector []
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
# FileSystemGuid: gEfiSystemNvDataFvGuid =
# { 0xFFF12B8D, 0x7696, 0x4C8B,
# { 0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50 }}
0x8D, 0x2B, 0xF1, 0xFF, 0x96, 0x76, 0x8B, 0x4C,
0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50,
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@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>
2017-04-29 03:37:41 +02:00
!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
OvmfPkg: extract varstore-related FD Layout Regions to an include file This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:56:53 +02:00
# FvLength: 0x20000
0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00,
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@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>
2017-04-29 03:37:41 +02:00
!endif
!if $(FD_SIZE_IN_KB) == 4096
# FvLength: 0x84000
0x00, 0x40, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00,
!endif
OvmfPkg: extract varstore-related FD Layout Regions to an include file This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:56:53 +02:00
# Signature "_FVH" # Attributes
0x5f, 0x46, 0x56, 0x48, 0xff, 0xfe, 0x04, 0x00,
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@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>
2017-04-29 03:37:41 +02:00
# HeaderLength
0x48, 0x00,
!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
# CheckSum
0x19, 0xF9,
!endif
!if $(FD_SIZE_IN_KB) == 4096
# CheckSum
0xAF, 0xB8,
!endif
# ExtHeaderOffset #Reserved #Revision
0x00, 0x00, 0x00, 0x02,
!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
OvmfPkg: extract varstore-related FD Layout Regions to an include file This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:56:53 +02:00
# Blockmap[0]: 0x20 Blocks * 0x1000 Bytes / Block
0x20, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00,
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@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>
2017-04-29 03:37:41 +02:00
!endif
!if $(FD_SIZE_IN_KB) == 4096
# Blockmap[0]: 0x84 Blocks * 0x1000 Bytes / Block
0x84, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00,
!endif
OvmfPkg: extract varstore-related FD Layout Regions to an include file This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:56:53 +02:00
# Blockmap[1]: End
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
## This is the VARIABLE_STORE_HEADER
OvmfPkg: simplify VARIABLE_STORE_HEADER generation Before the merger of the authenticated and non-authenticated variable drivers (commit fa0737a839d0), we had to match the varstore header GUID in "OvmfPkg/VarStore.fdf.inc" to SECURE_BOOT_ENABLE, because the opposite GUID would cause either driver to fail an assertion. The header structures for individual variables residing in the varstore were different (VARIABLE_HEADER vs. AUTHENTICATED_VARIABLE_HEADER), and each driver could only handle its own, so this GUID enforcement was necessary. Since the unification of the variable driver however, it treats (a) variable store format, and (b) AuthVariableLib instance as independent characteristics; it can always manipulate variable stores with both header types. All variations boot now; the difference is whether authenticated variables, and special variables computed from them (like SecureBoot) are supported at runtime: variable store non-auth auth and SB header GUID AuthVariableLib variables variables -- --------------------- ------------------- -> --------- ----------- 1 Variable SecurityPkg/... supported unsupported 2 Variable AuthVariableLibNull supported unsupported 3 AuthenticatedVariable SecurityPkg/... supported supported 4 AuthenticatedVariable AuthVariableLibNull supported unsupported At the moment, SECURE_BOOT_ENABLE selects between cases #2 (FALSE) and #3 (TRUE). That is, it controls both the varstore header GUID in "OvmfPkg/VarStore.fdf.inc", and the AuthVariableLib resolution in the DSC files. Exploiting the unified driver's flexibility, we can simplify "OvmfPkg/VarStore.fdf.inc" by picking the AuthenticatedVariable GUID as a constant, and letting SECURE_BOOT_ENABLE control only the AuthVariableLib resolution. This amounts to SECURE_BOOT_ENABLE choosing between cases #3 (TRUE) and #4 (FALSE), with identical results as before. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Star Zeng <star.zeng@intel.com> Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/7319/focus=7344 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
2016-02-05 20:35:30 +01:00
# It is compatible with SECURE_BOOT_ENABLE == FALSE as well.
OvmfPkg: extract varstore-related FD Layout Regions to an include file This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:56:53 +02:00
# Signature: gEfiAuthenticatedVariableGuid =
# { 0xaaf32c78, 0x947b, 0x439a,
# { 0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92 }}
0x78, 0x2c, 0xf3, 0xaa, 0x7b, 0x94, 0x9a, 0x43,
0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92,
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@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>
2017-04-29 03:37:41 +02:00
!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
OvmfPkg: extract varstore-related FD Layout Regions to an include file This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:56:53 +02:00
# Size: 0xe000 (gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize) -
# 0x48 (size of EFI_FIRMWARE_VOLUME_HEADER) = 0xdfb8
# This can speed up the Variable Dispatch a bit.
0xB8, 0xDF, 0x00, 0x00,
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@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>
2017-04-29 03:37:41 +02:00
!endif
!if $(FD_SIZE_IN_KB) == 4096
# Size: 0x40000 (gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize) -
# 0x48 (size of EFI_FIRMWARE_VOLUME_HEADER) = 0x3ffb8
# This can speed up the Variable Dispatch a bit.
0xB8, 0xFF, 0x03, 0x00,
!endif
OvmfPkg: extract varstore-related FD Layout Regions to an include file This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:56:53 +02:00
# FORMATTED: 0x5A #HEALTHY: 0xFE #Reserved: UINT16 #Reserved1: UINT32
0x5A, 0xFE, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
}
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@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>
2017-04-29 03:37:41 +02:00
!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
OvmfPkg: extract varstore-related FD Layout Regions to an include file This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:56:53 +02:00
0x0000e000|0x00001000
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@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>
2017-04-29 03:37:41 +02:00
!endif
!if $(FD_SIZE_IN_KB) == 4096
0x00040000|0x00001000
!endif
OvmfPkg: extract varstore-related FD Layout Regions to an include file This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:56:53 +02:00
#NV_EVENT_LOG
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@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>
2017-04-29 03:37:41 +02:00
!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
OvmfPkg: extract varstore-related FD Layout Regions to an include file This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:56:53 +02:00
0x0000f000|0x00001000
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@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>
2017-04-29 03:37:41 +02:00
!endif
!if $(FD_SIZE_IN_KB) == 4096
0x00041000|0x00001000
!endif
OvmfPkg: extract varstore-related FD Layout Regions to an include file This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:56:53 +02:00
#NV_FTW_WORKING
DATA = {
# EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature = gEdkiiWorkingBlockSignatureGuid =
# { 0x9e58292b, 0x7c68, 0x497d, { 0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95 }}
0x2b, 0x29, 0x58, 0x9e, 0x68, 0x7c, 0x7d, 0x49,
0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95,
# Crc:UINT32 #WorkingBlockValid:1, WorkingBlockInvalid:1, Reserved
0x2c, 0xaf, 0x2c, 0x64, 0xFE, 0xFF, 0xFF, 0xFF,
# WriteQueueSize: UINT64
0xE0, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
}
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@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>
2017-04-29 03:37:41 +02:00
!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
OvmfPkg: extract varstore-related FD Layout Regions to an include file This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:56:53 +02:00
0x00010000|0x00010000
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@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>
2017-04-29 03:37:41 +02:00
!endif
!if $(FD_SIZE_IN_KB) == 4096
0x00042000|0x00042000
!endif
OvmfPkg: extract varstore-related FD Layout Regions to an include file This saves code duplication between the Ia32, Ia32X64, and X64 flavors, and enables the next patch to include the varstore in new FD files by reference. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:56:53 +02:00
#NV_FTW_SPARE