Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Guo Mang
---
BraswellPlatformPkg/PlatformPkg.fdf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/BraswellPlatformPkg/PlatformPkg.fdf
b/BraswellPlatformPkg/PlatformPkg.fdf
index 4fcfd85..1aa68ab 100644
---
Reviewed-by : Samer El-Haj-Mahmoud
-Original Message-
From: Jiaxin Wu [jiaxin...@intel.com]
Received: Wednesday, 08 Jun 2016, 12:49AM
To: edk2-devel@lists.01.org [edk2-devel@lists.01.org]
CC: Ye Ting [ting...@intel.com]; El-Haj-Mahmoud, Samer
[samer.el-haj-mahm...@hpe.com]; Subramanian
Reviewed-by: Ye Ting
-Original Message-
From: Wu, Jiaxin
Sent: Wednesday, June 08, 2016 1:49 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; El-Haj-Mahmoud Samer
; Subramanian Sriram
Subject: [Patch] MdeModulePkg: Fix IPv4 UseDefaultAddress failure case.
This patch is used to update IP
This patch is used to update IP4->Configure() to allow the upper layer
modules to obtain a default address by setting UseDefaultAddress to TRUE
when default address is not available yet.
Cc: Ye Ting
Cc: El-Haj-Mahmoud Samer
Cc: Subramanian Sriram
Contributed-under: TianoCore Contribution Agreem
Fantastic info Liming ! Thanks !
Sent from Shubha Ramani's iPhone 6s Plus
> On Jun 7, 2016, at 7:30 PM, Gao, Liming wrote:
>
> Hi,
> FreePages() will trig DEBUG_CLEAR_MEMORY() macro to zero memory. This macro
> will only be called when BIT3 is configured in PcdDebugPropertyMask value.
> Nor
Hi,
FreePages() will trig DEBUG_CLEAR_MEMORY() macro to zero memory. This macro
will only be called when BIT3 is configured in PcdDebugPropertyMask value.
Normally, Debug Build will configure PcdDebugPropertyMask to 0x2F so that this
macro is enabled. You can build system BIOS with PCD value
> On Jun 7, 2016, at 2:59 PM, Brett Stahlman wrote:
>
> d'Oh! Mystery solved. Working through the `info registers' output you
> sent helped me see what was happening. The system I'm working with had
> a buggy printf: in particular, it was parsing but effectively throwing
> away the `l' in a %ld
The patch looks good.
And one typo was in original comment:
// Check the reponse data header (tag,parasize and returncode )
--> response
Reviewed-by: Qin Long
Best Regards & Thanks,
LONG, Qin
> -Original Message-
> From: edk2-devel [mailto:edk2-deve
d'Oh! Mystery solved. Working through the `info registers' output you
sent helped me see what was happening. The system I'm working with had
a buggy printf: in particular, it was parsing but effectively throwing
away the `l' in a %ld or %lx specifier, so my attempts to print GDT
entries with %lx we
Reviewed-by: Samer El-Haj-Mahmoud
-Original Message-
From: Palmer, Thomas
Sent: Monday, June 6, 2016 9:47 PM
To: edk2-devel@lists.01.org
Cc: El-Haj-Mahmoud, Samer ; jiaxin...@intel.com;
Palmer, Thomas
Subject: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: CryptoPkg/TlsLib: Remove NULL
ciph
Reviewed-by: Samer El-Haj-Mahmoud
-Original Message-
From: Palmer, Thomas
Sent: Tuesday, June 7, 2016 1:36 PM
To: edk2-devel@lists.01.org
Cc: El-Haj-Mahmoud, Samer ; jiaxin...@intel.com;
Palmer, Thomas
Subject: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: CryptoPkg/TlsLib: Handshake
fail
TlsLib should inspect the return from the SSL_do_handshake and return
EFI_PROTOCOL_ERROR on certain conditions that are not recoverable.
For example, if a client is configured with a certain set of ciphers
that the TLS server does not support, the server will send a fatal
alert before the handshak
which system are you testing this one?
DEBUG builds of UEFI can be very slow because they do many checks and clear
the memory on each alloc/free.
Thanks
Michael
On Tue, Jun 7, 2016 at 6:36 PM, Shubha Ramani
wrote:
> I'm building an edk2 application which kicks off during system boot. For
> this
I'm building an edk2 application which kicks off during system boot. For this
application I have to allocate huge slabs of memory repeatedly (96 times ) - an
examplewould be 1087570 pages, allocated 96 times. I'm finding that it takes on
the order of minutes to do gBS->FreePages() 96 times for m
On 06/07/16 17:35, Andrew Fish wrote:
>
>> On Jun 7, 2016, at 8:31 AM, Brett Stahlman wrote:
>>
>> Ah. I think I may have found the answer to at least part of my
>> question, but would appreciate if someone could confirm...
>>
>> Section 2.3.4 of the UEFI spec states:
>> "Selectors are set to be
> On Jun 7, 2016, at 8:31 AM, Brett Stahlman wrote:
>
> Ah. I think I may have found the answer to at least part of my
> question, but would appreciate if someone could confirm...
>
> Section 2.3.4 of the UEFI spec states:
> "Selectors are set to be flat and are otherwise not used."
>
> Sectio
Ah. I think I may have found the answer to at least part of my
question, but would appreciate if someone could confirm...
Section 2.3.4 of the UEFI spec states:
"Selectors are set to be flat and are otherwise not used."
Section 3.2.4 of the Intel processor spec (Vol. 3A 3-7) states:
"In 64-bit mo
Series reviewed-by: Tapan Shah
-Original Message-
From: Hao Wu [mailto:hao.a...@intel.com]
Sent: Monday, June 06, 2016 8:49 PM
To: edk2-devel@lists.01.org; feng.t...@intel.com; Shah, Tapan
; El-Haj-Mahmoud, Samer
Subject: [PATCH v2 2/2] MdeModulePkg/RamDiskDxe: Add Memory Type selectio
Just inside my 64-bit x64 EFI boot loader, I print out the contents of
the GDT to see how it was initialized by the firmware. I've tried
running the boot loader both in QEMU (OVMF) and VMware ESXi. In both
cases, the first 5 descriptors after the leading null descriptor look
like this:
0x0
For the series:
Reviewed-by: Hegde Nagaraj P
Tested-by: Hegde Nagaraj P
Regards,
Nagaraj.
-Original Message-
From: Jiaxin Wu [mailto:jiaxin...@intel.com]
Sent: Tuesday, May 31, 2016 7:47 PM
To: edk2-devel@lists.01.org
Cc: Ye Ting ; Fu Siyuan ; Zhang Lubo
; Hegde, Nagaraj P ; Gary Lin
20 matches
Mail list logo
