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

92 lines
3.7 KiB
PHP
Raw Normal View History

OvmfPkg: build OVMF_VARS.fd, OVMF_CODE.fd, OVMF.fd OVMF_VARS.fd and OVMF_CODE.fd split the variable store and the firmware code in separate files. The PCDs' values continue to depend only on FD_SIZE_1MB vs. FD_SIZE_2MB. With the split files, it must be ensured on the QEMU command line that OVMF_VARS.fd and OVMF_CODE.fd be contiguously mapped so that they end exactly at 4GB. See QEMU commit 637a5acb (first released in v2.0.0). In this patch we must take care to assign each PCD only once. 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@15670 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:57:01 +02:00
## @file
# FDF include file that defines the main macros and sets the dependent PCDs.
#
# 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: build OVMF_VARS.fd, OVMF_CODE.fd, OVMF.fd OVMF_VARS.fd and OVMF_CODE.fd split the variable store and the firmware code in separate files. The PCDs' values continue to depend only on FD_SIZE_1MB vs. FD_SIZE_2MB. With the split files, it must be ensured on the QEMU command line that OVMF_VARS.fd and OVMF_CODE.fd be contiguously mapped so that they end exactly at 4GB. See QEMU commit 637a5acb (first released in v2.0.0). In this patch we must take care to assign each PCD only once. 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@15670 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:57:01 +02:00
#
##
DEFINE BLOCK_SIZE = 0x1000
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
#
# A firmware binary built with FD_SIZE_IN_KB=1024, and a firmware binary built
# with FD_SIZE_IN_KB=2048, use the same variable store layout.
#
# Setting FD_SIZE_IN_KB to 4096 results in a different (much larger) variable
# store structure that is incompatible with both of the above-mentioned
# firmware binaries.
#
!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
OvmfPkg: build OVMF_VARS.fd, OVMF_CODE.fd, OVMF.fd OVMF_VARS.fd and OVMF_CODE.fd split the variable store and the firmware code in separate files. The PCDs' values continue to depend only on FD_SIZE_1MB vs. FD_SIZE_2MB. With the split files, it must be ensured on the QEMU command line that OVMF_VARS.fd and OVMF_CODE.fd be contiguously mapped so that they end exactly at 4GB. See QEMU commit 637a5acb (first released in v2.0.0). In this patch we must take care to assign each PCD only once. 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@15670 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:57:01 +02:00
DEFINE VARS_SIZE = 0x20000
DEFINE VARS_BLOCKS = 0x20
OvmfPkg/OvmfPkg.fdf.inc: extract VARS_LIVE_SIZE and VARS_SPARE_SIZE macros 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:35:23 +02:00
DEFINE VARS_LIVE_SIZE = 0xE000
DEFINE VARS_SPARE_SIZE = 0x10000
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
OvmfPkg: build OVMF_VARS.fd, OVMF_CODE.fd, OVMF.fd OVMF_VARS.fd and OVMF_CODE.fd split the variable store and the firmware code in separate files. The PCDs' values continue to depend only on FD_SIZE_1MB vs. FD_SIZE_2MB. With the split files, it must be ensured on the QEMU command line that OVMF_VARS.fd and OVMF_CODE.fd be contiguously mapped so that they end exactly at 4GB. See QEMU commit 637a5acb (first released in v2.0.0). In this patch we must take care to assign each PCD only once. 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@15670 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:57:01 +02:00
OvmfPkg: introduce the FD_SIZE_IN_KB macro / build flag FD_SIZE_xMB defines have existed for flash size selection. They can be passed as "-D FD_SIZE_xMB" on the command line. Passing multiple of them at the same time has never been supported; earlier settings on the command line cannot be overridden. Introduce the integer valued FD_SIZE_IN_KB macro, which provides the following improvements: - several instances of it are permitted on the command line, with the last one taking effect, - conditional statements in the DSC and FDF files need only check a single macro, and multiple values can be checked in a single !if with the || operator, - nested !ifdef / !else ladders can be replaced with flat equality tests, - in the future, flash sizes can be expressed with a finer than MB granularity, if necessary. For now, we're going to preserve the FD_SIZE_xMB defines as convenience wrappers for FD_SIZE_IN_KB. FD_SIZE_IN_KB is being added to the DSC files because this way we can depend on it in both the DSC and FDF files. 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-05-03 17:54:49 +02:00
!if $(FD_SIZE_IN_KB) == 1024
OvmfPkg: build OVMF_VARS.fd, OVMF_CODE.fd, OVMF.fd OVMF_VARS.fd and OVMF_CODE.fd split the variable store and the firmware code in separate files. The PCDs' values continue to depend only on FD_SIZE_1MB vs. FD_SIZE_2MB. With the split files, it must be ensured on the QEMU command line that OVMF_VARS.fd and OVMF_CODE.fd be contiguously mapped so that they end exactly at 4GB. See QEMU commit 637a5acb (first released in v2.0.0). In this patch we must take care to assign each PCD only once. 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@15670 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:57:01 +02:00
DEFINE FW_BASE_ADDRESS = 0xFFF00000
DEFINE FW_SIZE = 0x00100000
DEFINE FW_BLOCKS = 0x100
DEFINE CODE_BASE_ADDRESS = 0xFFF20000
DEFINE CODE_SIZE = 0x000E0000
DEFINE CODE_BLOCKS = 0xE0
DEFINE FVMAIN_SIZE = 0x000CC000
DEFINE SECFV_OFFSET = 0x000EC000
DEFINE SECFV_SIZE = 0x14000
OvmfPkg: introduce the FD_SIZE_IN_KB macro / build flag FD_SIZE_xMB defines have existed for flash size selection. They can be passed as "-D FD_SIZE_xMB" on the command line. Passing multiple of them at the same time has never been supported; earlier settings on the command line cannot be overridden. Introduce the integer valued FD_SIZE_IN_KB macro, which provides the following improvements: - several instances of it are permitted on the command line, with the last one taking effect, - conditional statements in the DSC and FDF files need only check a single macro, and multiple values can be checked in a single !if with the || operator, - nested !ifdef / !else ladders can be replaced with flat equality tests, - in the future, flash sizes can be expressed with a finer than MB granularity, if necessary. For now, we're going to preserve the FD_SIZE_xMB defines as convenience wrappers for FD_SIZE_IN_KB. FD_SIZE_IN_KB is being added to the DSC files because this way we can depend on it in both the DSC and FDF files. 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-05-03 17:54:49 +02:00
!endif
OvmfPkg: build OVMF_VARS.fd, OVMF_CODE.fd, OVMF.fd OVMF_VARS.fd and OVMF_CODE.fd split the variable store and the firmware code in separate files. The PCDs' values continue to depend only on FD_SIZE_1MB vs. FD_SIZE_2MB. With the split files, it must be ensured on the QEMU command line that OVMF_VARS.fd and OVMF_CODE.fd be contiguously mapped so that they end exactly at 4GB. See QEMU commit 637a5acb (first released in v2.0.0). In this patch we must take care to assign each PCD only once. 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@15670 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:57:01 +02:00
OvmfPkg: introduce the FD_SIZE_IN_KB macro / build flag FD_SIZE_xMB defines have existed for flash size selection. They can be passed as "-D FD_SIZE_xMB" on the command line. Passing multiple of them at the same time has never been supported; earlier settings on the command line cannot be overridden. Introduce the integer valued FD_SIZE_IN_KB macro, which provides the following improvements: - several instances of it are permitted on the command line, with the last one taking effect, - conditional statements in the DSC and FDF files need only check a single macro, and multiple values can be checked in a single !if with the || operator, - nested !ifdef / !else ladders can be replaced with flat equality tests, - in the future, flash sizes can be expressed with a finer than MB granularity, if necessary. For now, we're going to preserve the FD_SIZE_xMB defines as convenience wrappers for FD_SIZE_IN_KB. FD_SIZE_IN_KB is being added to the DSC files because this way we can depend on it in both the DSC and FDF files. 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-05-03 17:54:49 +02:00
!if $(FD_SIZE_IN_KB) == 2048
OvmfPkg: build OVMF_VARS.fd, OVMF_CODE.fd, OVMF.fd OVMF_VARS.fd and OVMF_CODE.fd split the variable store and the firmware code in separate files. The PCDs' values continue to depend only on FD_SIZE_1MB vs. FD_SIZE_2MB. With the split files, it must be ensured on the QEMU command line that OVMF_VARS.fd and OVMF_CODE.fd be contiguously mapped so that they end exactly at 4GB. See QEMU commit 637a5acb (first released in v2.0.0). In this patch we must take care to assign each PCD only once. 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@15670 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:57:01 +02:00
DEFINE FW_BASE_ADDRESS = 0xFFE00000
DEFINE FW_SIZE = 0x00200000
DEFINE FW_BLOCKS = 0x200
DEFINE CODE_BASE_ADDRESS = 0xFFE20000
DEFINE CODE_SIZE = 0x001E0000
DEFINE CODE_BLOCKS = 0x1E0
DEFINE FVMAIN_SIZE = 0x001AC000
DEFINE SECFV_OFFSET = 0x001CC000
DEFINE SECFV_SIZE = 0x34000
!endif
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) == 4096
DEFINE VARS_SIZE = 0x84000
DEFINE VARS_BLOCKS = 0x84
DEFINE VARS_LIVE_SIZE = 0x40000
DEFINE VARS_SPARE_SIZE = 0x42000
DEFINE FW_BASE_ADDRESS = 0xFFC00000
DEFINE FW_SIZE = 0x00400000
DEFINE FW_BLOCKS = 0x400
DEFINE CODE_BASE_ADDRESS = 0xFFC84000
DEFINE CODE_SIZE = 0x0037C000
DEFINE CODE_BLOCKS = 0x37C
DEFINE FVMAIN_SIZE = 0x00348000
DEFINE SECFV_OFFSET = 0x003CC000
DEFINE SECFV_SIZE = 0x34000
!endif
OvmfPkg: build OVMF_VARS.fd, OVMF_CODE.fd, OVMF.fd OVMF_VARS.fd and OVMF_CODE.fd split the variable store and the firmware code in separate files. The PCDs' values continue to depend only on FD_SIZE_1MB vs. FD_SIZE_2MB. With the split files, it must be ensured on the QEMU command line that OVMF_VARS.fd and OVMF_CODE.fd be contiguously mapped so that they end exactly at 4GB. See QEMU commit 637a5acb (first released in v2.0.0). In this patch we must take care to assign each PCD only once. 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@15670 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:57:01 +02:00
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress = $(FW_BASE_ADDRESS)
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize = $(FW_SIZE)
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize = $(BLOCK_SIZE)
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase = $(FW_BASE_ADDRESS)
OvmfPkg/OvmfPkg.fdf.inc: extract VARS_LIVE_SIZE and VARS_SPARE_SIZE macros 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:35:23 +02:00
SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize = $(VARS_LIVE_SIZE)
OvmfPkg: build OVMF_VARS.fd, OVMF_CODE.fd, OVMF.fd OVMF_VARS.fd and OVMF_CODE.fd split the variable store and the firmware code in separate files. The PCDs' values continue to depend only on FD_SIZE_1MB vs. FD_SIZE_2MB. With the split files, it must be ensured on the QEMU command line that OVMF_VARS.fd and OVMF_CODE.fd be contiguously mapped so that they end exactly at 4GB. See QEMU commit 637a5acb (first released in v2.0.0). In this patch we must take care to assign each PCD only once. 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@15670 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-22 23:57:01 +02:00
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogBase = gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogSize = $(BLOCK_SIZE)
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase = gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogBase + gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogSize
SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize = $(BLOCK_SIZE)
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwSpareBase = gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
OvmfPkg/OvmfPkg.fdf.inc: extract VARS_LIVE_SIZE and VARS_SPARE_SIZE macros 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:35:23 +02:00
SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize = $(VARS_SPARE_SIZE)
OvmfPkg: Sec: assert the build-time calculated end of the scratch buffer The DecompressMemFvs() function in "OvmfPkg/Sec/SecMain.c" uses more memory, temporarily, than what PEIFV and DXEFV will ultimately need. First, it uses an output buffer for decompression, second, the decompression itself needs a scratch buffer (and this scratch buffer is the highest area that SEC uses). DecompressMemFvs() used to be called on normal boots only (ie. not on S3 resume), which is why the decompression output buffer and the scratch buffer were allowed to scribble over RAM. However, we'll soon start to worry during S3 resume that the runtime OS might tamper with the pre-decompressed PEIFV, and we'll decompress the firmware volumes on S3 resume too, from pristine flash. For this we'll need to know the end of the scratch buffer in advance, so we can prepare a non-malicious OS for it. Calculate the end of the scratch buffer statically in the FDF files, and assert in DecompressMemFvs() that the runtime decompression will match it. 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@19036 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:41:20 +01:00
OvmfPkg: set fixed FlashNvStorage base addresses with -D SMM_REQUIRE The following flash-related base addresses: - PcdFlashNvStorageVariableBase64, - PcdFlashNvStorageFtwWorkingBase, - PcdFlashNvStorageFtwSpareBase, are always set to constant (invariable) values in the "-D SMM_REQUIRE" build of OVMF. (That's because in the SMM build, actual pflash is a hard requirement, and the RAM-based emulation is never available.) Set said PCDs statically, at build. This will allow us to depend on their values in the PEI phase. When SMM_REQUIRE is FALSE, this change has no effect (confirmed by report file comparison). When SMM_REQUIRE is TRUE, the report file shows the following changes: - "PcdOvmfFlashNvStorageFtwSpareBase" and "PcdOvmfFlashNvStorageFtwWorkingBase" are no longer consumed by any module directly, - for "PcdFlashNvStorageFtwSpareBase", "PcdFlashNvStorageFtwWorkingBase" and "PcdFlashNvStorageVariableBase64", the access method changes from DYN to FIXED, - for the latter PCDs, the zero (dynamic default) values are replaced with the desired constants. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200310222739.26717-4-lersek@redhat.com> Acked-by: Leif Lindholm <leif@nuviainc.com>
2020-03-10 23:27:37 +01:00
!if $(SMM_REQUIRE) == TRUE
SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64 = gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase
SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase = gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase
SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase = gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwSpareBase
!endif
OvmfPkg: Sec: assert the build-time calculated end of the scratch buffer The DecompressMemFvs() function in "OvmfPkg/Sec/SecMain.c" uses more memory, temporarily, than what PEIFV and DXEFV will ultimately need. First, it uses an output buffer for decompression, second, the decompression itself needs a scratch buffer (and this scratch buffer is the highest area that SEC uses). DecompressMemFvs() used to be called on normal boots only (ie. not on S3 resume), which is why the decompression output buffer and the scratch buffer were allowed to scribble over RAM. However, we'll soon start to worry during S3 resume that the runtime OS might tamper with the pre-decompressed PEIFV, and we'll decompress the firmware volumes on S3 resume too, from pristine flash. For this we'll need to know the end of the scratch buffer in advance, so we can prepare a non-malicious OS for it. Calculate the end of the scratch buffer statically in the FDF files, and assert in DecompressMemFvs() that the runtime decompression will match it. 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@19036 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:41:20 +01:00
DEFINE MEMFD_BASE_ADDRESS = 0x800000