2010-02-24 01:21:16 +01:00
## @file
2014-08-28 08:34:06 +02:00
# Capsule Runtime Driver produces two UEFI capsule runtime services: (UpdateCapsule, QueryCapsuleCapabilities).
#
2009-02-25 16:35:58 +01:00
# It installs the Capsule Architectural Protocol defined in PI1.0a to signify
2009-01-04 04:20:55 +01:00
# the capsule runtime services are ready.
2008-04-09 07:50:10 +02:00
#
2017-03-31 07:03:59 +02:00
# Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.<BR>
2010-04-24 11:33:45 +02:00
# This program and the accompanying materials
2007-07-18 16:31:27 +02:00
# are licensed and made available under the terms and conditions of the BSD License
2008-04-09 07:50:10 +02:00
# which accompanies this distribution. The full text of the license may be found at
2007-07-18 16:31:27 +02:00
# http://opensource.org/licenses/bsd-license.php
2008-04-09 07:50:10 +02:00
#
2007-07-18 16:31:27 +02:00
# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
2008-04-09 07:50:10 +02:00
#
2010-02-24 01:21:16 +01:00
##
2007-07-18 16:31:27 +02:00
[Defines]
INF_VERSION = 0x00010005
BASE_NAME = CapsuleRuntimeDxe
2014-08-28 08:34:06 +02:00
MODULE_UNI_FILE = CapsuleRuntimeDxe.uni
2007-07-18 16:31:27 +02:00
FILE_GUID = 42857F0A-13F2-4B21-8A23-53D3F714B840
MODULE_TYPE = DXE_RUNTIME_DRIVER
VERSION_STRING = 1.0
ENTRY_POINT = CapsuleServiceInitialize
#
# The following information is for reference only and not required by the build tools.
#
MdeModulePkg/CapsuleRuntimeDxe: clean the capsule payload to DRAM
When capsule updates are staged for processing after a warm reboot,
they are copied into memory with the MMU and caches enabled. When
the capsule PEI gets around to coalescing the capsule, the MMU and
caches may still be disabled, and so on architectures where uncached
accesses are incoherent with the caches (such as ARM and AARCH64),
we need to ensure that the data passed into UpdateCapsule() is
written back to main memory before performing the warm reboot.
Unfortunately, on ARM, the only type of cache maintenance instructions
that are suitable for this purpose operate on virtual addresses only,
and given that the UpdateCapsule() prototype includes the physical
address of a linked list of scatter/gather data structures that are
mapped at an address that is unknown to the firmware (and may not even
be mapped at all when UpdateCapsule() is invoked), we can only perform
this cache maintenance at boot time. Fortunately, both Windows and Linux
only invoke UpdateCapsule() before calling ExitBootServices(), so this
is not a problem in practice.
In the future, we may propose adding a secure firmware service that
permits performing the cache maintenance at OS runtime, in which case
this code may be enhanced to call that service if available. For now,
we just fail any UpdateCapsule() calls performed at OS runtime on ARM.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-06-12 12:37:08 +02:00
# VALID_ARCHITECTURES = IA32 X64 IPF EBC ARM AARCH64
2007-07-18 16:31:27 +02:00
#
2010-02-24 01:21:16 +01:00
[Sources]
2007-07-18 16:31:27 +02:00
CapsuleService.c
MdeModulePkg/CapsuleRuntimeDxe: clean the capsule payload to DRAM
When capsule updates are staged for processing after a warm reboot,
they are copied into memory with the MMU and caches enabled. When
the capsule PEI gets around to coalescing the capsule, the MMU and
caches may still be disabled, and so on architectures where uncached
accesses are incoherent with the caches (such as ARM and AARCH64),
we need to ensure that the data passed into UpdateCapsule() is
written back to main memory before performing the warm reboot.
Unfortunately, on ARM, the only type of cache maintenance instructions
that are suitable for this purpose operate on virtual addresses only,
and given that the UpdateCapsule() prototype includes the physical
address of a linked list of scatter/gather data structures that are
mapped at an address that is unknown to the firmware (and may not even
be mapped at all when UpdateCapsule() is invoked), we can only perform
this cache maintenance at boot time. Fortunately, both Windows and Linux
only invoke UpdateCapsule() before calling ExitBootServices(), so this
is not a problem in practice.
In the future, we may propose adding a secure firmware service that
permits performing the cache maintenance at OS runtime, in which case
this code may be enhanced to call that service if available. For now,
we just fail any UpdateCapsule() calls performed at OS runtime on ARM.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-06-12 12:37:08 +02:00
CapsuleService.h
2007-07-18 16:31:27 +02:00
MdeModulePkg/CapsuleRuntimeDxe: clean the capsule payload to DRAM
When capsule updates are staged for processing after a warm reboot,
they are copied into memory with the MMU and caches enabled. When
the capsule PEI gets around to coalescing the capsule, the MMU and
caches may still be disabled, and so on architectures where uncached
accesses are incoherent with the caches (such as ARM and AARCH64),
we need to ensure that the data passed into UpdateCapsule() is
written back to main memory before performing the warm reboot.
Unfortunately, on ARM, the only type of cache maintenance instructions
that are suitable for this purpose operate on virtual addresses only,
and given that the UpdateCapsule() prototype includes the physical
address of a linked list of scatter/gather data structures that are
mapped at an address that is unknown to the firmware (and may not even
be mapped at all when UpdateCapsule() is invoked), we can only perform
this cache maintenance at boot time. Fortunately, both Windows and Linux
only invoke UpdateCapsule() before calling ExitBootServices(), so this
is not a problem in practice.
In the future, we may propose adding a secure firmware service that
permits performing the cache maintenance at OS runtime, in which case
this code may be enhanced to call that service if available. For now,
we just fail any UpdateCapsule() calls performed at OS runtime on ARM.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-06-12 12:37:08 +02:00
[Sources.Ia32, Sources.IPF, Sources.EBC]
2011-09-02 13:34:35 +02:00
SaveLongModeContext.c
MdeModulePkg/CapsuleRuntimeDxe: clean the capsule payload to DRAM
When capsule updates are staged for processing after a warm reboot,
they are copied into memory with the MMU and caches enabled. When
the capsule PEI gets around to coalescing the capsule, the MMU and
caches may still be disabled, and so on architectures where uncached
accesses are incoherent with the caches (such as ARM and AARCH64),
we need to ensure that the data passed into UpdateCapsule() is
written back to main memory before performing the warm reboot.
Unfortunately, on ARM, the only type of cache maintenance instructions
that are suitable for this purpose operate on virtual addresses only,
and given that the UpdateCapsule() prototype includes the physical
address of a linked list of scatter/gather data structures that are
mapped at an address that is unknown to the firmware (and may not even
be mapped at all when UpdateCapsule() is invoked), we can only perform
this cache maintenance at boot time. Fortunately, both Windows and Linux
only invoke UpdateCapsule() before calling ExitBootServices(), so this
is not a problem in practice.
In the future, we may propose adding a secure firmware service that
permits performing the cache maintenance at OS runtime, in which case
this code may be enhanced to call that service if available. For now,
we just fail any UpdateCapsule() calls performed at OS runtime on ARM.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-06-12 12:37:08 +02:00
CapsuleReset.c
2011-09-02 13:34:35 +02:00
[Sources.X64]
X64/SaveLongModeContext.c
MdeModulePkg/CapsuleRuntimeDxe: clean the capsule payload to DRAM
When capsule updates are staged for processing after a warm reboot,
they are copied into memory with the MMU and caches enabled. When
the capsule PEI gets around to coalescing the capsule, the MMU and
caches may still be disabled, and so on architectures where uncached
accesses are incoherent with the caches (such as ARM and AARCH64),
we need to ensure that the data passed into UpdateCapsule() is
written back to main memory before performing the warm reboot.
Unfortunately, on ARM, the only type of cache maintenance instructions
that are suitable for this purpose operate on virtual addresses only,
and given that the UpdateCapsule() prototype includes the physical
address of a linked list of scatter/gather data structures that are
mapped at an address that is unknown to the firmware (and may not even
be mapped at all when UpdateCapsule() is invoked), we can only perform
this cache maintenance at boot time. Fortunately, both Windows and Linux
only invoke UpdateCapsule() before calling ExitBootServices(), so this
is not a problem in practice.
In the future, we may propose adding a secure firmware service that
permits performing the cache maintenance at OS runtime, in which case
this code may be enhanced to call that service if available. For now,
we just fail any UpdateCapsule() calls performed at OS runtime on ARM.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-06-12 12:37:08 +02:00
CapsuleReset.c
[Sources.ARM, Sources.AARCH64]
SaveLongModeContext.c
Arm/CapsuleReset.c
2011-09-02 13:34:35 +02:00
2007-07-18 16:31:27 +02:00
[Packages]
MdePkg/MdePkg.dec
2007-08-29 10:52:49 +02:00
MdeModulePkg/MdeModulePkg.dec
2007-07-18 16:31:27 +02:00
[LibraryClasses]
UefiBootServicesTableLib
PcdLib
DebugLib
2009-01-04 04:20:55 +01:00
UefiRuntimeServicesTableLib
2007-07-18 16:31:27 +02:00
UefiDriverEntryPoint
2007-12-05 10:58:33 +01:00
CapsuleLib
2009-01-04 04:20:55 +01:00
UefiRuntimeLib
2010-02-23 03:33:17 +01:00
BaseLib
PrintLib
2013-10-15 03:31:49 +02:00
BaseMemoryLib
2011-09-02 13:34:35 +02:00
[LibraryClasses.X64]
UefiLib
BaseMemoryLib
2007-07-18 16:31:27 +02:00
MdeModulePkg/CapsuleRuntimeDxe: clean the capsule payload to DRAM
When capsule updates are staged for processing after a warm reboot,
they are copied into memory with the MMU and caches enabled. When
the capsule PEI gets around to coalescing the capsule, the MMU and
caches may still be disabled, and so on architectures where uncached
accesses are incoherent with the caches (such as ARM and AARCH64),
we need to ensure that the data passed into UpdateCapsule() is
written back to main memory before performing the warm reboot.
Unfortunately, on ARM, the only type of cache maintenance instructions
that are suitable for this purpose operate on virtual addresses only,
and given that the UpdateCapsule() prototype includes the physical
address of a linked list of scatter/gather data structures that are
mapped at an address that is unknown to the firmware (and may not even
be mapped at all when UpdateCapsule() is invoked), we can only perform
this cache maintenance at boot time. Fortunately, both Windows and Linux
only invoke UpdateCapsule() before calling ExitBootServices(), so this
is not a problem in practice.
In the future, we may propose adding a secure firmware service that
permits performing the cache maintenance at OS runtime, in which case
this code may be enhanced to call that service if available. For now,
we just fail any UpdateCapsule() calls performed at OS runtime on ARM.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2018-06-12 12:37:08 +02:00
[LibraryClasses.ARM, LibraryClasses.AARCH64]
CacheMaintenanceLib
2007-07-18 16:31:27 +02:00
[Guids]
2014-08-28 08:34:06 +02:00
## SOMETIMES_PRODUCES ## Variable:L"CapsuleUpdateData" # (Process across reset capsule image) for capsule updated data
## SOMETIMES_PRODUCES ## Variable:L"CapsuleLongModeBuffer" # The long mode buffer used by IA32 Capsule PEIM to call X64 CapsuleCoalesce code to handle >4GB capsule blocks
gEfiCapsuleVendorGuid
gEfiFmpCapsuleGuid ## SOMETIMES_CONSUMES ## GUID # FMP capsule GUID
2007-07-18 16:31:27 +02:00
[Protocols]
2014-08-28 08:34:06 +02:00
gEfiCapsuleArchProtocolGuid ## PRODUCES
2007-07-18 16:31:27 +02:00
2011-09-02 13:34:35 +02:00
[Protocols.X64]
2014-08-26 14:26:32 +02:00
## UNDEFINED ## NOTIFY
## SOMETIMES_CONSUMES
gEdkiiVariableLockProtocolGuid
2011-09-02 13:34:35 +02:00
2009-01-04 04:20:55 +01:00
[FeaturePcd]
2014-08-28 08:34:06 +02:00
gEfiMdeModulePkgTokenSpaceGuid.PcdSupportUpdateCapsuleReset ## CONSUMES
2007-07-18 16:31:27 +02:00
2011-09-02 13:34:35 +02:00
[FeaturePcd.X64]
2014-08-28 08:34:06 +02:00
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode ## CONSUMES
2011-09-02 13:34:35 +02:00
2009-03-05 06:05:57 +01:00
[Pcd]
2014-08-28 08:34:06 +02:00
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizeNonPopulateCapsule ## SOMETIMES_CONSUMES
2017-03-31 07:03:59 +02:00
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxSizePopulateCapsule ## SOMETIMES_CONSUMES # Populate Image requires reset support.
2007-07-18 16:31:27 +02:00
2011-09-02 13:34:35 +02:00
[Pcd.X64]
2014-08-28 08:34:06 +02:00
gEfiMdeModulePkgTokenSpaceGuid.PcdCapsulePeiLongModeStackSize ## SOMETIMES_CONSUMES
2014-08-26 14:26:32 +02:00
gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable ## SOMETIMES_CONSUMES
2011-09-02 13:34:35 +02:00
2007-07-18 16:31:27 +02:00
[Depex]
2014-08-28 08:34:06 +02:00
gEfiVariableWriteArchProtocolGuid # Depends on variable write functionality to produce capsule data variable
# [Hob.X64]
# UNDEFINED ## SOMETIMES_CONSUMES # CPU
[UserExtensions.TianoCore."ExtraFiles"]
CapsuleRuntimeDxeExtra.uni
