Re: [edk2] [EDK2 tcg2] TCG2 variable TCG2_DEVICE_DETECTION_NAME does not work as expected?

Winddy: UEFI TCG/TCG2 solution is designed to make one BIOS image workable with either TPM1.2 or TPM2.0. According to TCG2 spec explanation about TBB/TCB (the platform hardware, connection between CPU, Chipset & TPM etc.) should always be secure and never be compromised. So here, the TPM chip

Re: [edk2] [PATCH v2 2/5] MdeModulePkg: Add FrameBufferBltLib library class

On 10/09/16 10:49, Ruiyu Ni wrote: > This library provides interfaces to perform UEFI Graphics > Output Protocol Video BLT operations. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ruiyu Ni > Cc: Feng Tian > Cc: Justen

Re: [edk2] [PATCH] Add NOOPT build targets to OvmfPkg for source level debugging

On 10/10/16 18:27, Laszlo Ersek wrote: > On 10/10/16 17:43, Bruce Cran wrote: >> >> >> 0001-Add-NOOPT-build-targets-to-OvmfPkg-for-source-level-.patch >> >> >> From ef7b3dfe26bb7748d838974af57cd73e40e24c94 Mon Sep 17 00:00:00 2001 >> From: Bruce Cran >> Date: Mon, 10 Oct

Re: [edk2] [PATCH] Add NOOPT build targets to OvmfPkg for source level debugging

On 10/10/16 17:43, Bruce Cran wrote: > > > 0001-Add-NOOPT-build-targets-to-OvmfPkg-for-source-level-.patch > > > From ef7b3dfe26bb7748d838974af57cd73e40e24c94 Mon Sep 17 00:00:00 2001 > From: Bruce Cran > Date: Mon, 10 Oct 2016 09:35:50 -0600 > Subject: [PATCH] Add

Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services

Eugene, Can you provide examples in EDK II today where the same GUID Value and Structure definition are used in both the UEFI Handle Database and the SMM Handle Database. I am aware of cases where an SMM Driver looks for protocols in the DXE Handle database, but I don't think your proposed lib

Re: [edk2] [PATCH 2/3] ArmPlatformPkg: Correct mendacious comments.

On Wed, Sep 21, 2016 at 09:33:14PM +0100, evan.ll...@arm.com wrote: > From: Alexei > > Correct some obviously incorrect comments that have invalid details for > the returned values. (Copy /Paste problem?) Oh, definitely. Reviewed-by: Leif Lindholm

Re: [edk2] [PATCH] Add NOOPT build targets to OvmfPkg for source level debugging

On 10/10/2016 4:29 PM, Laszlo Ersek wrote: (maybe the subject can be rewritten as OvmfPkg: add NOOPT build target for source level debugging but I can do that later when I commit the patch.) Oh, good point! -- Bruce ___ edk2-devel mailing

Re: [edk2] [PATCH 3/3] ArmPlatformPkg: Remove UINTN cast when setting BaudRate.

On Wed, Sep 21, 2016 at 09:33:15PM +0100, evan.ll...@arm.com wrote: > From: Alexei > > SerialPortInitialize() set the BaudRate variable (type UINT64) as: > BaudRate = (UINTN)FixedPcdGet64 (PcdUartDefaultBaudRate); > > This commit fixes a potential problem on ARM 32-bit

Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services

Mike, > Can you provide examples in EDK II today where the same GUID Value > and Structure definition > are used in both the UEFI Handle Database and the SMM Handle > Database. The example exists in our internal code right now. We have two platform families: one with SMM and one without. We

Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services

Eugene, I agree that accessing DXE protocols in an SMI handler is not allowed. It is legal for an SMM Driver to access DXE content in the SMM Driver Entry Point. For example, if an SMM Driver depends on PCDs, the PCD values can be read from the PCD database through the PCD Protocol in the

Re: [edk2] [PATCH V2 00/50] Add capsule update and recovery sample.

Jiewen, Mike, and the EDK2 list, This is not a feedback directly on this patch and the C code but more on the overall feature of capsule update/recovery. You are implementing one specific way to do capsule update. There are infinite other implementations and my issue is how this

[edk2] [PATCH V3 1/3] MdeModulePkg/dec: Add PcdRecoveryFileName PCD.

This PCD is used to indicated the recovery file name. The previous name - FvMain.Fv is hardcoded in FatPei and CdExpressPei. It does not make sense to force the name. Now a platform may use any recovery file name. Tested-by: Michael D Kinney Cc: Feng Tian

[edk2] [PATCH V3 3/3] FatPkg/FatPei: Use PcdRecoveryFileName PCD.

This PCD is used to indicated the recovery file name. The previous name - FvMain.Fv is hardcoded in FatPei. It does not make sense to force the name. Now a platform may use any recovery file name. Tested-by: Michael D Kinney Cc: Ruiyu Ni Cc:

Re: [edk2] [Patch] DuetPkg DxeIpl and EfiLdr: Add the missing EFIAPI for the function

Reviewed-by: Ruiyu Ni > -Original Message- > From: Gao, Liming > Sent: Tuesday, October 11, 2016 9:45 AM > To: edk2-devel@lists.01.org > Cc: Ni, Ruiyu > Subject: [Patch] DuetPkg DxeIpl and EfiLdr: Add the missing EFIAPI for the > function > > The

Re: [edk2] [PATCH V2 0/3] Add PcdRecoveryFileName PCD.

Jiewen, I have resolved my build issue. I have verified that using a recovery filename of L"QUARKREC.Cap" works. However, as part of my testing, I added this PCD to a [PcdsFixedAtBuild] section and the FAT PEIM does not build. With this PCD type the PcdGetPtr() function returns a CONST

Re: [edk2] [Patch V4] BaseTools: support the NOOPT target with the GCC tool chains

Reviewed-by: Liming Gao > -Original Message- > From: Zhu, Yonghong > Sent: Tuesday, October 11, 2016 10:01 AM > To: edk2-devel@lists.01.org > Cc: Gao, Liming ; Laszlo Ersek > Subject: [Patch V4] BaseTools: support the NOOPT

Re: [edk2] [PATCH 1/3] ArmPlatformPkg: Fix PL011 FIFO size test

Apologies for delay, now catching up post plugfest and Linaro Connect. On Wed, Sep 21, 2016 at 09:33:13PM +0100, evan.ll...@arm.com wrote: > From: Evan Lloyd > > This change updates PL011UartInitializePort to compare ReceiveFifoDepth > with the correct hardware FIFO size

Re: [edk2] [PATCH] QuarkPlatformPkg/PlatformFlashAccessLib: Skip the update if content is same.

Sure. Definition. It will be merged. :) Thanks to help me validate that. From: Kinney, Michael D Sent: Tuesday, October 11, 2016 8:38 AM To: Yao, Jiewen ; edk2-devel@lists.01.org; Kinney, Michael D Cc: Tian, Feng ; Gao,

Re: [edk2] [PATCH] Add NOOPT build targets to OvmfPkg for source level debugging

Looks good to me. When the BaseTools' support for NOOPT is reviewed and pushed, I will inform to you. Thanks. Best Regards, Zhu Yonghong -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Tuesday, October 11, 2016 12:30 AM To: Bruce Cran Cc:

[edk2] [Patch V4] BaseTools: support the NOOPT target with the GCC tool chains

Update the tools_def.template to add NOOPT support with GCC tool chains. Also disable -flto and -Os in NOOPT target for GCC5. Cc: Liming Gao Cc: Laszlo Ersek Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yonghong Zhu

Re: [edk2] [Patch] Nt32Pkg WinNtSimpleFileSystemDxe: Correct file length.

Reviewed-by: Ruiyu Ni > -Original Message- > From: Dong, Eric > Sent: Monday, October 10, 2016 4:36 PM > To: edk2-devel@lists.01.org > Cc: Ni, Ruiyu > Subject: [Patch] Nt32Pkg WinNtSimpleFileSystemDxe: Correct file length. > > In GetInfo

Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services

Eugene, I am confused by one aspect of this proposal. The GUID values for PPIs, DXE Protocols, UEFI Protocols, and SMM Protocols are unique. Which means if code is written to work in one phase, you can not share code to another phase because the GUID values must be changed. The other libs

Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services

Mike, > The GUID values for PPIs, DXE Protocols, UEFI Protocols, > and SMM Protocols are unique. Which means if code is written > to work in one phase, you can not share code to another > phase because the GUID values must be changed. My original use case was a protocol definition where both

Re: [edk2] [PATCH] QuarkPlatformPkg/PlatformFlashAccessLib: Skip the update if content is same.

Jiewen, I have applied this patch on top of your FMP v2 series and verified that it skips erase/write of FLASH sectors that match in Galileo Gen 2 platform. Since this patch is against the new lib that is part of Quark specific capsule update, it should be integrated into an FMP v3 patch series

[edk2] [PATCH V3 2/3] MdeModulePkg/CdExpressPei: Use PcdRecoveryFileName PCD.

This PCD is used to indicated the recovery file name. The previous name - FvMain.Fv is hardcoded in CdExpressPei. It does not make sense to force the name. Now a platform may use any recovery file name. Cc: Feng Tian Cc: Star Zeng Cc: Liming Gao

[edk2] [PATCH V3 0/3] Add PcdRecoveryFileName PCD.

The V3 version fixes PcdGetPtr() type cast issue in FatPei. = The V2 version moves PCD to [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx] = This PCD is used to indicated the recovery file name. The previous name - FvMain.Fv is

[edk2] [Patch] DuetPkg DxeIpl and EfiLdr: Add the missing EFIAPI for the function

The function with the variable parameters should have EFIAPI. Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao --- DuetPkg/DxeIpl/Debug.c | 1 + DuetPkg/DxeIpl/Debug.h | 1 + DuetPkg/EfiLdr/Debug.c | 1 +

[edk2] [PATCH V2 4/4] Vlv2TbleDevicePkg/Bds: Produce PcdTestKeyUsed.

Update BDS to produce PcdTestKeyUsed to indicate if there is any test key used in current BIOS, such as recovery key, or capsule update key. Then the generic UI may consume this PCD to show warning information. Cc: David Wei Cc: Eric Dong Cc: Ruiyu Ni

[edk2] [PATCH V2 2/4] MdeModulePkg/UiApp: Show test key warning info in FrontPage.

The UiApp is updated to consume PcdTestKeyUsed to know if there is any test key used in current BIOS, such as recovery key, or capsule update key. Then UiApp show warning information in front page. Cc: Eric Dong Cc: Ruiyu Ni Cc: Feng Tian

[edk2] [PATCH V2 1/4] MdeModulePkg/dec: Add PcdTestKeyUsed PCD.

This PCD can be set by platform to indicate if there is any test key used in current BIOS, such as recovery key, or capsule update key. Then the generic UI may consume this PCD to show warning information. Other platform driver may also consume this PCD to know such info, and report it via

[edk2] [PATCH V2 3/4] QuarkPlatformPkg/Bds: Produce PcdTestKeyUsed.

Update BDS to produce PcdTestKeyUsed to indicate if there is any test key used in current BIOS, such as recovery key, or capsule update key. Then the generic UI may consume this PCD to show warning information. Cc: Michael D Kinney Cc: Kelly Steele

Re: [edk2] [PATCH v2 0/5] Add FrameBufferBltLib and GraphicsOutputDxe

Reviewed-by: Feng Tian Thanks Feng -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni Sent: Sunday, October 9, 2016 4:50 PM To: edk2-devel@lists.01.org Subject: [edk2] [PATCH v2 0/5] Add FrameBufferBltLib and

[edk2] [Patch] Nt32Pkg WinNtSimpleFileSystemDxe: Correct file length.

In GetInfo interface, current code copy real file name buffer with full path file length. It should use real file name length. This patch fix this error. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong Cc: Ruiyu Ni ---

Re: [edk2] [PATCH V2 00/50] Add capsule update and recovery sample.

HI Correct me if I am wrong. I believe the package position in edkii is that: *only* MdePkg is industry standard. MdeModulePkg is *EDKII implementation*, instead of industry standard. That is why we separate MdeModulePkg from MdePkg. You may find some EDKII_* protocol in MdeModulePkg. But all

Re: [edk2] [PATCH V2 00/50] Add capsule update and recovery sample.

Sean, Thanks for the feedback. There are no touches to the MdePkg that contains the includes/libs for industry standard specifications. 23 of the patches are against MdeModulePkg, IntelFrameworkModulePkg, and the SecurityPkg. The MdeModulePkg contains modules that are allowed to depend on

Re: [edk2] [PATCH v3 1/5] MdePkg/GraphicsInfoHob: Add GraphicsDeviceInfo HOB GUID and structure

Reviewed-by: Liming Gao > -Original Message- > From: Ni, Ruiyu > Sent: Monday, October 10, 2016 10:35 AM > To: edk2-devel@lists.01.org > Cc: Gao, Liming > Subject: [PATCH v3 1/5] MdePkg/GraphicsInfoHob: Add GraphicsDeviceInfo > HOB GUID and

[edk2] [PATCH] MdeModulePkg/MdeModulePkg.dec: Fix EBC build failure of PciBus driver

When PciBus is built as EBC, PcdPciDegradeResourceForOptionRom does not have associated value resulting build failure. The patch sets the default value to TRUE, covering the EBC ARCH. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Ard

[edk2] [PATCH v4 0/8] Add FrameBufferBltLib and GraphicsOutputDxe

The patch serials add the FrameBufferBltLib to MdePkg. Based on the library, a generic GOP driver GraphicsOutputDxe is developed and added to MdeModulePkg. OvmfPkg/QemuVideoDxe driver is updated to use this new library. In v4: ArmVirtPkg was also updated because it also uses the QemuVideoDxe

[edk2] [PATCH v4 1/8] MdeModulePkg: Add FrameBufferBltLib library class

This library provides interfaces to perform UEFI Graphics Output Protocol Video BLT operations. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Reviewed-by: Feng Tian Cc: Justen Jordan

[edk2] [PATCH v4 2/8] MdeModulePkg: Add FrameBufferBltLib library instance

This library provides interfaces to perform UEFI Graphics Output Protocol Video BLT operations. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Reviewed-by: Feng Tian Cc: Justen Jordan Cc:

[edk2] [PATCH v4 3/8] MdeModulePkg: Add GraphicsOutputDxe driver.

The driver uses the GraphicsInfo HOB and GraphicsDeviceInfo HOB passed from PEI to find the graphics controller to manage and produce the GraphicsOutput protocol. GraphicsInfo HOB and GraphicsDeviceInfo HOB are created by a PEIM which initializes the graphics controller hardware in PEI phase.

[edk2] [PATCH v4 7/8] OvmfPkg: Remove unused BltLib reference

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Jordan Justen Cc: Laszlo Ersek --- OvmfPkg/OvmfPkgIa32.dsc| 5 + OvmfPkg/OvmfPkgIa32X64.dsc | 5 + OvmfPkg/OvmfPkgX64.dsc | 5

[edk2] [PATCH v4 6/8] OvmfPkg: QemuVideoDxe uses MdeModulePkg/FrameBufferLib

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Laszlo Ersek Cc: Jordan Justen --- OvmfPkg/QemuVideoDxe/Gop.c| 47 --- OvmfPkg/QemuVideoDxe/Qemu.h

[edk2] [PATCH v4 4/8] OvmfPkg: Include MdeModulePkg/FrameBufferLib in OvmfPkg

One of the following patches will change QemuVideoDxe driver to use the new FrameBufferLib. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Laszlo Ersek Cc: Jordan Justen ---

[edk2] [PATCH v4 5/8] ArmVirtPkg: Include MdeModulePkg/FrameBufferLib in ArmVirtPkg

One of the following patches will change QemuVideoDxe driver to use the new FrameBufferLib. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Laszlo Ersek Cc: Ard Biesheuvel ---

[edk2] [PATCH v4 8/8] ArmVirtPkg: Remove unused BltLib reference

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Laszlo Ersek Cc: Ard Biesheuvel --- ArmVirtPkg/ArmVirtQemu.dsc | 5 + ArmVirtPkg/ArmVirtQemuKernel.dsc | 5 + 2 files changed, 2

[edk2] [PATCH] Add NOOPT build targets to OvmfPkg for source level debugging

From ef7b3dfe26bb7748d838974af57cd73e40e24c94 Mon Sep 17 00:00:00 2001 From: Bruce Cran Date: Mon, 10 Oct 2016 09:35:50 -0600 Subject: [PATCH] Add NOOPT build targets to OvmfPkg for source level debugging Contributed-under: TianoCore Contribution Agreement 1.0 Cc:

Re: [edk2] [PATCH V3] PcAtChipsetPkg AcpiTimerLib: Clear bits [31:24] after reading by IoRead32()

Reviewed-by: Michael Kinney > -Original Message- > From: Zeng, Star > Sent: Saturday, October 8, 2016 5:59 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star ; Kinney, Michael D > ; > Yao, Jiewen

Re: [edk2] [PATCH v2 5/5] OvmfPkg: QemuVideoDxe uses MdeModulePkg/FrameBufferLib

On 10/09/16 10:49, Ruiyu Ni wrote: > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ruiyu Ni > Cc: Laszlo Ersek > Cc: Jordan Justen > --- > OvmfPkg/OvmfPkgIa32.dsc | 6 ++--- >

Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services

Liming, > Could this library cover PEI PPI? Yes - excellent suggestion for PEI - I hadn't considered it because the use case hadn't come up for me yet. > And, I think this library class will include Install, Notify and Locate APIs. > Right? Yes, this library class proposal incorporates all