[edk2] ArmCpuLib users

I just found out that ArmCpuLib seems to be unused even though it's included in a few dsc files. Is it deprecated and should we remove it or are there external users? Thanks Michael ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org

Re: [edk2] Using Intel UDk debugger

Arka, UDK Debugger tool supports your usage model. Please see the section "9.11 Debugging a standalone module loaded in a UEFI shell" @ https://firmware.intel.com/sites/default/files/UDK_Debugger_Tool_User_Manual_V1.11.pdf Thanks! Jeff -Original Message- From: edk2-devel [mailto:edk2-d

Re: [edk2] [PATCH 0/4] MdeModulePkg/BaseTools: Add Brotli algorithm support

Michael: Thanks for point. I will create the patch to fix 2&3. For 1, I am not sure whether there is generic way to handle it. Thanks Liming >-Original Message- >From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com] >Sent: Thursday, March 30, 2017 1:13 PM >To: Gao, Liming >Cc: So

[edk2] Using Intel UDk debugger

Hi, I am sorry if it is not a right place to ask this. I have installed WinDbg and Intel UDK debugger. I want to debug a driver and an application on an Asrock borad, but going through the UDK debugger user manual I realize that SourceLevelDebugPkg has to be included in target firmware image. Now

Re: [edk2] [PATCH 0/4] MdeModulePkg/BaseTools: Add Brotli algorithm support

Thanks you that worked. (sorry that I forgot about that) There were three things I had to workaround: 1) since I'm using -nostdinc I had to remove the sys/types.h include from MdeModulePkg/Library/BrotliCustomDecompressLib/common/types.h and use BOOLEAN, TRUE and FALSE instead of bool, true and fa

Re: [edk2] [PATCH v3] MdePkg: BaseIoLibIntrinsic (IoLib class) library

Leo: Your change is good. My comment is not to add asm code. Nasm is enough. For new added features, nasm is only required. Thanks Liming >-Original Message- >From: Leo Duran [mailto:leo.du...@amd.com] >Sent: Thursday, March 30, 2017 12:07 AM >To: edk2-de...@ml01.01.org >Cc: Leo Duran

Re: [edk2] [PATCH 0/4] MdeModulePkg/BaseTools: Add Brotli algorithm support

Michasel: Please delete cache Conf/tools_def.txt, and run edksetup again to apply new tools_def.txt. Thanks Liming >-Original Message- >From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com] >Sent: Thursday, March 30, 2017 5:04 AM >To: Gao, Liming >Cc: Song, BinX ; edk2-devel@list

[edk2] [PATCH] SecureBoot UI Update

--- .../SecureBootConfigDxe/SecureBootConfig.vfr | 38 +++- .../SecureBootConfigDxe/SecureBootConfigImpl.c | 196 - .../SecureBootConfigDxe/SecureBootConfigImpl.h | 32 .../SecureBootConfigDxe/SecureBootConfigNvData.h | 5 + .../SecureBootConfigStrings.

Re: [edk2] [RFC PATCH v1 0/2] OvmfPkg/QemuVideoDxe: Add VMWare SVGA2 framebuffer support

On 03/29/17 10:19, Phil Dennis-Jordan wrote: > This extends the QemuVideoDxe driver to support the VMWare SVGA2 display > device implemented by Qemu. Drivers for this device exist for guest OSes > which do not support Qemu's other display adapters, so supporting it in > OVMF is useful in conjunctio

Re: [edk2] [Patch] NetworkPkg/DnsDxe: Fix zero StationIp configuration failure of DNSv6

Reviewed-by: Zhang Lubo -Original Message- From: Wu, Jiaxin Sent: Friday, March 24, 2017 2:00 PM To: edk2-devel@lists.01.org Cc: Zhang, Lubo ; Ye, Ting ; Fu, Siyuan ; Wu, Jiaxin Subject: [Patch] NetworkPkg/DnsDxe: Fix zero StationIp configuration failure of DNSv6 According UEFI Spec,

Re: [edk2] [PATCH v1 1/1] OvmfPkg: Allow multiple add-pointer linker commands to same ACPI table

This is a very good first patch! I have a few requests. I'll generally rehash the points from . On 03/29/17 09:50, Phil Dennis-Jordan wrote: > From: Phil Dennis-Jordan > > ACPI tables may contain multiple pointer fields to the same destinat

Re: [edk2] [RFC PATCH 0/6] OVMF: HFS+ (and Mac OS X boot)

Hi Gabriel, First off, thanks for going to the effort of building an HFS+ driver! Due to travel, I've only just got around to checking these out, sorry. Before I can try to help out with cleaning the patches up to the extent they can be upstreamed, I still need to get them working. boot.efi seems

Re: [edk2] [PATCH 0/4] MdeModulePkg/BaseTools: Add Brotli algorithm support

How can I use this? If I change my compressed FV's GUID to 3D532050-5CDA-4FD0-879E-0F7F630D5AFB I get the following error: GenFds.py... : error F003: No tool found with GUID 3D532050-5CDA-4FD0-879E-0F7F630D5AFB Thanks Michael On Mon, Mar 27, 2017 at 5:15 AM, Gao, Liming wrote: > Reviewed-by: Li

Re: [edk2] [PATCH v2] ArmVirtPkg/PlatformHasAcpiDtDxe: allow guest level ACPI disable override

On 03/29/17 21:10, Ard Biesheuvel wrote: > On 29 March 2017 at 19:44, Laszlo Ersek wrote: >> On 03/29/17 19:50, Ard Biesheuvel wrote: >>> In general, we should not present two separate (and inevitably different) >>> hardware descriptions to the OS, in the form of ACPI tables and a device >>> tree

Re: [edk2] [PATCH v2] ArmVirtPkg/PlatformHasAcpiDtDxe: allow guest level ACPI disable override

On 29 March 2017 at 19:44, Laszlo Ersek wrote: > On 03/29/17 19:50, Ard Biesheuvel wrote: >> In general, we should not present two separate (and inevitably different) >> hardware descriptions to the OS, in the form of ACPI tables and a device >> tree blob. For this reason, we recently added the lo

Re: [edk2] Sec and Reset vector

Hi guys. This e-mail if for the future generations, and proves everything you guys commented to guide me when I did the first question. So if you have a uefi firmware image, and would like to check how everything happens using radare, you need to do the following: step 1: Check your .bin file si

Re: [edk2] [edk2-staging][PATCH 2/2] ShellPkg: Add acpiview tool to dump ACPI tables

Hi Jeff, Sadly, we do not have an environment setup to build tianocore-edk2 using Visual Studio 2015. We build the edk2 from the windows command prompt using the linaro gcc toolchain for ARM/AARCH64. Is it possible to send the error log, please ? Evan has made a request for creation of a branch

Re: [edk2] [PATCH v2] ArmVirtPkg/PlatformHasAcpiDtDxe: allow guest level ACPI disable override

On 03/29/17 19:50, Ard Biesheuvel wrote: > In general, we should not present two separate (and inevitably different) > hardware descriptions to the OS, in the form of ACPI tables and a device > tree blob. For this reason, we recently added the logic to ArmVirtQemu to > only expose the ACPI 2.0 entr

Re: [edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

On 03/29/17 19:30, Marc Zyngier wrote: > On 29/03/17 18:15, Laszlo Ersek wrote: >> On 03/29/17 19:01, Marc Zyngier wrote: >>> On 29/03/17 17:40, Laszlo Ersek wrote: On 03/29/17 18:07, Ard Biesheuvel wrote: > On 29 March 2017 at 17:03, Laszlo Ersek wrote: >> On 03/29/17 18:02, Ard Bies

Re: [edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

On 03/29/17 19:44, Mark Rutland wrote: > Hi, > > On Wed, Mar 29, 2017 at 06:55:26PM +0200, Laszlo Ersek wrote: >> On 03/29/17 18:17, Ard Biesheuvel wrote: >>> On 29 March 2017 at 17:09, Jon Masters wrote: Thanks Laszlo. A quick note from me that regardless of this discussion I will be p

Re: [edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

On 03/29/17 19:30, Ard Biesheuvel wrote: > On 29 March 2017 at 18:23, Laszlo Ersek wrote: >> On 03/29/17 19:07, Ard Biesheuvel wrote: >>> On 29 March 2017 at 18:01, Marc Zyngier wrote: On 29/03/17 17:40, Laszlo Ersek wrote: > [...] > On the technical side: > > - I think a dynamic

[edk2] [PATCH v2] ArmVirtPkg/PlatformHasAcpiDtDxe: allow guest level ACPI disable override

In general, we should not present two separate (and inevitably different) hardware descriptions to the OS, in the form of ACPI tables and a device tree blob. For this reason, we recently added the logic to ArmVirtQemu to only expose the ACPI 2.0 entry point if no DT binary is being passed, and vice

Re: [edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

Hi, On Wed, Mar 29, 2017 at 06:55:26PM +0200, Laszlo Ersek wrote: > On 03/29/17 18:17, Ard Biesheuvel wrote: > > On 29 March 2017 at 17:09, Jon Masters wrote: > >> Thanks Laszlo. A quick note from me that regardless of this > >> discussion I will be pushing to ensure the version Red Hat ships > >

Re: [edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

On 29 March 2017 at 18:23, Laszlo Ersek wrote: > On 03/29/17 19:07, Ard Biesheuvel wrote: >> On 29 March 2017 at 18:01, Marc Zyngier wrote: >>> On 29/03/17 17:40, Laszlo Ersek wrote: [...] On the technical side: - I think a dynamic boolean PCD would be superior, if that is possible

Re: [edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

On 03/29/17 19:07, Ard Biesheuvel wrote: > On 29 March 2017 at 18:01, Marc Zyngier wrote: >> On 29/03/17 17:40, Laszlo Ersek wrote: >>> On 03/29/17 18:07, Ard Biesheuvel wrote: On 29 March 2017 at 17:03, Laszlo Ersek wrote: > On 03/29/17 18:02, Ard Biesheuvel wrote: >> On 29 March 20

Re: [edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

On 29 March 2017 at 17:40, Laszlo Ersek wrote: > On 03/29/17 18:07, Ard Biesheuvel wrote: >> On 29 March 2017 at 17:03, Laszlo Ersek wrote: >>> On 03/29/17 18:02, Ard Biesheuvel wrote: On 29 March 2017 at 17:00, Laszlo Ersek wrote: [..] > NACK > OK, fair enough. How do you

Re: [edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

On 03/29/17 19:01, Marc Zyngier wrote: > On 29/03/17 17:40, Laszlo Ersek wrote: >> On 03/29/17 18:07, Ard Biesheuvel wrote: >>> On 29 March 2017 at 17:03, Laszlo Ersek wrote: On 03/29/17 18:02, Ard Biesheuvel wrote: > On 29 March 2017 at 17:00, Laszlo Ersek wrote: >> On 03/29/17 17:1

Re: [edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

On 29 March 2017 at 18:01, Marc Zyngier wrote: > On 29/03/17 17:40, Laszlo Ersek wrote: >> On 03/29/17 18:07, Ard Biesheuvel wrote: >>> On 29 March 2017 at 17:03, Laszlo Ersek wrote: On 03/29/17 18:02, Ard Biesheuvel wrote: > On 29 March 2017 at 17:00, Laszlo Ersek wrote: >> On 03/2

Re: [edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

On 03/29/17 18:16, Marc Zyngier wrote: > On 29/03/17 17:03, Laszlo Ersek wrote: >> On 03/29/17 18:02, Ard Biesheuvel wrote: >>> On 29 March 2017 at 17:00, Laszlo Ersek wrote: On 03/29/17 17:19, Ard Biesheuvel wrote: > In general, we should not present two separate (and inevitably differen

Re: [edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

On 03/29/17 18:17, Ard Biesheuvel wrote: > On 29 March 2017 at 17:09, Jon Masters wrote: >> Thanks Laszlo. A quick note from me that regardless of this discussion I >> will be pushing to ensure the version Red Hat ships makes ACPI the default >> with it being extremely painful to use DT. It is t

Re: [edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

On 03/29/17 18:07, Ard Biesheuvel wrote: > On 29 March 2017 at 17:03, Laszlo Ersek wrote: >> On 03/29/17 18:02, Ard Biesheuvel wrote: >>> On 29 March 2017 at 17:00, Laszlo Ersek wrote: On 03/29/17 17:19, Ard Biesheuvel wrote: > In general, we should not present two separate (and inevitab

Re: [edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

On 29 March 2017 at 17:09, Jon Masters wrote: > Thanks Laszlo. A quick note from me that regardless of this discussion I will > be pushing to ensure the version Red Hat ships makes ACPI the default with it > being extremely painful to use DT. It is time the ecosystem got with the > program we a

Re: [edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

On 29 March 2017 at 17:03, Laszlo Ersek wrote: > On 03/29/17 18:02, Ard Biesheuvel wrote: >> On 29 March 2017 at 17:00, Laszlo Ersek wrote: >>> On 03/29/17 17:19, Ard Biesheuvel wrote: In general, we should not present two separate (and inevitably different) hardware descriptions to the

[edk2] [PATCH v3] MdePkg: BaseIoLibIntrinsic (IoLib class) library

This patch adds an SEV-specific .INF and corresponding assembly files, to unroll REP INSx/OUTSx on IoRead/WriteFifo#() routines when the SEV feature is enabled under a hypervisor environment. The new .INF only supports the IA32 and X64 architectures. Cc: Michael D Kinney Cc: Liming Gao Contribu

[edk2] [PATCH v3] MdePkg: BaseIoLibIntrinsic (IoLib class) library

This patch adds an SEV-specific .INF and corresponding assembly files, to unroll REP INSx/OUTSx on IoRead/WriteFifo#() routines when the SEV feature is enabled under a hypervisor environment. The new .INF only supports the IA32 and X64 architectures. This patch follows the series "[PATCH v3 0

Re: [edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

On 03/29/17 18:02, Ard Biesheuvel wrote: > On 29 March 2017 at 17:00, Laszlo Ersek wrote: >> On 03/29/17 17:19, Ard Biesheuvel wrote: >>> In general, we should not present two separate (and inevitably different) >>> hardware descriptions to the OS, in the form of ACPI tables and a device >>> tree

Re: [edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

On 29 March 2017 at 17:00, Laszlo Ersek wrote: > On 03/29/17 17:19, Ard Biesheuvel wrote: >> In general, we should not present two separate (and inevitably different) >> hardware descriptions to the OS, in the form of ACPI tables and a device >> tree blob. For this reason, we recently added the lo

Re: [edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

On 03/29/17 17:19, Ard Biesheuvel wrote: > In general, we should not present two separate (and inevitably different) > hardware descriptions to the OS, in the form of ACPI tables and a device > tree blob. For this reason, we recently added the logic to ArmVirtQemu to > only expose the ACPI 2.0 entr

[edk2] [PATCH v2] MdePkg: BaseIoLibIntrinsic (IoLib class) library

This patch adds an SEV-specific .INF and corresponding assembly files, to unroll REP INSx/OUTSx on IoRead/WriteFifo#() routines when the SEV feature is enabled under a hypervisor environment. The new .INF only supports the IA32 and X64 architectures. This patch follows the series "[PATCH v3 0

[edk2] [PATCH v2] MdePkg: BaseIoLibIntrinsic (IoLib class) library

This patch adds an SEV-specific .INF and corresponding assembly files, to unroll REP INSx/OUTSx on IoRead/WriteFifo#() routines when the SEV feature is enabled under a hypervisor environment. The new .INF only supports the IA32 and X64 architectures. Cc: Michael D Kinney Cc: Liming Gao Contribu

Re: [edk2] [PATCH] kvm: pass the virtual SEI syndrome to guest OS

On 03/29/17 16:48, Christoffer Dall wrote: > On Wed, Mar 29, 2017 at 10:36:51PM +0800, gengdongjiu wrote: >> 2017-03-29 18:36 GMT+08:00, Achin Gupta : >>> Qemu is essentially fulfilling the role of secure firmware at the >>> EL2/EL1 interface (as discussed with Christoffer below). So it >>> should

[edk2] [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

In general, we should not present two separate (and inevitably different) hardware descriptions to the OS, in the form of ACPI tables and a device tree blob. For this reason, we recently added the logic to ArmVirtQemu to only expose the ACPI 2.0 entry point if no DT binary is being passed, and vice

Re: [edk2] [PATCH 1/3] MdeModulePkg/Include: Add IOMMU protocol definition.

On 29 March 2017 at 00:45, Yao, Jiewen wrote: > Agree. That is a good idea. > > > > I will add that in V2 patch. > Hello Jiewen, As a bit of background, what I have in mind is an enhancement of the PCI root bridge I/O allocate, map and unmap methods so that situations that would currently lead t

[edk2] [PATCH 6/6] ArmPlatformPkg/ArmVExpressDxe: simply FDT handling in ArmFvpDxe

Replace the elaborate but awkward handling of FDT images using device paths and string PCDs initialized to 128 spaces with a simple scheme involving a set of builtin DTBs and a bit of runtime logic to select between them. This is sufficient for ordinary use, which makes it more suitable as referen

[edk2] [PATCH 4/6] ArmPlatformPkg/ArmVExpressDxe: remove ARM support

The 32-bit ARM support in this driver is unused, and thus untested. So let's just remove it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/Arm/ArmFvpDxeArm.c | 84 ArmPlatformPkg/ArmVEx

[edk2] [PATCH 3/6] ArmPlatformPkg/ArmShellCmdRunAxf: remove BdsLib dependency

Remove ArmShellCmdRunAxf's dependency on the deprecated BdsLib by cloning the ShutdownUefiBootServices() routine into a local source file; this is the only BdsLib feature 'runaxf' depends on. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmPlatformPkg

[edk2] [PATCH 0/6] Embedded|ArmPlatformPkg: spring cleaning + DtPlatformDxe switch

This implements the upstream part of switching VExpress TC2 and the AArch64 FVP Foundation/Base models to the new DtPlatformDxe driver, which is much simpler and only allows ACPI or DT to be enabled but never both. Patches #1 and #2 tweak the new DtPlatformDxe so it can choose from several builtin

[edk2] [PATCH 2/6] EmbeddedPkg/DtPlatformDxe: declare symbolic name for FILE_GUID

Add a definition to the package .dec file to allow DEPEXes to refer to DtPlatformDxe in a BEFORE/AFTER DEPEX. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- EmbeddedPkg/Drivers/DtPlatformDxe/DtPlatformDxe.inf | 2 +- EmbeddedPkg/EmbeddedPkg.dec

[edk2] [PATCH 5/6] ArmPlatformPkg/ArmVExpressDxe: remove unused cruft from ArmHwDxe

Remove unused cruft from ArmHwDxe -- the only thing that remains is installation of the 'runaxf' shell command. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmHwDxe.c | 43 +--- ArmPlatf

[edk2] [PATCH 1/6] EmbeddedPkg/DtPlatformDxe: allow multiple entries in DTB FV file

To allow some dynamic behavior in selecting the DTB to expose to the OS, allow the DTB FV file to contain multiple sections, and indirect the choice of section via a fixed/dynamic PCD, which defaults to 0. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ---

Re: [edk2] [PATCH] kvm: pass the virtual SEI syndrome to guest OS

On 03/29/17 14:51, Michael S. Tsirkin wrote: > On Wed, Mar 29, 2017 at 01:58:29PM +0200, Laszlo Ersek wrote: >> (8) When QEMU gets SIGBUS from the kernel -- I hope that's going to come >> through a signalfd -- QEMU can format the CPER right into guest memory, >> and then inject whatever interrupt (

Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library

On 03/29/17 11:49, Gao, Liming wrote: > Laszlo: > I agree GuidCName can't be used to initialize the global variable. If > there is such requirement, GUID C MACRO will have to be defined. > Then, its header file will be required. > Now, we have no rule to forbid to add the header file if it has no

Re: [edk2] [PATCH] kvm: pass the virtual SEI syndrome to guest OS

(This ought to be one of the longest address lists I've ever seen :) Thanks for the CC. I'm glad Shannon is already on the CC list. For good measure, I'm adding MST and Igor.) On 03/29/17 12:36, Achin Gupta wrote: > Hi gengdongjiu, > > On Wed, Mar 29, 2017 at 05:36:37PM +0800, gengdongjiu wrote:

Re: [edk2] [PATCH] kvm: pass the virtual SEI syndrome to guest OS

Hi gengdongjiu, On Wed, Mar 29, 2017 at 05:36:37PM +0800, gengdongjiu wrote: > > Hi Laszlo/Biesheuvel/Qemu developer, > >Now I encounter a issue and want to consult with you in ARM64 platform， as > described below: > >when guest OS happen synchronous or asynchronous abort, kvm needs to se

Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library

Laszlo: I agree GuidCName can't be used to initialize the global variable. If there is such requirement, GUID C MACRO will have to be defined. Then, its header file will be required. Now, we have no rule to forbid to add the header file if it has no other definitions except for GUID value,

Re: [edk2] [Patch] BaseTools: tools_def.txt to append new option in VFRPP flag

Yonghong: Please consider the case that $(MODULE_NAME)ImgDefs.h is not generated. This patch may not work. Thanks Liming >-Original Message- >From: Zhu, Yonghong >Sent: Tuesday, March 28, 2017 5:37 PM >To: edk2-devel@lists.01.org >Cc: Gao, Liming >Subject: [Patch] BaseTools: tools_def

Re: [edk2] [PATCH] MdeModulePkg/PeiCore: avoid EFI_IMAGE_MACHINE_TYPE_SUPPORTED to check arch

Reviewed-by: Liming Gao >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard >Biesheuvel >Sent: Monday, March 27, 2017 8:22 PM >To: edk2-devel@lists.01.org; Gao, Liming >Cc: Ard Biesheuvel >Subject: [edk2] [PATCH] MdeModulePkg/PeiCore: avoid >E

Re: [edk2] [PATCH] MdeModulePkg/DxeCore: add missing id-to-string mapping for AARCH64

Reviewed-by: Liming Gao >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard >Biesheuvel >Sent: Monday, March 27, 2017 7:20 PM >To: edk2-devel@lists.01.org; Zeng, Star ; Tian, Feng > >Cc: Ard Biesheuvel >Subject: [edk2] [PATCH] MdeModulePkg/DxeC

[edk2] [RFC PATCH v1 2/2] OvmfPkg: Add VMWare SVGA II support in QemuVideoDxe.

From: Phil Dennis-Jordan In addition to the QXL, Cirrus, etc. VGA adapters, Qemu also implements a basic version of VMWare's SVGA2 display device. Drivers for this device exist for guest OSes which do not support Qemu's other display adapters, so supporting it in OVMF is useful in conjunction wit

[edk2] [RFC PATCH v1 1/2] OvmfPkg: Add SVGA2 device register definition header from VMWare

From: Phil Dennis-Jordan Import a header file defining symbolic constants for the VMWare SVGA2 virtual display device in preparation for supporting it in QemuVideoDXE. This file is made available by VMWare under the MIT license, for example at http://vmware-svga.sourceforge.net/ Cc: Jordan Juste

[edk2] [RFC PATCH v1 0/2] OvmfPkg/QemuVideoDxe: Add VMWare SVGA2 framebuffer support

This extends the QemuVideoDxe driver to support the VMWare SVGA2 display device implemented by Qemu. Drivers for this device exist for guest OSes which do not support Qemu's other display adapters, so supporting it in OVMF is useful in conjunction with those OSes. I've tried to follow the existing

[edk2] [PATCH v1 0/1] OvmfPkg/AcpiPlatformDxe: Fix bug 368, multiply pointed-to tables

From: Phil Dennis-Jordan This fixes the bug in OVMF's Qemu ACPI table linker which caused it to fail when multiple fields point to the same table. Previously, each pointer caused the pointed-to table to be installed via the EFI_ACPI_TABLE_PROTOCOL. However, each table must only be installed once

[edk2] [PATCH v1 1/1] OvmfPkg: Allow multiple add-pointer linker commands to same ACPI table

From: Phil Dennis-Jordan ACPI tables may contain multiple pointer fields to the same destination table. For example, in some revisions, the FADT contains both DSDT and X_DSDT fields, and they may both point to the DSDT. Indeed, some operating systems demand this to be the case. Previously, if Qe

Re: [edk2] [Patch] BaseTools: Update Pkcs7 and RSA2048 tool with shell=True

Reviewed-by: Liming Gao > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Yonghong Zhu > Sent: Tuesday, March 28, 2017 5:38 PM > To: edk2-devel@lists.01.org > Cc: Gao, Liming > Subject: [edk2] [Patch] BaseTools: Update Pkcs7 and RSA2048 tool