Re: [edk2] Why do I get this AllocatePages assert ?

Do you mean AllocatePages() will hit ASSERT after it is called many times to allocate at a fixed address? Do you use the same fixed address or the different fixed address for AllocatePages() calling? Thanks Liming -Original Message- From: edk2-devel

[edk2] [patch 2/2] MdePkg: Refine the function comments in Keyword Handler Protocol

Refine the function comments in HiiConfigKeyword.h. Cc: Liming Gao Cc: Eric Dong Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi Reviewed-by: Eric Dong ---

[edk2] [patch 0/2] Refine function comments in Keyword Handler Protocol

The follow two patches mainly to refine the function comments in EFI Configuration Keyword Handler Protocol. Cc: Liming Gao Cc: Eric Dong Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi Dandan Bi

Re: [edk2] [PATCH] MdeModulePkg/UsbBusDxe: Fix memory leak

On 2016/2/9 4:53, Alcantara, Paulo wrote: Cc: Feng Tian Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paulo Alcantara --- MdeModulePkg/Bus/Usb/UsbBusDxe/UsbUtility.c | 2 ++ 1 file

Re: [edk2] [PATCH] ShellPkg/UefiDpLib: Refine the code of locating all handles in DpTrace.c.

Cinnamon: On 2016/2/9 1:38, Cinnamon Shia wrote: Replace gBS->LocateHandle with gBS->LocateHandleBuffer Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Cinnamon Shia --- ShellPkg/Library/UefiDpLib/DpTrace.c | 40

Re: [edk2] PCD Local Token Numbers in PEI/DXE

Star -- There are many cases where the PEI FV is not updated because it resides in a portion of the flash that is specially protected, often by a pin on the motherboard. In many platforms, this recovery firmware in PEI is never updated throughout the life of the platform. But DXE might be

Re: [edk2] PCD Local Token Numbers in PEI/DXE

Tim, Basically, I aware PEI as the high-reliability, high-security portion of the BIOS. I mean for this case, should PEI FV be also updated? And the mismatch seems not a special case for PCD. Consider one situation that new DXE wants to consume a HOB produced by new PEI, the new DXE could also

Re: [edk2] SATA 3.0 AHCI host controller codebase

-Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Monday, February 08, 2016 1:20 PM To: Bhupesh Sharma ; Leif Lindholm ; Shaveta Leekha Cc: edk2-devel@lists.01.org

Re: [edk2] PCD Local Token Numbers in PEI/DXE

Star -- Consider the case where PEI FV is inside the flash boot block, but DXE FV is outside of the flash boot block. This case is very common, using PEI as the high-reliability, high-security portion of the BIOS. You are correct, there is another case which is: Build #1: PEI database A does

Re: [edk2] [PATCH] MdeModulePkg/UsbBusDxe: Fix memory leak

Paulo, Thanks for fixing this bug. Reviewed-by: Feng Tian Thanks Feng -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Alcantara, Paulo Sent: Tuesday, February 09, 2016 04:54 To: edk2-devel@lists.01.org Cc: Tian, Feng;

Re: [edk2] PCD Local Token Numbers in PEI/DXE

Mike, Could one PCD be accessed using both methods Dynamic and DynamicEx in one build? As I know, it could not. Another problem is about where the default PCD value stores. Currently, PEI and PEI+DXE phase consumed PCDs are stored in PEI PCD database, and only DXE phase consumed PCDs are

Re: [edk2] [PATCH v2 1/2] MdePkg: Add EFI Wireless MAC Connection II Protocol definitions

Reviewed-by: Liming Gao -Original Message- From: Wu, Hao A Sent: Monday, February 01, 2016 3:35 PM To: edk2-devel@lists.01.org; Kinney, Michael D; Gao, Liming; Ye, Ting Cc: Wu, Hao A Subject: [PATCH v2 1/2] MdePkg: Add EFI Wireless MAC Connection II Protocol

[edk2] Suggested wiki updates

Since I can't figure out how to submit changes to the wiki, I've noticed a few pages at least that should probably be updated: https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Issues still mentions Trac and Sourceforge.

Re: [edk2] [PATCH] NetworkPkg: better sanity check on Ipv6 prefix length

Hi Samer, The original code in Ip6GetPrefix() uses ASSERT() to guarantee the PrefixLength < IP6_PREFIX_NUM. If you think the patch is necessary I suggest to update the ASSERT() code as well. Do you agree? Thanks, Ting -Original Message- From: edk2-devel

Re: [edk2] [PATCH] OvmfPkg: simplify VARIABLE_STORE_HEADER generation

On 2016/2/6 4:41, Laszlo Ersek wrote: Before the merger of the authenticated and non-authenticated variable drivers (commit fa0737a839d0), we had to match the varstore header GUID in "OvmfPkg/VarStore.fdf.inc" to SECURE_BOOT_ENABLE, because the opposite GUID would cause either driver to fail an

Re: [edk2] [PATCH] MdeModulePkg, AtaBusDxe: Bounce buffer IO operations if unaligned

Hi, Jeremy Sorry for missing this mail. I would *REJECT* this patch as it should be grub2's bug in which it passes down an unaligned buffer. Accroding to UEFI spec , it clearly described that the IoAlign should be met by the BlockIo's caller "IoAlign Supplies the alignment requirement for

Re: [edk2] varstore compatibility between auth and non-auth

Just get back from Chinese New Year holiday. On 2016/2/6 1:55, Laszlo Ersek wrote: On 02/05/16 13:37, Laszlo Ersek wrote: On 02/05/16 13:18, Gerd Hoffmann wrote: Hi, So, my question is: is this intended and supported behavior (that is, going from a Secure Boot-capable build to a Secure

Re: [edk2] [patch 0/7] Add UEFI2.6 MemoryAttributesTable support.

On 02/14/16 10:22, Ard Biesheuvel wrote: > On 14 February 2016 at 07:51, Laszlo Ersek wrote: >> On 02/14/16 06:44, Yao, Jiewen wrote: >>> HI >>> Thanks to discuss this properties table issue. >>> The purpose of this patch is to *add* UEFI2.6 memory attributes table. This >>>

Re: [edk2] [patch 0/7] Add UEFI2.6 MemoryAttributesTable support.

On 14 February 2016 at 07:51, Laszlo Ersek wrote: > On 02/14/16 06:44, Yao, Jiewen wrote: >> HI >> Thanks to discuss this properties table issue. >> The purpose of this patch is to *add* UEFI2.6 memory attributes table. This >> patch does not handle any UEFI2.5 properties