Hess:
The patch is good.
Reviewed-by: Gao, Liming
From: Chen, Hesheng [mailto:hesheng.c...@intel.com]
Sent: Tuesday, August 19, 2014 2:44 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch][Basetools]Fix a build failure in Linux
Hello all,
Could you help review this patch?
This p
On Mon, Aug 18, 2014 at 11:43 PM, Chen, Hesheng wrote:
> Hello all,
>
> Could you help review this patch?
Hess, I tested the first two parts of the patch earlier. What do the
last two patch hunks do?
> This patch is going to fix a build failure in Linux system.
Is this the commit message? If so
Justen,
The last two parts are accidently included in last patch. They should work with
other code in my local code so I remove them since they will also cause build
failure.
I will add more description on commit message.
Best Regards,
Chen, Hess
Intel China Software Center
Tel: +86-21-6116-6740
No,
revision 15831 is still not working in OSX.
On 19.08.2014, at 12:07, Gao, Liming wrote:
> Hess:
> The patch is good.
> Reviewed-by: Gao, Liming
>
> From: Chen, Hesheng [mailto:hesheng.c...@intel.com]
> Sent: Tuesday, August 19, 2014 2:44 PM
> To: edk2-devel@lists.sourceforge.net
> Subje
Could you show the error message?
From: Sergey Isakov [mailto:isakov...@bk.ru]
Sent: Tuesday, August 19, 2014 5:05 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch][Basetools]Fix a build failure in Linux
No,
revision 15831 is still not working in OSX.
On 19.08.2014, at 12:07,
Hi Sergey,
Please help to review this patch which fix the typo about word “hanlde”, also
fix another three one in SourceLevelDebugPkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong mailto:eric.d...@intel.com>>
Thanks,
Eric
From: Sergey Isakov [mailto:isak
For example message
make: *** No rule to make target `fds'. Stop.
On 19.08.2014, at 13:05, Sergey Isakov wrote:
> No,
> revision 15831 is still not working in OSX.
>
> On 19.08.2014, at 12:07, Gao, Liming wrote:
>
>> Hess:
>> The patch is good.
>> Reviewed-by: Gao, Liming
>>
>> From: Chen
In file IntelFrameworkModulePkg/Library/GenericBdsLib/BdsConsole.c
cat * | grep hanlde
On OUT, new console hanlde in system table.
On OUT, new console protocol on new console hanlde
in system table.
Sergey
On 19.08.2014, at 13:1
Has include in this patch:
- On OUT, new console hanlde in system table.
+ On OUT, new console handle in system table.
@param ProtocolInterface On IN, console protocol on console handle in
System Table to be checked.
-
Sorry, it was with old build.py. With all new files all works but as I see the
syntax of fdf files become more strict
Previously I have
--
!if ($(ARCH) == X64)
[FV.DuetEfiMainFvX64]
!elseif ($(ARCH) == IA32)
[FV.DuetEfiMainFvIA32]
!endif
--
now this is a syntax error
GenFds.py...
: error C0DE: Tools code failure
Please send email to edk2-buildtools-de...@lists.sourceforge.net for
help, attaching following call stack trace!
Traceback (most recent call last):
File
"/tmp/workspace/workspace/ap-uefi-master/EDK2_PLATFORM/ArmRealViewEb-RTSM-A9
x2/lab
Thanks for reporting the issue. I committed a fix in SVN rev15837.
From: Kirkendall, Garrett [mailto:garrett.kirkend...@amd.com]
Sent: 14 August 2014 13:46
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] AARCH64 ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c
question. TCR adjusted but not
Hi Siyuan,
When I add that option to the file, UEFI complains "PXE-E16: No offer
received.\n".
I can see that DHCP server did reply to the request and the packet is received
but UEFI is not happy.
Here is the packet exchange.
12:36:23.621851 12:12:12:12:12:12 (oui Unknown) > Broadcast, etherty
The line endings & trailing space issues have been addressed in SVN rev15832
& rev15833.
Our build infrastructure has been updated to test for malicious line
endings/trailing spaces in the ARM packages.
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: 09
Hi Siyuan,
I am using Tianocore EDK2 2.4 and shell is 2.0 an I am running on ARM core.
Can you explain how the IP stack works ? In a few sentences. That will help me
debug this better.
Thanx.
From: siyuan...@intel.com
To: nd6...@hotmail.com; edk2-devel@lists.sourceforge.net
Subject: RE: [edk2] M
The attached patch should fix the issue.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: 19 August 2014 15:31
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch][Basetools]Fix a
I confirm this error too. It looks the recent BaseTools requires a '!else'
to interpret the file correctly ...
From: Sergey Isakov [mailto:isakov...@bk.ru]
Sent: 19 August 2014 12:44
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch][Basetools]Fix a build failure in Linux
Sor
Looks good.
Reviewed-by: Jaben Carsey
From: Qiu, Shumin
Sent: Monday, August 18, 2014 7:25 PM
To: Carsey, Jaben
Cc: edk2-devel@lists.sourceforge.net
Subject: [edk2][Patch][ShellPkg]ShellPkg: uni files typo fix
Importance: High
Hi Jaben,
Can you help to review this patch.
Fix typo in 'uni' file
Erik,
Can you review?
ShellPkg: Refactor string manipulation in UefiShellLib command
This patch replaces StrCpy with StrnCpy or refactors out the usage of StrCpy
through some other means.
This patch replaces StrCat with StrnCat or refactors out the usage of StrCat
through some other means.
Erik,
Can you review?
ShellPkg: Check while string up to space, not the character
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey
UefiShellLib.c.patch
Description: UefiShellLib.c.patch
---
On 08/19/14 03:24, Dong, Eric wrote:
> Hi Laszlo,
>
> I do some changes for this library to follow EDKII coding style, please help
> to review it.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Eric Dong
>
> Thanks,
> Eric
>
>
> BaseOrderedCollectionRedBlackTree
Scott,
You are right. The additional defines in arith.h (other than the "Long" macro
for GCC) are not used by the gdtoa library. They reflect internal assumptions
of the library and, as such, are not really necessary for public consumption.
Daryl McDaniel
"It is the mark of an educated mind
This patch is WITHDRAWN.
As pointed out by Scott Duplichan, the additional entries in arith.h are not
used by existing code and are of no use outside of the "private" gdtoa library.
These changes will NOT be committed to SVN.
My most sincere thanks to everyone that has provided review comments.
Because if statement is always FALSE.
On 19 авг. 2014 г., at 19:49, Olivier Martin wrote:
> I confirm this error too. It looks the recent BaseTools requires a ‘!else’ to
> interpret the file correctly ...
>
> From: Sergey Isakov [mailto:isakov...@bk.ru]
> Sent: 19 August 2014 12:44
> To: edk
Yes that’s right. I have just waste another couple of hours with this buggy
“!if” support.
From: Sergey Isakov [mailto:isakov...@bk.ru]
Sent: 19 August 2014 18:57
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch][Basetools]Fix a build failure in Linux
Because if statement i
Hello Mike,
I am surprised to hear about a source level debug problem
with static functions. The Microsoft build tools have an
optimization that can give the appearance of code stepping
through the incorrect function. Here is an example:
static int f1 (void) {return 2;}
static int f2 (voi
Reviewed-by: Erik Bjorge
From: Carsey, Jaben
Sent: Tuesday, August 19, 2014 9:26 AM
To: Bjorge, Erik C
Cc: edk2-devel@lists.sourceforge.net; Carsey, Jaben
Subject: ShellPkg: Refactor string manipulation in UefiShellLib command
Erik,
Can you review?
ShellPkg: Refactor string manipulation in U
Reviewed-by: Erik Bjorge
From: Carsey, Jaben
Sent: Tuesday, August 19, 2014 9:30 AM
To: Bjorge, Erik C
Cc: edk2-devel@lists.sourceforge.net; Carsey, Jaben
Subject: ShellPkg: Check while string up to space, not the character
Erik,
Can you review?
ShellPkg: Check while string up to space,
r15816: "This patch is going to retire the top level makefile on
BaseTools for supporting a pure binary build without any complier."
r15831: "This patch is going to fix a build failure (running of
GenFds) in Linux system caused by patch at r15816."
Something in these changes causes !if processing
Hi Siyuan,
The reason that the reply is missing is because when
the reply is received and "Ping6OnEchoReplyReceived" is called, it kicks
out in the call to "Ping6MatchEchoReply". The reason that reply does
not match because there is no entry in the TxList when reply is
received.
In the functi
Jordan,
Olivier sent in two patches for an issue related to this. Is this reversion
instead of that patch?
-Jaben
> -Original Message-
> From: Jordan Justen [mailto:jordan.l.jus...@intel.com]
> Sent: Tuesday, August 19, 2014 12:48 PM
> To: edk2-devel@lists.sourceforge.net
> Subject: [e
It is even worst. As Sergey said, the !if statement is always FALSE with the
latest BaseTools changes.
So this statement: !if ("$(ARCH)" == "X64") seems to always be false even if
you build for X64.
From: Jordan Justen [jordan.l.jus...@intel.com]
Sent: 19
I only fixed one issue (Linux build issue). But I have not fixed the "!if"
condition. I only confirmed this issue just before leaving the office. And I
would prefer to not have to fix it myself if possible.
From: Carsey, Jaben [jaben.car...@intel.com]
Sent
Please review the attached patch.
This fix moves the initialization of mHandleParsingHiiHandle to the functions
that require the handle parsing strings. Reduces code bloat for modules that
ultimately link against HandleParsingLib because of other dependencies.
Thanks,
Chris
ShellPkg:
Gotcha. That clarifies it.
> -Original Message-
> From: Olivier Martin [mailto:olivier.mar...@arm.com]
> Sent: Tuesday, August 19, 2014 2:14 PM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [PATCH] BaseTools: Revert r15816 and r15831 to fix !if in
> .fdf
>
> I only fixed o
All,
I have a system with a serial port on it over which I would like to send some
information.
This is a real serial port, not a USB to serial module.
The serial port works perfectly as COM1 in Windows7
When boot my USB key to FreeDOS it does not work right away.
If I use debug to write 0xF8 a
On 08/19/2014 01:20 PM, Scott Duplichan wrote:
> Hello Mike,
>
> I am surprised to hear about a source level debug problem
> with static functions. The Microsoft build tools have an
> optimization that can give the appearance of code stepping
> through the incorrect function. Here is an example:
>
Hi Tim,
I agree with your proposal for #1. - See highlighting in the original RFC text
(add and delete).
For #2 & 3, After looking through the UEFI specifications, the escape character
sequences are not defined for the code, so I have removed the majority of them.
The only ones that are now lis
Scott,
An example of a source level debug issue that can occur when all optimizations
are disabled is as follows:
int f1 (void) {return 2;}
static int f2 (void) {return 3;}
int f3 (void) {return 4;}
int main (int argc, char *argv [])
{
if (argc ==1) return f1 ();
if (argc ==2) return
Reviewed-by: Jaben Carsey
15840.
From: Phillips, Chris J (Plano, TX) [mailto:chr...@hp.com]
Sent: Tuesday, August 19, 2014 3:17 PM
To: Carsey, Jaben; edk2-devel@lists.sourceforge.net
Subject: ShellPkg: Fixes for timezone handling and 'date -sfo'
Importance: High
Please review the attached patc
Reviewed-by: Jaben Carsey
15841
From: Phillips, Chris J (Plano, TX) [mailto:chr...@hp.com]
Sent: Tuesday, August 19, 2014 2:35 PM
To: Carsey, Jaben; edk2-devel@lists.sourceforge.net
Subject: ShellPkg: Move mHandleParsingHiiHandle init out of the constructor
Importance: High
Please review the a
Larry -
Thanks for the cleanup.
Let me see whether our current extensions would be appropriate for a proposal.
If not, I'll find something that is appropriate.
Tim
From: Hauch, Larry [mailto:larry.ha...@intel.com]
Sent: Tuesday, August 19, 2014 2:54 PM
To: edk2-devel@lists.sourceforge.net
Subj
Lee,
Could you please review the attached patch. Both the full file and a patch
file are attached.
AppPkg/Applications/Sockets/TftpServer: Make the include file names match the
case of the files in the file system.
Change "#include " to "#include ".
Contributed-under: TianoCore Contribution
By using 'bits 16', we can write code for 16-bit use the actual
assembly syntax rather than 'DB' and sometimes writing code with
seemingly incorrect operands because we know it will run correctly
when the processor is running in 16-bit mode.
Contributed-under: TianoCore Contribution Agreement 1.0
This series:
* Adds support for creating object files from .nasm source files to
allow NASM source files to be linked into libraries and images
* Adds NASM source files for Thunk16 on IA32 and X64
* Convert BaseLib to use NASM Source Files for Thunk16 rather than
GNU Assembler (.S) files
Convert remaining 'DB' code to assembly code by:
* Move instruction immediate data labels to end of instruction
* Use strict keyword to make sure immediate data size is not optimized
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
MdePkg/Library/BaseLib/I
This is a translation of X64/Thunk16.asm to NASM.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
MdePkg/Library/BaseLib/BaseLib.inf | 2 +-
MdePkg/Library/BaseLib/X64/Thunk16.nasm | 334
2 files changed, 335 insert
This is a translation of Ia32/Thunk16.asm to NASM.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
MdePkg/Library/BaseLib/BaseLib.inf | 2 +-
MdePkg/Library/BaseLib/Ia32/Thunk16.nasm | 278 +++
2 files changed, 279 inse
Some compilers may define __USER_LABEL_PREFIX__ to determine the
prefix used with ASM_PFX. Otherwise, IA32 will use a single underscore
'_' character, and all other architectures will use an empty prefix.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
Md
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
BaseTools/Conf/build_rule.template | 15 +++
BaseTools/Conf/tools_def.template | 2 --
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/BaseTools/Conf/build_rule.template
b/BaseT
Note: Only tested with the GCC49 toolchain so far.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
BaseTools/Conf/tools_def.template | 285 +-
1 file changed, 280 insertions(+), 5 deletions(-)
diff --git a/BaseTools/Co
http://www.nasm.us/doc/nasmdoc3.html#section-3.9
A local label is a label beginning with the period, and it's actual
name is prefixed by the previous non-local label.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen
---
MdePkg/Library/BaseLib/Ia32/Thunk16.nas
You may check if SerialIo protocol is generated on your platform. Serial driver
is loaded but may be not started.
You could run dh -p SerialIo in shell to check.
From: lowell_den...@dell.com [mailto:lowell_den...@dell.com]
Sent: Wednesday, August 20, 2014 5:48 AM
To: edk2-devel@lists.sourceforge
Hi, Gurinder
I think you can just copy the whole EFI_PXE_BASE_CODE_PACKET to a
EFI_DHCP4_PACKET.
CopyMem (&Offer->Dhcp4, ProxyOffer. Raw, sizeof (ProxyOffer. Raw));
Offer-> Length = sizeof (ProxyOffer. Raw);
Offer-> Size = Offer-> Length + 2 * sizeof (UINT32);
Best Regards,
Siyuan
-Origina
Jordan:
Minor comments. NASM version could be 2.0.3 or later.
Thanks
Liming
-Original Message-
From: Jordan Justen [mailto:jordan.l.jus...@intel.com]
Sent: Wednesday, August 20, 2014 7:58 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH 2/8] BaseTools/build_rule: Add .na
Chris,
I think it's a bug of Ping command. The reply message may come before or after
the Transmit function return, so the caller should be ready to handle the reply
message before calling Transmit function. You can move the InsertTailList to
the front of Transmit and have a try.
Best Regards
Hello Jordan and all,
I think we should not revert the patch since only when problem happens then we
can fix them. I will try my best to provide responses quickly.
Actually I have root caused the issue: there is a difference mode between Linux
and Windows for handling popen() parameter. By my tes
Hi, Chris
In your DHCP Offer message, the client IP is AC191165 and next server IP
(treated as TFTP boot server in PXE) is 0A126836. The client and tftp server
locate in different subnet, but there is no gateway options in this offer. I
think that's why PXE client drop this offer message.
12:
On 2014-08-19 19:07:26, Chen, Hesheng wrote:
> Hello Jordan and all,
> I think we should not revert the patch since only when problem
> happens then we can fix them.
I do agree with this up to a point. It is nice to keep something in
place and fix it quickly if possible.
But, if we are keeping pe
Thanks! I will test.
May be add check for minimum NASM version?
On 20 авг. 2014 г., at 3:57, Jordan Justen wrote:
> Note: Only tested with the GCC49 toolchain so far.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jordan Justen
> ---
> BaseTools/Conf/tools_def.tem
Reviewed-by: Ruiyu Ni
From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Tuesday, August 19, 2014 5:20 PM
To: Sergey Isakov
Cc: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] IntelFrameworkModulePkg/SourceLevelDebugPkg : Fix
comment typos
Hi Sergey,
Please help to review this patch
Hi Jordan,
The issue has been root caused. Before retiring top level makefile, the GenFds
command was executed by make fds, but after the change, we call GenFds command
directly. The -D option passed to Genfds is encapsulated by quotes which is
remove automatically by shell, that's why building
Brian J. Johnson [mailto:bjohn...@sgi.com] wrote:
[...]
]> In this case, even the Microsoft Visual Studio debugger gives
]> the appearance of stepping through the 'wrong' function. But
]> the linker /verbose output confirms the debugger is correct:
]>
]> Selected symbol:
]> _f1 fr
I confirm, it works.
Thank you!
--
!if ($(ARCH) == X64)
--
On 20.08.2014, at 8:50, Liu, Yingke D wrote:
> Hi Jordan,
>
> The issue has been root caused. Before retiring top level makefile, the
> GenFds command was executed by make fds, but after the change, we call GenFds
> command dir
On Tue, Aug 19, 2014 at 6:59 PM, Gao, Liming wrote:
> Jordan:
> Minor comments. NASM version could be 2.0.3 or later.
Ok.
I notice for IASL, we specify a single version: v20101013.
Should we consider moving IASL to the new 'Other Supported Tools'
rather than duplicating it for each toolchain
On Tue, Aug 19, 2014 at 9:50 PM, Liu, Yingke D wrote:
> Hi Jordan,
>
> The issue has been root caused.
Ah. Good to hear. So, will you be posting this patch for review with a
commit message?
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format
Thanks Dennis and Hess!
-Jord
66 matches
Mail list logo
