[edk2] [PATCH v3] MdeModulePkg: Skip registering BootManagerMenu if its FFS is not found

This is a enhancement to support the case when platform firmware doesn’t support Boot Manager Menu. For now, if BootManagerMenu FFS can not be retrieved from FV, BDS core code will still register a boot option for it. Then, this non-functional boot option will still be booted by user's request

Re: [edk2] [PATCH 10/10] BaseTools Scripts: Add MemoryProfileSymbolGen.py

Reviewed-by: Liming Gao > -Original Message- > From: Zeng, Star > Sent: Sunday, June 26, 2016 1:36 PM > To: edk2-devel@lists.01.org > Cc: Yao, Jiewen ; Gao, Liming > ; Zhu, Yonghong > Subject:

Re: [edk2] [PATCH] UefiCpuPkg S3Resume2Pei: Report status code when allocate memory is failed

Reviewed-by: Jeff Fan -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng Sent: Friday, July 01, 2016 9:55 AM To: edk2-devel@lists.01.org Cc: Yao, Jiewen; Fan, Jeff Subject: [edk2] [PATCH] UefiCpuPkg S3Resume2Pei: Report

Re: [edk2] [PATCH] UefiCpuPkg S3Resume2Pei: Report status code when allocate memory is failed

Reviewed-by: jiewen@intel.com > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Star Zeng > Sent: Friday, July 1, 2016 9:55 AM > To: edk2-devel@lists.01.org > Cc: Yao, Jiewen ; Fan, Jeff >

[edk2] [PATCH] UefiCpuPkg S3Resume2Pei: Report status code when allocate memory is failed

Cc: Jiewen Yao Cc: Jeff Fan Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng --- UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c | 18 +++--- 1 file changed, 15 insertions(+), 3

[edk2] [PATCH 2/4] MdeModulePkg/PciBusDxe: look for the right capability in IsSHPC()

The PCI Hot Plug capability register block is marked with capability ID 0x0C (EFI_PCI_CAPABILITY_ID_SHPC), not 0x06 (EFI_PCI_CAPABILITY_ID_HOTPLUG). This bug prevents PciBusDxe from recognizing whether a PCI-to-PCI bridge supports hotplug. In turn the platform's EFI_PCI_HOT_PLUG_INIT_PROTOCOL is

[edk2] [PATCH 1/4] MdePkg/IndustryStandard: introduce EFI_PCI_CAPABILITY_ID_SHPC

The "Pci22.h" header file defines the macro EFI_PCI_CAPABILITY_ID_HOTPLUG with value 0x06. According to all of: - later parts of the same header file, - Appendix H ("Capability IDs") of the PCI Local Bus Specification Revision 2.3, - and Chapter 2 ("Capability IDs") of the PCI Code and ID

[edk2] [PATCH 4/4] OvmfPkg: add PciHotPlugInitDxe

After IncompatiblePciDeviceSupportDxe, this is another small driver / protocol implementation that tweaks the behavior of the PCI bus driver in edk2. The protocol is specified in the Platform Init Spec v1.4a, Volume 5, Chapter 12.6 "PCI Hot Plug PCI Initialization Protocol". This implementation

[edk2] [PATCH 0/4] PCI resource reservation changes for better hotpluggability

This series makes the following test case succeed: - Set the CODE env variable to the OVMF_CODE.fd file in the build output. - Set the TMPL env variable to the OVMF_VARS.fd file in the build output. - Set the ISO env variable to the pathname of a Linux LiveCD. - Create a copy of the

[edk2] [PATCH 3/4] MdeModulePkg/PciBusDxe: recognize hotplug-capable PCIe ports

Section 7.8.2 of the PCI Express specification (r4.0 v0.3), entitled "PCI Express Capabilities Register (Offset 02h)", describes the conditions when a PCIe port should be considered "supporting hotplug": - it should be a root complex port or a switch downstream port, and - it should have the "Slot

Re: [edk2] [RFC V2] Add more flexible PCD value formats in DEC/INF/DSC/FDF files

HI Mike One possible "skip byte" usage is to align with ACPI ASL OPREGION global NVS structure. For example, Field(GNVS,AnyAcc,Lock,Preserve) { // // Miscellaneous Dynamic Registers: // Offset(0), , 16, Offset(4), , 8, Offset(6), , 8, I think we can

Re: [edk2] [PATCH] ShellPkg: UefiHandleParsingLib: remove tautological comparison

On 06/30/16 23:09, Carsey, Jaben wrote: > Reviewed-by: Jaben Carsey Thank you! Commit 42cb90685275. Cheers Laszlo >> On Jun 30, 2016, at 2:05 PM, Laszlo Ersek wrote: >> >> The code being removed in this patch dates back to git commit a405b86d274d >>

Re: [edk2] [PATCH] ShellPkg: UefiHandleParsingLib: remove tautological comparison

Reviewed-by: Jaben Carsey -Jaben > On Jun 30, 2016, at 2:05 PM, Laszlo Ersek wrote: > > The code being removed in this patch dates back to git commit a405b86d274d > (Sep 14, 2010; "udk2010.up2.shell initial release."). The condition always >

[edk2] [PATCH] ShellPkg: UefiHandleParsingLib: remove tautological comparison

The code being removed in this patch dates back to git commit a405b86d274d (Sep 14, 2010; "udk2010.up2.shell initial release."). The condition always evaluates to true, and it breaks DEBUG builds of ArmVirtPkg with gcc-6.1: ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c: In

Re: [edk2] PCIe hotplug into downstream port

Of all the gin joints in all the towns in all the world, Laszlo Ersek had to walk into mine at 11:58:29 on Thursday 30 June 2016 and say: > On 06/30/16 20:14, Brian J. Johnson wrote: > > On 06/30/2016 11:47 AM, Laszlo Ersek wrote: > >> On 06/30/16 18:39, Marcel Apfelbaum wrote: > >>> On

Re: [edk2] PCIe hotplug into downstream port

On 06/30/2016 11:47 AM, Laszlo Ersek wrote: On 06/30/16 18:39, Marcel Apfelbaum wrote: On 06/30/2016 07:21 PM, Marcel Apfelbaum wrote: On 06/30/2016 04:07 PM, Laszlo Ersek wrote: Hi, does anyone on this list have experience with $SUBJECT, using physical UEFI firmware derived from edk2? The

Re: [edk2] PCIe hotplug into downstream port

On 06/30/16 18:39, Marcel Apfelbaum wrote: > On 06/30/2016 07:21 PM, Marcel Apfelbaum wrote: >> On 06/30/2016 04:07 PM, Laszlo Ersek wrote: >>> Hi, >>> >>> does anyone on this list have experience with $SUBJECT, using physical >>> UEFI firmware derived from edk2? >>> >>> The problem we're seeing

Re: [edk2] PCIe hotplug into downstream port

On 06/30/2016 07:21 PM, Marcel Apfelbaum wrote: On 06/30/2016 04:07 PM, Laszlo Ersek wrote: Hi, does anyone on this list have experience with $SUBJECT, using physical UEFI firmware derived from edk2? The problem we're seeing with OVMF is the following: PCIe hotplug works with PCIe root ports,

Re: [edk2] PCIe hotplug into downstream port

On 06/30/2016 04:07 PM, Laszlo Ersek wrote: Hi, does anyone on this list have experience with $SUBJECT, using physical UEFI firmware derived from edk2? The problem we're seeing with OVMF is the following: PCIe hotplug works with PCIe root ports, but it doesn't work with PCIe downstream ports.

Re: [edk2] PCIe hotplug into downstream port

On 06/30/2016 06:06 PM, Alex Williamson wrote: On Thu, 30 Jun 2016 15:07:27 +0200 Laszlo Ersek wrote: - What could be the difference between root ports and downstream ports? (Hotplug into root ports seems to work fine.) Hi Laszlo, It should be no difference IMHO. Both

Re: [edk2] weird ShellPkg line

Odd for sure! That little block will be added to my low priority chopping queue. > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Michael Zimmermann > Sent: Thursday, June 30, 2016 8:48 AM > To: Carsey, Jaben > Cc:

Re: [edk2] weird ShellPkg line

that operation must have taken place during the initial development process then because the line exists since the Initial commitof that file 'a405b86 udk2010.up2.shell initial release.' jcarsey is to blame :) On Thu, Jun 30, 2016 at 5:18 PM,

Re: [edk2] [PATCH 0/6] fix ASSERT_EFI_ERROR() misuse around the tree

On 06/28/16 15:25, Laszlo Ersek wrote: > Gerd's Jenkins CI worker has recently tried to build a few edk2 packages > with gcc-6. Gcc-6 introduces a new warning (among many others, likely) > called "bool-compare": > > >

Re: [edk2] weird ShellPkg line

Interesting… My guess would be that is used to do something and is the side effect of a find and replace operation and it should have been removed, but wasn’t… -Jaben From: peter.kirme...@ts.fujitsu.com [mailto:peter.kirme...@ts.fujitsu.com] Sent: Wednesday, June 29, 2016 1:22 AM To: Michael

Re: [edk2] [PATCH 4/6] ShellPkg: don't call functions with side effects in ASSERT_EFI_ERROR()

Reviewed-by: Jaben Carsey > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Thursday, June 30, 2016 4:07 AM > To: Carsey, Jaben ; Qiu, Shumin > > Cc: edk2-devel-01 >

Re: [edk2] PCIe hotplug into downstream port

On Thu, 30 Jun 2016 15:07:27 +0200 Laszlo Ersek wrote: > - What could be the difference between root ports and downstream ports? > (Hotplug into root ports seems to work fine.) Are OSes entitled to > allocate any unused address space (MMIO and IO) right when a device is >

Re: [edk2] PCIe hotplug into downstream port

On 06/30/16 16:48, Brian J. Johnson wrote: > On 06/30/2016 09:35 AM, Laszlo Ersek wrote: >> On 06/30/16 16:24, Brian J. Johnson wrote: >>> On 06/30/2016 08:07 AM, Laszlo Ersek wrote: >> - Does PCIe hotplug into downstream ports work with any (phys) firmware forked from edk2? Brian,

Re: [edk2] PCIe hotplug into downstream port

On 06/30/2016 09:35 AM, Laszlo Ersek wrote: On 06/30/16 16:24, Brian J. Johnson wrote: On 06/30/2016 08:07 AM, Laszlo Ersek wrote: - Does PCIe hotplug into downstream ports work with any (phys) firmware forked from edk2? Brian, Samer, do you guys have experience with this? Yes, we

Re: [edk2] PCIe hotplug into downstream port

On 06/30/16 16:24, Brian J. Johnson wrote: > On 06/30/2016 08:07 AM, Laszlo Ersek wrote: >> - Does PCIe hotplug into downstream ports work with any (phys) firmware >>forked from edk2? Brian, Samer, do you guys have experience with this? > > Yes, we support it on our UV server line.

Re: [edk2] [PATCH 1/6] EdkCompatibilityPkg: fix ASSERT_EFI_ERROR() typos

Thanks Laszlo for notifying. Sorry, it was by accident and didn't mean to send multiple R-b's :) Thanks, -Giri > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Thursday, June 30, 2016 3:23 AM > To: Mudusuru, Giri P > Cc: Gao,

Re: [edk2] PCIe hotplug into downstream port

On 06/30/16 16:22, Andrew Fish wrote: > >> On Jun 30, 2016, at 6:07 AM, Laszlo Ersek wrote: >> >> Hi, >> >> does anyone on this list have experience with $SUBJECT, using physical >> UEFI firmware derived from edk2? >> > > Laszlo, > > I don't know the edk2 specific answer

Re: [edk2] PCIe hotplug into downstream port

On 06/30/2016 08:07 AM, Laszlo Ersek wrote: Hi, does anyone on this list have experience with $SUBJECT, using physical UEFI firmware derived from edk2? The problem we're seeing with OVMF is the following: PCIe hotplug works with PCIe root ports, but it doesn't work with PCIe downstream ports.

Re: [edk2] [PATCH v3 2/3] MdeModulePkg: Add FrameBufferBltLib

On 06/30/16 15:40, Michael Zimmermann wrote: > Is this the same as OptionRomPkg/Library/FrameBufferBltLib ? AIUI, it has the same purpose, but it has improvements. For example, the API for the OptionRomPkg library forces all conforming library implementations to keep their configration in

Re: [edk2] PCIe hotplug into downstream port

> On Jun 30, 2016, at 6:07 AM, Laszlo Ersek wrote: > > Hi, > > does anyone on this list have experience with $SUBJECT, using physical > UEFI firmware derived from edk2? > Laszlo, I don't know the edk2 specific answer from memory, but in general as a system gets larger it

Re: [edk2] Memory Profile question.

> On Jun 30, 2016, at 12:05 AM, Yao, Jiewen wrote: > > Yes, Andrew. You are right. > We encounter similar problem, but it seems MSVC _ReturnAddress() does not > take parameter. > #define RETURN_ADDRESS(L) ((L == 0) ? _ReturnAddress() : (VOID *) 0) > For GCC family

Re: [edk2] [PATCH v3 2/3] MdeModulePkg: Add FrameBufferBltLib

Is this the same as OptionRomPkg/Library/FrameBufferBltLib ? Thanks Michael On Thu, Jun 30, 2016 at 1:23 PM, Laszlo Ersek wrote: > On 06/30/16 07:09, Ruiyu Ni wrote: > > This library provides interfaces to perform UEFI Graphics > > Output Protocol Video BLT operations. > > >

[edk2] PCIe hotplug into downstream port

Hi, does anyone on this list have experience with $SUBJECT, using physical UEFI firmware derived from edk2? The problem we're seeing with OVMF is the following: PCIe hotplug works with PCIe root ports, but it doesn't work with PCIe downstream ports. The error messages reported by both Linux and

Re: [edk2] [PATCH v3 2/3] MdeModulePkg: Add FrameBufferBltLib

On 06/30/16 07:09, Ruiyu Ni wrote: > This library provides interfaces to perform UEFI Graphics > Output Protocol Video BLT operations. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ruiyu Ni > Cc: Feng Tian > Cc: Justen

Re: [edk2] [PATCH 4/6] ShellPkg: don't call functions with side effects in ASSERT_EFI_ERROR()

Jaben, Shumin, On 06/28/16 15:25, Laszlo Ersek wrote: > When ASSERT_EFI_ERROR() is compiled out, dependent on build flags, only > the status checking should be removed; the function calls should stay. > > Cc: Jaben Carsey > Cc: Shumin Qiu >

Re: [edk2] [PATCH 1/6] EdkCompatibilityPkg: fix ASSERT_EFI_ERROR() typos

Hi Giri, On 06/30/16 06:40, Mudusuru, Giri P wrote: > Reviewed-by: Giri P Mudusuru Thank you for the reviews -- I did find and pick up your R-b messages soon after you sent them. There's no need to send repeated R-b's to the same patches. For example, this patch has

Re: [edk2] [PATCH v2] MdeModulePkg/MemoryStatusCode: Expose the DXE memory status code table.

On 06/30/16 04:40, Gao, Liming wrote: > Laszlo: > I have sent the patch to fix it. Thanks! > Besides, I suggest to update Ovmf > DSC/FDF to use StatusCode Router and Handler from MdeModulePkg > instead of IntelFrameworkModulePkg. What's the difference between them? Actually, what do these

Re: [edk2] [PATCH] OvmfPkg/build.sh: update gcc detection

On 06/30/16 07:00, Olaf Hering wrote: > On Wed, Jun 29, Jordan Justen wrote: > >> Missing Contributed-under. (See OvmfPkg/Contributions.txt) > > Looks like this project tries to avoid simple fixes from third party. It's not the case. Every project has its contribution rules (I reckon xen-devel

Re: [edk2] [Patch 0/2] Update-PXE-driver-to-follow-edk2-coding-standards

Series Reviewed-By: Wu Jiaxin Best Regards! Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fu > Siyuan > Sent: Thursday, June 30, 2016 10:08 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [Patch 0/2]

Re: [edk2] [patch] MdeModulePkg/EmmcDxe: Don't expose BlockIo interface for RPMB partition

The patch is good to me. Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Feng > Tian > Sent: Wednesday, June 29, 2016 11:18 AM > To: Wu, Hao A > Cc: edk2-devel@lists.01.org >

[edk2] [Patch] MdeModulePkg: Fix IPv4 stack potential disappeared issue

IP4_CONFIG2_INSTANCE->DataItem is used to save the configuration data to NV variable. When the policy is changed from static to DHCP, DnsServers info will be cleaned from DataItem first (See Ip4Config2SetPolicy), it's correct because DnsServers info should not be saved to NV variable. But if there

Re: [edk2] Memory Profile question.

Yes, Andrew. You are right. We encounter similar problem, but it seems MSVC _ReturnAddress() does not take parameter. #define RETURN_ADDRESS(L) ((L == 0) ? _ReturnAddress() : (VOID *) 0) So we enhanced MemoryAllocationLib to support add record from MemoryAllocationLib. The final log is

[edk2] Memory Profile question.

I've done some experimentation on the memory logging and if possible it is very useful to have 4 stack frames (non-LTO) as it is common for the MemoryAllocationLib to to call a sequence of Internal functions, so to find the calling spot in the driver you need 4 entries. For example:

Re: [edk2] [Patch] IntelFrameworkModulePkg StatusCode RuntimeDxe: Remove duplicated structure.

Reviewed-by: Cinnamon Shia -Original Message- From: Liming Gao [mailto:liming@intel.com] Sent: Thursday, June 30, 2016 10:38 AM To: edk2-devel@lists.01.org Cc: Shia, Cinnamon Subject: [Patch] IntelFrameworkModulePkg StatusCode