>From d6e2bb4a60ab7cca4c1b8757f4ef76fc090ade7a Mon Sep 17 00:00:00 2001
From: david wei
Date: Fri, 15 Jul 2016 14:34:26 +0800
Subject: [PATCH] Fixed code logic error.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Wei
---
Vlv2TbltDevicePkg/PlatformRtcRuntimeDxe/Pla
Looks good to me.
Reviewed-by: Ye Ting
-Original Message-
From: Long, Qin
Sent: Wednesday, July 13, 2016 2:16 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Woodhouse, David ;
Long, Qin
Subject: [Patch] CryptoPkg/OpensslLib: Upgrade OpenSSL version to 1.0.2h
OpenSSL 1.0.2h was release
On 07/15/16 08:07, Ard Biesheuvel wrote:
> On 15 July 2016 at 01:27, Laszlo Ersek wrote:
>> First, the build tests. I built OVMF 84 times, with the following settings:
>>
>> * Dimension 1: whether your and Steven's patches were applied or not.
>
> I take it this means this series only?
Ah, yes,
On 15 July 2016 at 01:27, Laszlo Ersek wrote:
> On 07/14/16 15:16, Ard Biesheuvel wrote:
>> This series is not an attempt to steal Steven's thunder. I was merely
>> inspired by some of the changes he is proposing for GCC 5 and Clang
>> support, which I noticed would be applicable to older versions
On 07/13/16 16:36, Laszlo Ersek wrote:
> v1: http://thread.gmane.org/gmane.comp.bios.edk2.devel/14214
> v2: http://thread.gmane.org/gmane.comp.bios.edk2.devel/14471
>
> Changes relative to v2:
> - Patches 2 and 3: pick up Jeff's R-b.
> - Patch 4: resolve CpuExceptionHandlerLib to PeiCpuExceptionHa
On 07/15/16 02:26, Jordan Justen wrote:
> On 2016-07-13 07:36:56, Laszlo Ersek wrote:
>> Move the permanent PEI memory for the S3 resume boot path to the top of
>> the low RAM (just below TSEG if the SMM driver stack is included in the
>> build). The new size is derived from CpuMpPei's approximate
On 15 July 2016 at 03:28, Gao, Liming wrote:
> I see Steven patch uses -Os after enables new MS VA intrinsics. So, -Os
> should work. But, I am not sure whether -Os is better than -O2 for edk2.
>
-Os did not work for me with GCC49 or earlier. It complains about a
missing -maccumulate-outgoing-ar
Reviewed-by: Giri P Mudusuru
> -Original Message-
> From: Gao, Liming
> Sent: Thursday, July 14, 2016 10:05 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Mudusuru, Giri P
>
> Subject: [Patch 2/3] IntelFsp2WrapperPkg: Add missing modules in Package
> DSC
>
> Package DSC is used
Reviewed-by: Giri P Mudusuru
> -Original Message-
> From: Gao, Liming
> Sent: Thursday, July 14, 2016 10:05 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Mudusuru, Giri P
>
> Subject: [Patch 3/3] IntelFsp2Pkg: Add missing modules in Package DSC
>
> Package DSC is used to verify
Reviewed-by: Giri P Mudusuru
> -Original Message-
> From: Gao, Liming
> Sent: Thursday, July 14, 2016 10:05 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Mudusuru, Giri P
>
> Subject: [Patch 1/3] IntelFsp2WrapperPkg
> SecFspWrapperPlatformSecLibSample:Update code to pass build
>
On 07/15/16 02:12, Jordan Justen wrote:
> On 2016-07-13 07:36:58, Laszlo Ersek wrote:
>> In the next patch we're going to put EFI_PEI_MP_SERVICES_PPI to use.
>>
>> CpuMpPei uses the following PCDs from gUefiCpuPkgTokenSpaceGuid, beyond
>> those already used by CpuDxe:
>>
>> - PcdCpuMicrocodePatchAd
Package DSC is used to verify the module source build.
Cc: Jiewen Yao
Cc: Giri Mudusuru
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao
---
IntelFsp2Pkg/IntelFsp2Pkg.dsc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/IntelFsp2Pkg/IntelFsp2Pkg.dsc b/Inte
Package DSC is used to verify the module source build.
Cc: Jiewen Yao
Cc: Giri Mudusuru
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao
---
IntelFsp2WrapperPkg/IntelFsp2WrapperPkg.dsc | 7 +++
1 file changed, 7 insertions(+)
diff --git a/IntelFsp2WrapperP
1. Update its library class to PlatformSecLib
2. Update source code to refer to the matched header file
Cc: Jiewen Yao
Cc: Giri Mudusuru
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao
---
.../FspWrapperPlatformSecLibSample.c| 2 ++
..
Package DSC is used to verify the module source build.
Liming Gao (3):
IntelFsp2WrapperPkg SecFspWrapperPlatformSecLibSample:Update code to
pass build
IntelFsp2WrapperPkg: Add missing modules in Package DSC
IntelFsp2Pkg: Add missing modules in Package DSC
IntelFsp2Pkg/IntelFsp2Pkg.dsc
Package DSC is used to verify the module source build.
Liming Gao (3):
IntelFsp2WrapperPkg SecFspWrapperPlatformSecLibSample:Update code to
pass build
IntelFsp2WrapperPkg: Add missing modules in Package DSC
IntelFsp2Pkg: Add missing modules in Package DSC
IntelFsp2Pkg/IntelFsp2Pkg.dsc
You are right Eugene!
Performance is getting impacted by all these factors, but that's true that I
shall get better performance figure than this.
That's why I am trying to figure out the possible optimizations in code that
may help in improving it.
Have you tried some optimizations to get bette
Hi, Mike
Thanks for providing such info.
I double checked WDK7600.16385.1 msahci driver. In P_Running_WaitOnFRE(), there
is a statement: " Wait for confirmation is a 'nice to have' but isn't
necessary. "
And in the code, it waits for 50ms for FR bit if it's not set to 1.
So the most safe way
Reviewed-by: Liming Gao
> -Original Message-
> From: Zhu, Yonghong
> Sent: Friday, July 15, 2016 10:22 AM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming
> Subject: [Patch] BaseTools: Fix a bug for FixedPcd value generation in
> AutoGen file
>
> If the library is listed in [Components]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
.../UefiShellBcfgCommandLib.c | 49 +++---
1 file changed, 25 insertions(+), 24 deletions(-)
diff --git a/ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellB
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
.../Library/UefiShellCommandLib/ConsistMapping.c | 499 +
1 file changed, 320 insertions(+), 179 deletions(-)
diff --git a/ShellPkg/Library/UefiShellCommandLib/ConsistMappi
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
.../UefiShellCommandLib/UefiShellCommandLib.c | 36 +-
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/ShellPkg/Library/UefiShellCommandLib/UefiShellComman
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
.../UefiShellDebug1CommandsLib/EfiCompress.c | 30 +-
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiComp
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c
b/Sh
The patch serials remove almost all assertions on memory allocation
result, replaces with the error handling code.
https://github.com/niruiyu/edk2/commits/shell_assert_v2
V2 adds "Status =" in patch #8, adds missing copy right year updates in
patch #7, #8, #9, #11, #13.
Ruiyu Ni (27):
ShellPkg
If the library is listed in [Components] section for build only, its
used FixedPcd Value is not generated into AutoGen code. This patch
cover this case to generate the FixedPcd Value in AutoGen file.
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zh
Jaben,
If we want to promote FreeArgList to library API. The structure ARG_LIST will
also be in the library header file. Let's wait and see if there is more such
usage
and abstract it then.
I will post a v2 for those that need update.
Regards,
Ray
>-Original Message-
>From: edk2-devel [
If the binary module is list in the FDF file but not list in the DSC
file, current build report would not include these binary module's info
in the report "Module section". The patch fix this issue.
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu
I see Steven patch uses -Os after enables new MS VA intrinsics. So, -Os should
work. But, I am not sure whether -Os is better than -O2 for edk2.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Friday, July 15, 2016 6:20
On 2016-07-13 07:36:56, Laszlo Ersek wrote:
> Move the permanent PEI memory for the S3 resume boot path to the top of
> the low RAM (just below TSEG if the SMM driver stack is included in the
> build). The new size is derived from CpuMpPei's approximate memory demand.
>
> Save the base address and
On 2016-07-13 07:36:58, Laszlo Ersek wrote:
> In the next patch we're going to put EFI_PEI_MP_SERVICES_PPI to use.
>
> CpuMpPei uses the following PCDs from gUefiCpuPkgTokenSpaceGuid, beyond
> those already used by CpuDxe:
>
> - PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize: thes
Reviewed-by: Jaben Carsey
> -Original Message-
> From: Wu, Jiaxin
> Sent: Wednesday, July 13, 2016 9:32 PM
> To: Zhang, Lubo ; Carsey, Jaben
> ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan
> Subject: RE: [edk2] [patch] ShellPkg: Fix issue about Ifconfig6 -r command.
> Importance:
On 07/14/16 15:16, Ard Biesheuvel wrote:
> This series is not an attempt to steal Steven's thunder. I was merely
> inspired by some of the changes he is proposing for GCC 5 and Clang
> support, which I noticed would be applicable to older versions of GCC
> as well.
>
> The first patch fixes the is
Hi Bruce,
I think size is most important for the default settings. This is why it
it important to measure the size changes for each set of flag options.
Size measurements are a bit complex due to the interaction with compressors.
I have found that measuring the used space in an FV with compressio
On 7/14/2016 4:20 PM, Laszlo Ersek wrote:
On 07/14/16 23:57, Bruce Cran wrote:
I wonder if -Os might be a better default optimization? Or perhaps
there's plenty of flash on devices nowadays and performance is more
important than size?
Beware of -Os with GCC48:
http://thread.gmane.org/gmane.c
On 07/14/16 23:57, Bruce Cran wrote:
> On 7/14/2016 7:16 AM, Ard Biesheuvel wrote:
>
>> Patch #3 enabled -O2 optimization for X64/RELEASE all the way back to
>> GCC44.
>
> I wonder if -Os might be a better default optimization? Or perhaps
> there's plenty of flash on devices nowadays and performa
BTW Windows waits for FR bit set for 50ms as opposed to Linux.
See P_Running_WaitOnFRE function of storahci from WDK.
So you can break Intel HBAs for example.
Could you ask iastor team about this issue?
Regards.
On Thu, 2016-07-14 at 06:25 +, Tian, Feng wrote:
> Hi, Shaveta
>
> We have app
On 7/14/2016 7:16 AM, Ard Biesheuvel wrote:
Patch #3 enabled -O2 optimization for X64/RELEASE all the way back to GCC44.
I wonder if -Os might be a better default optimization? Or perhaps
there's plenty of flash on devices nowadays and performance is more
important than size?
At least for
> -Original Message-
> From: Ni, Ruiyu
> Sent: Thursday, July 14, 2016 2:30 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben
> Subject: [PATCH 08/27] ShellPkg/ConsistMapping.c: Handle memory
> allocation failure
> Importance: High
>
> Contributed-under: TianoCore Contribution Agreem
Please check copyright. I notice that at minimum EfiCompress.c and LoadPciRom
need an update.
I think #8 has an error. Replied to that email separately.
Is it worth moving "IfConfig6FreeArgList" to a shared library? Looked like
there were 2 copies...
Otherwise for the series
Reviewed-By: Ja
On 14/07/2016 19:25, Laszlo Ersek wrote:
>> > Ugh, this is so wrong. :) I guess you could also use a macro that
>> > expands to
>> >
>> >bits 32
>> >mov src, dst
>> >bits 64
>> >
>> > because the encoding is the same in 32-bit and 64-bit.
> Nice trick :), but the point of using NA
On 07/14/16 19:16, Kinney, Michael D wrote:
> Laszlo,
>
> It may be possible to update NASM source to be compatible with both older and
> latest
> version of NASM.
I claim that it's not possible in this case, as long as we'd like to
avoid DBs and other coding tricks (i.e., as long as we'd like t
On 07/14/16 19:14, Paolo Bonzini wrote:
>
>
> On 14/07/2016 19:11, Laszlo Ersek wrote:
>> * I didn't say, but I also tried "mov ax, ds". The SDM writes, "The
>> upper 56 bits or 48 bits (respectively) of the destination
>> general-purpose register are not modified by the operation". In this
>
Laszlo,
It may be possible to update NASM source to be compatible with both older and
latest
version of NASM. We would have to evaluate the current build breaks to see if
that is
possible or not.
For VS20xx tool chains, I prefer to specify the min at 2.12.01. I think
support for
source leve
On 14/07/2016 19:11, Laszlo Ersek wrote:
> * I didn't say, but I also tried "mov ax, ds". The SDM writes, "The
> upper 56 bits or 48 bits (respectively) of the destination
> general-purpose register are not modified by the operation". In this
> context, those bits were known to be zero, and
On 07/14/16 18:33, Paolo Bonzini wrote:
>
>
> On 14/07/2016 13:19, Laszlo Ersek wrote:
>> The problem is that NASM wouldn't support segment register MOVs in
>> 64-bit mode until the following commit:
>>
>> http://repo.or.cz/nasm.git/commitdiff/21d4ccc3c338
>>
>> Wed, 25 Aug 2010 02:28:00 +020
On 14/07/2016 13:19, Laszlo Ersek wrote:
> The problem is that NASM wouldn't support segment register MOVs in
> 64-bit mode until the following commit:
>
> http://repo.or.cz/nasm.git/commitdiff/21d4ccc3c338
>
> Wed, 25 Aug 2010 02:28:00 +0200 (24 17:28 -0700)
>
> However, that change was f
On 07/14/16 18:00, Andrew Fish wrote:
>
>> On Jul 14, 2016, at 8:47 AM, Kinney, Michael D
>> wrote:
>>
>> Laszlo,
>>
>> We may have to specify a different min version based on the toolchain used.
>>
>> For VS20xx toolchains, we must have 2.12.01 as the minimum to support source
>> level debug.
On 07/14/16 17:47, Kinney, Michael D wrote:
> Laszlo,
>
> We may have to specify a different min version based on the toolchain used.
>
> For VS20xx toolchains, we must have 2.12.01 as the minimum to support source
> level debug.
>
> If GCCxx toolchains are compatible with NASM 2.07, then I see
> On Jul 14, 2016, at 8:47 AM, Kinney, Michael D
> wrote:
>
> Laszlo,
>
> We may have to specify a different min version based on the toolchain used.
>
> For VS20xx toolchains, we must have 2.12.01 as the minimum to support source
> level debug.
>
> If GCCxx toolchains are compatible with N
Laszlo,
We may have to specify a different min version based on the toolchain used.
For VS20xx toolchains, we must have 2.12.01 as the minimum to support source
level debug.
If GCCxx toolchains are compatible with NASM 2.07, then I see no reason to not
document it that way.
Mike
> -Origi
On 07/14/16 16:51, Michael Zimmermann wrote:
> Hi,
>
> if it would be very important to support that old version of NASM you
> could just write "raw" assembler by putting the needed instructions as
> word's within the executable code.
Edk2 has prided itself on supporting several versions of sever
On 07/14/16 16:28, Gao, Liming wrote:
> Laszlo:
>
> Sorry. I didn’t mention my version. I use 2.12.01 to verify all
> changes. In 2.12, it adds support of Codeview version 8 (cv8) debug
> format for win32 and win64 formats in the COFF backend. We need this
> feature to get cv8 debug.
I understa
On 14 July 2016 at 16:42, Gao, Liming wrote:
> Ard:
> On patch 4, the visibility 'hidden' GCC pragma globally. Does it work
> together with other mode, such as large? Or it only works with small and pic?
> I want to clarify this change has no negative impact.
The #if checks for 'defined(__pic
Hi,
if it would be very important to support that old version of NASM you could
just write "raw" assembler by putting the needed instructions as word's
within the executable code.
changing the min requirement seems more proper though :)
Thanks
Michael
On Thu, Jul 14, 2016 at 4:28 PM, Gao, Limin
Ard:
On patch 4, the visibility 'hidden' GCC pragma globally. Does it work
together with other mode, such as large? Or it only works with small and pic? I
want to clarify this change has no negative impact.
On patch 5, I don't see any change for IA32 arch. is there no mode for IA32
arch? He
On Thu, Jul 14, 2016 at 09:19:09AM -0500, Jeremy Linton wrote:
> On 07/14/2016 09:16 AM, Ard Biesheuvel wrote:
> >On 14 July 2016 at 15:58, Jeremy Linton wrote:
> >>The AXI<->PCIe translation comments are out of date with
> >>respect to the code. In the first case the AXI master port
> >>is incorr
Laszlo:
Sorry. I didn't mention my version. I use 2.12.01 to verify all changes. In
2.12, it adds support of Codeview version 8 (cv8) debug format for win32 and
win64 formats in the COFF backend. We need this feature to get cv8 debug. But,
this version will report the error message: nasm: fat
On 07/14/2016 09:16 AM, Ard Biesheuvel wrote:
On 14 July 2016 at 15:58, Jeremy Linton wrote:
The AXI<->PCIe translation comments are out of date with
respect to the code. In the first case the AXI master port
is incorrectly called a slave. In the second case the the
translation direction indica
On 14 July 2016 at 15:58, Jeremy Linton wrote:
> The AXI<->PCIe translation comments are out of date with
> respect to the code. In the first case the AXI master port
> is incorrectly called a slave. In the second case the the
> translation direction indicated for the slave port is the
> wrong dir
The PCIe PIO translation is incorrect on the Juno, correct that.
While we are updating that module correct the comments to more
accurately reflect the code and what is actually happening.
Jeremy Linton (2):
ArmJuno: fix Juno PIO host bridge mapping
ArmJuno: Correct AXI->PCIe translation commen
I've been down this road before...
Network performance (on non-coherent DMA architectures) can be affected by:
1. Excessive double buffering caused by unaligned buffers (PCI BusMasterRead /
BusMasterWrite cases)
2. Excessive accesses to uncached buffers (like PCI common buffer cases)
3. Packet l
On 14 July 2016 at 15:09, Leif Lindholm wrote:
> Thanks Jeremy.
>
> If Ryan's happy with this change, I'm happy to push it.
>
Yep, fine. I tested v3 (I think) and it worked fine.
> Regards,
>
> Leif
>
> On 14 July 2016 at 14:58, Jeremy Linton wrote:
>> The PCIe PIO translation is incorrect on
Thanks Jeremy.
If Ryan's happy with this change, I'm happy to push it.
Regards,
Leif
On 14 July 2016 at 14:58, Jeremy Linton wrote:
> The PCIe PIO translation is incorrect on the Juno, correct that.
> While we are updating that module correct the comments to more
> accurately reflect the code
Series Reviewed-By: Eugene Cohen
Thank you for your ongoing help with our TCP issues, it is much appreciated.
Eugene
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Wu, Jiaxin
> Sent: Tuesday, July 12, 2016 8:12 PM
> To: Fu, Siyuan ; edk2-
The AXI<->PCIe translation comments are out of date with
respect to the code. In the first case the AXI master port
is incorrectly called a slave. In the second case the the
translation direction indicated for the slave port is the
wrong direction.
Correct both of these comments to reflect what th
The Juno PIO mapping is 8M, so it should be using a 32-bit
PIO address translation. Further, PIO addresses should start
at 0 and be translated to/from the ARM MMIO region.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeremy Linton
Reviewed-by: Leif Lindholm
---
ArmPlat
Ok, I can try that !!
Thanks and Regards,
Shaveta
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Thursday, July 14, 2016 7:11 PM
To: Shaveta Leekha
Cc: edk2-devel@lists.01.org; Linaro UEFI Mailman List
Subject: Re: PCI performance issue
On 14 July 20
On 14 July 2016 at 15:29, Shaveta Leekha wrote:
> But I have not tested the code (software) on any other hardware/board.
> As I have not yet ported PCI code on any other board yet.
>
I would recommend to base your expectations not on U-Boot but on UEFI
running on a different architecture using si
But I have not tested the code (software) on any other hardware/board.
As I have not yet ported PCI code on any other board yet.
Regards,
Shaveta
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Shaveta
Leekha
Sent: Thursday, July 14, 2016 6:57 P
Hi Ard,
Tftp have been tested on u-boot and Linux on same platform/board (the hardware
on which tftp is tested on UEFI)
And it takes around 1 min(or even lesser) in getting this big file (initrd
image : around 30MB) over PCI using Tftp.
So the issue is not with hardware, its somewhere in (PCI
From: "Shi, Steven"
Both GCC and LLVM 3.8 64bits support new variable argument (VA)
intrinsics for Microsoft ABI, enable these new VA intrinsics for
GNUC family 64bits code build. These VA intrinsics are only
permitted use in 64bits code, so not use them in 32bits code build.
The original 32bits
On 14 July 2016 at 15:05, Shaveta Leekha wrote:
> Hi,
>
>
>
>
>
> I have been working on PCI controller driver performance (Root Bridge) for
> my ARMv8 platform. I had integrated my PciHostBridgeDxe code with
> MdeModulePkg/Bus/Pci/PciBusDxe. Have followed PCI Host bridge resource
> allocation and
On 14 July 2016 at 15:16, Ard Biesheuvel wrote:
> This series is not an attempt to steal Steven's thunder. I was merely
> inspired by some of the changes he is proposing for GCC 5 and Clang
> support, which I noticed would be applicable to older versions of GCC
> as well.
>
> The first patch fixes
GCC v4.4 does not implement __builtin_unreachable(), so avoid using
it when building with this version or earlier.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
MdePkg/Include/Base.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a
The ordinary small code model for x86_64 cannot be used in UEFI, since
it assumes the executable is loaded in the first 2 GB of memory.
Therefore, we use the large model instead, which can execute anywhere,
but uses absolute 64-bit wide quantities for all symbol references,
which is costly in terms
This series is not an attempt to steal Steven's thunder. I was merely
inspired by some of the changes he is proposing for GCC 5 and Clang
support, which I noticed would be applicable to older versions of GCC
as well.
The first patch fixes the issue that __builtin_unreachable() is not
implemented b
When building position independent (PIC) ELF objects, the GCC compiler
assumes that each symbol with external linkage may potentially end up
being exported from a shared library, which means that each of those
symbols may be subject to symbol preemption, i.e., the executable
linking to the shared l
Now that we switched to the __builtin_ms_va_list VA_LIST type for
GCC/X64, we can trust the compiler to do the right thing even under
optimization, and so we can enable -O2 optimization all the way back
to GCC44.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Hi,
I have been working on PCI controller driver performance (Root Bridge) for my
ARMv8 platform. I had integrated my PciHostBridgeDxe code with
MdeModulePkg/Bus/Pci/PciBusDxe. Have followed PCI Host bridge resource
allocation and Root bridge IO protocol, as used in some other existing PCI
On 07/14/16 13:19, Laszlo Ersek wrote:
> It seems that before NASM 2.10, there's simply no way to access segment
> registers in 64-bit mode. I propose that we upgrade the following
> comment in BaseTools:
>
>> diff --git a/BaseTools/Conf/tools_def.template
>> b/BaseTools/Conf/tools_def.template
Hi,
yesterday I set up a VS2015x86 toolchain for test-building OVMF. I also
resurrected my Fedora virtual machines that are dedicated to
test-building OVMF with GCC44-GCC49 toolchains.
I've found some C language build errors already, and I'm progressing
through them slowly. However, one "killer"
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
ShellPkg/Library/UefiShellLib/UefiShellLib.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
b/ShellPkg/Library/Uef
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
ShellPkg/Application/Shell/Shell.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/ShellPkg/Application/Shell/Shell.c
b/ShellPkg/Application/Shel
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
ShellPkg/Library/UefiShellLevel2CommandsLib/Cp.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Cp.c
b/Shell
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
ShellPkg/Library/UefiShellLevel1CommandsLib/If.c | 95 +---
1 file changed, 53 insertions(+), 42 deletions(-)
diff --git a/ShellPkg/Library/UefiShellLevel1CommandsLib/If.c
b
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
ShellPkg/Library/UefiShellLevel1CommandsLib/For.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/ShellPkg/Library/UefiShellLevel1CommandsLib/For.c
b/ShellPkg/Li
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
ShellPkg/Library/UefiShellLevel2CommandsLib/Cd.c | 34 +++-
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Cd.c
b
The patch serials remove almost all assertions on memory allocation
result, replaces with the error handling code.
https://github.com/niruiyu/edk2/commits/shell_assert
Ruiyu Ni (27):
ShellPkg/Shell.c: Handle memory allocation failure
ShellPkg/IsVolatileEnv: Handle memory allocation failure
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
.../UefiShellNetwork1CommandsLib/Ifconfig.c| 77 --
.../UefiShellNetwork1CommandsLib.uni | 1 +
2 files changed, 58 insertions(+), 20 deletions(-)
diff
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c
b/ShellPkg/Li
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
ShellPkg/Library/UefiShellLib/UefiShellLib.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
b/ShellPkg/Library/UefiS
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
.../UefiShellNetwork2CommandsLib/Ifconfig6.c | 75 --
.../UefiShellNetwork2CommandsLib.uni | 2 +
2 files changed, 56 insertions(+), 21 deletions(-)
diff
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
ShellPkg/Library/UefiShellDriver1CommandsLib/DrvDiag.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/DrvDiag.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
b/ShellPkg/Li
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/LoadPciRom.c
b/Shell
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
ShellPkg/Library/UefiShellDriver1CommandsLib/DevTree.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/DevTree.c
b/
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
ShellPkg/Library/UefiDpLib/Dp.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/ShellPkg/Library/UefiDpLib/Dp.c b/ShellPkg/Library/UefiDpLib/Dp.c
index 4bad3c2..75c7d11
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
ShellPkg/Library/UefiShellDriver1CommandsLib/DrvCfg.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/ShellPkg/Library/UefiShellDriver1CommandsLib/DrvCfg.c
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Jaben Carsey
---
.../UefiShellDebug1CommandsLib/EfiDecompress.c | 52 --
1 file changed, 28 insertions(+), 24 deletions(-)
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/EfiDeco
1 - 100 of 111 matches
Mail list logo
