Re: [edk2] [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI
Laszlo,
Minor comments included below. I know from later items in this thread that
SMM_COMMUNICATE has already been removed in your local branch.
Reviewed-by: Michael Kinney
Mike
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, November 3, 2015 1:01 PM
> To: edk2-de...@ml01.01.org
> Cc: Kinney, Michael D ; Justen, Jordan L
>
> Subject: [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-SMRAM
> during PEI
>
> "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" is the library
> instance that implements the LockBoxLib library class with SMRAM access
> for the PEI phase.
>
> Introduce a PEIM that produces the EFI_PEI_SMM_COMMUNICATION_PPI and
> PEI_SMM_ACCESS_PPI interfaces, enabling SmmLockBoxPeiLib to work.
>
> Said library instance can parse and access LockBox data itself (without
> additional LockBox drivers) if the
> EFI_PEI_SMM_COMMUNICATION_PPI.Communicate() function returns
> EFI_NOT_STARTED to it. However it requires that
> EFI_PEI_SMM_COMMUNICATION_PPI exist at least. Also, PEI_SMM_ACCESS_PPI
> must exist and work.
>
> The load / installation order of S3Resume2Pei and SmmAccessPei is
> indifferent. SmmAccessPei produces the GUIDed HOB during its installation
> (which happens during PEI), but S3Resume2Pei accesses the HOB only when
> the DXE IPL calls its S3RestoreConfig2 PPI member, as last act of PEI.
>
> MCH_SMRAM_D_LCK and MCH_ESMRAMC_T_EN are masked out the way they are, in
> SmmAccessPeiEntryPoint() and SmramAccessOpen() respectively, in order to
> prevent VS20xx from warning about the (otherwise fully intentional)
> truncation in the UINT8 casts. (Warnings reported by Michael Kinney.)
>
> Cc: Michael Kinney
> Cc: Jordan Justen
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek
> ---
>
> Notes:
> v3:
> - update bit-neg expressions to silence VS20xx warnings [Mike]
>
> OvmfPkg/OvmfPkgIa32.dsc| 6 +
> OvmfPkg/OvmfPkgIa32X64.dsc | 6 +
> OvmfPkg/OvmfPkgX64.dsc | 6 +
> OvmfPkg/OvmfPkgIa32.fdf| 3 +
> OvmfPkg/OvmfPkgIa32X64.fdf | 3 +
> OvmfPkg/OvmfPkgX64.fdf | 3 +
> OvmfPkg/SmmAccess/SmmAccessPei.inf | 70 +++
> OvmfPkg/SmmAccess/SmramInternal.h | 89
> OvmfPkg/SmmAccess/SmmAccessPei.c | 446
> OvmfPkg/SmmAccess/SmramInternal.c | 188 +
> 10 files changed, 820 insertions(+)
>
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index c6850ff..0b729ca 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -445,6 +445,12 @@ [Components]
>
>PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>}
> +!if $(SMM_REQUIRE) == TRUE
> + OvmfPkg/SmmAccess/SmmAccessPei.inf {
> +
> + PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
> + }
> +!endif
>
>#
># DXE Phase modules
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index dd65bf9..7f672d9 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -451,6 +451,12 @@ [Components.IA32]
>
>PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>}
> +!if $(SMM_REQUIRE) == TRUE
> + OvmfPkg/SmmAccess/SmmAccessPei.inf {
> +
> + PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
> + }
> +!endif
>
> [Components.X64]
>#
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 0de3c85..986c019 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -450,6 +450,12 @@ [Components]
>
>PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>}
> +!if $(SMM_REQUIRE) == TRUE
> + OvmfPkg/SmmAccess/SmmAccessPei.inf {
> +
> + PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
> + }
> +!endif
>
>#
># DXE Phase modules
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index 44e4a92..650dab1 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -171,6 +171,9 @@ [FV.PEIFV]
> INF OvmfPkg/PlatformPei/PlatformPei.inf
> INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
> +!if $(SMM_REQUIRE) == TRUE
> +INF OvmfPkg/SmmAccess/SmmAccessPei.inf
> +!endif
>
>
>
>
> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
> index 67bfbe7..5830401 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.fdf
> +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
> @@ -171,6 +171,9 @@ [FV.PEIFV]
> INF OvmfPkg/PlatformPei/PlatformPei.inf
> INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
> +!if $(SMM_REQUIRE) == TRUE
> +INF OvmfPkg/SmmAccess/SmmAccessPei.inf
> +!endif
>
>
>
>
> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
> index 6624789..9dd6171 100644
> ---
Re: [edk2] [PATCH v4 26/41] OvmfPkg: build PiSmmCpuDxeSmm for -D SMM_REQUIRE
Laszlo,
Reviewed-by: Michael Kinney
Mike
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, November 3, 2015 1:01 PM
> To: edk2-de...@ml01.01.org
> Cc: Paolo Bonzini
> Subject: [edk2] [PATCH v4 26/41] OvmfPkg: build PiSmmCpuDxeSmm for -D
> SMM_REQUIRE
>
> At this point we can enable building PiSmmCpuDxeSmm.
>
> CPU specific features, like SMRR detection, and functions that are used to
> initialize SMM and process SMIs, are abstracted through the
> SmmCpuFeaturesLib class for the PiSmmCpuDxeSmm module. Resolve it to our
> own implementation under OvmfPkg -- it allows PiSmmCpuDxeSmm to work with
> QEMU's and KVM's 64-bit state save map format, which follows the
> definition from AMD's programmer manual.
>
> SmmCpuPlatformHookLib provides platform specific functions that are used
> to initialize SMM and process SMIs. Resolve it to the one Null instance
> provided by UefiCpuPkg, which is expected to work for most platforms.
>
> PiSmmCpuDxeSmm is not yet intended to function correctly with regard to
> S3; the upcoming, trimmed down CpuMpDxe port (under the name CpuS3DataDxe)
> will be necessary for that.
>
> Cc: Paolo Bonzini
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek
> [pbonz...@redhat.com: resolve the SmmCpuFeaturesLib class to OVMF's own
> instance]
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Paolo Bonzini
> ---
>
> Notes:
> v4:
> - Drop the SmmLib resolution from the DSC files, and the matching
> paragraph from the commit message. Starting with SVN r18673 / git
> f40577c3563f ("UefiCpuPkg: PiSmmCpuDxeSmm: Remove unused references to
> SmmLib"), PiSmmCpuDxeSmm depends on SmmLib no more.
>
> v3:
> - resolve SmmCpuFeaturesLib to OvmfPkg's own instance [Paolo]
>
> v2:
> - The module builds now for X64 too, thanks to Intel for open sourcing
> the X64 SMM entry vector (huge kudos). Update the commit message
> accordingly.
> - Thanks to Mike, PiSmmCpuDxeSmm and SmmCpuPlatformHookLibNull are now
> under UefiCpuPkg; update pathnames in the DSC / FDF files accordingly.
> - Version 2 of this patch also obviates "OvmfPkg: PiSmmCpuDxeSmm:
> eliminate SmmLib dependency" from v1.
> - Resolve SmmCpuFeaturesLib. This abstraction is new in Mike's
> PiSmmCpuDxeSmm module; Quark used to have similar code in
> "SmmFeatures.c" non-separably.
>
> OvmfPkg/OvmfPkgIa32.dsc| 5 +
> OvmfPkg/OvmfPkgIa32X64.dsc | 5 +
> OvmfPkg/OvmfPkgX64.dsc | 5 +
> OvmfPkg/OvmfPkgIa32.fdf| 1 +
> OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
> OvmfPkg/OvmfPkgX64.fdf | 1 +
> 6 files changed, 18 insertions(+)
>
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index f9b7af7..d6d7253 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -741,4 +741,9 @@ [Components]
>
>LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
>}
> + UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
> +
> +
> SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
> +
> SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> + }
> !endif
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 028c21a..cea39c6 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -748,4 +748,9 @@ [Components.X64]
>
>LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
>}
> + UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
> +
> +
> SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
> +
> SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> + }
> !endif
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 5ee17ff..98a0133 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -746,4 +746,9 @@ [Components]
>
>LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
>}
> + UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
> +
> +
> SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
> +
> SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> + }
> !endif
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index 53ddae3..7f9e201 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -362,6 +362,7 @@ [FV.DXEFV]
> INF MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
> INF UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
> INF MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf
> +INF UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
> !endif
>
>
>
> diff
Re: [edk2] [PATCH v4 24/41] OvmfPkg: use relaxed AP SMM synchronization mode
Laszlo,
Reviewed-by: Michael Kinney
Mike
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, November 3, 2015 1:01 PM
> To: edk2-de...@ml01.01.org
> Subject: [edk2] [PATCH v4 24/41] OvmfPkg: use relaxed AP SMM synchronization
> mode
>
> From: Paolo Bonzini
>
> Port 0xb2 on QEMU only sends an SMI to the currently executing processor.
> The SMI handler, however, and in particular SmmWaitForApArrival, currently
> expects that SmmControl2DxeTrigger triggers an SMI IPI on all processors
> rather than just the BSP. Thus all SMM invocations loop for a second (the
> default value of PcdCpuSmmApSyncTimeout) before SmmWaitForApArrival sends
> another SMI IPI to the APs.
>
> With the default SmmCpuFeaturesLib, 32-bit machines must broadcast SMIs
> because 32-bit machines must reset the MTRRs on each entry to system
> management modes (they have no SMRRs). However, our virtual platform
> does not have problems with cacheability of SMRAM, so we can use "directed"
> SMIs instead. To do this, just set
> gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode
> to 1 (aka SmmCpuSyncModeRelaxedAp). This fixes SMM on multiprocessor virtual
> machines.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Paolo Bonzini
> ---
>
> Notes:
> v3:
> - new in v3
>
> OvmfPkg/OvmfPkgIa32.dsc| 4
> OvmfPkg/OvmfPkgIa32X64.dsc | 4
> OvmfPkg/OvmfPkgX64.dsc | 4
> 3 files changed, 12 insertions(+)
>
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 6e14604..850c2ab 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -404,6 +404,10 @@ [PcdsFixedAtBuild]
>gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04,
> 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0,
> 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
> !endif
>
> +!if $(SMM_REQUIRE) == TRUE
> + gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
> +!endif
> +
> !if $(SECURE_BOOT_ENABLE) == TRUE
># override the default values from SecurityPkg to ensure images from all
> sources are verified in secure boot
>gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 1c9de14..48960a5 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -410,6 +410,10 @@ [PcdsFixedAtBuild]
> !endif
>
> [PcdsFixedAtBuild.X64]
> +!if $(SMM_REQUIRE) == TRUE
> + gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
> +!endif
> +
> !if $(SECURE_BOOT_ENABLE) == TRUE
># override the default values from SecurityPkg to ensure images from all
> sources are verified in secure boot
>gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index faf123e..bb93a72 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -409,6 +409,10 @@ [PcdsFixedAtBuild]
>gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04,
> 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0,
> 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
> !endif
>
> +!if $(SMM_REQUIRE) == TRUE
> + gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
> +!endif
> +
> !if $(SECURE_BOOT_ENABLE) == TRUE
># override the default values from SecurityPkg to ensure images from all
> sources are verified in secure boot
>gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04
> --
> 1.8.3.1
>
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 23/41] OvmfPkg: SmmCpuFeaturesLib: customize state save map format
Laszlo,
Reviewed-by: Michael Kinney
Mike
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, November 3, 2015 1:01 PM
> To: edk2-de...@ml01.01.org
> Cc: Paolo Bonzini
> Subject: [edk2] [PATCH v4 23/41] OvmfPkg: SmmCpuFeaturesLib: customize state
> save map format
>
> From: Paolo Bonzini
>
> This adjusts the previously introduced state save map access functions, to
> account for QEMU and KVM's 64-bit state save map following the AMD spec
> rather than the Intel one.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Paolo Bonzini
> [ler...@redhat.com: reflow commit message, convert patch to CRLF]
> Cc: Paolo Bonzini
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek
> ---
>
> Notes:
> v3:
> - new in v3
>
> OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf | 1 +
> OvmfPkg/Include/Register/QemuSmramSaveStateMap.h| 184
>
> OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 50 +++---
> 3 files changed, 212 insertions(+), 23 deletions(-)
>
> diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> index 594d85b..aaf4b02 100644
> --- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> +++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> @@ -27,6 +27,7 @@ [Sources]
>
> [Packages]
>MdePkg/MdePkg.dec
> + OvmfPkg/OvmfPkg.dec
>UefiCpuPkg/UefiCpuPkg.dec
>
> [LibraryClasses]
> diff --git a/OvmfPkg/Include/Register/QemuSmramSaveStateMap.h
> b/OvmfPkg/Include/Register/QemuSmramSaveStateMap.h
> new file mode 100644
> index 000..389428d
> --- /dev/null
> +++ b/OvmfPkg/Include/Register/QemuSmramSaveStateMap.h
> @@ -0,0 +1,184 @@
> +/** @file
> +SMRAM Save State Map Definitions.
> +
> +SMRAM Save State Map definitions based on contents of the
> +Intel(R) 64 and IA-32 Architectures Software Developer's Manual
> + Volume 3C, Section 34.4 SMRAM
> + Volume 3C, Section 34.5 SMI Handler Execution Environment
> + Volume 3C, Section 34.7 Managing Synchronous and Asynchronous SMIs
> +
> +and the AMD64 Architecture Programmer's Manual
> + Volume 2, Section 10.2 SMM Resources
> +
> +Copyright (c) 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2015, Red Hat, Inc.
> +This program and the accompanying materials
> +are licensed and made available under the terms and conditions of the BSD
> License
> +which accompanies this distribution. The full text of the license may be
> found at
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __QEMU_SMRAM_SAVE_STATE_MAP_H__
> +#define __QEMU_SMRAM_SAVE_STATE_MAP_H__
> +
> +#pragma pack (1)
> +
> +///
> +/// 32-bit SMRAM Save State Map
> +///
> +typedef struct {
> + UINT8 Reserved0[0x200]; // 7c00h
> + UINT8 Reserved1[0xf8]; // 7e00h
> + UINT32 SMBASE; // 7ef8h
> + UINT32 SMMRevId; // 7efch
> + UINT16 IORestart;// 7f00h
> + UINT16 AutoHALTRestart; // 7f02h
> + UINT8 Reserved2[0x9C]; // 7f08h
> + UINT32 IOMemAddr;// 7fa0h
> + UINT32 IOMisc; // 7fa4h
> + UINT32 _ES; // 7fa8h
> + UINT32 _CS; // 7fach
> + UINT32 _SS; // 7fb0h
> + UINT32 _DS; // 7fb4h
> + UINT32 _FS; // 7fb8h
> + UINT32 _GS; // 7fbch
> + UINT32 Reserved3;// 7fc0h
> + UINT32 _TR; // 7fc4h
> + UINT32 _DR7; // 7fc8h
> + UINT32 _DR6; // 7fcch
> + UINT32 _EAX; // 7fd0h
> + UINT32 _ECX; // 7fd4h
> + UINT32 _EDX; // 7fd8h
> + UINT32 _EBX; // 7fdch
> + UINT32 _ESP; // 7fe0h
> + UINT32 _EBP; // 7fe4h
> + UINT32 _ESI; // 7fe8h
> + UINT32 _EDI; // 7fech
> + UINT32 _EIP; // 7ff0h
> + UINT32 _EFLAGS; // 7ff4h
> + UINT32 _CR3; // 7ff8h
> + UINT32 _CR0; // 7ffch
> +} QEMU_SMRAM_SAVE_STATE_MAP32;
> +
> +///
> +/// 64-bit SMRAM Save State Map
> +///
> +typedef struct {
> + UINT8 Reserved0[0x200]; // 7c00h
> +
> + UINT16 _ES; // 7e00h
> + UINT16 _ESAccessRights; // 7e02h
> + UINT32 _ESLimit; // 7e04h
> + UINT64 _ESBase; // 7e08h
> +
> + UINT16 _CS; // 7e10h
> + UINT16 _CSAccessRights; // 7e12h
> + UINT32 _CSLimit; // 7e14h
> + UINT64 _CSBase; // 7e18h
> +
> + UINT16 _SS; // 7e20h
> + UINT16 _SSAccessRights; // 7e22h
> + UINT32 _SSLimit; // 7e24h
> + UINT64 _SSBase; // 7e28h
> +
> + UINT16 _DS; // 7e30h
> + UINT16
Re: [edk2] [PATCH v4 22/41] OvmfPkg: SmmCpuFeaturesLib: implement SMRAM state save map access
Laszlo,
Reviewed-by: Michael Kinney
Mike
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, November 3, 2015 1:01 PM
> To: edk2-de...@ml01.01.org
> Cc: Paolo Bonzini
> Subject: [edk2] [PATCH v4 22/41] OvmfPkg: SmmCpuFeaturesLib: implement SMRAM
> state save map access
>
> From: Paolo Bonzini
>
> This implementation copies SMRAM state save map access from the
> PiSmmCpuDxeSmm module.
>
> The most notable change is:
>
> - dropping support for EFI_SMM_SAVE_STATE_REGISTER_IO
>
> - changing the implementation of EFI_SMM_SAVE_STATE_REGISTER_LMA to use
> the SMM revision id instead of a local variable (which
> UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c initializes from CPUID's LM
> bit). This accounts for QEMU's implementation of x86_64, which always
> uses revision 0x20064 even if the LM bit is zero.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Paolo Bonzini
> [ler...@redhat.com: reflow commit message & fix typo, convert patch to
> CRLF]
> Cc: Paolo Bonzini
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek
> ---
>
> Notes:
> v3:
> - new in v3
>
> OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf | 2 +
> OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 377
> +++-
> 2 files changed, 376 insertions(+), 3 deletions(-)
>
> diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> index 656dd08..594d85b 100644
> --- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> +++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> @@ -31,5 +31,7 @@ [Packages]
>
> [LibraryClasses]
>BaseLib
> + BaseMemoryLib
>PcdLib
>DebugLib
> + SmmServicesTableLib
> diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> index 078ea96..bd825b4 100644
> --- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> +++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> @@ -15,11 +15,18 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> #include
> #include
> #include
> +#include
> #include
> #include
> +#include
> #include
> #include
>
> +//
> +// EFER register LMA bit
> +//
> +#define LMA BIT10
> +
> /**
>The constructor function
>
> @@ -125,7 +132,35 @@ SmmCpuFeaturesHookReturnFromSmm (
>IN UINT64NewInstructionPointer
>)
> {
> - return 0;
> + UINT64 OriginalInstructionPointer;
> + SMRAM_SAVE_STATE_MAP *CpuSaveState = (SMRAM_SAVE_STATE_MAP *)CpuState;
> +
> + if ((CpuSaveState->x86.SMMRevId & 0x) == 0) {
> +OriginalInstructionPointer = (UINT64)CpuSaveState->x86._EIP;
> +CpuSaveState->x86._EIP = (UINT32)NewInstructionPointer;
> +//
> +// Clear the auto HALT restart flag so the RSM instruction returns
> +// program control to the instruction following the HLT instruction.
> +//
> +if ((CpuSaveState->x86.AutoHALTRestart & BIT0) != 0) {
> + CpuSaveState->x86.AutoHALTRestart &= ~BIT0;
> +}
> + } else {
> +OriginalInstructionPointer = CpuSaveState->x64._RIP;
> +if ((CpuSaveState->x64.IA32_EFER & LMA) == 0) {
> + CpuSaveState->x64._RIP = (UINT32)NewInstructionPointer32;
> +} else {
> + CpuSaveState->x64._RIP = (UINT32)NewInstructionPointer;
> +}
> +//
> +// Clear the auto HALT restart flag so the RSM instruction returns
> +// program control to the instruction following the HLT instruction.
> +//
> +if ((CpuSaveState->x64.AutoHALTRestart & BIT0) != 0) {
> + CpuSaveState->x64.AutoHALTRestart &= ~BIT0;
> +}
> + }
> + return OriginalInstructionPointer;
> }
>
> /**
> @@ -356,6 +391,213 @@ SmmCpuFeaturesSetSmmRegister (
>ASSERT (FALSE);
> }
>
> +///
> +/// Macro used to simplify the lookup table entries of type
> CPU_SMM_SAVE_STATE_LOOKUP_ENTRY
> +///
> +#define SMM_CPU_OFFSET(Field) OFFSET_OF (SMRAM_SAVE_STATE_MAP, Field)
> +
> +///
> +/// Macro used to simplify the lookup table entries of type
> CPU_SMM_SAVE_STATE_REGISTER_RANGE
> +///
> +#define SMM_REGISTER_RANGE(Start, End) { Start, End, End - Start + 1 }
> +
> +///
> +/// Structure used to describe a range of registers
> +///
> +typedef struct {
> + EFI_SMM_SAVE_STATE_REGISTER Start;
> + EFI_SMM_SAVE_STATE_REGISTER End;
> + UINTNLength;
> +} CPU_SMM_SAVE_STATE_REGISTER_RANGE;
> +
> +///
> +/// Structure used to build a lookup table to retrieve the widths and offsets
> +/// associated with each supported EFI_SMM_SAVE_STATE_REGISTER value
> +///
> +
> +#define SMM_SAVE_STATE_REGISTER_FIRST_INDEX 1
> +
> +typedef struct {
> + UINT8 Width32;
> + UINT8 Width64;
> + UINT16 Offset32;
> + UINT16 Offset64Lo;
> + UINT16 Offset64Hi;
> + BOOLEAN W
Re: [edk2] [PATCH v4 21/41] OvmfPkg: SmmCpuFeaturesLib: remove unnecessary bits
Laszlo,
Reviewed-by: Michael Kinney
Mike
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, November 3, 2015 1:01 PM
> To: edk2-de...@ml01.01.org
> Cc: Paolo Bonzini
> Subject: [edk2] [PATCH v4 21/41] OvmfPkg: SmmCpuFeaturesLib: remove
> unnecessary bits
>
> From: Paolo Bonzini
>
> SMRR and MTRR support is not needed on a virtual platform.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Paolo Bonzini
> Acked-by: Laszlo Ersek
> [ler...@redhat.com: insert space between ASSERT and (), convert to CRLF]
> Cc: Paolo Bonzini
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek
> ---
>
> Notes:
> v3:
> - new in v3
>
> OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf | 4 -
> OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 180
> ++--
> 2 files changed, 18 insertions(+), 166 deletions(-)
>
> diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> index b04c028..656dd08 100644
> --- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> +++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> @@ -32,8 +32,4 @@ [Packages]
> [LibraryClasses]
>BaseLib
>PcdLib
> - MemoryAllocationLib
>DebugLib
> -
> -[Pcd]
> - gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber##
> SOMETIMES_CONSUMES
> diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> index dd09387..078ea96 100644
> --- a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> +++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c
> @@ -15,46 +15,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> -#include
> #include
>
> -//
> -// Machine Specific Registers (MSRs)
> -//
> -#define SMM_FEATURES_LIB_IA32_MTRR_CAP0x0FE
> -#define SMM_FEATURES_LIB_IA32_FEATURE_CONTROL 0x03A
> -#define SMM_FEATURES_LIB_IA32_SMRR_PHYSBASE 0x1F2
> -#define SMM_FEATURES_LIB_IA32_SMRR_PHYSMASK 0x1F3
> -#define SMM_FEATURES_LIB_IA32_CORE_SMRR_PHYSBASE 0x0A0
> -#define SMM_FEATURES_LIB_IA32_CORE_SMRR_PHYSMASK 0x0A1
> -#defineEFI_MSR_SMRR_MASK 0xF000
> -#defineEFI_MSR_SMRR_PHYS_MASK_VALIDBIT11
> -
> -//
> -// Set default value to assume SMRR is not supported
> -//
> -BOOLEAN mSmrrSupported = FALSE;
> -
> -//
> -// Set default value to assume IA-32 Architectural MSRs are used
> -//
> -UINT32 mSmrrPhysBaseMsr = SMM_FEATURES_LIB_IA32_SMRR_PHYSBASE;
> -UINT32 mSmrrPhysMaskMsr = SMM_FEATURES_LIB_IA32_SMRR_PHYSMASK;
> -
> -//
> -// Set default value to assume MTRRs need to be configured on each SMI
> -//
> -BOOLEAN mNeedConfigureMtrrs = TRUE;
> -
> -//
> -// Array for state of SMRR enable on all CPUs
> -//
> -BOOLEAN *mSmrrEnabled;
> -
> /**
>The constructor function
>
> @@ -68,91 +33,9 @@ SmmCpuFeaturesLibConstructor (
>IN EFI_SYSTEM_TABLE *SystemTable
>)
> {
> - UINT32 RegEax;
> - UINT32 RegEdx;
> - UINTN FamilyId;
> - UINTN ModelId;
> -
>//
> - // Retrieve CPU Family and Model
> + // No need to program SMRRs on our virtual platform.
>//
> - AsmCpuid (CPUID_VERSION_INFO, &RegEax, NULL, NULL, &RegEdx);
> - FamilyId = (RegEax >> 8) & 0xf;
> - ModelId = (RegEax >> 4) & 0xf;
> - if (FamilyId == 0x06 || FamilyId == 0x0f) {
> -ModelId = ModelId | ((RegEax >> 12) & 0xf0);
> - }
> -
> - //
> - // Check CPUID(CPUID_VERSION_INFO).EDX[12] for MTRR capability
> - //
> - if ((RegEdx & BIT12) != 0) {
> -//
> -// Check MTRR_CAP MSR bit 11 for SMRR support
> -//
> -if ((AsmReadMsr64 (SMM_FEATURES_LIB_IA32_MTRR_CAP) & BIT11) != 0) {
> - mSmrrSupported = TRUE;
> -}
> - }
> -
> - //
> - // Intel(R) 64 and IA-32 Architectures Software Developer's Manual
> - // Volume 3C, Section 35.3 MSRs in the Intel(R) Atom(TM) Processor Family
> - //
> - // If CPU Family/Model is 06_1CH, 06_26H, 06_27H, 06_35H or 06_36H, then
> - // SMRR Physical Base and SMM Physical Mask MSRs are not available.
> - //
> - if (FamilyId == 0x06) {
> -if (ModelId == 0x1C || ModelId == 0x26 || ModelId == 0x27 || ModelId ==
> 0x35 || ModelId == 0x36) {
> - mSmrrSupported = FALSE;
> -}
> - }
> -
> - //
> - // Intel(R) 64 and IA-32 Architectures Software Developer's Manual
> - // Volume 3C, Section 35.2 MSRs in the Intel(R) Core(TM) 2 Processor Family
> - //
> - // If CPU Family/Model is 06_0F or 06_17, then use Intel(R) Core(TM) 2
> - // Processor Family MSRs
> - //
> - if (FamilyId == 0x06) {
> -if (ModelId == 0x17 || ModelId == 0x0f) {
> - mSmrrPhysBaseMsr = SMM_FEATURES_LIB_IA32_CORE_SMRR_PHYSBASE;
> - mSmrrPhysMaskMs
Re: [edk2] [PATCH v4 20/41] OvmfPkg: import SmmCpuFeaturesLib from UefiCpuPkg
Laszlo, Reviewed-by: Michael Kinney Mike > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo > Ersek > Sent: Tuesday, November 3, 2015 1:01 PM > To: edk2-de...@ml01.01.org > Cc: Paolo Bonzini > Subject: [edk2] [PATCH v4 20/41] OvmfPkg: import SmmCpuFeaturesLib from > UefiCpuPkg > > From: Paolo Bonzini > > The next patches will customize the implementation, but let's start from > the common version to better show the changes. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Paolo Bonzini > [ler...@redhat.com: drop UNI file, keep whitespace intact, generate new > FILE_GUID, split off DSC changes, reflow commit message] > Cc: Paolo Bonzini > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Laszlo Ersek > --- > > Notes: > v3: > - new in v3 > > OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf | 39 ++ > OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 559 > > 2 files changed, 598 insertions(+) > > diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf > b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf > new file mode 100644 > index 000..b04c028 > --- /dev/null > +++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf > @@ -0,0 +1,39 @@ > +## @file > +# The CPU specific programming for PiSmmCpuDxeSmm module. > +# > +# Copyright (c) 2009 - 2015, Intel Corporation. All rights reserved. > +# This program and the accompanying materials > +# are licensed and made available under the terms and conditions of the BSD > License > +# which accompanies this distribution. The full text of the license may be > found at > +# http://opensource.org/licenses/bsd-license.php > +# > +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, > +# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR > IMPLIED. > +# > +## > + > +[Defines] > + INF_VERSION= 0x00010005 > + BASE_NAME = SmmCpuFeaturesLib > + MODULE_UNI_FILE= SmmCpuFeaturesLib.uni > + FILE_GUID = AC9991BE-D77A-464C-A8DE-A873DB8A4836 > + MODULE_TYPE= DXE_SMM_DRIVER > + VERSION_STRING = 1.0 > + LIBRARY_CLASS = SmmCpuFeaturesLib > + CONSTRUCTOR= SmmCpuFeaturesLibConstructor > + > +[Sources] > + SmmCpuFeaturesLib.c > + > +[Packages] > + MdePkg/MdePkg.dec > + UefiCpuPkg/UefiCpuPkg.dec > + > +[LibraryClasses] > + BaseLib > + PcdLib > + MemoryAllocationLib > + DebugLib > + > +[Pcd] > + gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber## > SOMETIMES_CONSUMES > diff --git a/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c > b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c > new file mode 100644 > index 000..dd09387 > --- /dev/null > +++ b/OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c > @@ -0,0 +1,559 @@ > +/** @file > +The CPU specific programming for PiSmmCpuDxeSmm module. > + > +Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved. > +This program and the accompanying materials > +are licensed and made available under the terms and conditions of the BSD > License > +which accompanies this distribution. The full text of the license may be > found at > +http://opensource.org/licenses/bsd-license.php > + > +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, > +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. > + > +**/ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +// > +// Machine Specific Registers (MSRs) > +// > +#define SMM_FEATURES_LIB_IA32_MTRR_CAP0x0FE > +#define SMM_FEATURES_LIB_IA32_FEATURE_CONTROL 0x03A > +#define SMM_FEATURES_LIB_IA32_SMRR_PHYSBASE 0x1F2 > +#define SMM_FEATURES_LIB_IA32_SMRR_PHYSMASK 0x1F3 > +#define SMM_FEATURES_LIB_IA32_CORE_SMRR_PHYSBASE 0x0A0 > +#define SMM_FEATURES_LIB_IA32_CORE_SMRR_PHYSMASK 0x0A1 > +#defineEFI_MSR_SMRR_MASK 0xF000 > +#defineEFI_MSR_SMRR_PHYS_MASK_VALIDBIT11 > + > +// > +// Set default value to assume SMRR is not supported > +// > +BOOLEAN mSmrrSupported = FALSE; > + > +// > +// Set default value to assume IA-32 Architectural MSRs are used > +// > +UINT32 mSmrrPhysBaseMsr = SMM_FEATURES_LIB_IA32_SMRR_PHYSBASE; > +UINT32 mSmrrPhysMaskMsr = SMM_FEATURES_LIB_IA32_SMRR_PHYSMASK; > + > +// > +// Set default value to assume MTRRs need to be configured on each SMI > +// > +BOOLEAN mNeedConfigureMtrrs = TRUE; > + > +// > +// Array for state of SMRR enable on all CPUs > +// > +BOOLEAN *mSmrrEnabled; > + > +/** > + The constructor function > + > + @retval EFI_SUCCESS The constructor always returns RETURN_SUCCESS. > + > +**/ > +EFI_STATUS > +EFIAPI > +SmmCpuFea
Re: [edk2] [PATCH v4 09/41] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER
Laszlo, Minor comments included below. Reviewed-by: Michael Kinney Mike > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo > Ersek > Sent: Tuesday, November 3, 2015 1:01 PM > To: edk2-de...@ml01.01.org > Subject: [edk2] [PATCH v4 09/41] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL > with a DXE_RUNTIME_DRIVER > > The EFI_SMM_COMMUNICATION_PROTOCOL implementation that is provided by the SMM > core depends on > EFI_SMM_CONTROL2_PROTOCOL; see the > mSmmControl2->Trigger() call in the SmmCommunicationCommunicate() > mSmmControl2->function > [MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c]. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Laszlo Ersek > --- > > Notes: > v2: > - Set (APMC_EN|GBL_SMI_EN) in SMI_EN from the boot script at S3 resume. > Otherwise, because SMI_EN is cleared during warm reset, > SmmControl2DxeTrigger() would fail to trigger an SMI, and variable > access through the runtime services would fail. > > Set SMI_LOCK in GEN_PMCON_1 similarly. > > OvmfPkg/OvmfPkgIa32.dsc | 1 + > OvmfPkg/OvmfPkgIa32X64.dsc| 1 + > OvmfPkg/OvmfPkgX64.dsc| 1 + > OvmfPkg/OvmfPkgIa32.fdf | 1 + > OvmfPkg/OvmfPkgIa32X64.fdf| 1 + > OvmfPkg/OvmfPkgX64.fdf| 1 + > OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf | 65 > OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c | 365 > 8 files changed, 436 insertions(+) > > diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index > d7bc38d..c71a2f4 100644 > --- a/OvmfPkg/OvmfPkgIa32.dsc > +++ b/OvmfPkg/OvmfPkgIa32.dsc > @@ -675,4 +675,5 @@ [Components] > > !if $(SMM_REQUIRE) == TRUE >OvmfPkg/SmmAccess/SmmAccess2Dxe.inf > + OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf > !endif > diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc index > e17cbe5..a1e8f0d 100644 > --- a/OvmfPkg/OvmfPkgIa32X64.dsc > +++ b/OvmfPkg/OvmfPkgIa32X64.dsc > @@ -682,4 +682,5 @@ [Components.X64] > > !if $(SMM_REQUIRE) == TRUE >OvmfPkg/SmmAccess/SmmAccess2Dxe.inf > + OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf > !endif > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index > a748fb3..1176629 100644 > --- a/OvmfPkg/OvmfPkgX64.dsc > +++ b/OvmfPkg/OvmfPkgX64.dsc > @@ -680,4 +680,5 @@ [Components] > > !if $(SMM_REQUIRE) == TRUE >OvmfPkg/SmmAccess/SmmAccess2Dxe.inf > + OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf > !endif > diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf index > 285720f..43c9c30 100644 > --- a/OvmfPkg/OvmfPkgIa32.fdf > +++ b/OvmfPkg/OvmfPkgIa32.fdf > @@ -357,6 +357,7 @@ [FV.DXEFV] > > !if $(SMM_REQUIRE) == TRUE > INF OvmfPkg/SmmAccess/SmmAccess2Dxe.inf > +INF OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf > !endif > > > > diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf index > 02e8752..9446896 100644 > --- a/OvmfPkg/OvmfPkgIa32X64.fdf > +++ b/OvmfPkg/OvmfPkgIa32X64.fdf > @@ -357,6 +357,7 @@ [FV.DXEFV] > > !if $(SMM_REQUIRE) == TRUE > INF OvmfPkg/SmmAccess/SmmAccess2Dxe.inf > +INF OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf > !endif > > > > diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf index > f04c36b..b272b76 100644 > --- a/OvmfPkg/OvmfPkgX64.fdf > +++ b/OvmfPkg/OvmfPkgX64.fdf > @@ -357,6 +357,7 @@ [FV.DXEFV] > > !if $(SMM_REQUIRE) == TRUE > INF OvmfPkg/SmmAccess/SmmAccess2Dxe.inf > +INF OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf > !endif > > > > diff --git a/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf > b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf > new file mode 100644 > index 000..bc66a27 > --- /dev/null > +++ b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf > @@ -0,0 +1,65 @@ > +## @file > +# A DXE_RUNTIME_DRIVER providing synchronous SMI activations via the # > +EFI_SMM_CONTROL2_PROTOCOL. > +# > +# We expect the PEI phase to have covered the following: > +# - ensure that the underlying QEMU machine type be Q35 > +# (responsible: OvmfPkg/SmmAccess/SmmAccessPei.inf) > +# - ensure that the ACPI PM IO space be configured > +# (responsible: OvmfPkg/PlatformPei/PlatformPei.inf) > +# > +# Our own entry point is responsible for confirming the SMI feature and > +for # configuring it. > +# > +# Copyright (C) 2013, 2015, Red Hat, Inc. > +# > +# This program and the accompanying materials are licensed and made > +available # under the terms and conditions of the BSD License which > +accompanies this # distribution. The full text of the license may be > +found at # http://opensource.org/licenses/bsd-license.php > +# > +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN
Re: [edk2] [PATCH v4 08/41] OvmfPkg: add DXE_DRIVER for providing TSEG-as-SMRAM during boot-time DXE
Laszlo, Minor comments included below. Reviewed-by: Michael Kinney Mike > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo > Ersek > Sent: Tuesday, November 3, 2015 1:01 PM > To: edk2-de...@ml01.01.org > Subject: [edk2] [PATCH v4 08/41] OvmfPkg: add DXE_DRIVER for providing > TSEG-as-SMRAM during boot-time DXE > > The SMM core depends on EFI_SMM_ACCESS2_PROTOCOL. This small driver (which is > a thin wrapper around > "OvmfPkg/SmmAccess/SmramInternal.c" that was added in the previous patch) > provides that protocol. > > Notably, EFI_SMM_ACCESS2_PROTOCOL is for boot time only, therefore our > MODULE_TYPE is not DXE_RUNTIME_DRIVER. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Laszlo Ersek > --- > OvmfPkg/OvmfPkgIa32.dsc | 4 + > OvmfPkg/OvmfPkgIa32X64.dsc | 4 + > OvmfPkg/OvmfPkgX64.dsc | 4 + > OvmfPkg/OvmfPkgIa32.fdf | 4 + > OvmfPkg/OvmfPkgIa32X64.fdf | 4 + > OvmfPkg/OvmfPkgX64.fdf | 4 + > OvmfPkg/SmmAccess/SmmAccess2Dxe.inf | 57 +++ > OvmfPkg/SmmAccess/SmmAccess2Dxe.c | 156 > 8 files changed, 237 insertions(+) > > diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index > 0b729ca..d7bc38d 100644 > --- a/OvmfPkg/OvmfPkgIa32.dsc > +++ b/OvmfPkg/OvmfPkgIa32.dsc > @@ -672,3 +672,7 @@ [Components] > !endif > >OvmfPkg/PlatformDxe/Platform.inf > + > +!if $(SMM_REQUIRE) == TRUE > + OvmfPkg/SmmAccess/SmmAccess2Dxe.inf > +!endif > diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc index > 7f672d9..e17cbe5 100644 > --- a/OvmfPkg/OvmfPkgIa32X64.dsc > +++ b/OvmfPkg/OvmfPkgIa32X64.dsc > @@ -679,3 +679,7 @@ [Components.X64] > !endif > >OvmfPkg/PlatformDxe/Platform.inf > + > +!if $(SMM_REQUIRE) == TRUE > + OvmfPkg/SmmAccess/SmmAccess2Dxe.inf > +!endif > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index > 986c019..a748fb3 100644 > --- a/OvmfPkg/OvmfPkgX64.dsc > +++ b/OvmfPkg/OvmfPkgX64.dsc > @@ -677,3 +677,7 @@ [Components] > !endif > >OvmfPkg/PlatformDxe/Platform.inf > + > +!if $(SMM_REQUIRE) == TRUE > + OvmfPkg/SmmAccess/SmmAccess2Dxe.inf > +!endif > diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf index > 650dab1..285720f 100644 > --- a/OvmfPkg/OvmfPkgIa32.fdf > +++ b/OvmfPkg/OvmfPkgIa32.fdf > @@ -355,6 +355,10 @@ [FV.DXEFV] > INF OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf > INF OvmfPkg/PlatformDxe/Platform.inf > > +!if $(SMM_REQUIRE) == TRUE > +INF OvmfPkg/SmmAccess/SmmAccess2Dxe.inf > +!endif > + > > > > [FV.FVMAIN_COMPACT] > diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf index > 5830401..02e8752 100644 > --- a/OvmfPkg/OvmfPkgIa32X64.fdf > +++ b/OvmfPkg/OvmfPkgIa32X64.fdf > @@ -355,6 +355,10 @@ [FV.DXEFV] > INF OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf > INF OvmfPkg/PlatformDxe/Platform.inf > > +!if $(SMM_REQUIRE) == TRUE > +INF OvmfPkg/SmmAccess/SmmAccess2Dxe.inf > +!endif > + > > > > [FV.FVMAIN_COMPACT] > diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf index > 9dd6171..f04c36b 100644 > --- a/OvmfPkg/OvmfPkgX64.fdf > +++ b/OvmfPkg/OvmfPkgX64.fdf > @@ -355,6 +355,10 @@ [FV.DXEFV] > INF OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf > INF OvmfPkg/PlatformDxe/Platform.inf > > +!if $(SMM_REQUIRE) == TRUE > +INF OvmfPkg/SmmAccess/SmmAccess2Dxe.inf > +!endif > + > > > > [FV.FVMAIN_COMPACT] > diff --git a/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf > b/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf > new file mode 100644 > index 000..3ce48ae > --- /dev/null > +++ b/OvmfPkg/SmmAccess/SmmAccess2Dxe.inf > @@ -0,0 +1,57 @@ > +## @file > +# A DXE_DRIVER providing SMRAM access by producing EFI_SMM_ACCESS2_PROTOCOL. > +# > +# Q35 TSEG is expected to have been verified and set up by the > +SmmAccessPei # driver. > +# > +# Copyright (C) 2013, 2015, Red Hat, Inc. > +# > +# This program and the accompanying materials are licensed and made > +available # under the terms and conditions of the BSD License which > +accompanies this # distribution. The full text of the license may be > +found at # http://opensource.org/licenses/bsd-license.php > +# > +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, > +WITHOUT # WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR > IMPLIED. > +# > +## > + > +[Defines] > + INF_VERSION= 0x00010005 > + BASE_NAME = SmmAccess2Dxe > + FILE_GUID = AC95AD3D-4366-44BF-9A62-E4B29D7A2206 > + MODULE_TYPE= DXE_DRIVER > + VERSION_STRING = 1.0 > + PI_SPECIFICATION_VERSION = 0x00010400 > + ENTRY_POINT
Re: [edk2] How to add /O1 (min size) compile option to edk2 apps ?
Andrew, A minor correction on DEBUG and RELEASE. DEBUG - Size optimized with symbolic debug information included. There are some platforms DSC files that overload the build target DEBUG to also enable the libraries and PCD settings to generate log messages. Some other platforms use a define name (e.g. LOGGING) to enable/disable log messages. RELEASE - Size optimized with symbolic debug information stripped. Best regards, Mike > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew > Fish > Sent: Friday, November 20, 2015 3:01 PM > To: Shubha Ramani > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] How to add /O1 (min size) compile option to edk2 apps ? > > > > On Nov 20, 2015, at 2:42 PM, Shubha Ramani wrote: > > > > Forgot to mentionunder[BuildOptions] in the *.inf file Shubha D. > > ramanishubharam...@gmail.com shubharam...@yahoo.com > > > > > >On Friday, November 20, 2015 2:41 PM, Shubha Ramani > > wrote: > > > > > > For instance, if I already have this:MSFT:NOOPT_*_*_CC_FLAGS = /D > > ENABLE_PRINT > > > > *_*_*_CC_FLAGS are the compiler flags so you add them. For most compilers the > last flag wins. > > But you should not need to add anything as the there are already three sets > of flags. > NOOPT - Optimizations disabled for debugging. > DEBUG - Size optimized, but with DEBUG prints > RELEASE - Size optimized. > > So all you need to do is change the -b, --buildtarget=BUILDTARGET, flag to > the build command to change which of the build targets are > being used. > So: build -b RELEASE > > The optimization flags for VC++ are more complex than /O1, as it is uses a > very specific /O1 variant and also uses other flags to turn on > link time optimization. > > Thanks, > > Andrew Fish > > > How do I also add /O1 (that's capitol letter "O" 1). > > Thanks, > > Shubha Shubha D. ramanishubharam...@gmail.com shubharam...@yahoo.com > > > > > > ___ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Dynamic PCD Variable Storage in PEI Phase
> On Nov 20, 2015, at 4:52 PM, Narinder Dhillon wrote: > > Hi All, > > Is it possible to set a dynamic PCD variable in PEI phase and get it > in DXE phase ? > Yes. > I am having trouble setting it. Log below. > > Thanx, > > add-symbol-file > /projects/cps-sw-ext1/ndhillon/uefi_cleanup/firmware/uefi/Build/DEBUG_GCC49/AARCH64/ArmPlatformPkg/PrePeiCore/PrePeiCoreMPCore/DEBUG/ArmPlatformPrePeiCore.dll > 0xC0001800 > add-symbol-file > /projects/cps-sw-ext1/ndhillon/uefi_cleanup/firmware/uefi/Build/DEBUG_GCC49/AARCH64/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll > 0xC0016A90 > Platform: Nodes:0 Cores:176 Threads:1 > ASSERT > /projects/cps-sw-ext1/ndhillon/uefi_cleanup/firmware/uefi/MdePkg/Library/BasePcdLibNull/PcdLib.c(470): > ((BOOLEAN)(0==1)) You are using the wrong PcdLib instance. The BasePcdLibNull instance will ASSERT on any calls. You want to use the instances of the library that call the PPI/Protocol. https://github.com/tianocore/edk2/tree/master/MdePkg/Library/PeiPcdLib https://github.com/tianocore/edk2/tree/master/MdePkg/Library/DxePcdLib Thanks, Andrew Fish > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Dynamic PCD Variable Storage in PEI Phase
Hi All, Is it possible to set a dynamic PCD variable in PEI phase and get it in DXE phase ? I am having trouble setting it. Log below. Thanx, add-symbol-file /projects/cps-sw-ext1/ndhillon/uefi_cleanup/firmware/uefi/Build/DEBUG_GCC49/AARCH64/ArmPlatformPkg/PrePeiCore/PrePeiCoreMPCore/DEBUG/ArmPlatformPrePeiCore.dll 0xC0001800 add-symbol-file /projects/cps-sw-ext1/ndhillon/uefi_cleanup/firmware/uefi/Build/DEBUG_GCC49/AARCH64/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll 0xC0016A90 Platform: Nodes:0 Cores:176 Threads:1 ASSERT /projects/cps-sw-ext1/ndhillon/uefi_cleanup/firmware/uefi/MdePkg/Library/BasePcdLibNull/PcdLib.c(470): ((BOOLEAN)(0==1)) ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch V3 2/2] MdeModulePkg FileExplorerDxe: Create file explorer Protocol.
Reviewed-by: Samer El-Haj-Mahmoud
-Original Message-
From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Wednesday, November 11, 2015 12:30 AM
To: af...@apple.com
Cc: edk2-devel@lists.01.org; Sheng, Cecil (HPS SW) ;
El-Haj-Mahmoud, Samer ; Gao, Liming
Subject: RE: [edk2] [Patch V3 2/2] MdeModulePkg FileExplorerDxe: Create file
explorer Protocol.
Yes, will update when check in the code.
-Original Message-
From: af...@apple.com [mailto:af...@apple.com]
Sent: Wednesday, November 11, 2015 1:41 PM
To: Dong, Eric
Cc: edk2-devel@lists.01.org; cecil.sh...@hpe.com; samer.el-haj-mahm...@hpe.com;
Gao, Liming
Subject: Re: [edk2] [Patch V3 2/2] MdeModulePkg FileExplorerDxe: Create file
explorer Protocol.
> On Nov 10, 2015, at 9:34 PM, Eric Dong wrote:
>
> This driver produces file explorer protocol layered on top of the
> FileExplorerLib.
>
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Eric Dong
> ---
> MdeModulePkg/Include/Protocol/FileExplorer.h | 75 +
> .../Library/FileExplorerLib/FileExplorerLib.inf| 3 +-
> MdeModulePkg/MdeModulePkg.dec | 3 +
> MdeModulePkg/MdeModulePkg.dsc | 2 +
> .../Universal/FileExplorerDxe/FileExplorerDxe.c| 58
> .../Universal/FileExplorerDxe/FileExplorerDxe.inf | 53
> +++ .../Universal/FileExplorerDxe/FileExplorerDxe.uni | Bin 0 ->
> 2038 bytes
> .../FileExplorerDxe/FileExplorerDxeExtra.uni | Bin 0 -> 1362 bytes
> 8 files changed, 193 insertions(+), 1 deletion(-) create mode 100644
> MdeModulePkg/Include/Protocol/FileExplorer.h
> create mode 100644
> MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxe.c
> create mode 100644
> MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxe.inf
> create mode 100644
> MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxe.uni
> create mode 100644
> MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxeExtra.uni
>
> diff --git a/MdeModulePkg/Include/Protocol/FileExplorer.h
> b/MdeModulePkg/Include/Protocol/FileExplorer.h
> new file mode 100644
> index 000..7f6cbd9
> --- /dev/null
> +++ b/MdeModulePkg/Include/Protocol/FileExplorer.h
> @@ -0,0 +1,75 @@
> +/** @file
> +
> + This file explorer protocol defines defines a set of interfaces for
> + how to do file explorer.
> +
> +Copyright (c) 2006 - 2010, Intel Corporation. All rights
> +reserved.
Should this be 2015?
Thanks,
Andrew Fish
> +This program and the accompanying materials are licensed and made
> +available under the terms and conditions of the BSD License that accompanies
> this distribution.
> +The full text of the license may be found at
> +http://opensource.org/licenses/bsd-license.php.
>
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __FILE_EXPLORER_H__
> +#define __FILE_EXPLORER_H__
> +
> +#define EFI_FILE_EXPLORER_PROTOCOL_GUID \
> + { 0x2C03C536, 0x4594, 0x4515, { 0x9E, 0x7A, 0xD3, 0xD2, 0x04, 0xFE,
> +0x13, 0x63 } }
> +
> +//
> +// Forward reference for pure ANSI compatability // typedef struct
> +_EFI_FILE_EXPLORER_PROTOCOL EFI_FILE_EXPLORER_PROTOCOL;
> +
> +/**
> + Prototype for the next process after user chosed one file.
> +
> + @param[in] FilePath The device path of the find file.
> +
> + @retvalTRUE Need exit file explorer after do the extra task.
> + @retvalFALSENot need to exit file explorer after do the extra
> task.
> +
> +**/
> +typedef
> +BOOLEAN
> +(EFIAPI *CHOOSE_HANDLER)(
> + IN EFI_DEVICE_PATH_PROTOCOL *FilePath
> + );
> +
> +/**
> + Choose a file in the specified directory.
> +
> + If user input NULL for the RootDirectory, will choose file in the system.
> +
> + If user input *File != NULL, function will return the allocate
> + device path info for the choosed file, caller has to free the memory after
> use it.
> +
> + @param RootDirectoryPointer to the root directory.
> + @param FileType The file type need to choose.
> + @param ChooseHandlerFunction pointer to the extra task need to do
> + after choose one file.
> + @param File Return the device path for the last time chosed
> file.
> +
> + @retval EFI_SUCESS Choose the file success.
> + @retval Other errors Choose the file failed.
> +**/
> +typedef
> +EFI_STATUS
> +(EFIAPI *CHOOSE_FILE) (
> + IN EFI_DEVICE_PATH_PROTOCOL *RootDirectory,
> + IN CHAR16*FileType, OPTIONAL
> + IN CHOOSE_HANDLERChooseHandler, OPTIONAL
> + OUT EFI_DEVICE_PATH_PROTOCOL **File OPTIONAL
> + );
> +
> +struct _EFI_FILE_EXPLORER_PROTOCOL {
> + CHOOSE_FILE ChooseFile;
> +};
> +
> +extern EFI_GUID gEfiFileExplorerProtocolGuid;
> +
>
Re: [edk2] How to add /O1 (min size) compile option to edk2 apps ?
> On Nov 20, 2015, at 2:42 PM, Shubha Ramani wrote: > > Forgot to mentionunder[BuildOptions] in the *.inf file > Shubha D. ramanishubharam...@gmail.com > shubharam...@yahoo.com > > >On Friday, November 20, 2015 2:41 PM, Shubha Ramani > wrote: > > > For instance, if I already have this:MSFT:NOOPT_*_*_CC_FLAGS = /D > ENABLE_PRINT > *_*_*_CC_FLAGS are the compiler flags so you add them. For most compilers the last flag wins. But you should not need to add anything as the there are already three sets of flags. NOOPT - Optimizations disabled for debugging. DEBUG - Size optimized, but with DEBUG prints RELEASE - Size optimized. So all you need to do is change the -b, --buildtarget=BUILDTARGET, flag to the build command to change which of the build targets are being used. So: build -b RELEASE The optimization flags for VC++ are more complex than /O1, as it is uses a very specific /O1 variant and also uses other flags to turn on link time optimization. Thanks, Andrew Fish > How do I also add /O1 (that's capitol letter "O" 1). > Thanks, > Shubha Shubha D. ramanishubharam...@gmail.com > shubharam...@yahoo.com > > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] How to add /O1 (min size) compile option to edk2 apps ?
Forgot to mentionunder[BuildOptions] in the *.inf file Shubha D. ramanishubharam...@gmail.com shubharam...@yahoo.com On Friday, November 20, 2015 2:41 PM, Shubha Ramani wrote: For instance, if I already have this:MSFT:NOOPT_*_*_CC_FLAGS = /D ENABLE_PRINT How do I also add /O1 (that's capitol letter "O" 1). Thanks, Shubha Shubha D. ramanishubharam...@gmail.com shubharam...@yahoo.com ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] How to add /O1 (min size) compile option to edk2 apps ?
For instance, if I already have this:MSFT:NOOPT_*_*_CC_FLAGS = /D ENABLE_PRINT How do I also add /O1 (that's capitol letter "O" 1). Thanks, Shubha Shubha D. ramanishubharam...@gmail.com shubharam...@yahoo.com ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 2/3] Convert ArmJunoDxe to use common juno revision code
Now that the code to detect the Juno revision is in
the header, convert the ArmJunoDxe to use it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton
---
.../ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 52 --
1 file changed, 8 insertions(+), 44 deletions(-)
diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
index 756c275..780e56a 100644
--- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
+++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
@@ -37,14 +37,6 @@
//
#define SKY2_MAC_ADDRESS_BOOTARG_LEN 47
-//
-// Hardware platform identifiers
-//
-typedef enum {
- UNKNOWN,
- JUNO_R0,
- JUNO_R1
-} JUNO_REVISION;
//
// Function prototypes
@@ -229,13 +221,9 @@ ArmJunoEntryPoint (
CHAR16*TextDevicePath;
UINTN TextDevicePathSize;
VOID *Buffer;
- UINT32Midr;
- UINT32CpuType;
- UINT32CpuRev;
- JUNO_REVISION JunoRevision;
+ UINT32JunoRevision;
EFI_EVENT EndOfDxeEvent;
-
- JunoRevision = UNKNOWN;
+
Status = PciEmulationEntryPoint ();
if (EFI_ERROR (Status)) {
return Status;
@@ -300,38 +288,14 @@ ArmJunoEntryPoint (
DEBUG ((EFI_D_ERROR, "ArmJunoDxe: Failed to install ShellDynCmdRunAxf\n"));
}
- //
- // We detect whether we are running on a Juno r0 or Juno r1 board at
- // runtime by checking the value of the MIDR register.
- //
-
- Midr = ArmReadMidr ();
- CpuType = (Midr >> ARM_CPU_TYPE_SHIFT) & ARM_CPU_TYPE_MASK;
- CpuRev = Midr & ARM_CPU_REV_MASK;
-
- switch (CpuType) {
- case ARM_CPU_TYPE_A53:
-if (CpuRev == ARM_CPU_REV (0, 0)) {
- JunoRevision = JUNO_R0;
-} else if (CpuRev == ARM_CPU_REV (0, 3)) {
- JunoRevision = JUNO_R1;
-}
-break;
-
- case ARM_CPU_TYPE_A57:
-if (CpuRev == ARM_CPU_REV (0, 0)) {
- JunoRevision = JUNO_R0;
-} else if (CpuRev == ARM_CPU_REV (1, 1)) {
- JunoRevision = JUNO_R1;
-}
- }
+ GetJunoRevision(JunoRevision);
//
// Try to install the ACPI Tables
//
- if (JunoRevision == JUNO_R0) {
+ if (JunoRevision == JUNO_REVISION_R0) {
Status = LocateAndInstallAcpiFromFvConditional (&mJunoAcpiTableFile,
AcpiTableJunoR0Check);
- } else if (JunoRevision == JUNO_R1) {
+ } else if (JunoRevision == JUNO_REVISION_R1) {
Status = LocateAndInstallAcpiFromFvConditional (&mJunoAcpiTableFile,
AcpiTableJunoR1Check);
}
ASSERT_EFI_ERROR (Status);
@@ -340,7 +304,7 @@ ArmJunoEntryPoint (
//
// Set the R1 two boot options if not already done.
//
- if (JunoRevision == JUNO_R1) {
+ if (JunoRevision == JUNO_REVISION_R1) {
Status = SetJunoR1DefaultBootEntries ();
if (EFI_ERROR (Status)) {
return Status;
@@ -363,11 +327,11 @@ ArmJunoEntryPoint (
// Set up the device path to the FDT.
//
switch (JunoRevision) {
- case JUNO_R0:
+ case JUNO_REVISION_R0:
TextDevicePath = (CHAR16*)FixedPcdGetPtr (PcdJunoR0FdtDevicePath);
break;
- case JUNO_R1:
+ case JUNO_REVISION_R1:
TextDevicePath = (CHAR16*)FixedPcdGetPtr (PcdJunoR1A57x2FdtDevicePath);
break;
--
2.4.3
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 1/3] Code to detect what juno revision we are running on.
The code to detect what juno revision we are running on
is fairly small. Put it in a common header, where it may be
shared by a couple modules.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton
---
ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h | 41 +
1 file changed, 41 insertions(+)
diff --git a/ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h
b/ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h
index d01d136..0e72a5c 100644
--- a/ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h
+++ b/ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h
@@ -83,6 +83,47 @@
EFI_ACPI_ARM_CREATOR_REVISION /* UINT32 CreatorRevision */ \
}
+//
+// Hardware platform identifiers
+//
+#define JUNO_REVISION_UNKNOWN 0
+#define JUNO_REVISION_R0 1
+#define JUNO_REVISION_R1 2
+
+//
+// We detect whether we are running on a Juno r0 or Juno r1
+// board at runtime by checking the value of the MIDR register.
+//
+#define GetJunoRevision(JunoRevision) \
+{ \
+ UINT32Midr; \
+ UINT32CpuType; \
+ UINT32CpuRev;\
+ \
+ JunoRevision = JUNO_REVISION_UNKNOWN;\
+ \
+ Midr = ArmReadMidr (); \
+ CpuType = (Midr >> ARM_CPU_TYPE_SHIFT) & ARM_CPU_TYPE_MASK; \
+ CpuRev = Midr & ARM_CPU_REV_MASK; \
+ \
+ switch (CpuType) { \
+ case ARM_CPU_TYPE_A53: \
+if (CpuRev == ARM_CPU_REV (0, 0)) {\
+ JunoRevision = JUNO_REVISION_R0; \
+} else if (CpuRev == ARM_CPU_REV (0, 3)) { \
+ JunoRevision = JUNO_REVISION_R1; \
+} \
+break; \
+ \
+ case ARM_CPU_TYPE_A57: \
+if (CpuRev == ARM_CPU_REV (0, 0)) {\
+ JunoRevision = JUNO_REVISION_R0; \
+} else if (CpuRev == ARM_CPU_REV (1, 1)) { \
+ JunoRevision = JUNO_REVISION_R1; \
+} \
+ }\
+}
+
#define JUNO_WATCHDOG_COUNT 2
// Define if the exported ACPI Tables are based on ACPI 5.0 spec or latest
--
2.4.3
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 3/3] ArmPlatformPkg/ArmJunoPkg: Create SMBIOS/DMI data for Juno
SMBIOS data is consumed by a wide range of enterprise applications. Fill in the basic requirements of the SMBIOS specification by hardcoding the minimum required structures and data using Juno information. With this change both the EFI shell and linux dmidecode commands return useful information. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeremy Linton --- ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc | 12 + ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf | 6 + .../SmbiosPlatformDxe/SmbiosPlatformDxe.c | 781 + .../SmbiosPlatformDxe/SmbiosPlatformDxe.inf| 69 ++ 4 files changed, 868 insertions(+) create mode 100644 ArmPlatformPkg/ArmJunoPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c create mode 100644 ArmPlatformPkg/ArmJunoPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf diff --git a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc index f5af426..7a26cd8 100644 --- a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc +++ b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc @@ -161,6 +161,12 @@ gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|5000 gEmbeddedTokenSpaceGuid.PcdMetronomeTickPeriod|1000 + # + # SMBIOS entry point version + # + gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion|0x0300 + gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosDocRev|0x0 + [PcdsPatchableInModule] # Console Resolution (Full HD) gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|1920 @@ -286,6 +292,12 @@ ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf # + # SMBIOS/DMI + # + MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf + ArmPlatformPkg/ArmJunoPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf + + # # Bds # MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf diff --git a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf index c8f5831..136ab30 100644 --- a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf +++ b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf @@ -198,6 +198,12 @@ FvNameGuid = B73FE497-B92E-416e-8326-45AD0D270092 INF ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.inf # + # SMBIOS/DMI + # + INF MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf + INF ArmPlatformPkg/ArmJunoPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf + + # # Bds # INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf diff --git a/ArmPlatformPkg/ArmJunoPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c b/ArmPlatformPkg/ArmJunoPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c new file mode 100644 index 000..7298c42 --- /dev/null +++ b/ArmPlatformPkg/ArmJunoPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c @@ -0,0 +1,781 @@ +/** @file + This driver installs SMBIOS information for ARM Juno platforms + + Copyright (c) 2015, ARM Limited. All rights reserved. + + This program and the accompanying materials + are licensed and made available under the terms and conditions of the BSD License + which accompanies this distribution. The full text of the license may be found at + http://opensource.org/licenses/bsd-license.php + + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. + +**/ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +#define TYPE0_STRINGS\ + "EFI Development Kit II / ARM LTD\0" /* Vendor */ \ + "EDK II\0" /* BiosVersion */ \ + __DATE__"\0" /* BiosReleaseDate */ + +#define TYPE1_STRINGS \ + "ARM LTD\0"/* Manufacturer */ \ + "ARM Juno Development Platform\0" /* Product Name */ \ + "None\0" /* Version */ \ + "\0" /* 20 character buffer */ + +#define TYPE2_STRINGS \ + "ARM LTD\0"/* Manufacturer */ \ + "ARM Juno Development Platform\0" /* Product Name */ \ + "R0\0" /* Version */\ + "Serial Not Set\0" /* Serial */ \ + "Base of Chassis\0"/* board location */ \ + "R1\0" /* Version */ + +#define TYPE3_STRINGS \ + "ARM LTD\0"/* Manufacturer */ \ + "None\0" /* Version */ \ + "Serial Not Set\0" /* Serial */ + +#define TYPE4_STRINGS \ + "BGA-1156\0" /* socket type */ \ + "ARM LTD\0"/* manufactuer */ \ + "Cortex-A57\0" /* processor 1 description */ \ + "Cortex-A53\0" /* processor 2 description */ \ + "0xd03\0" /* A53 part number */
[edk2] [PATCH 0/3] ArmPlatformPkg/ArmJunoPkg: Adds SMBIOS data for ARM Juno
SMBIOS data is consumed by a wide range of enterprise applications. This patch adds basic SMBIOS data for the ARM Juno. Most of the data is static. The system memory layout and juno revision are updated depending on the platform. To accomplish the juno revision detection the Juno revision code in ArmJunoDxe was hoisted into the platform.h file on the recommendation of others (to avoid a AFTER dependency). With this patch, both the EFI shell and linux dmidecode commands return useful information. Jeremy Linton (3): Code to detect what juno revision we are running on. Convert ArmJunoDxe to use common juno revision code ArmPlatformPkg/ArmJunoPkg: Create SMBIOS/DMI data for Juno ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc | 12 + ArmPlatformPkg/ArmJunoPkg/ArmJuno.fdf | 6 + .../ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 52 +- ArmPlatformPkg/ArmJunoPkg/Include/ArmPlatform.h| 41 ++ .../SmbiosPlatformDxe/SmbiosPlatformDxe.c | 781 + .../SmbiosPlatformDxe/SmbiosPlatformDxe.inf| 69 ++ 6 files changed, 917 insertions(+), 44 deletions(-) create mode 100644 ArmPlatformPkg/ArmJunoPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c create mode 100644 ArmPlatformPkg/ArmJunoPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf -- 2.4.3 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] BaseTools/toolsetup.bat: fixed the error when the path contains space
looks like my original fix submittal, which Mr. Gao said caused failure on his system. -Original Message- From: Gao, Liming [mailto:liming@intel.com] Sent: Friday, November 20, 2015 1:10 AM To: Zhu, Yonghong; edk2-devel@lists.01.org Cc: Hauch, Larry; Miller, Carl H Subject: RE: [edk2] [Patch] BaseTools/toolsetup.bat: fixed the error when the path contains space Reviewed-by: Liming Gao -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yonghong Zhu Sent: Friday, November 20, 2015 5:08 PM To: edk2-devel@lists.01.org Cc: Hauch, Larry; carl.mil...@pnnl.gov Subject: [edk2] [Patch] BaseTools/toolsetup.bat: fixed the error when the path contains space We have a new simple and effective method to resolve the original issue that the PATH env's update error when the path contains space, so this patch remove the last check in and use the new method to fix the original issue. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yonghong Zhu --- toolsetup.bat | 21 + 1 file changed, 5 insertions(+), 16 deletions(-) diff --git a/toolsetup.bat b/toolsetup.bat index 310ddd0..76fd8bb 100755 --- a/toolsetup.bat +++ b/toolsetup.bat @@ -320,28 +320,17 @@ goto end if not defined PYTHON_FREEZER_PATH ( echo. echo !!! WARNING !!! Will not be able to compile Python programs to .exe echo Will setup environment to run Python scripts directly. echo. - goto UpdatePATH + set "PATH=%BASETOOLS_PYTHON_SOURCE%\Trim;%PATH%" + set "PATH=%BASETOOLS_PYTHON_SOURCE%\GenFds;%PATH%" + set "PATH=%BASETOOLS_PYTHON_SOURCE%\build;%PATH%" + set PATHEXT=%PATHEXT%;.py ) -else ( - goto UpdateEnv -) - ) - else ( -goto UpdateEnv ) - -:UpdatePATH - set PATH=%BASETOOLS_PYTHON_SOURCE%\Trim;%PATH% - set PATH=%BASETOOLS_PYTHON_SOURCE%\GenFds;%PATH% - set PATH=%BASETOOLS_PYTHON_SOURCE%\build;%PATH% - set PATHEXT=%PATHEXT%;.py - goto UpdateEnv - -:UpdateEnv + echo BASE_TOOLS_PATH = %BASE_TOOLS_PATH% echo PYTHON_PATH = %PYTHON_PATH% echo PYTHON_FREEZER_PATH = %PYTHON_FREEZER_PATH% echo. -- 2.6.1.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V2 05/12] EmulatorPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg
Reviewed-by: Jordan Justen
On 2015-11-17 03:07:21, Star Zeng wrote:
> It is also to add GetControl/SetControl/SetAttributes implementation
> for DxeEmuSerialPortLib.
>
> Cc: Michael D Kinney
> Cc: Liming Gao
> Cc: Jordan Justen
> Cc: Andrew Fish
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng
> ---
> EmulatorPkg/EmulatorPkg.dsc| 3 +-
> EmulatorPkg/EmulatorPkg.fdf| 2 +-
> .../DxeEmuSerialPortLib/DxeEmuSerialPortLib.c | 85
> +-
> 3 files changed, 86 insertions(+), 4 deletions(-)
>
> diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
> index 8eff20e..27a78d5 100644
> --- a/EmulatorPkg/EmulatorPkg.dsc
> +++ b/EmulatorPkg/EmulatorPkg.dsc
> @@ -87,7 +87,6 @@ [LibraryClasses]
>
> SecurityManagementLib|MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.inf
>
> TimerLib|MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf
>
> SerialPortLib|MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf
> -
> SerialPortExtLib|EmbeddedPkg/Library/TemplateSerialPortExtLib/TemplateSerialPortExtLib.inf
>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
>#
># Platform
> @@ -325,7 +324,7 @@ [Components]
>MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
>MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
>MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
> - EmbeddedPkg/SerialDxe/SerialDxe.inf {
> + MdeModulePkg/Universal/SerialDxe/SerialDxe.inf {
>
>DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
>
> SerialPortLib|EmulatorPkg/Library/DxeEmuSerialPortLib/DxeEmuSerialPortLib.inf
> diff --git a/EmulatorPkg/EmulatorPkg.fdf b/EmulatorPkg/EmulatorPkg.fdf
> index a002389..985a78e 100644
> --- a/EmulatorPkg/EmulatorPkg.fdf
> +++ b/EmulatorPkg/EmulatorPkg.fdf
> @@ -161,7 +161,7 @@ [FV.FvRecovery]
> INF MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
> INF MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
>
> -INF EmbeddedPkg/SerialDxe/SerialDxe.inf
> +INF MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
> INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
> INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
> diff --git a/EmulatorPkg/Library/DxeEmuSerialPortLib/DxeEmuSerialPortLib.c
> b/EmulatorPkg/Library/DxeEmuSerialPortLib/DxeEmuSerialPortLib.c
> index 792bd62..9978e51 100644
> --- a/EmulatorPkg/Library/DxeEmuSerialPortLib/DxeEmuSerialPortLib.c
> +++ b/EmulatorPkg/Library/DxeEmuSerialPortLib/DxeEmuSerialPortLib.c
> @@ -2,7 +2,7 @@
>Serial Port Lib that thunks back to Emulator services to write to StdErr.
>All read functions are stubed out.
>
> - Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.
> + Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
>Portions copyright (c) 2011, Apple Inc. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
> @@ -116,3 +116,86 @@ SerialPortPoll (
>return gEmuThunk->PollStdIn ();
> }
>
> +/**
> + Sets the control bits on a serial device.
> +
> + @param ControlSets the bits of Control that are settable.
> +
> + @retval RETURN_SUCCESSThe new control bits were set on the serial
> device.
> + @retval RETURN_UNSUPPORTEDThe serial device does not support this
> operation.
> + @retval RETURN_DEVICE_ERROR The serial device is not functioning
> correctly.
> +
> +**/
> +RETURN_STATUS
> +EFIAPI
> +SerialPortSetControl (
> + IN UINT32 Control
> + )
> +{
> + return RETURN_UNSUPPORTED;
> +}
> +
> +/**
> + Retrieve the status of the control bits on a serial device.
> +
> + @param ControlA pointer to return the current control
> signals from the serial device.
> +
> + @retval RETURN_SUCCESSThe control bits were read from the serial
> device.
> + @retval RETURN_UNSUPPORTEDThe serial device does not support this
> operation.
> + @retval RETURN_DEVICE_ERROR The serial device is not functioning
> correctly.
> +
> +**/
> +RETURN_STATUS
> +EFIAPI
> +SerialPortGetControl (
> + OUT UINT32 *Control
> + )
> +{
> + *Control = 0;
> + if (!SerialPortPoll ()) {
> +*Control = EFI_SERIAL_INPUT_BUFFER_EMPTY;
> + }
> + return RETURN_SUCCESS;
> +}
> +
> +/**
> + Sets the baud rate, receive FIFO depth, transmit/receice time out, parity,
> + data buts, and stop bits on a serial device.
> +
> + @param BaudRate The requested baud rate. A BaudRate value of 0
> will use the
> +device's default interface speed.
> + @param ReveiveFifoDepth The requested depth of the FIFO on the receive
> sid
Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang issue
Ni, Ruiyu [mailto:ruiyu...@intel.com] wrote: ]Sent: Friday, November 20, 2015 01:37 AM ]To: Scott Duplichan ]Cc: Paolo Bonzini ; edk2-devel@lists.01.org ; Zeng, Star ] ]Subject: Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang issue ] ]Scott, ]The UEFI Windows 7 is fresh installed. Could you please tell me how to check ]whether a platform turns on the RTC alarm? ] ]Thanks, ]Ray Hello Ray, I think just about every system that can run UEFI supports RTC alarm, at least in the x86 world. It is support for the century feature that could possibly be disabled on some systems. For example, an internet search for "RTC Century support" finds an AMD Bolton document that describes a CenturyEn bit: Enable RTC Century support. So apparently systems using AMD Bolton could be configured for no RTC century support at all. I don't know if anyone would actually do this. But if they did, it would make sense for UEFI to not write a value into a CMOS century byte. Tahnks, Scott > 在 2015年11月20日，10:49，Scott Duplichan 写道： > > Ni, Ruiyu [mailto:ruiyu...@intel.com] wrote: > > ]Sent: Thursday, November 19, 2015 06:37 PM > ]To: Paolo Bonzini ; Zeng, Star ; > edk2-devel@lists.01.org > ]Subject: Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang > issue > ] > ]If we strictly follow the spec, it's only needed to save the century value > ]in CMOS when FADT.CenturyOffset is not zero. But the fact is even we set > ]the FADT.CenturyOffset to 0 indicating the platform doesn't store century > ]value in CMOS, UEFI Win7 still hang during booting until we updates the value > ]in CMOS location. So we have to always save the century value in CMOS. > ] > ]Regards, > ]Ray > > It sounds like you are testing on a machine that requires programming of > the RTC century value in order for the RTC alarm interrupt to work. If the > century value is not programmed, the alarm interrupt will never occur and > Windows 7 bootup will hang waiting for the interrupt. So a boot hang after > setting FADT.CenturyOffset to zero with no CMOS x32 write is expected. It > could be said that this machine requires FADT.CenturyOffset be set in order > to boot Windows 7. I don't see how this justifies writing CMOS x32 > unconditionally. > > What if a different system keeps some important value in CMOS x32 that is > unrelated to the RTC alarm function? The UEFI developer will set > FADT.CenturyOffset to zero and that will keep the OS from overwriting it. > But with this patch, UEFI itself will overwrite the value at CMOS x32. The > developer no longer has a configuration mechanism that prevents both the OS > and UEFI itself from writing to CMOS. > > Thanks, > Scott > > > ]-Original Message- > ]From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo > Bonzini > ]Sent: Friday, November 20, 2015 6:17 AM > ]To: Zeng, Star ; Ni, Ruiyu ; > edk2-devel@lists.01.org > ]Subject: Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang > issue > > > >> On 18/11/2015 06:08, Zeng, Star wrote: >> >> @@ -508,6 +509,7 @@ PcRtcSetTime ( >>RtcWrite (RTC_ADDRESS_DAY_OF_THE_MONTH, RtcTime.Day); >>RtcWrite (RTC_ADDRESS_MONTH, RtcTime.Month); >>RtcWrite (RTC_ADDRESS_YEAR, (UINT8) RtcTime.Year); >> + RtcWrite (RTC_ADDRESS_CENTURY, Century); > > Should it be written only if the FADT CenturyOffset is zero? > > Paolo > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmPkg: ArmLib: purge incorrect ArmDrainWriteBuffer () alias
On 20 November 2015 at 12:08, Ard Biesheuvel wrote:
> On 19 November 2015 at 17:25, Leif Lindholm wrote:
>> In ArmLib, there exists an alias for ArmDataSynchronizationBarrier,
>> named after one of several names for the pre-ARMv6 cp15 operation that
>> was formalised into the Data Synchronization Barrier in ARMv6.
>>
>> This alias is also the one called from within ArmLib, in preference of
>> the correct name. Through the power of code reuse, this name slipped
>> into the AArch64 variant as well.
>>
>> Expunge it from the codebase.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Leif Lindholm
>
> Reviewed-by: Ard Biesheuvel
Thanks. Committed as r18915.
/
Leif
>> ---
>> ArmPkg/Include/Library/ArmLib.h| 6 --
>> ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c | 8
>> ArmPkg/Library/ArmLib/AArch64/AArch64Support.S | 2 --
>> ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c | 8
>> ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S | 2 --
>> ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm | 2 --
>> 6 files changed, 8 insertions(+), 20 deletions(-)
>>
>> diff --git a/ArmPkg/Include/Library/ArmLib.h
>> b/ArmPkg/Include/Library/ArmLib.h
>> index a328146..9622444 100644
>> --- a/ArmPkg/Include/Library/ArmLib.h
>> +++ b/ArmPkg/Include/Library/ArmLib.h
>> @@ -393,12 +393,6 @@ ArmSetHighVectors (
>>
>> VOID
>> EFIAPI
>> -ArmDrainWriteBuffer (
>> - VOID
>> - );
>> -
>> -VOID
>> -EFIAPI
>> ArmDataMemoryBarrier (
>>VOID
>>);
>> diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
>> b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
>> index dec125f..ec35097 100644
>> --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
>> +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
>> @@ -33,7 +33,7 @@ AArch64DataCacheOperation (
>>
>>AArch64AllDataCachesOperation (DataCacheOperation);
>>
>> - ArmDrainWriteBuffer ();
>> + ArmDataSynchronizationBarrier ();
>>
>>if (SavedInterruptState) {
>> ArmEnableInterrupts ();
>> @@ -46,7 +46,7 @@ ArmInvalidateDataCache (
>>VOID
>>)
>> {
>> - ArmDrainWriteBuffer ();
>> + ArmDataSynchronizationBarrier ();
>>AArch64DataCacheOperation (ArmInvalidateDataCacheEntryBySetWay);
>> }
>>
>> @@ -56,7 +56,7 @@ ArmCleanInvalidateDataCache (
>>VOID
>>)
>> {
>> - ArmDrainWriteBuffer ();
>> + ArmDataSynchronizationBarrier ();
>>AArch64DataCacheOperation (ArmCleanInvalidateDataCacheEntryBySetWay);
>> }
>>
>> @@ -66,6 +66,6 @@ ArmCleanDataCache (
>>VOID
>>)
>> {
>> - ArmDrainWriteBuffer ();
>> + ArmDataSynchronizationBarrier ();
>>AArch64DataCacheOperation (ArmCleanDataCacheEntryBySetWay);
>> }
>> diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
>> b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
>> index df2dc93..c530d19 100644
>> --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
>> +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
>> @@ -26,7 +26,6 @@ GCC_ASM_EXPORT (ArmCleanInvalidateDataCacheEntryByMVA)
>> GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryBySetWay)
>> GCC_ASM_EXPORT (ArmCleanDataCacheEntryBySetWay)
>> GCC_ASM_EXPORT (ArmCleanInvalidateDataCacheEntryBySetWay)
>> -GCC_ASM_EXPORT (ArmDrainWriteBuffer)
>> GCC_ASM_EXPORT (ArmEnableMmu)
>> GCC_ASM_EXPORT (ArmDisableMmu)
>> GCC_ASM_EXPORT (ArmDisableCachesAndMmu)
>> @@ -364,7 +363,6 @@ ASM_PFX(ArmDataMemoryBarrier):
>>
>>
>> ASM_PFX(ArmDataSynchronizationBarrier):
>> -ASM_PFX(ArmDrainWriteBuffer):
>>dsb sy
>>ret
>>
>> diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c
>> b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c
>> index b53f455..23a7f2f 100644
>> --- a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c
>> +++ b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c
>> @@ -32,7 +32,7 @@ ArmV7DataCacheOperation (
>>
>>ArmV7AllDataCachesOperation (DataCacheOperation);
>>
>> - ArmDrainWriteBuffer ();
>> + ArmDataSynchronizationBarrier ();
>>
>>if (SavedInterruptState) {
>> ArmEnableInterrupts ();
>> @@ -45,7 +45,7 @@ ArmInvalidateDataCache (
>>VOID
>>)
>> {
>> - ArmDrainWriteBuffer ();
>> + ArmDataSynchronizationBarrier ();
>>ArmV7DataCacheOperation (ArmInvalidateDataCacheEntryBySetWay);
>> }
>>
>> @@ -55,7 +55,7 @@ ArmCleanInvalidateDataCache (
>>VOID
>>)
>> {
>> - ArmDrainWriteBuffer ();
>> + ArmDataSynchronizationBarrier ();
>>ArmV7DataCacheOperation (ArmCleanInvalidateDataCacheEntryBySetWay);
>> }
>>
>> @@ -65,6 +65,6 @@ ArmCleanDataCache (
>>VOID
>>)
>> {
>> - ArmDrainWriteBuffer ();
>> + ArmDataSynchronizationBarrier ();
>>ArmV7DataCacheOperation (ArmCleanDataCacheEntryBySetWay);
>> }
>> diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
>> b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
>> index 7366eee..5f030d9 100644
>> --- a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
>> +++ b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
>> @@ -23,7 +23,6 @@ GCC_ASM_EXPORT (ArmCleanInvalidateDataCacheEntryByMVA)
>> GCC_ASM_EXPORT (ArmInvalidateDataCa
Re: [edk2] [PATCH] ArmPlatformPkg/PrePeiCore: add missing entries to AArch64 vector table
On Fri, Nov 20, 2015 at 01:39:26PM +0100, Ard Biesheuvel wrote:
> The PrePeiCore vector table for AArch64 mode is only half populated.
> However unlikely, if exceptions from lower exception levels are ever
> taken, they should be reported correctly, rather than causing a
> recursive undefined instruction fault on the zero padding that was
> introduced by commit SVN r18904 ("ArmPkg/ArmPlatformPkg: position
> vectors relative to base"). So add the missing entries, and wire
> them up to the default handler.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
Acked-by: Mark Rutland
Mark.
> ---
> ArmPlatformPkg/PrePeiCore/AArch64/Exception.S | 40
> 1 file changed, 40 insertions(+)
>
> diff --git a/ArmPlatformPkg/PrePeiCore/AArch64/Exception.S
> b/ArmPlatformPkg/PrePeiCore/AArch64/Exception.S
> index b31854ced256..75cd98ff4863 100644
> --- a/ArmPlatformPkg/PrePeiCore/AArch64/Exception.S
> +++ b/ArmPlatformPkg/PrePeiCore/AArch64/Exception.S
> @@ -77,4 +77,44 @@ _DefaultSError_h:
>mov x0, #EXCEPT_AARCH64_SERROR
>TO_HANDLER
>
> +VECTOR_ENTRY(PeiVectorTable, ARM_VECTOR_LOW_A64_SYNC)
> +_DefaultSyncExceptHandler_LowerA64:
> + mov x0, #EXCEPT_AARCH64_SYNCHRONOUS_EXCEPTIONS
> + TO_HANDLER
> +
> +VECTOR_ENTRY(PeiVectorTable, ARM_VECTOR_LOW_A64_IRQ)
> +_DefaultIrq_LowerA64:
> + mov x0, #EXCEPT_AARCH64_IRQ
> + TO_HANDLER
> +
> +VECTOR_ENTRY(PeiVectorTable, ARM_VECTOR_LOW_A64_FIQ)
> +_DefaultFiq_LowerA64:
> + mov x0, #EXCEPT_AARCH64_FIQ
> + TO_HANDLER
> +
> +VECTOR_ENTRY(PeiVectorTable, ARM_VECTOR_LOW_A64_SERR)
> +_DefaultSError_LowerA64:
> + mov x0, #EXCEPT_AARCH64_SERROR
> + TO_HANDLER
> +
> +VECTOR_ENTRY(PeiVectorTable, ARM_VECTOR_LOW_A32_SYNC)
> +_DefaultSyncExceptHandler_LowerA32:
> + mov x0, #EXCEPT_AARCH64_SYNCHRONOUS_EXCEPTIONS
> + TO_HANDLER
> +
> +VECTOR_ENTRY(PeiVectorTable, ARM_VECTOR_LOW_A32_IRQ)
> +_DefaultIrq_LowerA32:
> + mov x0, #EXCEPT_AARCH64_IRQ
> + TO_HANDLER
> +
> +VECTOR_ENTRY(PeiVectorTable, ARM_VECTOR_LOW_A32_FIQ)
> +_DefaultFiq_LowerA32:
> + mov x0, #EXCEPT_AARCH64_FIQ
> + TO_HANDLER
> +
> +VECTOR_ENTRY(PeiVectorTable, ARM_VECTOR_LOW_A32_SERR)
> +_DefaultSError_LowerA32:
> + mov x0, #EXCEPT_AARCH64_SERROR
> + TO_HANDLER
> +
> VECTOR_END(PeiVectorTable)
> --
> 1.9.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] ArmPlatformPkg/PrePeiCore: add missing entries to AArch64 vector table
The PrePeiCore vector table for AArch64 mode is only half populated.
However unlikely, if exceptions from lower exception levels are ever
taken, they should be reported correctly, rather than causing a
recursive undefined instruction fault on the zero padding that was
introduced by commit SVN r18904 ("ArmPkg/ArmPlatformPkg: position
vectors relative to base"). So add the missing entries, and wire
them up to the default handler.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/PrePeiCore/AArch64/Exception.S | 40
1 file changed, 40 insertions(+)
diff --git a/ArmPlatformPkg/PrePeiCore/AArch64/Exception.S
b/ArmPlatformPkg/PrePeiCore/AArch64/Exception.S
index b31854ced256..75cd98ff4863 100644
--- a/ArmPlatformPkg/PrePeiCore/AArch64/Exception.S
+++ b/ArmPlatformPkg/PrePeiCore/AArch64/Exception.S
@@ -77,4 +77,44 @@ _DefaultSError_h:
mov x0, #EXCEPT_AARCH64_SERROR
TO_HANDLER
+VECTOR_ENTRY(PeiVectorTable, ARM_VECTOR_LOW_A64_SYNC)
+_DefaultSyncExceptHandler_LowerA64:
+ mov x0, #EXCEPT_AARCH64_SYNCHRONOUS_EXCEPTIONS
+ TO_HANDLER
+
+VECTOR_ENTRY(PeiVectorTable, ARM_VECTOR_LOW_A64_IRQ)
+_DefaultIrq_LowerA64:
+ mov x0, #EXCEPT_AARCH64_IRQ
+ TO_HANDLER
+
+VECTOR_ENTRY(PeiVectorTable, ARM_VECTOR_LOW_A64_FIQ)
+_DefaultFiq_LowerA64:
+ mov x0, #EXCEPT_AARCH64_FIQ
+ TO_HANDLER
+
+VECTOR_ENTRY(PeiVectorTable, ARM_VECTOR_LOW_A64_SERR)
+_DefaultSError_LowerA64:
+ mov x0, #EXCEPT_AARCH64_SERROR
+ TO_HANDLER
+
+VECTOR_ENTRY(PeiVectorTable, ARM_VECTOR_LOW_A32_SYNC)
+_DefaultSyncExceptHandler_LowerA32:
+ mov x0, #EXCEPT_AARCH64_SYNCHRONOUS_EXCEPTIONS
+ TO_HANDLER
+
+VECTOR_ENTRY(PeiVectorTable, ARM_VECTOR_LOW_A32_IRQ)
+_DefaultIrq_LowerA32:
+ mov x0, #EXCEPT_AARCH64_IRQ
+ TO_HANDLER
+
+VECTOR_ENTRY(PeiVectorTable, ARM_VECTOR_LOW_A32_FIQ)
+_DefaultFiq_LowerA32:
+ mov x0, #EXCEPT_AARCH64_FIQ
+ TO_HANDLER
+
+VECTOR_ENTRY(PeiVectorTable, ARM_VECTOR_LOW_A32_SERR)
+_DefaultSError_LowerA32:
+ mov x0, #EXCEPT_AARCH64_SERROR
+ TO_HANDLER
+
VECTOR_END(PeiVectorTable)
--
1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmPkg: ArmLib: purge incorrect ArmDrainWriteBuffer () alias
On 19 November 2015 at 17:25, Leif Lindholm wrote:
> In ArmLib, there exists an alias for ArmDataSynchronizationBarrier,
> named after one of several names for the pre-ARMv6 cp15 operation that
> was formalised into the Data Synchronization Barrier in ARMv6.
>
> This alias is also the one called from within ArmLib, in preference of
> the correct name. Through the power of code reuse, this name slipped
> into the AArch64 variant as well.
>
> Expunge it from the codebase.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Leif Lindholm
Reviewed-by: Ard Biesheuvel
> ---
> ArmPkg/Include/Library/ArmLib.h| 6 --
> ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c | 8
> ArmPkg/Library/ArmLib/AArch64/AArch64Support.S | 2 --
> ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c | 8
> ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S | 2 --
> ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.asm | 2 --
> 6 files changed, 8 insertions(+), 20 deletions(-)
>
> diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h
> index a328146..9622444 100644
> --- a/ArmPkg/Include/Library/ArmLib.h
> +++ b/ArmPkg/Include/Library/ArmLib.h
> @@ -393,12 +393,6 @@ ArmSetHighVectors (
>
> VOID
> EFIAPI
> -ArmDrainWriteBuffer (
> - VOID
> - );
> -
> -VOID
> -EFIAPI
> ArmDataMemoryBarrier (
>VOID
>);
> diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
> b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
> index dec125f..ec35097 100644
> --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
> +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c
> @@ -33,7 +33,7 @@ AArch64DataCacheOperation (
>
>AArch64AllDataCachesOperation (DataCacheOperation);
>
> - ArmDrainWriteBuffer ();
> + ArmDataSynchronizationBarrier ();
>
>if (SavedInterruptState) {
> ArmEnableInterrupts ();
> @@ -46,7 +46,7 @@ ArmInvalidateDataCache (
>VOID
>)
> {
> - ArmDrainWriteBuffer ();
> + ArmDataSynchronizationBarrier ();
>AArch64DataCacheOperation (ArmInvalidateDataCacheEntryBySetWay);
> }
>
> @@ -56,7 +56,7 @@ ArmCleanInvalidateDataCache (
>VOID
>)
> {
> - ArmDrainWriteBuffer ();
> + ArmDataSynchronizationBarrier ();
>AArch64DataCacheOperation (ArmCleanInvalidateDataCacheEntryBySetWay);
> }
>
> @@ -66,6 +66,6 @@ ArmCleanDataCache (
>VOID
>)
> {
> - ArmDrainWriteBuffer ();
> + ArmDataSynchronizationBarrier ();
>AArch64DataCacheOperation (ArmCleanDataCacheEntryBySetWay);
> }
> diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> index df2dc93..c530d19 100644
> --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
> @@ -26,7 +26,6 @@ GCC_ASM_EXPORT (ArmCleanInvalidateDataCacheEntryByMVA)
> GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryBySetWay)
> GCC_ASM_EXPORT (ArmCleanDataCacheEntryBySetWay)
> GCC_ASM_EXPORT (ArmCleanInvalidateDataCacheEntryBySetWay)
> -GCC_ASM_EXPORT (ArmDrainWriteBuffer)
> GCC_ASM_EXPORT (ArmEnableMmu)
> GCC_ASM_EXPORT (ArmDisableMmu)
> GCC_ASM_EXPORT (ArmDisableCachesAndMmu)
> @@ -364,7 +363,6 @@ ASM_PFX(ArmDataMemoryBarrier):
>
>
> ASM_PFX(ArmDataSynchronizationBarrier):
> -ASM_PFX(ArmDrainWriteBuffer):
>dsb sy
>ret
>
> diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c
> b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c
> index b53f455..23a7f2f 100644
> --- a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c
> +++ b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Lib.c
> @@ -32,7 +32,7 @@ ArmV7DataCacheOperation (
>
>ArmV7AllDataCachesOperation (DataCacheOperation);
>
> - ArmDrainWriteBuffer ();
> + ArmDataSynchronizationBarrier ();
>
>if (SavedInterruptState) {
> ArmEnableInterrupts ();
> @@ -45,7 +45,7 @@ ArmInvalidateDataCache (
>VOID
>)
> {
> - ArmDrainWriteBuffer ();
> + ArmDataSynchronizationBarrier ();
>ArmV7DataCacheOperation (ArmInvalidateDataCacheEntryBySetWay);
> }
>
> @@ -55,7 +55,7 @@ ArmCleanInvalidateDataCache (
>VOID
>)
> {
> - ArmDrainWriteBuffer ();
> + ArmDataSynchronizationBarrier ();
>ArmV7DataCacheOperation (ArmCleanInvalidateDataCacheEntryBySetWay);
> }
>
> @@ -65,6 +65,6 @@ ArmCleanDataCache (
>VOID
>)
> {
> - ArmDrainWriteBuffer ();
> + ArmDataSynchronizationBarrier ();
>ArmV7DataCacheOperation (ArmCleanDataCacheEntryBySetWay);
> }
> diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
> b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
> index 7366eee..5f030d9 100644
> --- a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
> +++ b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Support.S
> @@ -23,7 +23,6 @@ GCC_ASM_EXPORT (ArmCleanInvalidateDataCacheEntryByMVA)
> GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryBySetWay)
> GCC_ASM_EXPORT (ArmCleanDataCacheEntryBySetWay)
> GCC_ASM_EXPORT (ArmCleanInvalidateDataCacheEntryBySetWay)
> -GCC_ASM_EXPORT (ArmDrainWriteBuffer)
> GCC_ASM_EXPORT (ArmEnableMmu)
> GCC_ASM_EXPORT (ArmDisableMmu)
> GCC_ASM_EX
Re: [edk2] [PATCH] ArmPkg: Flush cache after allocating UC memory
On Fri, Nov 20, 2015 at 12:20:56PM +0100, Ard Biesheuvel wrote:
> On 20 November 2015 at 10:29, Heyi Guo wrote:
> > Hi Ard,
> >
> > Do we have special reason of not cleaning the allocated pages? If not
> > having, I think it is safer to use "clean and invalidate".
>
> Actually, I disagree. If your firmware relies on data making it to
> main memory only due to a subsequent clean performed by the next owner
> of the memory range, I'd much rather make it explicit.
> And clean + invalidate is obviously more costly.
>
> Leif?
Completely agree (with Ard).
Such a contract would have to be codified into the UEFI
specification to begin with (and I would argue against it if anyone
proposed to do that).
/
Leif
> > On 11/20/2015 02:25 PM, Ard Biesheuvel wrote:
> >>
> >> On 20 November 2015 at 06:32, Heyi Guo wrote:
> >>>
> >>> It is implied that the memory returned from UncachedMemoryAllocationLib
> >>> should have cache cleaned. So we clean and invalidate memory range after
> >>> changing memory attribute to uncached.
> >>>
> >>> Contributed-under: TianoCore Contribution Agreement 1.0
> >>> Signed-off-by: Heyi Guo
> >>> Cc: Leif Lindholm
> >>> Cc: Ard Biesheuvel
> >>> ---
> >>> .../Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
> >>> | 3 +++
> >>> .../UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
> >>> | 1 +
> >>> 2 files changed, 4 insertions(+)
> >>>
> >>> diff --git
> >>> a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
> >>> b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
> >>> index b859f63..3242579 100644
> >>> ---
> >>> a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
> >>> +++
> >>> b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
> >>> @@ -25,6 +25,7 @@
> >>> #include
> >>> #include
> >>> #include
> >>> +#include
> >>>
> >>> VOID *
> >>> UncachedInternalAllocatePages (
> >>> @@ -165,6 +166,8 @@ AllocatePagesFromList (
> >>> return Status;
> >>> }
> >>>
> >>> + WriteBackInvalidateDataCacheRange ((VOID *)(UINTN)Memory,
> >>> EFI_PAGES_TO_SIZE (Pages));
> >>> +
> >>
> >> I think invalidate only should be fine here, since it is a new
> >> allocation, and we are allocating full pages. Since the architectural
> >> max value of CWG is 2 KB, we could never end up discarding data that
> >> is not covered by the allocation itself.
> >>
> >>> NewNode = AllocatePool (sizeof (FREE_PAGE_NODE));
> >>> if (NewNode == NULL) {
> >>> ASSERT (FALSE);
> >>> diff --git
> >>> a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
> >>> b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
> >>> index 0a0b6cb..d7a0f2f 100644
> >>> ---
> >>> a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
> >>> +++
> >>> b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
> >>> @@ -38,6 +38,7 @@
> >>> MemoryAllocationLib
> >>> PcdLib
> >>> DxeServicesTableLib
> >>> + CacheMaintenanceLib
> >>>
> >>> [Pcd]
> >>> gArmTokenSpaceGuid.PcdArmFreeUncachedMemorySizeThreshold
> >>> --
> >>> 2.6.2
> >>>
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmPkg: Flush cache after allocating UC memory
On 20 November 2015 at 10:29, Heyi Guo wrote:
> Hi Ard,
>
> Do we have special reason of not cleaning the allocated pages? If not
> having, I think it is safer to use "clean and invalidate".
>
Actually, I disagree. If your firmware relies on data making it to
main memory only due to a subsequent clean performed by the next owner
of the memory range, I'd much rather make it explicit.
And clean + invalidate is obviously more costly.
Leif?
> On 11/20/2015 02:25 PM, Ard Biesheuvel wrote:
>>
>> On 20 November 2015 at 06:32, Heyi Guo wrote:
>>>
>>> It is implied that the memory returned from UncachedMemoryAllocationLib
>>> should have cache cleaned. So we clean and invalidate memory range after
>>> changing memory attribute to uncached.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Heyi Guo
>>> Cc: Leif Lindholm
>>> Cc: Ard Biesheuvel
>>> ---
>>> .../Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
>>> | 3 +++
>>> .../UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
>>> | 1 +
>>> 2 files changed, 4 insertions(+)
>>>
>>> diff --git
>>> a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
>>> b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
>>> index b859f63..3242579 100644
>>> ---
>>> a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
>>> +++
>>> b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
>>> @@ -25,6 +25,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> VOID *
>>> UncachedInternalAllocatePages (
>>> @@ -165,6 +166,8 @@ AllocatePagesFromList (
>>> return Status;
>>> }
>>>
>>> + WriteBackInvalidateDataCacheRange ((VOID *)(UINTN)Memory,
>>> EFI_PAGES_TO_SIZE (Pages));
>>> +
>>
>> I think invalidate only should be fine here, since it is a new
>> allocation, and we are allocating full pages. Since the architectural
>> max value of CWG is 2 KB, we could never end up discarding data that
>> is not covered by the allocation itself.
>>
>>> NewNode = AllocatePool (sizeof (FREE_PAGE_NODE));
>>> if (NewNode == NULL) {
>>> ASSERT (FALSE);
>>> diff --git
>>> a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
>>> b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
>>> index 0a0b6cb..d7a0f2f 100644
>>> ---
>>> a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
>>> +++
>>> b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
>>> @@ -38,6 +38,7 @@
>>> MemoryAllocationLib
>>> PcdLib
>>> DxeServicesTableLib
>>> + CacheMaintenanceLib
>>>
>>> [Pcd]
>>> gArmTokenSpaceGuid.PcdArmFreeUncachedMemorySizeThreshold
>>> --
>>> 2.6.2
>>>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmPkg: Flush cache after allocating UC memory
Hi Ard,
Do we have special reason of not cleaning the allocated pages? If not
having, I think it is safer to use "clean and invalidate".
Thanks.
Heyi
On 11/20/2015 02:25 PM, Ard Biesheuvel wrote:
On 20 November 2015 at 06:32, Heyi Guo wrote:
It is implied that the memory returned from UncachedMemoryAllocationLib
should have cache cleaned. So we clean and invalidate memory range after
changing memory attribute to uncached.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo
Cc: Leif Lindholm
Cc: Ard Biesheuvel
---
.../Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c | 3 +++
.../UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf| 1 +
2 files changed, 4 insertions(+)
diff --git
a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
index b859f63..3242579 100644
--- a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
+++ b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
VOID *
UncachedInternalAllocatePages (
@@ -165,6 +166,8 @@ AllocatePagesFromList (
return Status;
}
+ WriteBackInvalidateDataCacheRange ((VOID *)(UINTN)Memory, EFI_PAGES_TO_SIZE
(Pages));
+
I think invalidate only should be fine here, since it is a new
allocation, and we are allocating full pages. Since the architectural
max value of CWG is 2 KB, we could never end up discarding data that
is not covered by the allocation itself.
NewNode = AllocatePool (sizeof (FREE_PAGE_NODE));
if (NewNode == NULL) {
ASSERT (FALSE);
diff --git
a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
index 0a0b6cb..d7a0f2f 100644
--- a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
+++ b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.inf
@@ -38,6 +38,7 @@
MemoryAllocationLib
PcdLib
DxeServicesTableLib
+ CacheMaintenanceLib
[Pcd]
gArmTokenSpaceGuid.PcdArmFreeUncachedMemorySizeThreshold
--
2.6.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/Pxe: Fix bug of checking input FilePath
Sorry I missed to see FilePath is not used in the function at all.
However, I'd like to know where this requirement comes from? I searched
in the section of load file protocol and didn't find such requirement.
Thanks.
Heyi
On 11/20/2015 04:50 PM, Fu, Siyuan wrote:
Hi, Guo
It's not a bug, for EfiPxeLoadFile function the input FilePath should always be
an end device path node.
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
Sent: Friday, November 20, 2015 4:23 PM
To: edk2-devel@lists.01.org
Cc: Zhang, Lubo ; Heyi Guo ; Tian, Feng
Subject: [edk2] [PATCH] MdeModulePkg/Pxe: Fix bug of checking input FilePath
There is a simple bug in below code and will cause PXE always returning invalid
parameter:
if (FilePath == NULL || !IsDevicePathEnd (FilePath)) {
return EFI_INVALID_PARAMETER;
FilePath should *not* be end node, so return invalid parameter when FilePath
*is* device path end.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo
Cc: Feng Tian
Cc: Zhang Lubo
---
MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
index 89977e6..1c7b664 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
@@ -2776,7 +2776,7 @@ EfiPxeLoadFile (
UINT64 TmpBufSize;
BOOLEAN MediaPresent;
- if (FilePath == NULL || !IsDevicePathEnd (FilePath)) {
+ if (FilePath == NULL || IsDevicePathEnd (FilePath)) {
return EFI_INVALID_PARAMETER;
}
--
2.6.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] BaseTools/toolsetup.bat: fixed the error when the path contains space
Reviewed-by: Liming Gao -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yonghong Zhu Sent: Friday, November 20, 2015 5:08 PM To: edk2-devel@lists.01.org Cc: Hauch, Larry; carl.mil...@pnnl.gov Subject: [edk2] [Patch] BaseTools/toolsetup.bat: fixed the error when the path contains space We have a new simple and effective method to resolve the original issue that the PATH env's update error when the path contains space, so this patch remove the last check in and use the new method to fix the original issue. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yonghong Zhu --- toolsetup.bat | 21 + 1 file changed, 5 insertions(+), 16 deletions(-) diff --git a/toolsetup.bat b/toolsetup.bat index 310ddd0..76fd8bb 100755 --- a/toolsetup.bat +++ b/toolsetup.bat @@ -320,28 +320,17 @@ goto end if not defined PYTHON_FREEZER_PATH ( echo. echo !!! WARNING !!! Will not be able to compile Python programs to .exe echo Will setup environment to run Python scripts directly. echo. - goto UpdatePATH + set "PATH=%BASETOOLS_PYTHON_SOURCE%\Trim;%PATH%" + set "PATH=%BASETOOLS_PYTHON_SOURCE%\GenFds;%PATH%" + set "PATH=%BASETOOLS_PYTHON_SOURCE%\build;%PATH%" + set PATHEXT=%PATHEXT%;.py ) -else ( - goto UpdateEnv -) - ) - else ( -goto UpdateEnv ) - -:UpdatePATH - set PATH=%BASETOOLS_PYTHON_SOURCE%\Trim;%PATH% - set PATH=%BASETOOLS_PYTHON_SOURCE%\GenFds;%PATH% - set PATH=%BASETOOLS_PYTHON_SOURCE%\build;%PATH% - set PATHEXT=%PATHEXT%;.py - goto UpdateEnv - -:UpdateEnv + echo BASE_TOOLS_PATH = %BASE_TOOLS_PATH% echo PYTHON_PATH = %PYTHON_PATH% echo PYTHON_FREEZER_PATH = %PYTHON_FREEZER_PATH% echo. -- 2.6.1.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch] BaseTools/toolsetup.bat: fixed the error when the path contains space
We have a new simple and effective method to resolve the original issue that the PATH env's update error when the path contains space, so this patch remove the last check in and use the new method to fix the original issue. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yonghong Zhu --- toolsetup.bat | 21 + 1 file changed, 5 insertions(+), 16 deletions(-) diff --git a/toolsetup.bat b/toolsetup.bat index 310ddd0..76fd8bb 100755 --- a/toolsetup.bat +++ b/toolsetup.bat @@ -320,28 +320,17 @@ goto end if not defined PYTHON_FREEZER_PATH ( echo. echo !!! WARNING !!! Will not be able to compile Python programs to .exe echo Will setup environment to run Python scripts directly. echo. - goto UpdatePATH + set "PATH=%BASETOOLS_PYTHON_SOURCE%\Trim;%PATH%" + set "PATH=%BASETOOLS_PYTHON_SOURCE%\GenFds;%PATH%" + set "PATH=%BASETOOLS_PYTHON_SOURCE%\build;%PATH%" + set PATHEXT=%PATHEXT%;.py ) -else ( - goto UpdateEnv -) - ) - else ( -goto UpdateEnv ) - -:UpdatePATH - set PATH=%BASETOOLS_PYTHON_SOURCE%\Trim;%PATH% - set PATH=%BASETOOLS_PYTHON_SOURCE%\GenFds;%PATH% - set PATH=%BASETOOLS_PYTHON_SOURCE%\build;%PATH% - set PATHEXT=%PATHEXT%;.py - goto UpdateEnv - -:UpdateEnv + echo BASE_TOOLS_PATH = %BASE_TOOLS_PATH% echo PYTHON_PATH = %PYTHON_PATH% echo PYTHON_FREEZER_PATH = %PYTHON_FREEZER_PATH% echo. -- 2.6.1.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/Pxe: Fix bug of checking input FilePath
Hi, Guo
It's not a bug, for EfiPxeLoadFile function the input FilePath should always be
an end device path node.
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Heyi Guo
Sent: Friday, November 20, 2015 4:23 PM
To: edk2-devel@lists.01.org
Cc: Zhang, Lubo ; Heyi Guo ; Tian,
Feng
Subject: [edk2] [PATCH] MdeModulePkg/Pxe: Fix bug of checking input FilePath
There is a simple bug in below code and will cause PXE always returning invalid
parameter:
if (FilePath == NULL || !IsDevicePathEnd (FilePath)) {
return EFI_INVALID_PARAMETER;
FilePath should *not* be end node, so return invalid parameter when FilePath
*is* device path end.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo
Cc: Feng Tian
Cc: Zhang Lubo
---
MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
index 89977e6..1c7b664 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
@@ -2776,7 +2776,7 @@ EfiPxeLoadFile (
UINT64 TmpBufSize;
BOOLEAN MediaPresent;
- if (FilePath == NULL || !IsDevicePathEnd (FilePath)) {
+ if (FilePath == NULL || IsDevicePathEnd (FilePath)) {
return EFI_INVALID_PARAMETER;
}
--
2.6.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 14/41] OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRE
On 11/20/15 07:02, Jordan Justen wrote:
> Reviewed-by: Jordan Justen
Thank you! But, I think you reviewed this one earlier:
http://thread.gmane.org/gmane.comp.bios.edk2.devel/3788/focus=4205
In that message, you wrote:
With those move into a new patch, or into patch 14
13-14 Reviewed-by: Jordan Justen intel.com>
and patch 14 is exactly this one. (I complied with your suggestion for v5.)
(This is why I prefer to give my R-b explicitly for each patch in
separation. It means more emails but is clearer down the road.)
Thanks again!
Laszlo
>
> On 2015-11-03 13:00:50, Laszlo Ersek wrote:
>> During DXE, drivers save data in the LockBox. A save operation is layered
>> as follows:
>>
>> - The unprivileged driver wishing to store data in the LockBox links
>> against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf"
>> library instance.
>>
>> The library allows the unprivileged driver to format requests for the
>> privileged SMM LockBox driver (see below), and to parse responses.
>>
>> We apply this resolution for DXE_DRIVER modules.
>>
>> - The privileged SMM LockBox driver is built from
>> "MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". This driver
>> has module type DXE_SMM_DRIVER and can access SMRAM.
>>
>> The driver delegates command parsing and response formatting to
>> "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf".
>>
>> Therefore we include this DXE_SMM_DRIVER in the build, and apply said
>> resolution specifically to it.
>>
>> (Including the driver requires us to resolve a few of other library
>> classes for DXE_SMM_DRIVER modules.)
>>
>> - In PEI, the S3 Resume PEIM (UefiCpuPkg/Universal/Acpi/S3Resume2Pei)
>> retrieves data from the LockBox. It is capable of searching SMRAM
>> itself.
>>
>> We resolve LockBoxLib to
>> "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" specifically
>> for this one PEIM.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek
>> ---
>> OvmfPkg/OvmfPkgIa32.dsc| 16
>> OvmfPkg/OvmfPkgIa32X64.dsc | 16
>> OvmfPkg/OvmfPkgX64.dsc | 16
>> OvmfPkg/OvmfPkgIa32.fdf| 1 +
>> OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
>> OvmfPkg/OvmfPkgX64.fdf | 1 +
>> 6 files changed, 51 insertions(+)
>>
>> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
>> index 6cfd58e..a19d4e2 100644
>> --- a/OvmfPkg/OvmfPkgIa32.dsc
>> +++ b/OvmfPkg/OvmfPkgIa32.dsc
>> @@ -106,7 +106,9 @@ [LibraryClasses]
>>QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf
>>VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
>>LoadLinuxLib|OvmfPkg/Library/LoadLinuxLib/LoadLinuxLib.inf
>> +!if $(SMM_REQUIRE) == FALSE
>>LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
>> +!endif
>>
>> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>>
>> !ifdef $(SOURCE_DEBUG_ENABLE)
>> @@ -272,7 +274,11 @@ [LibraryClasses.common.DXE_DRIVER]
>>DpcLib|MdeModulePkg/Library/DxeDpcLib/DxeDpcLib.inf
>>PlatformBdsLib|OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
>>
>> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
>> +!if $(SMM_REQUIRE) == TRUE
>> + LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
>> +!else
>>LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
>> +!endif
>> !ifdef $(SOURCE_DEBUG_ENABLE)
>>DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
>> !endif
>> @@ -292,6 +298,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
>> [LibraryClasses.common.DXE_SMM_DRIVER]
>>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>>TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
>> +
>> MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
>> + HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>> + SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
>>
>> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
>> !ifdef $(DEBUG_ON_SERIAL_PORT)
>>DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
>> @@ -461,6 +470,9 @@ [Components]
>>UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf {
>>
>>PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
>> +!if $(SMM_REQUIRE) == TRUE
>> + LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
>> +!endif
>>}
>> !if $(SMM_REQUIRE) == TRUE
>>OvmfPkg/SmmAccess/SmmAccessPei.inf {
>> @@ -708,4 +720,8 @@ [Components]
>># Privileged drivers (DXE_SMM_DRIVER modules)
>>#
>>UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
>> + MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf {
>> +
>> + LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
>> + }
>> !endif
>> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
>> index 6679e8a..d177154 100644
>> -
[edk2] [PATCH] MdeModulePkg/Pxe: Fix bug of checking input FilePath
There is a simple bug in below code and will cause PXE always
returning invalid parameter:
if (FilePath == NULL || !IsDevicePathEnd (FilePath)) {
return EFI_INVALID_PARAMETER;
FilePath should *not* be end node, so return invalid parameter
when FilePath *is* device path end.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Heyi Guo
Cc: Feng Tian
Cc: Zhang Lubo
---
MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
index 89977e6..1c7b664 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
@@ -2776,7 +2776,7 @@ EfiPxeLoadFile (
UINT64 TmpBufSize;
BOOLEAN MediaPresent;
- if (FilePath == NULL || !IsDevicePathEnd (FilePath)) {
+ if (FilePath == NULL || IsDevicePathEnd (FilePath)) {
return EFI_INVALID_PARAMETER;
}
--
2.6.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
