[edk2-devel] [PATCH V3 1/2] MdePkg/Include: EFI Redfish Discover protocol

Move GUID definition of EFI Redfish Discover protocol to under MdePkg. With this we don't have dependency of RedfishPkg in ShellPkg. Signed-off-by: Abner Chang Cc: Michael D Kinney Cc: Liming Gao Cc: Zhiguang Liu Cc: Nickle Wang Cc: Peter O'Hanley --- MdePkg/MdePkg.dec

[edk2-devel] [PATCH V3 0/2] Support EFI Redfish protocols

In v3: Correct the mismatched definitions in both RedfishDiscover.h and UEFI spec 2.8 (Refer to v2.9). In v2: Address comments given by Liming on patch 1/2. Add handle parsing for EFI Redfish Discover protocol and EFI RestEx protocol. This change also moves the GUID definition of EFI Redfi

[edk2-devel] [PATCH V3 2/2] ShellPkg/UefiHandleParsingLib: Support EFI Redfish protocols

Add handle parsing for EFI Redfish Discover protocol. Add handle parsing for EFI RestEx protocol. Signed-off-by: Abner Chang Cc: Ray Ni Cc: Zhichao Gao Cc: Nickle Wang Cc: Peter O'Hanley Reviewed-by: Zhichao Gao --- .../Library/UefiHandleParsingLib/UefiHandleParsingLib.inf | 4 +++- .../Lib

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

Andrew, If the change is to use the gEfiAcpiTableGuid to identify another entry in the EFI configuration table, I agree it's a violation. We position this as a pure implementation that reuses a spec defined GUID. We didn't realize that it's a violation to the spec. We could define a new GUID for

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

> > (1) Currently, BlSupportDxe expects the ACPI content to come from > "SYSTEM_TABLE_INFO.AcpiTableBase" > [Include/Guid/SystemTableInfoGuid.h]. > That header file is at least *moderately* documented (it's better than > nothing). Additionally, BlSupportDxe is a DXE-phase component. > > The patch

Re: [EXTERNAL] [edk2-devel] [PATCH 1/1] MdeModulePkg/BmpSupportLib: Allow BMP with extra data

Is this a *good* idea? What is considered valid extra data? If it’s immaterial to the FW displaying the image, our policy has been to strip it off BEFORE adding it to the FW image. - Bret From: Jeff Brasen via groups.io Sent: Tuesday, March 23, 2021 10:29 AM

[edk2-devel] [PATCH 1/1] MdeModulePkg/BmpSupportLib: Allow BMP with extra data

Add support for processing BMP data that contains extra data after the image array, this data will not be parsed in anyway in the library but images that contain this will not be rejected from processing. --- MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c | 2 +- 1 file changed, 1 inserti

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

The universal payload specification proposes to re-use the existing GUID from UEFI for the HOB. I don't know if we have to update the UEFI spec firstly in order to reuse the GUID. Any idea? Thanks, Guo From: Andrew Fish Sent: T

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

Hi Laszlo, I don't mean currently UEFI payload is already standardized and modularized. There are still lots of things to do and I think the AcpiTableDxe patch is the one it needed. More information on ideas behind could be found from https://universalpayload.github.io/documentation/spec/spec.

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

On 03/23/21 16:45, Guo Dong wrote: > > Add my comments on the ideas behind. > UefiPayloadPkg is not a platform specific package, it tries to provide a > generic payload using platform independent Modules. This allows to reuse the > payload for different boot firmware solutions (Slim Bootloader,

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

My concern is gEfiAcpiTableGuid is owned by the UEFI Spec and any off label usage should probably be defined by the PI Spec. Is this a code 1st proposal or just an implementation? Thanks, Andrew Fish > On Mar 23, 2021, at 8:45 AM, Guo Dong wrote: > > > Add my comments on the ideas behind.

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

Add my comments on the ideas behind. UefiPayloadPkg is not a platform specific package, it tries to provide a generic payload using platform independent Modules. This allows to reuse the payload for different boot firmware solutions (Slim Bootloader, Coreboot, EDK2 bootloader) on different plat

Re: [edk2-devel] GSoC 2021 (MinPlatform, Ext2, ACPICA, etc)

Hi Nate! Sorry for taking so long to get back to you, I've been a bit busy and I'm not too used to so many emails in my inbox :) So, if I'm getting this right, essentially what is proposed in the MinPlatform board ports is to refactor the existing board code into an OpenBoardPkg that uses MinP

Re: [edk2-devel] [PATCH] UefiCpuPkg/SmmCommunication: Remove out-dated comments

Reviewed-by: Eric Dong -Original Message- From: Ni, Ray Sent: Tuesday, March 23, 2021 9:15 AM To: devel@edk2.groups.io Cc: Dong, Eric ; Laszlo Ersek ; Kumar, Rahul1 Subject: [PATCH] UefiCpuPkg/SmmCommunication: Remove out-dated comments The comments in PiSmmCommunicationPei.c describ

Re: [edk2-devel] [Patch V2 0/2] Let AcpiTableDxe driver install Acpi table from Hob

On 03/23/21 04:24, Zhiguang Liu wrote: > If HOB contains APCI table information, entry point of AcpiTableDxe.inf > should parse the APCI table from HOB, and install these tables. > We assume the whole ACPI table (starting with > EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER) > is contained by a sin

Re: [edk2-devel] [PATCH] UefiCpuPkg/SmmCommunication: Remove out-dated comments

On 03/23/21 02:15, Ray Ni wrote: > The comments in PiSmmCommunicationPei.c describe the whole memory > layout of the SMRAM regarding the SMM communication. > > But SHA-1: 8b1d14939053b63d80355465649c50f9f391a64a > PiSmmCommunicationSmm: Deprecate SMM Communication ACPI Table > removed the code tha

回复: [edk2-devel] [patch V2 00/29] Add a new library class RegisterFilterLib in edk2 to filter/trace port IO/MMIO/MSR access

Dandan: This change is good to me. Reviewed-by: Liming Gao for the patch set. Thanks Liming > -邮件原件- > 发件人: Bi, Dandan > 发送时间: 2021年3月23日 10:06 > 收件人: devel@edk2.groups.io; Bi, Dandan > 抄送: Andrew Fish ; Leif Lindholm ; > Laszlo Ersek ; Kinney, Michael D > ; Liming Gao ; Liu, > Zhigu

[edk2-devel] Cancelled Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, 23 March 2021 #cal-cancelled

BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Groups.io Inc//Groups.io Calendar//EN METHOD:CANCELLED CALSCALE:GREGORIAN BEGIN:VTIMEZONE TZID:America/Los_Angeles LAST-MODIFIED:20201011T015911Z TZURL:http://tzurl.org/zoneinfo-outlook/America/Los_Angeles X-LIC-LOCATION:America/Los_Angeles BEGIN:DAYLIGHT TZNAM

回复: [edk2-devel] TianoCore Bug Triage - APAC / NAMO - Tue, 03/23/2021 6:30pm-7:30pm #cal-reminder

There are few issues. Let’s cancel meeting on this week. 3272 EDK2 Tes UEFI-SCT unassig...@tianocore.org UNCO ImageIndex need be corrected in CheckForSupportGetImage Sun 22:09