Re: [edk2] [patch] Nt32Pkg: Fix VS2010/VS2012 build failure

Reviewed-by: Eric Dong > -Original Message- > From: Bi, Dandan > Sent: Tuesday, September 06, 2016 1:30 PM > To: edk2-devel@lists.01.org > Cc: Dong, Eric > Subject: [patch] Nt32Pkg: Fix VS2010/VS2012 build failure > > Initialize the variable "OptionNumber". > >

Re: [edk2] [Patch 4/4] BaseTools VfrCompile Pccts: Update GCC Flags to the specific one with BUILD_ prefix

Reviewed the series of 4 patches Reviewed-by: Giri P Mudusuru > -Original Message- > From: Gao, Liming > Sent: Monday, September 5, 2016 9:00 PM > To: edk2-devel@lists.01.org > Cc: Mudusuru, Giri P ; Zhu, Yonghong >

[edk2] [Patch 4/4] BaseTools VfrCompile Pccts: Update GCC Flags to the specific one with BUILD_ prefix

This change is also applied to VfrCompile Pccts antlr and dlg tool. In V2, add the missing C rules. Cc: Giri P Mudusuru Cc: Yonghong Zhu Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao

[edk2] [Patch 3/4] BaseTools VfrCompile GNU makefile: Replace CXX with BUILD_CXX

The change is missing in VfrComile GNUmakefile. Cc: Giri P Mudusuru Cc: Yonghong Zhu Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao --- BaseTools/Source/C/VfrCompile/GNUmakefile | 10

[edk2] [Patch 1/4] BaseTools GNU makefile: Add BUILD_CXXFLAGS to align make built-in rule

GNU make built-in rule to Compiling C++ programs with ‘$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c’. To align to it, add empty BUILD_CXXFLAGS in cpp rule. Cc: Giri P Mudusuru Cc: Yonghong Zhu Contributed-under: TianoCore Contribution Agreement 1.0

[edk2] [Patch 0/4] BaseTools GNU makefile: Update GCC Flags to the specific one with BUILD_ prefix

The following 4 patches clean up the remaining issues in GNU makefile. With those changes, all GNU makefiles have been updated. Liming Gao (4): BaseTools GNU makefile: Add BUILD_CXXFLAGS to align make built-in rule BaseTools GNU makefile: remove unused .S rule BaseTools VfrCompile GNU

Re: [edk2] [Patch] NetworkPkg/IpSecDxe: Generate SPI randomly and correct IKE_SPI_BASE value

Reviewed-by: Fu Siyuan > -Original Message- > From: Wu, Jiaxin > Sent: Tuesday, September 6, 2016 11:39 AM > To: edk2-devel@lists.01.org > Cc: Ye, Ting ; Fu, Siyuan > Subject: [Patch] NetworkPkg/IpSecDxe: Generate SPI

[edk2] [Patch] NetworkPkg/DnsDxe: Handle CNAME type responded from the name server

According RFC 1034 - 3.6.2, if the query name is an alias, the name server will include the CNAME record in the response and restart the query at the domain name specified in the data field of the CNAME record. RFC also provides one example server action when A query received: Suppose a name

Re: [edk2] [Patch] MdeModulePkg: Support classless IP for DHCPv4 TransmitReceive()

Reviewed-by: Fu Siyuan > -Original Message- > From: Wu, Jiaxin > Sent: Thursday, August 18, 2016 1:39 PM > To: edk2-devel@lists.01.org > Cc: Santhapur Naveen ; Ye, Ting > ; Fu, Siyuan > Subject: [Patch]

Re: [edk2] Ingebrigtsen: The End of Gmane?

Hi everyone. Sorry for the possibly stupid question, maybe I lose something. Did we get to a conclusion about this? I tried to access the link https://lists.01.org/pipermail/edk2-devel/ but didn't find to much information. Just e-mails from 3 moths ago. Thanks Rafael R. Machado Em seg, 1 de ago

Re: [edk2] [PATCH] ArmPkg/CompilerIntrinsicsLib ARM: make memset() weak again

On Mon, Sep 05, 2016 at 01:37:46PM +0100, Ard Biesheuvel wrote: > After the recent update of CompilerIntrinsicsLib, our memset() is no > longer emitted as a weak symbol. On ARM, this may cause problems when > combining this library with another library that supplies memset() [e.g., >

Re: [edk2] [PATCH 00/11] OvmfPkg, ArmVirtPkg: GOP driver for the VirtIo GPU (virtio-gpu-pci)

Hi, > Is there no chance that ARM KVM might someday also be able to support > a framebuffer? Problem on arm is that you can't expose something as pci memory to the guest which in reality isn't pci memory but normal ram (like the emulated vga memory pci bar). Storing a framebuffer in normal

Re: [edk2] [PATCH 00/11] OvmfPkg, ArmVirtPkg: GOP driver for the VirtIo GPU (virtio-gpu-pci)

On 09/05/16 14:59, Alexander Graf wrote: > On 09/05/2016 02:56 PM, Laszlo Ersek wrote: >> On 09/05/16 14:26, Alexander Graf wrote: >>> On 09/02/2016 12:02 AM, Laszlo Ersek wrote: On 08/19/16 14:49, Laszlo Ersek wrote: > - Also tested loading and launching Linux from GRUB. Here the

Re: [edk2] [PATCH 00/11] OvmfPkg, ArmVirtPkg: GOP driver for the VirtIo GPU (virtio-gpu-pci)

On 09/05/16 14:26, Alexander Graf wrote: > On 09/02/2016 12:02 AM, Laszlo Ersek wrote: >> On 08/19/16 14:49, Laszlo Ersek wrote: >> >>> - Also tested loading and launching Linux from GRUB. Here the results >>>differ of course: x86_64 Fedora 24 drives virtio-gpu-pci with its >>>native

Re: [edk2] [PATCH 2/7] MdeModulePkg/EhciDxe: enable 64-bit PCI DMA

On 5 September 2016 at 13:19, Laszlo Ersek wrote: > On 09/05/16 11:17, Ard Biesheuvel wrote: >> PCI controller drivers must set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE >> attribute if the controller supports 64-bit DMA addressing. >> >> Contributed-under: TianoCore

[edk2] [PATCH] ArmPkg/CompilerIntrinsicsLib ARM: make memset() weak again

After the recent update of CompilerIntrinsicsLib, our memset() is no longer emitted as a weak symbol. On ARM, this may cause problems when combining this library with another library that supplies memset() [e.g., CryptoPkg/IntrinsicLib], due to the fact that the object also supplies the

Re: [edk2] [PATCH 2/7] MdeModulePkg/EhciDxe: enable 64-bit PCI DMA

On 09/05/16 11:17, Ard Biesheuvel wrote: > PCI controller drivers must set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE > attribute if the controller supports 64-bit DMA addressing. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ard Biesheuvel

Re: [edk2] [PATCH 5/7] MdeModulePkg/XhciDxe: enable 64-bit PCI DMA

On 09/05/16 11:17, Ard Biesheuvel wrote: > PCI controller drivers must set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE > attribute if the controller supports 64-bit DMA addressing. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ard Biesheuvel

Re: [edk2] [PATCH 7/7] ArmVirtPkg/FdtPciHostBridgeLib: enable 64-bit PCI DMA

On 09/05/16 11:17, Ard Biesheuvel wrote: > Now that the PCI root bridge driver and various host controller drivers > have been fixed, remove the 4 GB limit on PCI DMA allocation for QEMU's > ECAM PCI host bridge. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ard

Re: [edk2] [PATCH 6/7] MdeModulePkg/PciHostBridgeDxe: restrict 64-bit DMA to devices that support it

On 09/05/16 11:17, Ard Biesheuvel wrote: > Currently, the EFI_PCI_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute is completely > ignored by the PCI host bridge driver, which means that, on an implementation > that supports DMA above 4 GB, allocations above 4 GB may be provided to > devices that have not

Re: [edk2] [PATCH] ArmVirtPkg/FdtPciPcdProducerLib: zero init local var to please GCC 4.8

On 5 September 2016 at 12:41, Laszlo Ersek wrote: > On 09/05/16 09:56, Ard Biesheuvel wrote: >> GCC 4.8 in RELEASE mode complains about GetPciIoTranslation () potentially >> not assigning IoTranslation, but does not notice that it returns failure in >> this case, which means

Re: [edk2] [PATCH] ArmVirtPkg/FdtPciPcdProducerLib: zero init local var to please GCC 4.8

On 09/05/16 09:56, Ard Biesheuvel wrote: > GCC 4.8 in RELEASE mode complains about GetPciIoTranslation () potentially > not assigning IoTranslation, but does not notice that it returns failure in > this case, which means IoTranslation is never referenced *unless* it has > been assigned. So simply

Re: [edk2] [PATCH 0/5] ArmPkg ArmVirtPkg etc: consolidate ArmLib implementations

On Mon, Sep 05, 2016 at 12:06:01PM +0100, Ard Biesheuvel wrote: > Now that the MMU manipulation routines have been moved out of ArmLib into > ArmMmuLib, we are left with the following implementations of ArmLib which > are all identical except for the fact that they target either ARM or AARCH64 >

[edk2] [PATCH 3/5] ArmVirtPkg: remove all ArmLib resolutions with ArmBaseLib

The various ArmLib flavors are identical in practice, and a new ArmBaseLib has been introduced that can replace all of them. So replace all occurrences with ArmBaseLib. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ---

[edk2] [PATCH 0/5] ArmPkg ArmVirtPkg etc: consolidate ArmLib implementations

Now that the MMU manipulation routines have been moved out of ArmLib into ArmMmuLib, we are left with the following implementations of ArmLib which are all identical except for the fact that they target either ARM or AARCH64 but not both. ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf

[edk2] [PATCH 4/5] BeagleBoardPkg EmbeddedPkg Omap35xxPkg: move to ArmBaseLib

The various ArmLib flavors are identical in practice, and a new ArmBaseLib has been introduced that can replace all of them. So replace all occurrences with ArmBaseLib. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ---

[edk2] [PATCH 2/5] ArmPkg/ArmLib: introduce ArmBaseLib

Introduce a new ArmLib version ArmBaseLib, which encapsulates the ARM version ArmV7Lib and the AArch64 version AArch64Lib. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmPkg/ArmPkg.dsc| 1 +

[edk2] [PATCH 5/5] ArmPkg/ArmLib: remove all ArmLib flavors except ArmBaseLib

This removes the following ArmLib implementation, which were, apart from the fact that they targeted either ARM or AARCH64, fully identical: ArmPkg/Library/ArmLib/AArch64/AArch64Lib.inf ArmPkg/Library/ArmLib/AArch64/AArch64LibPei.inf ArmPkg/Library/ArmLib/AArch64/AArch64LibPrePi.inf

[edk2] [PATCH 1/5] ArmPkg/ArmLib: remove NullArmLib

Remove the NULL instance of ArmLib: it is not currently used, and its usefulness its dubious. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmPkg/ArmPkg.dsc | 1 -

Re: [edk2] [PATCH] ArmPkg: GICv2/v3 base address width fix-up

Hello Dennis, On 5 September 2016 at 09:27, Dennis Chen wrote: > According to the ACPI 6.0/6.1 spec, the physical base address of > GICC, GICD, GICR and GIC ITS is 64-bit. This patch is trying to > fix the original 32-bit width. > $ git grep PcdGic |grep -E Pcd.et32 gives

[edk2] [PATCH 5/7] MdeModulePkg/XhciDxe: enable 64-bit PCI DMA

PCI controller drivers must set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute if the controller supports 64-bit DMA addressing. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c | 22

[edk2] [PATCH 6/7] MdeModulePkg/PciHostBridgeDxe: restrict 64-bit DMA to devices that support it

Currently, the EFI_PCI_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute is completely ignored by the PCI host bridge driver, which means that, on an implementation that supports DMA above 4 GB, allocations above 4 GB may be provided to devices that have not expressed support for it. So in addition to

[edk2] [PATCH 7/7] ArmVirtPkg/FdtPciHostBridgeLib: enable 64-bit PCI DMA

Now that the PCI root bridge driver and various host controller drivers have been fixed, remove the 4 GB limit on PCI DMA allocation for QEMU's ECAM PCI host bridge. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ---

[edk2] [PATCH 2/7] MdeModulePkg/EhciDxe: enable 64-bit PCI DMA

PCI controller drivers must set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute if the controller supports 64-bit DMA addressing. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- MdeModulePkg/Bus/Pci/EhciDxe/Ehci.c |

[edk2] [PATCH 4/7] MdeModulePkg/SdMmcPciHcDxe: enable 64-bit PCI DMA

PCI controller drivers must set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute if the controller supports 64-bit DMA addressing. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ---

[edk2] [PATCH 1/7] MdeModulePkg/AtaAtapiPassThru: enable 64-bit PCI DMA

PCI controller drivers must set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute if the controller supports 64-bit DMA addressing. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ---

[edk2] [PATCH 0/7] MdeModulePkg ArmVirtPkg: fixes for 64-bit PCI DMA

After moving ArmVirtQemu to the generic PciHostBridgeDxe, we noticed that setting DmaAbove4G resulted in problems with the emulated EHCI USB host controller, which were caused by the fact that the PCI layer was providing DMA buffers allocated above 4 GB while the emulated EHCI controller in QEMU

[edk2] [PATCH 3/7] MdeModulePkg/NvmExpressDxe: enable 64-bit PCI DMA

PCI controller drivers must set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute if the controller supports 64-bit DMA addressing. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ---

[edk2] [PATCH] ArmVirtPkg/FdtPciPcdProducerLib: zero init local var to please GCC 4.8

GCC 4.8 in RELEASE mode complains about GetPciIoTranslation () potentially not assigning IoTranslation, but does not notice that it returns failure in this case, which means IoTranslation is never referenced *unless* it has been assigned. So simply set IoTranslation to zero to help the compiler.