On 2014-10-08 18:44:41, Fan, Jeff wrote:
Jordan,
For single patch sync, I agree with using patch+message in the first line
is better for git to summarize the log history. But it is rare case.
On most cases, to reduce the maintain effort (hundreds of patches
for each branch release.
I
Jordan,
We have the following branches totally.
UDK2010: https://svn.code.sf.net/p/edk2/code/branches/UDK2010
UKD2010.SR1 : https://svn.code.sf.net/p/edk2/code/branches/UDK2010.SR1
UDK2014 : https://svn.code.sf.net/p/edk2/code/branches/UDK2014
UDK2014.SP1:
On 10/08/14 23:56, Leif Lindholm wrote:
On 8 October 2014 17:56, Laszlo Ersek ler...@redhat.com wrote:
Please consider adding tags as well.
Good call.
Not added as it isn't a build artefact as such, but if people would
accept taking this patch to begin with, I agree that tags would be a
Hi, Reza and Laszlo
Sorry for late response due to PRC holiday.
For #1 (MdeModulePkg: Check D2H register status in AhciPioTransfer), I have
refined the patch according to Sava's feedback. I will check it in after
passing unit test.
For #6 (MdeModulePkg; IdeMode needs to select master or slave
On 2014-10-09 04:11:31, Fan, Jeff wrote:
Jordan,
We have the following branches totally.
UDK2010: https://svn.code.sf.net/p/edk2/code/branches/UDK2010
Last updated January 2012 :)
UKD2010.SR1 : https://svn.code.sf.net/p/edk2/code/branches/UDK2010.SR1
UDK2014 :
Question:
What must one do to get the DXE core to load a random Firmware Volume (FV)
and any drivers and/or legacy option ROMs (OROMs) it contains.
Background:
I am building a BIOS with EDK2.
I moved a UEFI driver and legacy OROM for a device from the main FV into one
devoted strictly to them
Jordan,
UDK2010.SR1 and UDK2014 are still be updated in 2014.
UDK2014.SP1 will be expected to like all the branches before. There will be
many patches to be waited for syncing.
I have tried to use svn to create/apply patch automatically. But svn
create/apply operations cannot work for the
On Wed, Oct 8, 2014 at 8:33 AM, Leif Lindholm leif.lindh...@linaro.org wrote:
From: Ryan Harkin ryan.har...@linaro.org
From: Ryan Harkin ryan.har...@linaro.org
While edk2 is still maintained in SVN, Many edk2 developers use git
for their main workflow, using the official mirrors.
This
On 10/09/14 14:50, Jordan Justen wrote:
On Wed, Oct 8, 2014 at 8:33 AM, Leif Lindholm leif.lindh...@linaro.org
wrote:
From: Ryan Harkin ryan.har...@linaro.org
From: Ryan Harkin ryan.har...@linaro.org
While edk2 is still maintained in SVN, Many edk2 developers use git
for their main
On Thu, Oct 9, 2014 at 5:58 AM, Laszlo Ersek ler...@redhat.com wrote:
On 10/09/14 14:50, Jordan Justen wrote:
On Wed, Oct 8, 2014 at 8:33 AM, Leif Lindholm leif.lindh...@linaro.org
wrote:
From: Ryan Harkin ryan.har...@linaro.org
From: Ryan Harkin ryan.har...@linaro.org
While edk2 is still
We'll test on Apple systems before the end of this year and I'll keep this
link handy, thanks! It would be nice if there was a vendor page on the
tianocore website with links and instructions for reporting UEFI bugs for
each vendor. Maybe someone can add that?
On Wed, Oct 8, 2014 at 10:32 PM,
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
Maintainers.txt | 176
1 file changed, 176 insertions(+)
create mode 100644 Maintainers.txt
diff --git a/Maintainers.txt
Second comment. StdLib (both) should be moved to Daryl.Mcdaniel
-Original Message-
From: Jordan Justen [mailto:jordan.l.jus...@intel.com]
Sent: Thursday, October 09, 2014 7:21 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH v2] EDK II: Add Maintainers.txt file
EdkShell and EdkShellBin should be tagged as obsolete. We are not actively
supporting them.
Reviewed-by: Jaben Carsey jaben.car...@intel.com
-Original Message-
From: Jordan Justen [mailto:jordan.l.jus...@intel.com]
Sent: Thursday, October 09, 2014 7:21 AM
To:
On Thu, Oct 9, 2014 at 7:27 AM, Carsey, Jaben jaben.car...@intel.com wrote:
EdkShell and EdkShellBin should be tagged as obsolete. We are not actively
supporting them.
Good point. I wonder if we should consider how long they should
continue to live in the EDK II tree if they are obsolete.
On Thu, Oct 9, 2014 at 7:29 AM, Carsey, Jaben jaben.car...@intel.com wrote:
Second comment. StdLib (both) should be moved to Daryl.Mcdaniel
I wondered about that.
According to the wiki history, you added your username to these
packages when adding the packages on the EDKII Packages wiki page
On Thu, Oct 09, 2014 at 06:23:18AM -0700, Jordan Justen wrote:
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..8b6147b
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,20 @@
+*.d
+*.o
+*.pyc
+BaseTools/Source/C/VfrCompile/EfiVfrParser.cpp
On Oct 9, 2014, at 5:18 AM, jim_dai...@dell.com wrote:
Question:
What must one do to get the DXE core to load a random Firmware Volume (FV)
and any drivers and/or legacy option ROMs (OROMs) it contains.
The DXE Core dispatcher has a protocol notify event,
On Oct 8, 2014, at 3:43 PM, J. E. nszero...@hotmail.com wrote:
I always use the last handle in the handle list, it works on 100% of the PC's
Ive tested. Some PC's have 3 or 4 handles.
However I'd prefer to do it the correct way so I will query the protocol as
suggested.
I’ve put one
Hi,
Our project needs to port existing UEFI diag application code from X86 to Arm
A57 core (AArch64),
Current codebase is using EDK Toolkit 2, so we need to move to EADK. Does EADK
have
AArch64 support? I searched documents and email threads but can not find much
info on this.
Thanks,
Joey
I noticed that in Library/SynchronizationLib.h the Interlocked
functions (e.g. InterlockedIncrement) don't specify that the Value is
volatile, but the InternalSync* functions they call in
Synchronization.c _are_ specified as taking a volatile integer.
Is that due to the limitation imposed by the
Joey,
Don't know about EADK but go back in the mailing list archive and look for
EDK2 GenFw. I posted some info on 9/17 about getting drivers and applications
(MdeModule/Application/HelloWorld) to build for AArch64.
I've ported several of our drivers and apps (using the StdLib package) to
On Oct 9, 2014, at 11:24 AM, Bruce Cran bruce.c...@gmail.com wrote:
I noticed that in Library/SynchronizationLib.h the Interlocked
functions (e.g. InterlockedIncrement) don't specify that the Value is
volatile, but the InternalSync* functions they call in
Synchronization.c _are_ specified as
On Thu, Oct 9, 2014 at 1:29 PM, Andrew Fish af...@apple.com wrote:
If you add volatile to Value then the loop
will check the value on every iteration. If you just use the return value of
the functions to return the value, you will always get the correct answer.
My question was really about
On Oct 9, 2014, at 1:15 PM, Bruce Cran bruce.c...@gmail.com wrote:
On Thu, Oct 9, 2014 at 1:29 PM, Andrew Fish af...@apple.com wrote:
If you add volatile to Value then the loop
will check the value on every iteration. If you just use the return value of
the functions to return the value,
Can anyone assist me on root causing this build failure?
: error C0DE: Unknown fatal error when processing
[w:\xxxPlatformPkg\xxxPlatformPkg.dsc]
(Please send email to
edk2-buildtools-de...@lists.sourceforge.netmailto:edk2-buildtools-de...@lists.sourceforge.net
for help, attaching following
On Thu, Oct 9, 2014 at 7:45 AM, Leif Lindholm leif.lindh...@linaro.org wrote:
On Thu, Oct 09, 2014 at 06:23:18AM -0700, Jordan Justen wrote:
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..8b6147b
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,20 @@
+*.d
+*.o
27 matches
Mail list logo
