[edk2] [PATCH] CryptoPkg: Update package version to 0.97

Update package version of CryptoPkg to 0.97. Cc: Ting Ye Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Qin Long --- CryptoPkg/CryptoPkg.dec | 2 +- CryptoPkg/CryptoPkg.dsc | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/CryptoPkg/CryptoPkg.dec b

Re: [edk2] SMRAM sizes on large hosts

Hi, > > The problem with this is that I need the TSEG size in another module as > > well, namely PlatformPei. The dispatch order between PlatformPei and > > SmmAccessPei is unspecified (they have both TRUE for DEPEX). If > > PlatformPei gets dispatched second, I really wouldn't want to write to

Re: [edk2] SMRAM sizes on large hosts

On 05/04/17 00:33, Laszlo Ersek wrote: > On 05/03/17 15:44, Gerd Hoffmann wrote: >> Hi, >> >>> I propose the following: add a new fw_cfg file which communicates how >>> much memory (how many megabytes) the "11b" value in the tseg size >>> register will configure. >> >> I'd prefer to keep fw_cfg o

[edk2] [RFC] migration of OpenPlatformPkg to tianocore

Hi all, As some of you may be aware, I have been working around the lack of a clear upstreaming strategy for platform support by keeping such code in a dedicated repository I set up at Linaro for that purpose: https://git.linaro.org/uefi/OpenPlatformPkg.git During discussions at the last Seattle

Re: [edk2] SMRAM sizes on large hosts

On 05/03/17 15:55, Paolo Bonzini wrote: > > > On 03/05/2017 15:35, Laszlo Ersek wrote: >>> I see. In my other answer I tried to keep it as intact as possible. >>> >>> I'm a bit worried about the limits on the number of fw-cfg files. >> We've promoted that to a device property in QEMU commit e12f

Re: [edk2] SMRAM sizes on large hosts

On 05/03/17 15:44, Gerd Hoffmann wrote: > Hi, > >> I propose the following: add a new fw_cfg file which communicates how >> much memory (how many megabytes) the "11b" value in the tseg size >> register will configure. > > I'd prefer to keep fw_cfg out of the picture, and I think we can do it > wi

[edk2] [PATCH v2 4/5] OvmfPkg: raise max variable size (auth & non-auth) to 33KB for FD_SIZE_4MB

The "ConfirmSetOfLargeVariable" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit sets a 32 KB large non-authenticated variable. In the FD_SIZE_4MB build, our live varstore is now 256 KB big, so we can accommodate this.

[edk2] [PATCH v2 3/5] OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK

The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticate

[edk2] [PATCH v2 1/5] OvmfPkg: introduce the FD_SIZE_IN_KB macro / build flag

FD_SIZE_xMB defines have existed for flash size selection. They can be passed as "-D FD_SIZE_xMB" on the command line. Passing multiple of them at the same time has never been supported; earlier settings on the command line cannot be overridden. Introduce the integer valued FD_SIZE_IN_KB macro, wh

[edk2] [PATCH v2 5/5] OvmfPkg: make the 4MB flash size the default

The previously default 2MB can be explicitly selected with -D FD_SIZE_2MB or -D FD_SIZE_IN_KB=2048 Cc: Gary Ching-Pang Lin Cc: Jordan Justen Suggested-by: Jordan Justen Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- Notes: v2: - new in v

[edk2] [PATCH v2 2/5] OvmfPkg/OvmfPkg.fdf.inc: extract VARS_LIVE_SIZE and VARS_SPARE_SIZE macros

Cc: Gary Ching-Pang Lin Cc: Jordan Justen Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- Notes: v2: - no changes OvmfPkg/OvmfPkg.fdf.inc | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/OvmfPkg/OvmfPkg.fdf.inc b/OvmfPkg

[edk2] [PATCH v2 0/5] OvmfPkg: add FD_SIZE_4MB for Windows HCK SB tests, and for future proofing

This is version 2 of the series posted at . Changes in v2: - consolidate FD_SIZE_1MB, FD_SIZE_2MB, FD_SIZE_4MB, basing them all on the new macro FD_SIZE_IN_KB, - increase the variable store from 248 KB to 256 KB, and propagate tha

[edk2] [PATCH 0/3] Import a few items from OpenPlatformPkg

In preparation for moving OpenPlatformPkg into edk2-platforms: - move across the DesignWare EMMC driver - import EfiTimeBaseLib EfiTimeBaseLib started out as some generically useful functions pulled out of PL031RealTimeClockLib and used also for other RTC devices. We re-align it with the original

[edk2] [PATCH 2/3] EmbeddedPkg: import EfiTimeBaseLib

Some generic RTC helper functions were broken out from the PL031 library for use with other RTCs in OpenPlatformPkg. Import the code back here, realigning it with the current state of PL031RealTimeClockLib to simplify comparisons. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-

[edk2] [PATCH 3/3] ArmPlatformPkg, ArmVirtPkg: delete redundant PL031 functions

Remove the functions now provided by EfiTimeBaseLib from PL031RealTimeClockLib. Add EfiTimeBaseLib resolution to ArmVirtPkg in same commit to prevent breakage. Cc: Laszlo Ersek Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Leif Lindholm --- .../Include/Drivers/PL031Rea

[edk2] [PATCH 1/3] EmbeddedPkg: import DesignWare EMMC driver

Imported from OpenPlatformPkg 0434ff62e3eb896e6c561dea84cfb8b80391603e. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Leif Lindholm --- EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmc.h | 127 ++ EmbeddedPkg/Drivers/DwEmmcDxe/DwEmmcDxe.c | 648 +++

Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

We use SKU IDs for working with 15 different key resources in our product. Some are related to code execution, but most are related to selection of resources. I mentioned logo components and HII strings already. I am asking that the information about SKU relationships be output in some form so

[edk2] ArmPlatformPkg: LcdGraphicsOutputDxe, PL111, and HdLcd rejig

Hi, With a view to an upcoming change, we have been examining the current Graphics Output Protocol implementation. Currently for, ARM platforms, the UEFI Graphics Output Protocol is implemented using a platform specific Library (PL111LcdArmVExpressLib/HdLcdArmVExpressLib) and a DXE driver (PL111Lc

Re: [edk2] [PATCH] ArmVirtPkg: include XenPlatformHasAcpiDtDxe and PlatformHasAcpiDtDxe in the 32-bit builds too

On 05/03/17 00:38, Nerijus Baliūnas wrote: > Please see https://bugzilla.tianocore.org/show_bug.cgi?id=524 > why it is needed. With this patch my arm uefi VM boots. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Nerijus Baliūnas > --- > > diff -ur edk2.git.orig/ArmV

Re: [edk2] [Patch 2/2] SecurityPkg: Consume SmmIoLib.

Reviewed-by: jiewen@intel.com > -Original Message- > From: Dong, Eric > Sent: Wednesday, May 3, 2017 11:32 AM > To: edk2-devel@lists.01.org > Cc: Yao, Jiewen > Subject: [Patch 2/2] SecurityPkg: Consume SmmIoLib. > > Update code to consume SmmIoLib to pass build. > > Contributed-unde

Re: [edk2] [Patch 1/2] SecurityPkg OpalPasswordSmm: Consume SmmIoLib.

Reviewed-by: jiewen@intel.com > -Original Message- > From: Dong, Eric > Sent: Wednesday, May 3, 2017 11:32 AM > To: edk2-devel@lists.01.org > Cc: Yao, Jiewen > Subject: [Patch 1/2] SecurityPkg OpalPasswordSmm: Consume SmmIoLib. > > Update code to consume SmmIoLib to check Mmio valida

Re: [edk2] [RFC] [PATCH V4 0/3] Add IOMMU support.

Hi Yao, We're OK so far (as noted below). Leo From: Yao, Jiewen [mailto:jiewen@intel.com] Sent: Tuesday, May 02, 2017 8:33 PM To: Duran, Leo ; edk2-devel@lists.01.org Cc: Ni, Ruiyu ; Singh, Brijesh ; Ard Biesheuvel Subject: RE: [RFC] [PATCH V4 0/3] Add IOMMU support. It is a good question.

Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

Tim, Could you help share and explain the use cases in your code base that is using [SkuIds] section and SKUID_IDENTIFIER for others beyond PCD? Then we can consider more in [RFC] PCD: Extended SKU support. Or do you have detailed propose in this RFC or new RFC about your use cases? Thanks, Sta

Re: [edk2] SMRAM sizes on large hosts

On 03/05/2017 15:35, Laszlo Ersek wrote: >> I see. In my other answer I tried to keep it as intact as possible. >> >> I'm a bit worried about the limits on the number of fw-cfg files. > We've promoted that to a device property in QEMU commit e12f3a13e2e1 > ("fw-cfg: turn FW_CFG_FILE_SLOTS into a

Re: [edk2] [PATCH 2/3] OvmfPkg: introduce FD_SIZE_4MB (mainly) for Windows HCK

On 05/02/17 23:45, Jordan Justen wrote: > On 2017-05-02 12:31:39, Laszlo Ersek wrote: >> On 05/02/17 20:22, Jordan Justen wrote: >>> On 2017-05-02 07:39:04, Laszlo Ersek wrote: I wouldn't mind if we made more room for the varstore in the 2MB build, even at the expense of FVMAIN_COMPA

Re: [edk2] SMRAM sizes on large hosts

Hi, > I propose the following: add a new fw_cfg file which communicates how > much memory (how many megabytes) the "11b" value in the tseg size > register will configure. I'd prefer to keep fw_cfg out of the picture, and I think we can do it without too much problems. We have a TSEGMB (tseg me

Re: [edk2] SMRAM sizes on large hosts

On 05/03/17 15:26, Paolo Bonzini wrote: > > > On 03/05/2017 15:14, Laszlo Ersek wrote: >> I'd prefer a solution that would keep the fw logic / code flow related >> to register configuration intact, and would just replace a few numbers / >> constants if possible. > > I see. In my other answer I

Re: [edk2] [PATCH v3] ShellPkg/ShellCommandLib: Update DumpHex to print {|}~

Ray, do you agree? If so, can you please push this? Thank you, Jeff On Wed, 26 Apr 2017, Carsey, Jaben wrote: That makes sense. When I wrote that I was unsure where to draw the line between which characters to print and which to replace. Reviewed-by: Jaben Carsey -Original Message

Re: [edk2] SMRAM sizes on large hosts

On 03/05/2017 15:14, Laszlo Ersek wrote: > I'd prefer a solution that would keep the fw logic / code flow related > to register configuration intact, and would just replace a few numbers / > constants if possible. I see. In my other answer I tried to keep it as intact as possible. I'm a bit wo

Re: [edk2] SMRAM sizes on large hosts

On 05/03/17 14:56, Paolo Bonzini wrote: > > > On 03/05/2017 08:57, Gerd Hoffmann wrote: >> qemu implements what physical q35 support. The extended smram register >> has two bits for the tseg size, three out of the four values are used >> (for 1, 2, 8 MB sizes). "11" is reserved in the specs. W

Re: [edk2] SMRAM sizes on large hosts

On 05/03/17 08:57, Gerd Hoffmann wrote: > On Di, 2017-05-02 at 20:49 +, Kinney, Michael D wrote: >> Laszlo, >> >> Is it possible to add more TSEG sizes to the Q35 board? > > qemu implements what physical q35 support. The extended smram register > has two bits for the tseg size, three out of t

Re: [edk2] SMRAM sizes on large hosts

On 03/05/2017 08:57, Gerd Hoffmann wrote: > qemu implements what physical q35 support. The extended smram register > has two bits for the tseg size, three out of the four values are used > (for 1, 2, 8 MB sizes). "11" is reserved in the specs. We could use > "11" to implement a bigger tseg. C

[edk2] [Patch] SecurityPkg/Pkcs7VerifyDxe: Add format check in DB list contents

Add the size check for invalid format detection in AllowedDb, RevokedDb and TimeStampDb list contents. Cc: Chao Zhang Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Qin Long --- .../Pkcs7Verify/Pkcs7VerifyDxe/Pkcs7VerifyDxe.c| 66 -- 1 file change

Re: [edk2] [Patch] BaseTools: Copy "TianoCore" userextensions into As Built Inf

Reviewed-by: Liming Gao >-Original Message- >From: Zhu, Yonghong >Sent: Thursday, April 13, 2017 3:38 PM >To: edk2-devel@lists.01.org >Cc: Gao, Liming >Subject: [Patch] BaseTools: Copy "TianoCore" userextensions into As Built Inf > >Per build spec to update the tool to copy "TianoCore" u

[edk2] [Patch] BaseTools: remove the hardcoded /bin/bash for PreBuild/PostBuild

This patch remove the hardcoded /bin/bash for PreBuild/PostBuild scripts. Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yonghong Zhu --- BaseTools/Source/Python/build/build.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/BaseToo

[edk2] [Patch] BaseTools: PCD can only use single access method by source build

Add the error check that A PCD can only use one type for all source modules. Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yonghong Zhu --- BaseTools/Source/Python/AutoGen/AutoGen.py | 16 1 file changed, 16 insertions(+) diff --git a/Ba

[edk2] [Patch] NetworkPkg: Update package version to 0.97.

Cc: Wu Jiaxin Cc: Ye Ting Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan --- NetworkPkg/NetworkPkg.dec | 2 +- NetworkPkg/NetworkPkg.dsc | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/NetworkPkg/NetworkPkg.dec b/NetworkPkg/NetworkPkg.d

[edk2] [Patch] NetworkPkg: Addressing TCP Window Retraction when window scale factor is used.

The RFC1323 which defines the TCP window scale option has been obsoleted by RFC7323. This patch is to follow the RFC3723 to address the TCP window retraction problem when a non-zero scale factor is used. Cc: Wu Jiaxin Cc: Andrey Tepin Cc: Ye Ting Contributed-under: TianoCore Contribution Agree

[edk2] [Patch] MdeModulePkg: Addressing TCP Window Retraction when window scale factor is used.

The RFC1323 which defines the TCP window scale option has been obsoleted by RFC7323. This patch is to follow the RFC3723 to address the TCP window retraction problem when a non-zero scale factor is used. Cc: Wu Jiaxin Cc: Andrey Tepin Cc: Ye Ting Contributed-under: TianoCore Contribution Agree