[edk2] [Patch] SecurityPkg OpalPasswordDxe: Suppress option for special device.

According to current Pyrite SSC Spec 1.00, there is no parameter for RevertSP method. So suppress KeepUserData option for the Pyrite Ssc type device. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong Cc: Feng Tian ---

Re: [edk2] [Patch] BaseTools: Add support to merge Prebuild and Postbuild into build Process

Reviewed-by: Liming Gao > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Yonghong Zhu > Sent: Tuesday, April 05, 2016 3:04 PM > To: edk2-devel@lists.01.org > Subject: [edk2] [Patch] BaseTools: Add support to merge

Re: [edk2] [Patch] BaseTools: Enhance --Pcd which override by build option

Reviewed-by: Liming Gao > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Yonghong Zhu > Sent: Tuesday, April 05, 2016 12:32 PM > To: edk2-devel@lists.01.org > Subject: [edk2] [Patch] BaseTools: Enhance --Pcd which

Re: [edk2] [Patch] MdeModulePkg/Bds: Fix build failures of VS tool chain

Reviewed-by: Qiu Shumin -Original Message- From: Ni, Ruiyu Sent: Thursday, April 07, 2016 10:14 AM To: edk2-devel@lists.01.org Cc: Ni, Ruiyu; Qiu, Shumin Subject: [Patch] MdeModulePkg/Bds: Fix build failures of VS tool chain Contributed-under: TianoCore

Re: [edk2] [Patch] MdeModulePkg/Bds: Fix build failures of VS tool chain

Thanks for fixing this. Reviewed-by: Sunny Wang -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni Sent: Thursday, April 07, 2016 10:14 AM To: edk2-devel@lists.01.org Cc: Ruiyu Ni ; Shumin Qiu

[edk2] [Patch] MdeModulePkg/Bds: Fix build failures of VS tool chain

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Shumin Qiu --- MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 1 + MdeModulePkg/Library/UefiBootManagerLib/BmMisc.c | 2 +- 2 files changed, 2 insertions(+), 1

Re: [edk2] [PATCH 03/12] FatBinPkg: Change to 2-clause BSD license

My understanding is: Shell is a very standalone project so the binary package was created for a certain level of isolation. And it does save build time. It also assumes that most of the users don't need to source debug the Shell. Fat is similar to Shell. But I agree the build time saving is not

Re: [edk2] [PATCH V2 0/8] Move S3Ready() functional code from AcpiS3SaveDxe to S3SaveStateDxe

MdeModelPkg/IntelFrameworkModulePkg reviewed by: jiewen@intel.com > -Original Message- > From: Zeng, Star > Sent: Wednesday, April 6, 2016 8:40 PM > To: edk2-devel@lists.01.org > Cc: Yao, Jiewen ; Tian, Feng ; > Fan, Jeff

Re: [edk2] [PATCH] SecurityPkg/Tpm12CommandLib: Fix Tpm12NvWriteValue cmd.

Reviewed by: jiewen@intel.com > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Derek Lin > Sent: Thursday, April 7, 2016 9:55 AM > To: edk2-devel@lists.01.org > Cc: Derek Lin > Subject: [edk2] [PATCH]

[edk2] [PATCH] SecurityPkg/Tpm12CommandLib: Fix Tpm12NvWriteValue cmd.

Fix command length endian. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Derek Lin --- SecurityPkg/Library/Tpm12CommandLib/Tpm12NvStorage.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git

Re: [edk2] [PATCH V2 0/8] Move S3Ready() functional code from AcpiS3SaveDxe to S3SaveStateDxe

On 2016/4/7 0:04, Laszlo Ersek wrote: Hi Star, On 04/06/16 14:40, Star Zeng wrote: The S3Ready() functional code in AcpiS3SaveDxe of IntelFrameworkModulePkg is to do ACPI S3 Context save. In fact, that is not really related to Intel framework ACPI S3 protocol. IntelFrameworkModulePkg will be

Re: [edk2] [PATCH V2 3/8] OvmfPkg: Install LockBox protocol in constructor of LockBoxDxeLib

The comments below are fair enough, accepted. Thanks, Star On 2016/4/7 0:24, Laszlo Ersek wrote: On 04/06/16 14:40, Star Zeng wrote: Currently, the LockBox protocol is installed in entrypoint of OVMF AcpiS3SaveDxe, that is strange. (6) please remove the phrase that is strange It is not

Re: [edk2] [PATCH V2 2/8] OvmfPkg: Set PcdAcpiS3Enable according to QemuFwCfgS3Enabled()

On 2016/4/7 0:16, Laszlo Ersek wrote: On 04/06/16 14:40, Star Zeng wrote: Also need to declare PcdAcpiS3Enable as DynamicDefault in *.dsc. Cc: Laszlo Ersek Cc: Jordan Justen Cc: Jiewen Yao Contributed-under: TianoCore

[edk2] Building a SMM_CORE module as an XIP image

Hi All, I am prototyping the proposal made in ECR #1390 (MM in Standalone mode etc) on the Juno and FVP ARM development platforms. The prototype mainly has a module of type SMM_CORE that contains: a. The MM Foundation code in Standalone mode. Lets call the entry point of this module

Re: [edk2] [PATCH 04/21] ArmVirtPkg/FdtClientDxe: implement new driver

On 04/06/16 18:15, Ard Biesheuvel wrote: > This implements a new DXE driver FdtClientDxe to produce the FDT client > protocol based on a device tree image supplied by the virt host. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ard Biesheuvel

Re: [edk2] [PATCH 03/21] ArmVirtPkg: drop dependency on PeiPcdLib for PEI Pcd.inf

On 04/06/16 18:15, Ard Biesheuvel wrote: > The PcdPeim dynamic PCD driver is dispatched explicitly via an 'A PRIORI' > declaration in the platform DSC. Without that declaration, the PEI module > can never be dispatched since it transitively depends on protocols it (4) s/protocols/the PPI/ with

Re: [edk2] [PATCH 02/21] ArmVirtPkg: drop dependency on DxePcdLib for DXE Pcd.inf

On 04/06/16 18:15, Ard Biesheuvel wrote: > The PcdDxe dynamic PCD driver is dispatched explicitly via an 'A PRIORI' > declaration in the platform DSC. Without that declaration, the DXE driver > can never be dispatched since it transitively depends on protocols it > produces itself via DxePcdLib.

Re: [edk2] [PATCH 01/21] ArmVirtPkg: introduce FdtClientProtocol

On 04/06/16 18:14, Ard Biesheuvel wrote: > This introduces the FdtClientProtocol, which will be used to expose the > device tree provided by the host to other DXE drivers. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ard Biesheuvel > ---

Re: [edk2] [PATCH 04/12] ArmVirtPkg: Convert to build FatPkg from source

On 04/06/16 17:14, Jordan Justen wrote: > Now that FatPkg is open source (and therefore can be included in the > EDK II tree) we build and use it directly. > > Note: Not build tested > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Jordan Justen

Re: [edk2] [PATCH 03/12] FatBinPkg: Change to 2-clause BSD license

On 04/06/16 17:14, Jordan Justen wrote: > The FatPkg is now open source. Update FatBinPkg license to match > FatPkg. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Jordan Justen > Cc: Ruiyu Ni > --- >

Re: [edk2] [PATCH 02/12] FatPkg: Add Contributions.txt

On 04/06/16 17:14, Jordan Justen wrote: > This is copied from MdePkg/Contributions.txt > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Jordan Justen > Cc: Ruiyu Ni > --- > FatPkg/Contributions.txt | 218 >

Re: [edk2] [PATCH 01/12] FatPkg: Update License.txt to have the full license text

On 04/06/16 17:14, Jordan Justen wrote: > The script replaced the contents of License.txt will the words the s/will the words/with the words of/ > shortened text that we include in the headers to files. Instead, use s/headers to/source/ > the full text. This is copied from MdePkg/License.txt.

Re: [edk2] [PATCH 1/2] OvmfPkg: disable PcdHiiOsRuntimeSupport

On 04/06/16 19:32, Jordan Justen wrote: > Reviewed-by: Jordan Justen Commit eccc28bfcb91b5d72adf173d7404652c7aa63c26. Thank you! Laszlo > > On 2016-03-29 10:51:29, Laszlo Ersek wrote: >> Edk2 commit 8a45f80edad4 ("MdeModulePkg: Make HII configuration settings >>

Re: [edk2] [PATCH] OvmfPkg: remove PcdMaxHardwareErrorVariableSize from the DSC files

On 04/06/16 19:34, Jordan Justen wrote: > Reviewed-by: Jordan Justen Commit 29d0259e06ee0d0772d1068e02fb2242542fad2a. Thanks! Laszlo > On 2016-03-25 04:02:25, Laszlo Ersek wrote: >> PcdMaxHardwareErrorVariableSize sets the size limit for individual >> Hardware Error

Re: [edk2] [PATCH] OvmfPkg: remove PcdMaxHardwareErrorVariableSize from the DSC files

Reviewed-by: Jordan Justen On 2016-03-25 04:02:25, Laszlo Ersek wrote: > PcdMaxHardwareErrorVariableSize sets the size limit for individual > Hardware Error Record Variables (see "7.2.3 Hardware Error Record > Persistence" and "Appendix P, Hardware Error Record

Re: [edk2] [PATCH 1/2] OvmfPkg: disable PcdHiiOsRuntimeSupport

Reviewed-by: Jordan Justen On 2016-03-29 10:51:29, Laszlo Ersek wrote: > Edk2 commit 8a45f80edad4 ("MdeModulePkg: Make HII configuration settings > available to OS runtime") implements the optional UEFI feature described > in "31.2.11.1 OS Runtime Utilization" in UEFI

Re: [edk2] [wave 3 PATCH v2 00/17] OvmfPkg, ArmVirtPkg: VirtIo 1.0

On 04/06/16 16:57, Jordan Justen wrote: > On 2016-04-06 05:40:10, Laszlo Ersek wrote: >> Version 2 of >> . >> >> Public branch: . >> >> * The following patches are new: >> >>

Re: [edk2] [PATCH V2 0/8] Move S3Ready() functional code from AcpiS3SaveDxe to S3SaveStateDxe

On 04/06/16 18:04, Laszlo Ersek wrote: > Hi Star, > > On 04/06/16 14:40, Star Zeng wrote: >> The S3Ready() functional code in AcpiS3SaveDxe of IntelFrameworkModulePkg >> is to do ACPI S3 Context save. In fact, that is not really related to >> Intel framework ACPI S3 protocol. >> >>

Re: [edk2] [PATCH V2 6/8] OvmfPkg: Retire AcpiS3SaveDxe

On 04/06/16 14:40, Star Zeng wrote: > The same functional code has been in S3SaveStateDxe, > OVMF AcpiS3SaveDxe can be retired now. > > Cc: Laszlo Ersek > Cc: Jordan Justen > Cc: Jiewen Yao > Contributed-under: TianoCore

Re: [edk2] [PATCH 00/21] VirtFdtDxe refactoring

On 6 April 2016 at 18:14, Ard Biesheuvel wrote: > This is the first step towards getting rid of the kludge which is VirtFdtDxe. > > This series addresses the cases where other DXE drivers rely on dynamic PCDs > populated by VirtFdtDxe, which requires it to execute first

Re: [edk2] [PATCH V2 4/8] MdeModulePkg S3SaveStateDxe: Consume PcdAcpiS3Enable to control the code

On 04/06/16 14:40, Star Zeng wrote: > Cc: Feng Tian > Cc: Jiewen Yao > Cc: Laszlo Ersek > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Star Zeng > --- >

Re: [edk2] [PATCH V2 3/8] OvmfPkg: Install LockBox protocol in constructor of LockBoxDxeLib

On 04/06/16 14:40, Star Zeng wrote: > Currently, the LockBox protocol is installed in entrypoint of > OVMF AcpiS3SaveDxe, that is strange. (6) please remove the phrase that is strange It is not strange; the commit message for the change justified it. (In other words, what the patch does is

[edk2] [PATCH 21/21] ArmVirtPkg: get rid of A PRIORI DXE declarations for VirtFdtDxe

We no longer care when VirtFdtDxe executes, since the dependencies are now all resolved via protocols. So drop the A PRIORI declaration. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmVirtPkg/ArmVirtQemu.fdf | 4

Re: [edk2] [PATCH V2 2/8] OvmfPkg: Set PcdAcpiS3Enable according to QemuFwCfgS3Enabled()

On 04/06/16 14:40, Star Zeng wrote: > Also need to declare PcdAcpiS3Enable as DynamicDefault in *.dsc. > > Cc: Laszlo Ersek > Cc: Jordan Justen > Cc: Jiewen Yao > Contributed-under: TianoCore Contribution Agreement 1.0 >

[edk2] [PATCH 19/21] ArmVirtPkg: move QEMU based platforms to ArmVirtRtcFdtClientLib

This moves QEMU based platforms to ArmVirtRtcFdtClientLib, so that we no longer have to rely on VirtFdtDxe to execute first and set the RTC base address in a dynamic PCD. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ---

[edk2] [PATCH 16/21] ArmVirtPkg/BaseCachingPciExpressLib: construct at first invocation

Instead of using a constructor, which may reference a dynamic PCD which is set by the DXE entry point of its user, defer the assignment of the global mPciExpressBaseAddress until the first the library is actually invoked. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard

Re: [edk2] [PATCH 06/12] CorebootPayloadPkg: Convert to build FatPkg from source

On 2016-04-06 08:57:01, Agyeman, Prince wrote: > Jordan, >Will the FatPkg move into the EDKII repo then ? Yes. It should be added to EDK II later today. (Before this patch would be pushed.) -Jordan > > -Original Message- > From: Justen, Jordan L > Sent: Wednesday, April 6, 2016

[edk2] [PATCH 14/21] ArmVirtPkg/VirtFdtDxe: remove handling of fw_cfg DT node

Remove the handling of the fw_cfg DT node from VirtFdtDxe now that the fw_cfg client library has been moved to the FDT client protocol, and no longer relies on VirtFdtDxe to pass this information via dynamic PCDs. Since the PCDs in question are now no longer used, remove them from the various DEC

[edk2] [PATCH 18/21] ArmVirtPkg: implement ArmVirtRtcFdtClientLib

This implements a library ArmVirtRtcFdtClientLib which is intended to be incorporated into RealTimeClockRuntimeDxe via NULL library class resolution. This allows us to make RealTimeClockRuntimeDxe depend on the FDT client protocol, and discover the RTC base address from the device tree directly

[edk2] [PATCH 15/21] ArmVirtPkg/PciHostBridgeDxe: move to FDT client protocol

Instead of relying on VirtFdtDxe to populate various dynamic PCDs with information retrieved from the host provided device tree, perform the PCI ECAM related DT node parsing directly in PciHostBridgeDxe. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel

[edk2] [PATCH 20/21] ArmVirtPkg/VirtFdtDxe: drop RTC handling

The RTC driver no longer relies on VirtFdtDxe to set the pl031 RTC base address in a dynamic PCD, so drop the handling altogether. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c | 36

[edk2] [PATCH 13/21] ArmVirtPkg/QemuFwCfgLib: move to FDT client protocol

Make this library depend on the FDT client protocol to access the host supplied device tree directly rather than depending on VirtFdtDxe to set them using dynamic PCDs. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ---

[edk2] [PATCH 17/21] ArmVirtPkg/VirtFdtDxe: drop PCI host bridge handling

Now that the PCI host bridge driver parses the DT node that describes the PCI host bridge directly via the FDT client protocol, we can drop the handling from VirtFdtDxe completely. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel

[edk2] [PATCH 08/21] ArmVirtPkg/ArmVirtPsciResetSystemLib: move to FDT client protocol

Instead of relying on VirtFdtDxe to detect the PSCI method, move our EfiResetSystemLib to the FDT client protocol to interrogate the device tree directly. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ---

[edk2] [PATCH 12/21] ArmVirtPkg/VirtFdtDxe: remove timer DT node handling

The timer code no longer relies on VirtFdtDxe to set the PCDs, so remove the handling of the timer node and the references to those PCDs. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c |

[edk2] [PATCH 11/21] ArmVirtPkg: move TimerDxe to FDT client library

Move to the new dedicated to ArmVirtTimerFdtClientLib to populate the various timer related PCDs at driver load time rather than relying on VirtFdtDxe to do it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ---

[edk2] [PATCH 05/21] ArmVirtPkg: add FdtClientDxe to the ArmVirtPkg platforms

Add FdtClientDxe to the various platforms under ArmVirtPkg, which will be required when we update the shared ArmGicArchLib to depend on it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmVirtPkg/ArmVirtQemu.dsc | 1 +

[edk2] [PATCH 10/21] ArmVirtPkg: implement ArmVirtTimerFdtClientLib

This implements a library ArmVirtTimerFdtClientLib which is intended to be incorporated into TimerDxe via NULL library class resolution. This allows us to make TimerDxe depend on the FDT client protocol, and discover the timer interrupts from the device tree directly rather than relying on

[edk2] [PATCH 03/21] ArmVirtPkg: drop dependency on PeiPcdLib for PEI Pcd.inf

The PcdPeim dynamic PCD driver is dispatched explicitly via an 'A PRIORI' declaration in the platform DSC. Without that declaration, the PEI module can never be dispatched since it transitively depends on protocols it produces itself via PeiPcdLib. So use the NULL PcdLib explicitly only for this

[edk2] [PATCH 09/21] ArmVirtPkg/VirtFdtDxe: drop detection of PSCI method

The detection of the PSCI method has been moved to the EfiResetSystemLib implementation, so drop the handling from VirtFdtDxe. Since no users remain of gArmVirtTokenSpaceGuid.PcdArmPsciMethod, remove that as well. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard

[edk2] [PATCH 01/21] ArmVirtPkg: introduce FdtClientProtocol

This introduces the FdtClientProtocol, which will be used to expose the device tree provided by the host to other DXE drivers. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmVirtPkg/ArmVirtPkg.dec | 3 +

[edk2] [PATCH 00/21] VirtFdtDxe refactoring

This is the first step towards getting rid of the kludge which is VirtFdtDxe. This series addresses the cases where other DXE drivers rely on dynamic PCDs populated by VirtFdtDxe, which requires it to execute first using an A PRIORI declaration. Instead, this series moves the DT node parsing to

[edk2] [PATCH 04/21] ArmVirtPkg/FdtClientDxe: implement new driver

This implements a new DXE driver FdtClientDxe to produce the FDT client protocol based on a device tree image supplied by the virt host. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmVirtPkg/FdtClientDxe/FdtClientDxe.c

Re: [edk2] [PATCH V2 0/8] Move S3Ready() functional code from AcpiS3SaveDxe to S3SaveStateDxe

Hi Star, On 04/06/16 14:40, Star Zeng wrote: > The S3Ready() functional code in AcpiS3SaveDxe of IntelFrameworkModulePkg > is to do ACPI S3 Context save. In fact, that is not really related to > Intel framework ACPI S3 protocol. > > IntelFrameworkModulePkg will be deprecated step by step, so

[edk2] Performance identifier mismatch in TrEEDxe.c and TrEEPei.c

Hello all, I am studying about measuring the boot performance with PERF_START_EX and PERF_STOP_EX. I notice that in both files SecurityPkg/Tcg/TrEEDxe/TrEEDxe.c and SecurityPkg/Tcg/TrEEPei/TrEEPei.c the input identifier value of the PERF_STOP_EX is one bigger than the input identifier value

Re: [edk2] [PATCH 04/12] ArmVirtPkg: Convert to build FatPkg from source

On 6 April 2016 at 17:14, Jordan Justen wrote: > Now that FatPkg is open source (and therefore can be included in the > EDK II tree) we build and use it directly. > > Note: Not build tested > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by:

Re: [edk2] [PATCH 05/12] BeagleBoardPkg: Convert to build FatPkg from source

On 6 April 2016 at 17:14, Jordan Justen wrote: > Now that FatPkg is open source (and therefore can be included in the > EDK II tree) we build and use it directly. > > Note: Not build tested > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by:

Re: [edk2] [PATCH 09/12] EmulatorPkg: Convert to always build FatPkg

> On Apr 6, 2016, at 8:14 AM, Jordan Justen wrote: > > Now that FatPkg is open source (and therefore can be included in the > EDK II tree) we always build and use it directly. > > Build and boot tested with GCC 5.3 on X64, but I did not test > attaching a disk image

[edk2] [PATCH 05/12] BeagleBoardPkg: Convert to build FatPkg from source

Now that FatPkg is open source (and therefore can be included in the EDK II tree) we build and use it directly. Note: Not build tested Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen Cc: Leif Lindholm Cc:

[edk2] [PATCH 09/12] EmulatorPkg: Convert to always build FatPkg

Now that FatPkg is open source (and therefore can be included in the EDK II tree) we always build and use it directly. Build and boot tested with GCC 5.3 on X64, but I did not test attaching a disk image with a FAT filesystem. Contributed-under: TianoCore Contribution Agreement 1.0

[edk2] [PATCH 02/12] FatPkg: Add Contributions.txt

This is copied from MdePkg/Contributions.txt Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen Cc: Ruiyu Ni --- FatPkg/Contributions.txt | 218 +++ 1 file changed, 218

[edk2] [PATCH 00/12] Cleanups to follow FatPkg license update

web: https://github.com/jljusten/edk2/tree/fatpkg-open-source-cleanups-v1 git: https://github.com/jljusten/edk2.git fatpkg-open-source-cleanups-v1 The license update to FatPkg is expected to be pushed later today. Following the license update, I recommend these changes. Jordan Justen (12):

[edk2] [PATCH 11/12] OvmfPkg: Convert to using FatPkg in the EDK II tree

Now that FatPkg is open source (and therefore can be included in the EDK II tree) we build and use it directly. Build tested with GCC 5.3 on IA32 and X64. Boot tested to UEFI Shell on IA32 and UEFI Linux on X64. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen

[edk2] [PATCH 10/12] Nt32Pkg: Convert to build FatPkg from source

Now that FatPkg is open source (and therefore can be included in the EDK II tree) we build and use it directly. Note: Not build tested Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen Cc: Ruiyu Ni ---

[edk2] [PATCH 12/12] Vlv2TbltDevicePkg: Convert to build FatPkg from source

Now that FatPkg is open source (and therefore can be included in the EDK II tree) we build and use it directly. Note: Not build tested Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen Cc: David Wei Cc: Tim He

[edk2] [PATCH 03/12] FatBinPkg: Change to 2-clause BSD license

The FatPkg is now open source. Update FatBinPkg license to match FatPkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen Cc: Ruiyu Ni --- FatBinPkg/FatBinPkg.dec | 2 +- FatBinPkg/License.txt | 53

[edk2] [PATCH 06/12] CorebootPayloadPkg: Convert to build FatPkg from source

Now that FatPkg is open source (and therefore can be included in the EDK II tree) we build and use it directly. Note: Build tested with GCC 5.3 on IA32 and IA32+X64. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen Cc: Maurice Ma

[edk2] [PATCH 04/12] ArmVirtPkg: Convert to build FatPkg from source

Now that FatPkg is open source (and therefore can be included in the EDK II tree) we build and use it directly. Note: Not build tested Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen Cc: Laszlo Ersek Cc: Ard

[edk2] [PATCH 07/12] DuetPkg scripts: Support building with GCC45 - GCC49

Build tested with GCC 5.3 with both IA32 and X64. Unfortunately both seemed to hang very early when boot tested on QEMU. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen Cc: Ruiyu Ni --- DuetPkg/PostBuild.sh |

[edk2] [PATCH 01/12] FatPkg: Update License.txt to have the full license text

The script replaced the contents of License.txt will the words the shortened text that we include in the headers to files. Instead, use the full text. This is copied from MdePkg/License.txt. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen

Re: [edk2] [wave 3 PATCH v2 00/17] OvmfPkg, ArmVirtPkg: VirtIo 1.0

On 2016-04-06 05:40:10, Laszlo Ersek wrote: > Version 2 of > . > > Public branch: . > > * The following patches are new: > > v2 06/17 OvmfPkg: IndustryStandard: factor out

[edk2] 答复: 答复: [EDK2]an issue that PXE boot failed when received a NACK from the DHCP server

Hi Siyuan, Ard and Michael: I am very sorry to reply you so late because of busy work. The attachment is the DHCP log when the issue happens. First of all, Let me introduce the environment in detail: Multiple boards connect to the DHCP server through a switch . The

[edk2] [wave 3 PATCH v2 09/17] OvmfPkg: VirtioLib: add Virtio10WriteFeatures() function

In VirtIo 1.0, a device can reject a self-inconsistent feature bitmap through the new VSTAT_FEATURES_OK status bit. (For example if the driver requests a higher level feature but clears a prerequisite feature.) This function is a small wrapper around VIRTIO_DEVICE_PROTOCOL.SetGuestFeatures() that

[edk2] [PATCH V2 6/8] OvmfPkg: Retire AcpiS3SaveDxe

The same functional code has been in S3SaveStateDxe, OVMF AcpiS3SaveDxe can be retired now. Cc: Laszlo Ersek Cc: Jordan Justen Cc: Jiewen Yao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng

[edk2] [wave 3 PATCH v2 10/17] OvmfPkg: VirtioBlkDxe: adapt feature negotiation to virtio-1.0

Relative to virtio-0.9.5, virtio-1.0 reverses the order of queue discovery and feature negotiation. In virtio-1.0, feature negotiation has to complete first, and the device can also reject a self-inconsistent feature request through the new VSTAT_FEATURES_OK status bit. (For example if the driver

[edk2] [PATCH V2 8/8] IntelFrameworkModulePkg AcpiS3SaveDxe: Remove S3Ready() functional code

The S3Ready() functional code has been moved to S3SaveStateDxe in MdeModulePkg, the ACPI global variable related code is leaved as is for compatibility. PcdS3BootScriptStackSize is also moved to MdeModulePkg. Cc: Jiewen Yao Cc: Jeff Fan

[edk2] [PATCH V2 1/8] MdeModulePkg: Introduce new PCD PcdAcpiS3Enable

Platform can configure the PCD statically or dynamically to control if ACPI S3 will be enabled. S3 related modules can consume the PCD to control the code. Cc: Feng Tian Cc: Jiewen Yao Cc: Laszlo Ersek Contributed-under: TianoCore

[edk2] [PATCH V2 4/8] MdeModulePkg S3SaveStateDxe: Consume PcdAcpiS3Enable to control the code

Cc: Feng Tian Cc: Jiewen Yao Cc: Laszlo Ersek Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng --- MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c | 5 -

[edk2] [PATCH V2 5/8] MdeModulePkg S3SaveStateDxe: Move S3Ready() functional code from AcpiS3SaveDxe

The S3Ready() functional code in AcpiS3SaveDxe of IntelFrameworkModulePkg is to do ACPI S3 Context save. In fact, that is not really related to Intel framework ACPI S3 protocol. IntelFrameworkModulePkg will be deprecated step by step, so move the functional code to MdeModulePkg and S3SaveStateDxe

[edk2] [wave 3 PATCH v2 13/17] OvmfPkg: VirtioScsiDxe: adapt feature negotiation to virtio-1.0

Relative to virtio-0.9.5, virtio-1.0 reverses the order of queue discovery and feature negotiation. In virtio-1.0, feature negotiation has to complete first, and the device can also reject a self-inconsistent feature request through the new VSTAT_FEATURES_OK status bit. (For example if the driver

[edk2] [wave 3 PATCH v2 15/17] OvmfPkg: Virtio10Dxe: non-transitional driver for virtio-1.0 PCI devices

This driver implements the VIRTIO_DEVICE_PROTOCOL for non-transitional PCI devices, based on the virtio-1.0 specification (csprd05). Non-transitional means that it only binds QEMU's virtio-xxx-pci devices that receive the ",disable-legacy=on,disable-modern=off" properties on the QEMU command line.

[edk2] [wave 3 PATCH v2 06/17] OvmfPkg: IndustryStandard: factor out Virtio095.h

In the upcoming virtio-1.0 series, we'll introduce "Virtio10.h". However, the "Virtio.h" header file should continue to expose the generic type and macro definitions for all virtio versions that OvmfPkg supports. Therefore extract "Virtio095.h" like this: Virtio.h -> Virtio095.h so that in the

[edk2] [wave 3 PATCH v2 08/17] OvmfPkg: IndustryStandard: add definitions from the VirtIo 1.0 spec

These header files are intentionally minimal, and intentionally kept apart from the VirtIo 0.9.5 headers. The header inclusion chains end up like this (the Virtio10*.h header files in the middle are new): Virtio.h-> Virtio10.h-> Virtio095.h ^ ^

[edk2] [wave 3 PATCH v2 17/17] ArmVirtPkg: include Virtio10Dxe from OvmfPkg

Cc: Ard Biesheuvel Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Reviewed-by: Ard Biesheuvel Tested-by: Ard Biesheuvel Reviewed-by: Jordan Justen

[edk2] [wave 3 PATCH v2 14/17] OvmfPkg: VirtioNetDxe: adapt virtio-net packet header size to virtio-1.0

In virtio-0.9.5, the size of the virtio-net packet header depends on whether the VIRTIO_NET_F_MRG_RXBUF feature is negotiated -- the "num_buffers" field is only appended to the header if the feature is negotiated. Since we never negotiate this feature, VirtioNetDxe never allocates room for the

[edk2] [wave 3 PATCH v2 16/17] OvmfPkg: include Virtio10Dxe

Cc: Jordan Justen Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Tested-by: Ard Biesheuvel Reviewed-by: Jordan Justen --- OvmfPkg/OvmfPkgIa32.dsc| 1 +

[edk2] [wave 3 PATCH v2 00/17] OvmfPkg, ArmVirtPkg: VirtIo 1.0

Version 2 of . Public branch: . * The following patches are new: v2 06/17 OvmfPkg: IndustryStandard: factor out Virtio095.h v2 07/17 OvmfPkg: IndustryStandard: factor out

[edk2] [wave 3 PATCH v2 03/17] OvmfPkg: VIRTIO_DEVICE_PROTOCOL: pass VRING object to SetQueueAddress()

In virtio-1.0, it is not enough to pass the base address of the virtio queue to the hypervisor (as a frame number); instead it will want the addresses of the descriptor table, the available ring, and the used ring separately. Pass the VRING object to the SetQueueAddress() member function; this

[edk2] [wave 3 PATCH v2 02/17] OvmfPkg: VIRTIO_DEVICE_PROTOCOL: remove GetQueueAddress() member

This function was never consumed by drivers, and the current prototype is unsupportable with virtio-1.0. Remove the function from the protocol definition, and drop the current (unused) implementations. Cc: Ard Biesheuvel Cc: Jordan Justen

[edk2] [wave 3 PATCH v2 07/17] OvmfPkg: IndustryStandard: factor out Virtio095Net.h

In the upcoming virtio-1.0 series, we'll introduce "Virtio10Net.h". However, the "VirtioNet.h" header file should continue to expose the Virtio Network Device specific type and macro definitions for all virtio versions that OvmfPkg supports. Therefore extract "Virtio095Net.h" like this:

[edk2] [wave 3 PATCH v2 04/17] OvmfPkg: VirtioBlkDxe: don't clear non-negotiable feature bits

VirtioBlkDxe only recognizes virtio-block feature bits that the device offers non-negotiably. Nonetheless, in preparation for the following patches, don't try to clear them even for simplicity. Cc: Ard Biesheuvel Cc: Jordan Justen

[edk2] [wave 3 PATCH v2 05/17] OvmfPkg: VirtioRngDxe: clear all feature bits more explicitly

This too is in preparation for the following patches. After this patch, all four drivers manage their feature bits with explicit masking. Cc: Ard Biesheuvel Cc: Jordan Justen Contributed-under: TianoCore Contribution Agreement 1.0

[edk2] [wave 3 PATCH v2 01/17] OvmfPkg: VIRTIO_DEVICE_PROTOCOL: widen the Features bitmap to 64 bits

The virtio-1.0 spec widens the Features bitmap to 64 bits. Modify the declarations of the GetDeviceFeatures() and SetGuestFeatures() protocol member functions accordingly. Normally, a protocol cannot be changed in incompatible ways if the GUID stays the same; however, we've always been extremely

Re: [edk2] [PATCH 0/4] Move S3Ready() functional code from AcpiS3SaveDxe to S3SaveStateDxe

On 2016/4/1 1:12, Laszlo Ersek wrote: On 03/31/16 17:10, Zeng, Star wrote: On 2016/3/31 19:47, Laszlo Ersek wrote: Therefore, if this subsystem in edk2 is being reworked, my preference would be the following: (1) Please fix the DepEx bug in BootScriptExecutorDxe first, if possible. Instead,

Re: [edk2] [PATCH] MdeModulePkg/UefiBootManagerLib: API BmIsValidLoadOptionVariableName

Looks good to me. Reviewed-by: Sunny Wang -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Palmer, Thomas Sent: Tuesday, April 05, 2016 3:52 AM To: edk2-devel@lists.01.org Cc: ruiyu...@intel.com; feng.t...@intel.com;

[edk2] SMBUS device address mapping

Hello All, Am trying to get SMBUS slave addresses (EFIAPI *EFI_SMBUS_HC_PROTOCOL_ARP_DEVICE) ( IN EFI_SMBUS_HC_PROTOCOL * This, IN BOOLEAN ArpAll, IN EFI_SMBUS_UDID* SmbusUdid, OPTIONAL IN OUT EFI_SMBUS_DEVICE_ADDRESS *

Re: [edk2] [Patch] NetworkPkg: Add RAM disk boot support to HTTP Boot driver.

Siyuan, Some minor comments to the patch: 1. Add perform parameter check for ImageType in HttpBootGetFileFromCache(). 2. Update function description of HttpBootStart/HttpBootLoadFile for EFI_INVALID_PARAMETER since we now add further check. 3. Add EFI_INVALID_PARAMETER to function description

Re: [edk2] [PATCH v2 2/2] NetworkPkg: Add new macros and refine codes

Yes , the label of the patch should be PATCH v2 1/2, may be the patch order generated upside down. thanks for review. Lubo -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Subramanian, Sriram (EG Servers Platform SW) Sent: Wednesday, April 06,

Re: [edk2] [PATCH v2 2/2] NetworkPkg: Add new macros and refine codes

I believe this is PATCH v2 1/2, and not 2/2 as stated in the subject. Looks fine. Reviewed-by: Sriram Subramanian Thanks, Sriram. -Original Message- From: Zhang Lubo [mailto:lubo.zh...@intel.com] Sent: Wednesday, April 6, 2016 11:53 AM To: edk2-devel@lists.01.org Cc:

Re: [edk2] [wave 3 PATCH 00/15] OvmfPkg, ArmVirtPkg: VirtIo 1.0

On 04/06/16 07:40, Jordan Justen wrote: > On 2016-03-14 05:53:17, Laszlo Ersek wrote: >> This series enables OvmfPkg and ArmVirtPkg to work with non-transitional >> VirtIo 1.0 PCI devices. The first 12 patches rework our edk2-only, >> private VIRTIO_DEVICE_PROTOCOL (and its two existent

  1   2   >