Re: [edk2] [patch] MdeModulePkg/SetupBrowserDxe: Fix incorrect local variable used

Reviewed-by: Eric Dong > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Dandan > Bi > Sent: Monday, December 05, 2016 7:41 PM > To: edk2-devel@lists.01.org > Cc: Dong, Eric > Subject: [edk2] [patch]

Re: [edk2] [PATCH 7/7] Vlv2TbltDevicePkg: Remove use of IntelFrameworkModulePkg legacy libs

It looks good. Reviewed-by: David Wei Thanks, David Wei -Original Message- From: Leif Lindholm [mailto:leif.lindh...@linaro.org] Sent: Tuesday, December 06, 2016 1:33 AM To: edk2-devel@lists.01.org Cc: Wei, David

[edk2] [Patch] Vlv2TbltDevicePkg/PlatformInitPei: Better SMRAM size alignment

https://bugzilla.tianocore.org/show_bug.cgi?id=260 Update workaround to be more generic. * Search for the largest region between 1MB and 4GB * Find all adjacent regions to compute total size * Minimum aligned size if 4KB * Mark extended region to align size as EFI_ALLOCATED * If an adjacent

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Remove MTRR field from PSD

Reviewed-by: Jeff Fan -Original Message- From: Kinney, Michael D Sent: Tuesday, December 06, 2016 12:41 PM To: edk2-devel@lists.01.org Cc: Yao, Jiewen; Fan, Jeff; Tian, Feng Subject: [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Remove MTRR field from PSD

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Always initialze PSD

Reviewed-by: Feng Tian Thanks Feng -Original Message- From: Kinney, Michael D Sent: Tuesday, December 6, 2016 11:57 AM To: edk2-devel@lists.01.org Cc: Yao, Jiewen ; Fan, Jeff ; Tian, Feng Subject:

[edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Remove MTRR field from PSD

https://bugzilla.tianocore.org/show_bug.cgi?id=277 The MTRR field was removed from PROCESS_SMM_DESCRIPTOR structure in commit: https://github.com/tianocore/edk2/commit/26ab5ac3621bdefe96987f8c1512ca79e1bb7ac0 However, the references to the MTRR field in assembly files were not removed. Remove

Re: [edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Always initialze PSD

Reviewed-by: Jeff Fan -Original Message- From: Kinney, Michael D Sent: Tuesday, December 06, 2016 11:57 AM To: edk2-devel@lists.01.org Cc: Yao, Jiewen; Fan, Jeff; Tian, Feng Subject: [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Always initialze PSD The following commit moved

[edk2] [Patch] UefiCpuPkg/PiSmmCpuDxeSmm: Always initialze PSD

The following commit moved the initialization of the default PROCESSOR_SMM_DESCRIPTOR from MpService.c to SmramSaveState.c and made this initialization conditional on the value returned by the SmmCpuFeaturesGetSmiHandlerSize() library function.

Re: [edk2] Sync staging/HTTPS-TLS feature into edk2 master!

Thanks Thomas and Mike, I will refine the code first according your feedback, then following the EDK2 process by sending the series patches for the whole feature. Best Regards! Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >

Re: [edk2] Sync staging/HTTPS-TLS feature into edk2 master!

Besides formal EDK2 process, there are a couple more things to fix up for Linux/GCC compiles: 1) Need to remove no-pqueue from process_files.sh 2) In OpensslTlsLib.inf, GCC:*_*_*_CC_FLAGS = -Wno-unused-but-set-variable I'm wondering also if the SSL library compilation in

[edk2] Password protection for settings?

Hello everyone, I was playing around with Tianocore (CorebootPayloadPkg) and found that everyone can just modify my settings, and use my UEFI shell. I was looking for a solution which allows me to add password protection to both, but the only password-related thing I could find was the Opal

Re: [edk2] [PATCH v5 0/5] MdeModulePkg: add support for non-discoverable devices

Hi Ard, I confirm, that v5 continues to work with my platform. Best regards, Marcin 2016-12-05 16:35 GMT+01:00 Ard Biesheuvel : > The rationale for this series is the fact that many ARM platforms implement > some form of PCI 'emulation', to allow non-discoverable

Re: [edk2] [PATCH v2 0/6] OvmfPkg/QemuFwCfgLib: support the DMA-like interface

On 12/05/16 19:28, Jordan Justen wrote: > Series Reviewed-by: Jordan Justen Thank you. Series pushed as 209b8f3c2710..2c8dcbc65ab6. Cheers! Laszlo > On 2016-12-02 12:20:53, Laszlo Ersek wrote: >> Version 2 of >>

Re: [edk2] [PATCH v2 0/6] OvmfPkg/QemuFwCfgLib: support the DMA-like interface

Series Reviewed-by: Jordan Justen On 2016-12-02 12:20:53, Laszlo Ersek wrote: > Version 2 of > . > > The following patches > > [PATCH 3/5] OvmfPkg/IndustryStandard: add QemuFwCfgDma.h > [PATCH

Re: [edk2] [PATCH 7/7] Vlv2TbltDevicePkg: Remove use of IntelFrameworkModulePkg legacy libs

Hi David, Mang - any comments? All the other parts of the series have now been pushed. Regards, Leif On Thu, Dec 01, 2016 at 03:53:26PM +, Leif Lindholm wrote: > LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied > from IntelFrameworkModulePkg to MdeModulePkg, but the

Re: [edk2] [PATCH] Omap35xxPkg, BeagleBoardPkg: Use Pcd for INTERRUPT_BASE

On Mon, Dec 05, 2016 at 04:40:44PM +, Ard Biesheuvel wrote: > On 27 November 2016 at 23:26, Leif Lindholm wrote: > > The base address for the interrupt controller is hard-coded in > > Omap3530Interrupt.h, although Omap35xxPkg/InterruptDxe appears to > > have

Re: [edk2] [PATCH] Omap35xxPkg, BeagleBoardPkg: Use Pcd for INTERRUPT_BASE

On 27 November 2016 at 23:26, Leif Lindholm wrote: > The base address for the interrupt controller is hard-coded in > Omap3530Interrupt.h, although Omap35xxPkg/InterruptDxe appears to > have initially intended to make use of PcdInterruptBaseAddress from > EmbeddedPkg.

Re: [edk2] [PATCH v5 5/5] Omap35xxPkg/PciEmulation: port to new non-discoverable device infrastructure

On Mon, Dec 05, 2016 at 03:35:22PM +, Ard Biesheuvel wrote: > Move to the new non-discoverable device protocols for wiring the PCI based > EHCI controller driver to the non-discoverable EHCI controller found on the > OMAP 3530. > > Contributed-under: TianoCore Contribution Agreement 1.0 >

Re: [edk2] [PATCH 0/7] Various: Remove EDK2 use of IntelFrameworkModulePkg legacy libs

On Mon, Dec 05, 2016 at 03:38:18PM +, Ard Biesheuvel wrote: > > The following remain without feedback (and Ard will be back next week, > > so expect at least two of those can be resolved then): > > > >> BeagleBoardPkg: Remove use of IntelFrameworkModulePkg legacy libs > >> EmbeddedPkg:

Re: [edk2] [PATCH v2 0/6] OvmfPkg/QemuFwCfgLib: support the DMA-like interface

On 12/05/16 16:37, Ard Biesheuvel wrote: > On 2 December 2016 at 20:20, Laszlo Ersek wrote: >> Version 2 of >> . >> >> The following patches >> >> [PATCH 3/5] OvmfPkg/IndustryStandard: add QemuFwCfgDma.h >>

[edk2] [PATCH v5 5/5] Omap35xxPkg/PciEmulation: port to new non-discoverable device infrastructure

Move to the new non-discoverable device protocols for wiring the PCI based EHCI controller driver to the non-discoverable EHCI controller found on the OMAP 3530. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ---

[edk2] [PATCH v5 4/5] MdeModulePkg/NonDiscoverablePciDeviceDxe: add support for non-coherent DMA

Add support for non-coherent DMA, either by performing explicit cache maintenance when DMA mappings are aligned to the CPU's DMA buffer alignment, or by bounce buffering via uncached mappings otherwise. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel

[edk2] [PATCH v5 0/5] MdeModulePkg: add support for non-discoverable devices

The rationale for this series is the fact that many ARM platforms implement some form of PCI 'emulation', to allow non-discoverable devices that implement standardized host controller interfaces (i.e., EHCI, AHCI) to be controlled by the generic EDK2 drivers, which are layered on top of the PCI

Re: [edk2] [PATCH v2 0/6] OvmfPkg/QemuFwCfgLib: support the DMA-like interface

On 2 December 2016 at 20:20, Laszlo Ersek wrote: > Version 2 of > . > > The following patches > > [PATCH 3/5] OvmfPkg/IndustryStandard: add QemuFwCfgDma.h > [PATCH 4/5] ArmVirtPkg/QemuFwCfgLib: rebase lib

[edk2] [PATCH v5 1/5] MdeModulePkg: introduce non-discoverable device protocol

Introduce a protocol that can be exposed by a platform for devices that are not discoverable, usually because they are wired straight to the memory bus rather than to an enumerable bus like PCI or USB. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel

Re: [edk2] [PATCH 0/7] Various: Remove EDK2 use of IntelFrameworkModulePkg legacy libs

On 2 December 2016 at 16:13, Leif Lindholm wrote: > On Thu, Dec 01, 2016 at 03:53:19PM +, Leif Lindholm wrote: >> LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied >> from IntelFrameworkModulePkg to MdeModulePkg, but the originals were >> kept

[edk2] [PATCH v5 3/5] MdeModulePkg: implement generic PCI I/O driver for non-discoverable devices

This implements support for non-discoverable PCI compatible devices, i.e, devices that are not on a PCI bus but that can be controlled by generic PCI drivers in EDK2. This is implemented as a UEFI driver, which means we take full advantage of the UEFI driver model, and only instantiate those

[edk2] [PATCH v5 2/5] MdeModulePkg: introduce helper library to register non-discoverable devices

Non-discoverable devices need to be registered explicitly by the platform. Introduce a helper library that takes care of this. This implementation currently only supports registering devices that are covered by one or more MMIO resources. The underlying protocol allows for more flexibility than

Re: [edk2] [patch 0/5] MdeModulePkg/EbcDxe: Fix coding style issues

Reviewed-by: jiewen@intel.com > -Original Message- > From: Bi, Dandan > Sent: Monday, December 5, 2016 1:27 PM > To: edk2-devel@lists.01.org > Cc: Yao, Jiewen ; Pete Batard > Subject: [patch 0/5] MdeModulePkg/EbcDxe: Fix coding style issues > >

[edk2] [patch] MdeModulePkg/SetupBrowserDxe: Fix incorrect local variable used

https://bugzilla.tianocore.org/show_bug.cgi?id=280 Cc: Eric Dong Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi --- MdeModulePkg/Universal/SetupBrowserDxe/Setup.c | 9 + 1 file changed, 5 insertions(+), 4

Re: [edk2] [PATCH v2 5/6] ArmVirtPkg/QemuFwCfgLib: rebase lib instance to updated lib class header

On 12/05/16 11:30, Leif Lindholm wrote: > On Fri, Dec 02, 2016 at 09:20:58PM +0100, Laszlo Ersek wrote: >> Put the FW_CFG_F_DMA constant, introduced in the last patch, to use. >> >> Cc: Ard Biesheuvel >> Cc: Leif Lindholm >> Contributed-under:

Re: [edk2] [PATCH v2 4/6] OvmfPkg/QemuFwCfgLib: extend lib class header with more definitions

On Fri, Dec 02, 2016 at 09:20:57PM +0100, Laszlo Ersek wrote: > The last patch consists purely of code movement; going forward, we should > use a few more symbolic constants. > > Cc: Ard Biesheuvel > Cc: Jordan Justen > Cc: Leif Lindholm

Re: [edk2] [PATCH v2 5/6] ArmVirtPkg/QemuFwCfgLib: rebase lib instance to updated lib class header

On Fri, Dec 02, 2016 at 09:20:58PM +0100, Laszlo Ersek wrote: > Put the FW_CFG_F_DMA constant, introduced in the last patch, to use. > > Cc: Ard Biesheuvel > Cc: Leif Lindholm > Contributed-under: TianoCore Contribution Agreement 1.0 >

Re: [edk2] [PATCH v2 3/6] ArmVirtPkg, OvmfPkg: QemuFwCfgLib: move DMA-related defs to lib class

On Fri, Dec 02, 2016 at 09:20:56PM +0100, Laszlo Ersek wrote: > Move the type and macro definitions related to QEMU's DMA-like fw_cfg > access method to the library class header. > > Cc: Ard Biesheuvel > Cc: Jordan Justen > Cc: Leif Lindholm

Re: [edk2] [PATCH 0/4] Fix runtime issue in XenBusDxe when compiled with GCC5

On 12/05/16 03:55, Gao, Liming wrote: > Laszlo: > Thanks for your investigation. In tools_def.txt, there are two > chains: GCC49 and GCC5. GCC49 enables Os without lto, GCC5 enables Os > and lto. If GCC version supports lto well, it can use GCC5 tool > chain. Otherwise, it can use GCC49 tool

Re: [edk2] [PATCH v4 3/5] MdeModulePkg: implement generic PCI I/O driver for non-discoverable devices

On Fri, Dec 02, 2016 at 06:42:58PM +, Ard Biesheuvel wrote: > >> > The point is that there is nothing clever here for the compiler to do: > >> > casting a 64-bit int to a 32-bit int is an operation that discards the > >> > top 32 bits - but the behaviour is entirely defined. > >> > > >> > In