Re: [edk2] How to retrieve HII form's default value

Intel provides FCE tool. It can parse the generated BIOS image and output the default value for every HII question. You can try it. Here is the latest version https://firmware.intel.com/sites/default/files/2018-WW13-FCE.34-Release.zip >-Original Message- >From: edk2-devel

[edk2] [PATCH 2/2] OvmfPkg/PlatformBootManagerLib: connect Virtio RNG devices again

Virtio RNG devices are never boot devices, so in commit 245c643cc8b7 we stopped connecting them. This is a problem because an OS boot loader may depend on EFI_RNG_PROTOCOL to seed the OS's RNG. Connect Virtio RNG devices again. And, while commit 245c643cc8b7 removed that from

[edk2] [patch] IntelFrameworkPkg/UefiLib: Fix build fail caused by commit b6d5def2fa

In commit b6d5def2faf56334128ea2f056356d7e3852831e when adding 'OUT' decorator for the parameter in AddUnicodeString(), it delete the function name by mistake. This patch is to fix this issue. CC: Marvin Haeuser CC: Liming Gao Contributed-under:

[edk2] [PATCH 0/2] ArmVirtPkg, OvmfPkg: connect Virtio RNG devices again

Repo: https://github.com/lersek/edk2.git Branch: connect_vrng_bz1579518 This is a fix for another regression from the March 2018 series [edk2] [PATCH 0/6] OvmfPkg, ArmVirtQemu: leaner platform BDS policy for connecting devices Turns out EfiBootManagerConnectAll() used

[edk2] [PATCH 1/2] ArmVirtPkg/PlatformBootManagerLib: connect Virtio RNG devices again

Virtio RNG devices are never boot devices, so in commit ff1d0fbfbaec we stopped connecting them. This is a problem because an OS boot loader may depend on EFI_RNG_PROTOCOL to seed the OS's RNG. Connect Virtio RNG devices again. And, while commit ff1d0fbfbaec removed that from

[edk2] [Patch][edk2-platforms/devel-IntelAtomProcessorE3900] Platform/ReadMe.MD

Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Guo Mang --- Platform/ReadMe.MD | 186 + 1 file changed, 175 insertions(+), 11 deletions(-) diff --git a/Platform/ReadMe.MD b/Platform/ReadMe.MD index

Re: [edk2] [PATCH 0/2] ArmVirtPkg, OvmfPkg: connect Virtio RNG devices again

On 18 May 2018 at 08:20, Laszlo Ersek wrote: > Repo: https://github.com/lersek/edk2.git > Branch: connect_vrng_bz1579518 > > This is a fix for another regression from the March 2018 series > > [edk2] [PATCH 0/6] OvmfPkg, ArmVirtQemu: leaner platform BDS policy >

Re: [edk2] [PATCH 0/2] ArmVirtPkg, OvmfPkg: connect Virtio RNG devices again

On 05/18/18 11:09, Ard Biesheuvel wrote: > On 18 May 2018 at 08:20, Laszlo Ersek wrote: >> Repo: https://github.com/lersek/edk2.git >> Branch: connect_vrng_bz1579518 >> >> This is a fix for another regression from the March 2018 series >> >> [edk2] [PATCH 0/6] OvmfPkg,

[edk2] [PATCH v3 1/4] OvmfPkg: add Tcg2PhysicalPresenceLibNull when !TPM2_ENABLE

From: Marc-André Lureau This NULL library will let us call Tcg2PhysicalPresenceLibProcessRequest() unconditionally from BdsPlatform when building without TPM2_ENABLE. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-André Lureau

[edk2] [PATCH v3 3/4] OvmfPkg: add Tcg2PhysicalPresenceLibQemu

From: Marc-André Lureau Cloned "SecurityPkg/Library/DxeTcg2PhysicalPresenceLib" and: - removed all the functions that are unreachable from Tcg2PhysicalPresenceLibProcessRequest() [called from platform BDS], or SubmitRequestToPreOSFunction() and

[edk2] [PATCH v3 0/4] RFC: ovmf: Add support for TPM Physical Presence interface

From: Marc-André Lureau Hi, The following series adds basic TPM PPI 1.3 support for OVMF-on-QEMU with TPM2 (I haven't looked at TPM1, for lack of interest). PPI test runs successfully with Windows 10 WHLK, despite the limited number of supported funcions

[edk2] [PATCH v3 4/4] OvmfPkg/PlatformBootManagerLib: process TPM PPI request

From: Marc-André Lureau Call Tcg2PhysicalPresenceLibProcessRequest() to process pending PPI requests from PlatformBootManagerAfterConsole(). Laszlo understanding of edk2 is that the PPI operation processing was meant to occur *entirely* before End-Of-Dxe, so that

[edk2] reg: EDK2 - HTTP Boot

Hello All, There is an observation found during HTTP Boot that, when HTTP 1.1 server does not support keep-alives, the system sometimes failed boot when connections are not persistent. RFC 2616 section 8.2.1 says "HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's flow

[edk2] [Patch v2 0/5] Remove X86 ASM and S files

For IA32 and X64, NASM has replaced ASM and S files. 1. Remove ASM from all modules. 2. Remove S files from the drivers only. 3. https://bugzilla.tianocore.org/show_bug.cgi?id=881 After NASM is updated, S files can be removed from Library. V2: Update commit message. The patch set are in

Re: [edk2] [PATCH v3 0/4] RFC: ovmf: Add support for TPM Physical Presence interface

On 05/18/2018 08:23 AM, marcandre.lur...@redhat.com wrote: From: Marc-André Lureau Hi, The following series adds basic TPM PPI 1.3 support for OVMF-on-QEMU with TPM2 (I haven't looked at TPM1, for lack of interest). PPI test runs successfully with Windows 10

[edk2] [staging/dynamictables PATCH v2] Update Readme.md to reflect ACPICA compiler update

The ACPICA iASL compiler has been enhanced to support the generation of an AML hex file which is required by the Dynamic Tables Framework. The patch for this enhancement has been integrated in the ACPICA repository. Therefore the Prerequisites section in the Readme has been updated accordingly.

Re: [edk2] [Patch v2 0/5] Remove X86 ASM and S files

Hi Limint, On 05/18/18 11:32, Liming Gao wrote: > For IA32 and X64, NASM has replaced ASM and S files. > 1. Remove ASM from all modules. > 2. Remove S files from the drivers only. > 3. https://bugzilla.tianocore.org/show_bug.cgi?id=881 > After NASM is updated, S files can be removed from Library.

[edk2] [PATCH v3 2/4] OvmfPkg/IndustryStandard: add QemuTpm.h header

From: Marc-André Lureau Add some common macros and type definitions corresponding to the QEMU TPM interface. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-André Lureau Acked-by: Laszlo Ersek

[edk2] reg: EDK2 - HTTP Boot Image Validation

Hello all, When HTTP Boot performed the code checking if the Image type as EFI ISO and IMG. If not the boot not proceeding when the content type is as "Content-type: text/plain". https://github.com/tianocore/edk2/blob/master/NetworkPkg/HttpBootDxe/HttpBootSupport.c (HttpBootCheckImageType())

Re: [edk2] [PATCH edk2-platforms v2 0/3][platforms/devel-dynamictables] Update for ACPICA compiler enhancements

Reviewed-by: Evan Lloyd Leif, Ard - are you happy to accept this for the patchset, or should I respond to each patch? Regards, Evan > -Original Message- > From: edk2-devel On Behalf Of Sami > Mujawar > Sent: 18 May 2018 14:13 > To:

Re: [edk2] [staging/dynamictables PATCH v2] Update Readme.md to reflect ACPICA compiler update

Reviewed-by: Evan Lloyd > -Original Message- > From: Sami Mujawar > Sent: 18 May 2018 12:09 > To: edk2-devel@lists.01.org > Cc: ard.biesheu...@linaro.org; leif.lindh...@linaro.org; Matteo Carlini > ; Stephanie

[edk2] [PATCH edk2-platforms v2 0/3][platforms/devel-dynamictables] Update for ACPICA compiler enhancements

The ACPICA iAsl compiler has recently been enhanced to support a feature required by Dynamic Tables Framework for processing ASL files. The compiler however generates slightly different symbol names to what was previously referenced in the Configuration Manager. This patchset adapts to the latest

[edk2] [PATCH edk2-platforms v2 3/3][platforms/devel-dynamictables] Update Readme.md to reflect ACPICA compiler update

The ACPICA iASL compiler has been enhanced to support the generation of an AML hex file which is required by the Dynamic Tables Framework. The patch for this enhancement has been integrated in the ACPICA repository. Therefore the Prerequisites section in the Readme has been updated accordingly.

[edk2] [PATCH edk2-platforms v2 1/3][platforms/devel-dynamictables] Platform/ARM: Match asl compiler output for Juno

The iASL compiler's -tc option has been updated to generate output that is suitable for including from a C file. The iASL compiler uniquely names the C array containing the processed table data as _aml_code.The patch for this update, 'iASL: Enhance the -tc option (create AML hex file in C)', dated

[edk2] [PATCH edk2-platforms v2 2/3][platforms/devel-dynamictables] Platform/ARM: Match asl compiler output for FVP

The iASL compiler's -tc option has been updated to generate output that is suitable for including from a C file. The iASL compiler uniquely names the C array containing the processed table data as _aml_code. The patch for this update, 'iASL: Enhance the -tc option (create AML hex file in C)',

[edk2] [PATCH] BaseTools/tools_def: add "-fno-unwind-tables" to GCC_AARCH64_CC_FLAGS

The ElfConvert routines in GenFw don't handle the ".eh_frame" ELF section emitted by gcc. For this reason, Leif disabled the generation of that section for AARCH64 with "-fno-asynchronous-unwind-tables" in commit 28e80befa4fe [1], and Ard did the same for IA32 and X64 in commit 26ecc55c027d [2].

Re: [edk2] Does __attribute__ ((selectany)) make sense now for GCC?

Andrew - I know for Visual Studio it does the same thing for data that /Gy does for code. That is, if the data is unreferenced, then it doesn't get brought it. Maybe link-time code generation has the same effect. That's what I'm curious about. Tim From: af...@apple.com

[edk2] [PATCH] BaseTools/Workspace: Fix ValueChain set

Commit 88252a90d1ca7846731cd2e4e8e860454f7d97a3 changed ValueChain from a dict to a set, but also changed the (former) key type from a touple to two separate values, which was probably unintended and also breaks build for packages involving Structured PCDs, because add() only takes one argument.

[edk2] Does __attribute__ ((selectany)) make sense now for GCC?

In Visual Studio we have __declspec(selectany) to limit the impact of unused data. I see that GCC for Windows has __attribute__ ((selectany)). Should we me using this for GLOBAL_REMOVE_IF_UNREFERENCED in MdePkg\Include\Base.h? Tim ___

Re: [edk2] Does __attribute__ ((selectany)) make sense now for GCC?

Tim, VC++ is a strange beast. See C99 support. VC++ seems to do strange things to support non standard hackyness of years past. So the only reason I can think of that __attribute__ ((selectany)) is associated with dead stripping, is doing it correctly broke some chunk of code that was