On 9 September 2015 at 11:44, Ard Biesheuvel wrote:
> SVN commit r18077 ("BaseTools/GenFw: move .debug contents to .data to
> save space") removed the separate .debug section after moving its
> contents into .text or .data. However, this change does not take into
> account that some of these conte
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi
---
.../RegularExpressionDxe/RegularExpressionDxe.c| 146 +
.../RegularExpressionDxe/RegularExpressionDxe.h| 108 +++
.../RegularExpressionDxe/RegularExpressionDxe.inf | 10 +
> On Sep 10, 2015, at 8:44 PM, Kevin Davis wrote:
>
>>
>> On 09/10/2015 08:14 PM, Kevin Davis wrote:
>>> Ah. I wasn't in the room when they figured it out. And I've never seen
>> their written opinion. Is it documented somewhere?
>>
>> which in turn leads to this FAQ:
>> https://urlde
>
> On 09/10/2015 08:14 PM, Kevin Davis wrote:
> >>
> > Ah. I wasn't in the room when they figured it out. And I've never seen
> their written opinion. Is it documented somewhere?
>
> which in turn leads to this FAQ:
> https://web.archive.org/web/20121116185559/http://lkml.org/lkml/2009/6/
> 2
Cc: Jaben Carsey
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin
---
ShellPkg/Application/Shell/Shell.c | 36 +---
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/ShellPkg/Application/Shell/Shell.c
b/ShellPkg/Appl
>
>
> On 10/09/2015 16:24, Kevin Davis wrote:
> > Further leading me to guess that any actual use of those
> > implementations could lead to you actually needing to hire a real
> > attorney and not one that you find on YouTube.
>
> The good thing is that attorneys have already figured it out. I
> On Sep 10, 2015, at 7:22 AM, Blibbet wrote:
>
>
>> Sure, mixture of licenses makes life more difficult. Not an excuse for
>> ignoring non-BSD innovations and embracing Linux OSV/OEM community with
>> their preferred license. GPL'ed LibreOffice bugfixes can't go upstream
>> to BSD-like, ASF2 l
On 10/09/2015 16:24, Kevin Davis wrote:
> Further leading me to guess that any actual use of those
> implementations could lead to you actually needing to hire a real
> attorney and not one that you find on YouTube.
The good thing is that attorneys have already figured it out. IBM
figured out a
>
> > On Sep 10, 2015, at 4:40 AM, Alexander Graf wrote:
> >
> >
> >
> > On 10.09.15 12:04, Laszlo Ersek wrote:
> >> On 09/10/15 08:19, Alexander Graf wrote:
> >>>
> >>>
> Am 10.09.2015 um 07:32 schrieb Jordan Justen
> :
> >>
> Laszlo's email raised the GPL question, but I was not sure
> Sure, mixture of licenses makes life more difficult. Not an excuse for
> ignoring non-BSD innovations and embracing Linux OSV/OEM community with
> their preferred license. GPL'ed LibreOffice bugfixes can't go upstream
> to BSD-like, ASF2 license of Apache OpenOffice, but that's life.
I spent th
> On Sep 10, 2015, at 4:40 AM, Alexander Graf wrote:
>
>
>
> On 10.09.15 12:04, Laszlo Ersek wrote:
>> On 09/10/15 08:19, Alexander Graf wrote:
>>>
>>>
Am 10.09.2015 um 07:32 schrieb Jordan Justen :
>>
Laszlo's email raised the GPL question, but I was not sure what the
EDK II
On 09/10/15 02:46, Tian, Feng wrote:
> Series Reviewed-by: Feng Tian
Thank you! Committed as SVN r18437 and r18438.
Laszlo
>
> Thanks
> Feng
>
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, September 09, 2015 17:39
> To: edk2-de...@ml01.01.org
On 10 September 2015 at 11:45, Gao, Liming wrote:
> Thanks. I am fine to GenFw tool change.
>
Thanks Liming.
Any comments on the DebugRVA patch I sent out yesterday?
Regards,
Ard.
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, September
On 09/10/15 08:19, Alexander Graf wrote:
>
>
>> Am 10.09.2015 um 07:32 schrieb Jordan Justen :
>> Laszlo's email raised the GPL question, but I was not sure what the
>> EDK II community would accept with regards to GPL. Thus ... I asked. I
>> guess I'm getting a better idea with regards to Apple
Thanks. I am fine to GenFw tool change.
Liming
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Thursday, September 10, 2015 5:44 PM
To: Gao, Liming
Cc: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Liu, Yingke D;
sigmaepsilo...@gmail.com; ler...@red
On 10 September 2015 at 11:32, Gao, Liming wrote:
> Ard:
> Does GenFw tool patch impact X86 arch?
>
No, it does not.
Patch #1 just removes some dead code from Elf64Convert.c (since EM_ARM
is only used for 32 bit code)
Patch #2 changes three things in Elf32Convert.c:
a) it removes a special ca
On 09/10/15 05:05, Zeng, Star wrote:
> On 2015/9/9 18:48, Laszlo Ersek wrote:
>> me neither :)
>>
>>> but if this (executable code on stack) is
>>> happening in grub is there something which is explicitly forbidden to
>>> UEFI
>>> apps by the UEFI spec?
>>
>> Yes, there is. This small OvmfPkg patch
Ard:
Does GenFw tool patch impact X86 arch?
Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
Biesheuvel
Sent: Thursday, September 10, 2015 4:55 PM
To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Liu, Yingke D
Cc: sigmaep
WORKSPACE is still kept.
New optional PACKAGES_PATH is introduced to specify the additional WORKSPACEs.
In PACKAGES_PATH, ';' is separator in Windows, ':' is separator in Linux.
Build directory is in WORKSPACE. Package, BaseTools and Conf directory
will be found from WORKSPACE and PACKAGES_PATH.
Update ECC to refer MultipleWorkspace class to convert
the file path from WORKSPACE and PACKAGES_PATH.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Li YangX
Reviewed-by: Liming Gao
---
BaseTools/Source/Python/Ecc/Check.py | 13 +
BaseTools/Source/P
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao
Reviewed-by: Wu Hao A
---
BaseTools/Scripts/SetVisualStudio.bat | 2 +-
BaseTools/Scripts/ShowEnvironment.bat | 2 ++
Edk2Setup.bat | 64 +--
3 files change
WORKSPACE is still kept.
New PACKAGES_PATH is introduced to specify the additional WORKSPACEs.
In PACKAGES_PATH, ';' is separator in Windows, ':' is separator in Linux.
Build directory is in WORKSPACE. Package, BaseTools and Conf directory
will be found from WORKSPACE and PACKAGES_PATH.
In implem
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao
Reviewed-by: Wu Hao A
---
BaseTools/BuildEnv | 66 --
edksetup.sh| 19 +---
2 files changed, 65 insertions(+), 20 deletions(-)
diff --git a/B
Update UPT to refer MultipleWorkspace class to convert
the file path from WORKSPACE and PACKAGES_PATH.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hesheng Chen
Reviewed-by: Liming Gao
---
.../Python/UPT/Core/DistributionPackageClass.py| 26 +++---
Base
1. Update edksetup.bat and toolsetup.bat to handle PACKAGES_PATH.
BaseTools directory may be in PACKAGES_PATH instead of WORKSAPCE.
2. Introduce EDK_TOOLS_BIN env points to the windows binary tools dir.
Windows BaseTools Win32 may be a separate directory.
Contributed-under: TianoCore Contrib
On 10/09/2015 08:57, Sharma Bhupesh wrote:
> So based on my limited understanding, can't the OVMF driver which
> uses features from some GPL based code, carry a dual license (GPL +
> x11 [MIT]),
No, that would require agreement from the original copyright holder,
which you are not going to get.
ARM and RVCT apply to 32-bit code only, so remove any references
to them from the 64-bit version of ElfConvert.c
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
BaseTools/Source/C/GenFw/Elf64Convert.c | 23 +---
1 file changed, 1 insertio
This series implements 4 KB section alignment for ARM, which is required
for supporting the Properties Table memory protection feature on this
architecture.
Patch #1 is a simple cleanup from the copy/paste that created Elf64Convert.c
Patch #2 changes the PE/COFF .data alignment to adhere to the g
Instead of using the ARM builtin linker script for GNU ld, use the
new unified one instead. This will allow us to increase the section
alignment for DXE_RUNTIME_MODULEs, which is a prerequisite for
enabling the UEFIv2.5 Properties Table memory protection feature.
Also, remove the -mword-relocation
In order to support the Properties Table memory protection feature
on 32-bit ARM, build DXE_RUNTIME_MODULE type binaries with 4 KB section
alignment by setting the common-page-size linker command line option.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Ac
There is a special case in the 32-bit ElfConvert code where ARM's
.data is not aligned to section alignment. This is needed to deal
with an ARM RVCT specific size optimization that results in sections
being misaligned with respect to their own alignment. The contents
of these sections are laid out
TestArgv.nsh is a very simple shell script to test how the interpreter parses
the parameters. It uses Argv.efi to dump the parameters passed from the
interpreter.
TestArgv.log is the desired output created by "TestArgv.nsh > TestArgv.log".
Contributed-under: TianoCore Contribution Agreement 1.0
S
Hello Yang and all,
Could you help review this patch? Thank you
[Description]
1. Fix a bug of removing the checkpoint for STATIC modifier
2. Fix a bug of parsing CONST variable
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen
Best Regards,
Chen, Hess
Intel Chi
33 matches
Mail list logo
