[edk2] [Patch][Basetools]Fix a build failure in Linux

[Chen, Hesheng]

Hello all,
Could you help review this patch?


This patch is going to fix a build failure in Linux system.


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen mailto:hesheng.c...@intel.com>>


Best Regards,
Chen, Hess
Intel China Software Center
Tel: +86-21-6116-6740
Email: hesheng.c...@intel.com



build.patch
Description: build.patch
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Redundant codes in MdeModulePkg PartitionDxe

[Tian, Feng]

Agree.

Reviewed-By: Feng Tian 

Thanks
Feng

From: Sergey Isakov [mailto:isakov...@bk.ru]
Sent: Tuesday, August 19, 2014 11:46
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Redundant codes in MdeModulePkg PartitionDxe

Dear MdeModulePkg maintainers,

I think this codes in MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c:168
-
  if (EFI_ERROR (Status)) {
return Status;
  }

  return EFI_SUCCESS;
}
---
may be safely reduced to
-
 return Status;
}


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Sergey Isakov mailto:isakov...@bk.ru>>
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Patch for review: StdLibPrivateInternalFiles/Include/{Ia32, X64}/arith.h

[Scott Duplichan]

Mcdaniel, Daryl [mailto:daryl.mcdan...@intel.com] wrote:

]Please review the attached changes.
]
]StdLibPrivateInternalFiles/Include/{Ia32,X64}/arith.h: Use programmatically 
]generated arith.h files for greater compatibility with
the gdtoa library in ]StdLib.
]
]Contributed-under: TianoCore Contribution Agreement 1.0
]Signed-off-by: Daryl McDaniel 
]Reviewed-by: 
]
]Thank You,
]Daryl McDaniel

Hello Daryl,

In what way does this change provide greater compatibility
with the gdtoa library? The gdtoa library is documented as
for internal use by stdlib. Yet stdlib doesn't use the new
defines added by this patch.

Thanks,
Scott


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg: refine code for BaseOrderedCollectionRedBlackTreeLib

[Kinney, Michael D]

Scott,

We have seen issues with some source level debuggers when using static 
functions.  I some cases, it will show the wrong function name when stepping 
through a static function.  Unless there is a really good reason, we prefer to 
not use static to improve debugability.

Public functions are declared in the library class include file.  I agree that 
making it obvious that a function in a library implementation is an internal 
worker function is very helpful when looking at the source code.

Can you provide an example where use of 'static' improves optimization?

Thanks,

Mike

-Original Message-
From: Scott Duplichan [mailto:sc...@notabs.org] 
Sent: Monday, August 18, 2014 8:09 PM
To: edk2-devel@lists.sourceforge.net; 'Laszlo Ersek'
Subject: Re: [edk2] [PATCH] MdePkg: refine code for 
BaseOrderedCollectionRedBlackTreeLib

Dong, Eric [mailto:eric.d...@intel.com] 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

Hello Eric,

A couple of questions:
1) Why convert static functions to global functions?
2) Where is this explained in an EDKII coding document?

I ask because I consider declaring a local helper
function as static a courtesy to the reader of the code.
It keeps the reader from having to search other files to
know if the function is called elsewhere. Declaring a
private function as static can also help the build tools
optimize in some cases.

Thanks,
Scott





--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/ArchExceptionHandler.c: Fix comment typos

[Sergey Isakov]

Hi,

I also find the word “hanlde” in the
edk2/IntelFrameworkModulePkg/Library/GenericBdsLib/
Please also fix

On 08 июля 2014 г., at 13:17, chen.fan.f...@cn.fujitsu.com wrote:

> On Tue, 2014-07-08 at 07:30 +, Fan, Jeff wrote: 
>> Hi, Chen
>> 
>> Thanks your fix.
>> 
>> I will help to check-in your fix.  I also noticed 2 same typos in other 
>> files in attached patch file.
>> 
>> Reviewed-by: Jeff Fan 
> 
> Hi, Jeff
> 
>   Thanks for your review. I also found there were more typos in
> spelling the word "handler", please see the attached file and 
> check-in them too.
> 
> Thanks,
> Chen
> 
> 
>> 
>> Thanks!
>> Jeff
>> 
>> -Original Message-
>> From: Chen Fan [mailto:chen.fan.f...@cn.fujitsu.com] 
>> Sent: Tuesday, July 08, 2014 2:05 PM
>> To: edk2-devel@lists.sourceforge.net
>> Subject: [edk2] [PATCH] UefiCpuPkg/ArchExceptionHandler.c: Fix comment typos
>> 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Chen Fan 
>> ---
>> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git 
>> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c 
>> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
>> index 74ad138..ee16ea8 100644
>> --- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
>> +++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
>> @@ -1,5 +1,5 @@
>> /** @file
>> -  x64 CPU Exception Hanlder.
>> +  x64 CPU Exception Handler.
>> 
>>   Copyright (c) 2012 - 2013, Intel Corporation. All rights reserved.
>>   This program and the accompanying materials
> 
> <0001-Fix-comment-typos.patch>--
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] PXE Boot Error

[Fu, Siyuan]

Hi, Chris

Just add "option vendor-class-identifier "PXEClient";" to your dhcpd.conf file, 
it will enable option 60.

Best Regards,
Siyuan


From: Chris Cuthbert [mailto:nd6...@hotmail.com]
Sent: Tuesday, August 19, 2014 4:20 AM
To: Edk2 Devel
Subject: [edk2] PXE Boot Error

Hi All,

I am trying to boot an ARM core using PXE boot and I am following the steps 
mentioned in this Linaro wiki 
(https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/UEFI_Network_Booting). 
Most importantly, the DHCP server configuration part of it. It says:

Add these lines to /etc/dhcp/dhcpd.conf:

allow booting;

allow bootp;



subnet 192.168.0.0 netmask 255.255.255.0 {

  range 192.168.0.3 192.168.0.253;

}



host rtsm {

  hardware ethernet 00:02:f7:ef:5c:f5;

  fixed-address 192.168.0.20;

  option host-name "rtsm";

  next-server 192.168.0.1;

  filename "efi/grub.efi";

}

When I do configure the UEFI boot manager to boot, I get error in 
"PxeBcSelectBootPrompt" function at the following check:

  if (Packet->OfferType != DHCP4_PACKET_TYPE_PXE10) {
return EFI_NOT_FOUND;
  }


Seems like the DHCP server is offering "DHCP4_PACKET_TYPE_DHCP_ONLY" and not 
"DHCP4_PACKET_TYPE_PXE10".
After looking around, it seems I need to enable option 060 in DHCP server. I 
have not been able to find a way to configure
the DHCP to allow PXE boot. The most popular configuration change suggested was 
"option vendor-class-identifier "PXEClient";".

Any suggestions ?
Thanx.

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Missing Ping Reply

[Fu, Siyuan]

Hi, Chris

I still can't reproduce this issue on my side, what's the EDKII and shell 
revision you are using? Can you reproduce it on other NIC, like NT32?

Best Regards,
Siyuan

From: Chris Cuthbert [mailto:nd6...@hotmail.com]
Sent: Tuesday, August 19, 2014 10:22 AM
To: Fu, Siyuan; Edk2 Devel
Subject: RE: [edk2] Missing Ping Reply

Looks okay.

Ip4InstanceDeliverPacket: Before SignalEvent Token->Status 0x0
Ip4InstanceDeliverPacket: Before SignalEvent Token->Packet.RxData->HeaderLength 
0x14
Ip4InstanceDeliverPacket: Before SignalEvent Token->Packet.RxData->DataLength 
0x10



From: siyuan...@intel.com
To: nd6...@hotmail.com; 
edk2-devel@lists.sourceforge.net
Subject: RE: [edk2] Missing Ping Reply
Date: Tue, 19 Aug 2014 01:20:55 +
Hi, Chris

DispatchDpc returns NOT_FOUND is correct. Ping command doesn't use DPC so the 
Rx event's callback function will be invoked immediately after SingalEvent(). 
Did you check the Token->Status and Token->Packet.RxData in 
Ip4InstanceDeliverPacket() before SingalEvent?

Best Regards,
Siyuan

From: Chris Cuthbert [mailto:nd6...@hotmail.com]
Sent: Tuesday, August 19, 2014 1:18 AM
To: Fu, Siyuan; Edk2 Devel
Subject: RE: [edk2] Missing Ping Reply

Hi Siyuan,

Here is the log again. Looks like NOT_FOUND is being returned by DispatchDpc.
Thanx.


Shell> ping -n 1 172.25.17.100
Ping StartsAPing 172.25.17.100 16 data bytes
NicVfTransmit (ARP request)
NicVfGetPacket   (ARP reply)
NicVfTransmit  (Ping 
request)
NicVfGetPacket(Ping reply)
Ip4AccpetFrame EFI_IP_PROTO_ICMP
Ip4IcmpHandle ICMP_QUERY_MESSAGE
Ip4ProcessIcmpQuery Ip4Demultiplex
Ip4Demultiplex Ip4InterfaceEnquePacket
Ip4Demultiplex Ip4InterfaceEnquePacket
Ip4Demultiplex Ip4InterfaceDeliverPacket
Ip4InstanceDeliverPacket: Before SignalEvent
Ip4InstanceDeliverPacket: After SignalEvent 0x0
Ip4Demultiplex Ip4InterfaceDeliverPacket
Ip4AccpetFrame: Before DispatchDpc
Ip4AccpetFrame: After DispatchDpc 0x800E

1 packets transmitted, 0 received, 100% packet loss, time 0ms

From: siyuan...@intel.com
To: edk2-devel@lists.sourceforge.net; 
nd6...@hotmail.com
Subject: RE: [edk2] Missing Ping Reply
Date: Mon, 18 Aug 2014 06:14:08 +
Hi, Chris

Could you please help to check the return status of the gBS->SignalEvent and 
DispatchDpc (see attached patch file)?  Ping's call back function should be 
invoked when IP4 driver calling SignalEvent or DispatchDpc (mostly after 
SingalEvent if you execute the ping command in EFI shell).

Best Regards,
Siyuan

From: Chris Cuthbert [mailto:nd6...@hotmail.com]
Sent: Sunday, August 17, 2014 11:14 AM
To: Edk2 Devel
Subject: [edk2] Missing Ping Reply

Hi All,

I am implementing a UEFI driver for a network controller and I am producing 
Simple Network Protocol(SNP). To test this, I am using the 'ping' shell 
command. The problem is that I never get the first ping reply. I have debugged 
this all the way up the IPv4 stack and I can see that reply packet is being 
passed up but the first packet never reaches the 'ping' command. Logs below. 
From the ping source code it looks like it is creating an event to get a call 
back on reply packet and as part of the call back, it registers for event again 
if more replies are expected. But the first reply never kicks the call back 
function.
Any suggestions ?
Thanx.

Shell> ping -n 1 172.25.17.100
Ping StartsAPing 172.25.17.100 16 data bytes
NicVfTransmit  (ARP 
request)
NicVfGetPacket(ARP 
reply)
NicVfTransmit  (Ping 
packet)
NicVfGetPacket(Ping 
reply)
Ip4AccpetFrame EFI_IP_PROTO_ICMP(ICMP recognized)
Ip4IcmpHandle ICMP_QUERY_MESSAGE
Ip4ProcessIcmpQuery Ip4Demultiplex(Ip4Demultiplex function 
call)
Ip4Demultiplex Ip4InterfaceEnquePacket
Ip4Demultiplex Ip4InterfaceEnquePacket
Ip4Demultiplex Ip4InterfaceDeliverPacket
Ip4Demultiplex Ip4InterfaceDeliverPacket

1 packets transmitted, 0 received, 100% packet loss, time 0ms

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Redundant codes in MdeModulePkg PartitionDxe

[Sergey Isakov]

Dear MdeModulePkg maintainers,

I think this codes in MdeModulePkg/Universal/Disk/PartitionDxe/Partition.c:168
—
  if (EFI_ERROR (Status)) {
return Status;
  }

  return EFI_SUCCESS;  
}
———
may be safely reduced to
-
 return Status;
}


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Sergey Isakov --
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg: refine code for BaseOrderedCollectionRedBlackTreeLib

[Scott Duplichan]

Dong, Eric [mailto:eric.d...@intel.com] 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

Hello Eric,

A couple of questions:
1) Why convert static functions to global functions?
2) Where is this explained in an EDKII coding document?

I ask because I consider declaring a local helper
function as static a courtesy to the reader of the code.
It keeps the reader from having to search other files to
know if the function is called elsewhere. Declaring a
private function as static can also help the build tools
optimize in some cases.

Thanks,
Scott





--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] How to Parse DHCP Options

[Gurinder Singh]

Hi guys,

I'm writing a bootloader that is downloaded by the client over PXE and
executed. In the bootloader I need to extract the value of some DHCP
options from the last boot server ACK message. I understand that this
message is available as EFI_PXE_BASE_CODE_PROTOCOL->Mode.ProxyOffer.
My question is what is the best way to parse out a DHCP option from
this ProxyOffer object?

I noticed that EFI_DHCP4_PROTOCOL offers a Parse() method. This would
be perfectly suited except it takes an EFI_DHCP4_PACKET object whereas
the ProxyOffer is of the type EFI_PXE_BASE_CODE_PACKET. Perhaps
there's an easy way to convert the latter to the former without having
to write too much code by hand. If yes, could you please point me to
it?

Thanks in advance.

Cheers,
Gurinder

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Missing Ping Reply

[Chris Cuthbert]

Looks okay.
Ip4InstanceDeliverPacket: Before SignalEvent Token->Status 
0x0Ip4InstanceDeliverPacket: Before SignalEvent 
Token->Packet.RxData->HeaderLength 0x14Ip4InstanceDeliverPacket: Before 
SignalEvent Token->Packet.RxData->DataLength 0x10

From: siyuan...@intel.com
To: nd6...@hotmail.com; edk2-devel@lists.sourceforge.net
Subject: RE: [edk2] Missing Ping Reply
Date: Tue, 19 Aug 2014 01:20:55 +









Hi, Chris
 
DispatchDpc returns NOT_FOUND is correct. Ping command doesn’t use DPC so the 
Rx event’s callback function will be invoked immediately after SingalEvent().
 Did you check the Token->Status and Token->Packet.RxData in 
Ip4InstanceDeliverPacket() before SingalEvent?
 
Best Regards,
Siyuan
 


From: Chris Cuthbert [mailto:nd6...@hotmail.com]


Sent: Tuesday, August 19, 2014 1:18 AM

To: Fu, Siyuan; Edk2 Devel

Subject: RE: [edk2] Missing Ping Reply


 

Hi Siyuan,



Here is the log again. Looks like NOT_FOUND is being returned by DispatchDpc.

Thanx.





Shell> ping -n 1 172.25.17.100

Ping StartsAPing 172.25.17.100 16 data bytes

NicVfTransmit (ARP request)

NicVfGetPacket   (ARP reply)

NicVfTransmit  (Ping 
request)

NicVfGetPacket(Ping reply)

Ip4AccpetFrame EFI_IP_PROTO_ICMP

Ip4IcmpHandle ICMP_QUERY_MESSAGE

Ip4ProcessIcmpQuery Ip4Demultiplex

Ip4Demultiplex Ip4InterfaceEnquePacket

Ip4Demultiplex Ip4InterfaceEnquePacket

Ip4Demultiplex Ip4InterfaceDeliverPacket

Ip4InstanceDeliverPacket: Before SignalEvent

Ip4InstanceDeliverPacket: After SignalEvent 0x0

Ip4Demultiplex Ip4InterfaceDeliverPacket

Ip4AccpetFrame: Before DispatchDpc

Ip4AccpetFrame: After DispatchDpc 0x800E



1 packets transmitted, 0 received, 100% packet loss, time 0ms




From:
siyuan...@intel.com

To: edk2-devel@lists.sourceforge.net;
nd6...@hotmail.com

Subject: RE: [edk2] Missing Ping Reply

Date: Mon, 18 Aug 2014 06:14:08 +

Hi, Chris
 
Could you please help to check the return status of the gBS->SignalEvent and 
DispatchDpc (see attached patch file)?  Ping’s call back function
 should be invoked when IP4 driver calling SignalEvent or DispatchDpc (mostly 
after SingalEvent if you execute the ping command in EFI shell).
 
Best Regards,
Siyuan
 


From: Chris Cuthbert [mailto:nd6...@hotmail.com]


Sent: Sunday, August 17, 2014 11:14 AM

To: Edk2 Devel

Subject: [edk2] Missing Ping Reply


 

Hi All,

 


I am implementing a UEFI driver for a network controller and I am producing 
Simple Network Protocol(SNP). To test this, I am using the 'ping' shell 
command. The problem is that
 I never get the first ping reply. I have debugged this all the way up the IPv4 
stack and I can see that reply packet is being passed up but the first packet 
never reaches the 'ping' command. Logs below. From the ping source code it 
looks like it is creating
 an event to get a call back on reply packet and as part of the call back, it 
registers for event again if more replies are expected. But the first reply 
never kicks the call back function.


Any suggestions ?


Thanx.


 



Shell> ping -n 1 172.25.17.100


Ping StartsAPing 172.25.17.100 16 data bytes


NicVfTransmit  (ARP 
request)


NicVfGetPacket(ARP 
reply)


NicVfTransmit  (Ping 
packet)


NicVfGetPacket(Ping 
reply)


Ip4AccpetFrame EFI_IP_PROTO_ICMP(ICMP recognized)


Ip4IcmpHandle ICMP_QUERY_MESSAGE


Ip4ProcessIcmpQuery Ip4Demultiplex(Ip4Demultiplex function 
call)


Ip4Demultiplex Ip4InterfaceEnquePacket


Ip4Demultiplex Ip4InterfaceEnquePacket


Ip4Demultiplex Ip4InterfaceDeliverPacket


Ip4Demultiplex Ip4InterfaceDeliverPacket


 


1 packets transmitted, 0 received, 100% packet loss, time 0ms


 






  --
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH] MdePkg: refine code for BaseOrderedCollectionRedBlackTreeLib

[Dong, Eric]

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


BaseOrderedCollectionRedBlackTreeLib.c.patch
Description: BaseOrderedCollectionRedBlackTreeLib.c.patch
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Missing Ping Reply

[Fu, Siyuan]

Hi, Chris

DispatchDpc returns NOT_FOUND is correct. Ping command doesn't use DPC so the 
Rx event's callback function will be invoked immediately after SingalEvent(). 
Did you check the Token->Status and Token->Packet.RxData in 
Ip4InstanceDeliverPacket() before SingalEvent?

Best Regards,
Siyuan

From: Chris Cuthbert [mailto:nd6...@hotmail.com]
Sent: Tuesday, August 19, 2014 1:18 AM
To: Fu, Siyuan; Edk2 Devel
Subject: RE: [edk2] Missing Ping Reply

Hi Siyuan,

Here is the log again. Looks like NOT_FOUND is being returned by DispatchDpc.
Thanx.


Shell> ping -n 1 172.25.17.100
Ping StartsAPing 172.25.17.100 16 data bytes
NicVfTransmit (ARP request)
NicVfGetPacket   (ARP reply)
NicVfTransmit  (Ping 
request)
NicVfGetPacket(Ping reply)
Ip4AccpetFrame EFI_IP_PROTO_ICMP
Ip4IcmpHandle ICMP_QUERY_MESSAGE
Ip4ProcessIcmpQuery Ip4Demultiplex
Ip4Demultiplex Ip4InterfaceEnquePacket
Ip4Demultiplex Ip4InterfaceEnquePacket
Ip4Demultiplex Ip4InterfaceDeliverPacket
Ip4InstanceDeliverPacket: Before SignalEvent
Ip4InstanceDeliverPacket: After SignalEvent 0x0
Ip4Demultiplex Ip4InterfaceDeliverPacket
Ip4AccpetFrame: Before DispatchDpc
Ip4AccpetFrame: After DispatchDpc 0x800E

1 packets transmitted, 0 received, 100% packet loss, time 0ms

From: siyuan...@intel.com
To: edk2-devel@lists.sourceforge.net; 
nd6...@hotmail.com
Subject: RE: [edk2] Missing Ping Reply
Date: Mon, 18 Aug 2014 06:14:08 +
Hi, Chris

Could you please help to check the return status of the gBS->SignalEvent and 
DispatchDpc (see attached patch file)?  Ping's call back function should be 
invoked when IP4 driver calling SignalEvent or DispatchDpc (mostly after 
SingalEvent if you execute the ping command in EFI shell).

Best Regards,
Siyuan

From: Chris Cuthbert [mailto:nd6...@hotmail.com]
Sent: Sunday, August 17, 2014 11:14 AM
To: Edk2 Devel
Subject: [edk2] Missing Ping Reply

Hi All,

I am implementing a UEFI driver for a network controller and I am producing 
Simple Network Protocol(SNP). To test this, I am using the 'ping' shell 
command. The problem is that I never get the first ping reply. I have debugged 
this all the way up the IPv4 stack and I can see that reply packet is being 
passed up but the first packet never reaches the 'ping' command. Logs below. 
From the ping source code it looks like it is creating an event to get a call 
back on reply packet and as part of the call back, it registers for event again 
if more replies are expected. But the first reply never kicks the call back 
function.
Any suggestions ?
Thanx.

Shell> ping -n 1 172.25.17.100
Ping StartsAPing 172.25.17.100 16 data bytes
NicVfTransmit  (ARP 
request)
NicVfGetPacket(ARP 
reply)
NicVfTransmit  (Ping 
packet)
NicVfGetPacket(Ping 
reply)
Ip4AccpetFrame EFI_IP_PROTO_ICMP(ICMP recognized)
Ip4IcmpHandle ICMP_QUERY_MESSAGE
Ip4ProcessIcmpQuery Ip4Demultiplex(Ip4Demultiplex function 
call)
Ip4Demultiplex Ip4InterfaceEnquePacket
Ip4Demultiplex Ip4InterfaceEnquePacket
Ip4Demultiplex Ip4InterfaceDeliverPacket
Ip4Demultiplex Ip4InterfaceDeliverPacket

1 packets transmitted, 0 received, 100% packet loss, time 0ms

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Patch for review: StdLibPrivateInternalFiles/Include/{Ia32, X64}/arith.h

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 




From: Mcdaniel, Daryl
Sent: Monday, August 18, 2014 3:57 PM
To: edk2-devel@lists.sourceforge.net
Subject: Patch for review: StdLibPrivateInternalFiles/Include/{Ia32,X64}/arith.h

Please review the attached changes.

StdLibPrivateInternalFiles/Include/{Ia32,X64}/arith.h: Use programmatically 
generated arith.h files for greater compatibility with the gdtoa library in 
StdLib.


Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Daryl McDaniel 
mailto:daryl.mcdan...@intel.com>>

Reviewed-by:


Thank You,
Daryl McDaniel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [RFC] EDK II UNI Unicode File Specification

[Tim Lewis]

Larry -

The description of the extensions for modules/package abstracts/description are 
much better.

Here are a few comments which are not specific to your update (although they 
are contained in the text below)

1.   It is readable. I do think that adding <> terminals for single 
characters makes it harder to read, but otherwise the text is clear. Why not 
"/" instead of  and "(" instead of ?

2.   I don't think there is any UEFI spec requirement that a \endbold be 
preceded by a \bold. Since the font for any string may include the bold 
attribute, it may be that the \endbold might be desirable. This is further 
complicated by the fact the the .UNI specification doesn't not provide 
font-select capabilities.

3.   The current escape character mechanism prevents future expansion, 
because the escape sequences are neither fixed length nor well-delimited. 
Consider what would happen if someone wanted to add \bolder to the grammar. 
This would make older strings suspect, since it could be interpreted as "\bold" 
 and "er" or "\bolder" I mentioned this long ago.

Tim

From: Hauch, Larry [mailto:larry.ha...@intel.com]
Sent: Monday, August 18, 2014 3:54 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [RFC] EDK II UNI Unicode File Specification

Hi Folks,

Here are the proposed changes to the EDK II UNI Unicode File Specification. 
Hopefully, HTML format for the chapters will be easier to review and respond 
with feedback.
Please provide feedback by the end of this week (22 Aug. 2014).


Updates:

·  Updated EBNF to follow syntax specified in EBNF by the ANTLR project

·  Added content related to EDK II Meta-Data Unicode files

·  Restructured document

·  Removed security and C format GUID definitions, not required for HII 
or other UNI files.

Cheers,
Larry
2
Unicode Strings File Format
EDK II Unicode files are used for mapping token names to localized strings that 
are identified by an RFC4646 language code. The format for storing EDK II 
Unicode files is UTF-16LE. The character content must be UCS-2.
Strings ends are determined by the first of the following items found:

· a control character

· a comment

· the end of the file

· a blank line
Comments may appear anywhere within the string file.
All the files must begin with a Unicode BOM character.

Note:Please make sure you select an editor that supports UCS-2 characters 
that can be stored in a UTF-16LE file.

2.1   2. 1 Common EBNF
The following EBNF uses quoted (double quotes) encapsulated characters to 
represent UCS-2 string literals. In the following definitions, the semi-colon 
is used to denote a comment.


::=  \u0020   ; Space Character

::=  \u0027   ; Forward Slash, /


::=  \u0028   ; Left Parenthesis, (

::=  \u0029   ; Right Parenthesis, )

::=  {(\u0041-\u005A)} ; Characters A - Z
 {(\u0061-\u007A)} ; Characters a - z

 ::=  (\u0030-\u0039)   ; Characters 0 - 9

::=  \u005F; Underscore Character, _

::=  +

::=  {} {}

   ::=*  

 ::=  

 ::=  (\u0001-\uF6FF)



::=  (\u0020-\uF6FF)



::=  (\u0021-\uF6FF)



  ::=   

 [ [ ]+]+



  ::=   "language"   



 ::=  {}

 {(\u0041-\u0046)} ; Characters A - F

 {(\u0061-\u0066)} ; Characters a - f



  ::=  \u0023   ; Hash Character, #



 ::=   "string"  



::=   [{} {} {}]*



  ::=  



::=  (\u002D) ; Dash Character, -



   ::=  {2,8} [ *]



  ::=   [{} {}]{1,8}



   ::=   [{} {}]{1,}



 ::=  \u0022   ; Double Quote Character, "



::=   * 



  ::=  {} {} {}



::=   *

[]



::=   



  ::=  \u005C   ; Backslash Character, \



 ::=   "end" 



  ::=  {} {}



   ::=  {"narrow">} {"wide"}



 ::=  {"normal"} {"bold"} {"italic"}

 {"emboss"}

 {"shadow"} {"underline"} {"dblunder"}



  ::=   {"n"} {"f"} {"r"} {"p"}

 {"ospace"} {"enquad"} {"emquad"}

 {"ensp"} {"emsp"} {"em3sp"} {"em4sp"}

 {"em6sp"} {"usp"} {"tsp"} {"hsp"}

 {"msp"} {"!bsp"} {"!nbsp"}

 {"zsp"} {"ah"} { "hy"} { "df"} {"den"}

 {"dem"} {"!bh"} {"g"} {"osp"} {"k"}



   ::=  \u005D   ; Backslash Character, \





2.1.1  Definitions
LanguageCodes
The language code must be a valid RFC4646 language code.
EscChar
In 

Re: [edk2] Patch for review: StdLibPrivateInternalFiles/Include/{Ia32, X64}/arith.h

[Bjorge, Erik C]

Reviewed-by: Erik Bjorge 

From: Mcdaniel, Daryl
Sent: Monday, August 18, 2014 3:57 PM
To: edk2-devel@lists.sourceforge.net
Subject: Patch for review: StdLibPrivateInternalFiles/Include/{Ia32,X64}/arith.h

Please review the attached changes.

StdLibPrivateInternalFiles/Include/{Ia32,X64}/arith.h: Use programmatically 
generated arith.h files for greater compatibility with the gdtoa library in 
StdLib.


Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Daryl McDaniel 
mailto:daryl.mcdan...@intel.com>>

Reviewed-by:


Thank You,
Daryl McDaniel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Patch for review: StdLibPrivateInternalFiles/Include/{Ia32, X64}/arith.h

[Mcdaniel, Daryl]

Please review the attached changes.

StdLibPrivateInternalFiles/Include/{Ia32,X64}/arith.h: Use programmatically 
generated arith.h files for greater compatibility with the gdtoa library in 
StdLib.


Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Daryl McDaniel 
mailto:daryl.mcdan...@intel.com>>

Reviewed-by:


Thank You,
Daryl McDaniel



arith_h.patch
Description: arith_h.patch
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC] EDK II UNI Unicode File Specification

[Hauch, Larry]

Hi Folks,

Here are the proposed changes to the EDK II UNI Unicode File Specification. 
Hopefully, HTML format for the chapters will be easier to review and respond 
with feedback.
Please provide feedback by the end of this week (22 Aug. 2014).


Updates:

·  Updated EBNF to follow syntax specified in EBNF by the ANTLR project

·  Added content related to EDK II Meta-Data Unicode files

·  Restructured document

·  Removed security and C format GUID definitions, not required for HII 
or other UNI files.

Cheers,
Larry
2
Unicode Strings File Format
EDK II Unicode files are used for mapping token names to localized strings that 
are identified by an RFC4646 language code. The format for storing EDK II 
Unicode files is UTF-16LE. The character content must be UCS-2.
Strings ends are determined by the first of the following items found:

·a control character

·a comment

·the end of the file

·a blank line
Comments may appear anywhere within the string file.
All the files must begin with a Unicode BOM character.

Note:Please make sure you select an editor that supports UCS-2 characters 
that can be stored in a UTF-16LE file.

2.1  2. 1 Common EBNF
The following EBNF uses quoted (double quotes) encapsulated characters to 
represent UCS-2 string literals. In the following definitions, the semi-colon 
is used to denote a comment.


::=  \u0020   ; Space Character

::=  \u0027   ; Forward Slash, /


::=  \u0028   ; Left Parenthesis, (

::=  \u0029   ; Right Parenthesis, )

::=  {(\u0041-\u005A)} ; Characters A - Z
 {(\u0061-\u007A)} ; Characters a - z

 ::=  (\u0030-\u0039)   ; Characters 0 - 9

::=  \u005F; Underscore Character, _

::=  +

::=  {} {}

   ::=*  

 ::=  

 ::=  (\u0001-\uF6FF)



::=  (\u0020-\uF6FF)



::=  (\u0021-\uF6FF)



  ::=   

 [ [ ]+]+



  ::=   "language"   



 ::=  {}

 {(\u0041-\u0046)} ; Characters A - F

 {(\u0061-\u0066)} ; Characters a - f



  ::=  \u0023   ; Hash Character, #



 ::=   "string"  



::=   [{} {} {}]*



  ::=  



::=  (\u002D) ; Dash Character, -



   ::=  {2,8} [ *]



  ::=   [{} {}]{1,8}



   ::=   [{} {}]{1,}



 ::=  \u0022   ; Double Quote Character, "



::=   * 



  ::=  {} {} {}



::=   *

[]



::=   



  ::=  \u005C   ; Backslash Character, \



 ::=   "end" 



  ::=  {} {}



   ::=  {"narrow">} {"wide"}



 ::=  {"normal"} {"bold"} {"italic"}

 {"emboss"}

 {"shadow"} {"underline"} {"dblunder"}



  ::=   {"n"} {"f"} {"r"} {"p"}

 {"ospace"} {"enquad"} {"emquad"}

 {"ensp"} {"emsp"} {"em3sp"} {"em4sp"}

 {"em6sp"} {"usp"} {"tsp"} {"hsp"}

 {"msp"} {"!bsp"} {"!nbsp"}

 {"zsp"} {"ah"} { "hy"} { "df"} {"den"}

 {"dem"} {"!bh"} {"g"} {"osp"} {"k"}



   ::=  \u005D   ; Backslash Character, \





2.1.1  Definitions
LanguageCodes
The language code must be a valid RFC4646 language code.
EscChar
In order to include some standard characters, such as the "\" back-slash 
character within a string, the character must be prefixed with the escape 
character. Characters that may require a prefixed escape character include the 
following, back slash "\" character, single-quote "'" character, double-quote 
'"' character and the forward slash "/" character. The back slash always 
requires the escape character.
StandardAttrs
The standard font attribute, "normal" was not defined in the UEFI 
Specification; however it has been proposed and is included here. Additional 
attributes defined in the UEFI Specification, such as double underline 
(dblunder), did not have the double-byte encoding for the character mapping, 
however recommendations have been given for these characters (see
 below).
Token
The token (strong identifier) may only contain numbers, upper and lower case 
letters, underscore character, and dash character.
Include
An include line is used to parse another file, also compliant with this 
specification, as if it was in the file.  The tokens should not overlap between 
the file for the same language.


Table 1 HII Double-Byte Encoding Map

String


Double-Byte Encoding


String


Double-Byte Encoding

\bold

0xF620

\endbold

0xF621

\italic

0xF622

\enditalic

0xF623

\underline

0xF624

Re: [edk2] Question for EDK II package owners - Re: [RFC 2/2] EDK II Contributions.txt: Note acceptable contribution licenses

[Carsey, Jaben]

No concern.

> -Original Message-
> From: Jordan Justen [mailto:jordan.l.jus...@intel.com]
> Sent: Monday, August 18, 2014 2:04 PM
> To: edk2-devel@lists.sourceforge.net
> Subject: [edk2] Question for EDK II package owners - Re: [RFC 2/2] EDK II
> Contributions.txt: Note acceptable contribution licenses
> 
> This patch to Contributions.txt will update:
> 
>   AppPkg, ArmPkg, ArmPlatformPkg, BaseTools, BeagleBoardPkg,
>   CryptoPkg, DuetPkg, EdkCompatibilityPkg, EdkShellBinPkg,
>   EdkShellPkg, EmbeddedPkg, EmulatorPkg, FatBinPkg,
>   IntelFrameworkModulePkg, IntelFrameworkPkg, MdeModulePkg, MdePkg,
>   NetworkPkg, Nt32Pkg, Omap35xxPkg, OptionRomPkg, OvmfPkg,
>   PcAtChipsetPkg, PerformancePkg, SecurityPkg, ShellBinPkg, ShellPkg,
>   SourceLevelDebugPkg, StdLib, StdLibPrivateInternalFiles, and
>   UefiCpuPkg
> 
> Do the owners of these packages have a concern with this change? (With the
> BDS=>BSD spelling fix, of course.)
> 
> -Jordan
> 
> On 2014-08-04 20:32:16, Doran, Mark wrote:
> > Reviewed-by: Mark Doran 
> >
> > Fix "BDS" to read "BSD" (two instances) and I think it's good to go.
> > --
> > Cheers,
> >
> > Mark.
> >
> >
> > -Original Message-
> > From: Justen, Jordan L
> > Sent: Friday, August 1, 2014 3:52 PM
> > To: edk2-devel@lists.sourceforge.net
> > Cc: Justen, Jordan L; Doran, Mark
> > Subject: [RFC 2/2] EDK II Contributions.txt: Note acceptable
> > contribution licenses
> >
> > We strongly prefer that contribtions be offered using the same license as
> the project/module. But, we should document other acceptable licenses for
> contributions.
> >
> > This will allow package owners to more easily know if they can accept a
> contribution under a different source license.
> >
> > NOTE: This does not modify the wording of the "TianoCore Contribution
> >   Agreement 1.0" section
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Jordan Justen 
> > Cc: Mark Doran 
> > ---
> >  MdePkg/Contributions.txt | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/MdePkg/Contributions.txt b/MdePkg/Contributions.txt index
> > dd1c6c3..66d62b3 100644
> > --- a/MdePkg/Contributions.txt
> > +++ b/MdePkg/Contributions.txt
> > @@ -19,6 +19,20 @@ To make a contribution to a TianoCore project, follow
> these steps.
> > that the project documents on its web page.  If the process is
> > not documented, then submit the code on development email list
> > for the project.
> > +5. It is preferred that contributions are submitted using the same
> > +   copyright license as the base project. When that is not possible,
> > +   then contributions using the following licenses can be accepted:
> > +   * BDS (2-clause): http://opensource.org/licenses/BSD-2-Clause
> > +   * BDS (3-clause): http://opensource.org/licenses/BSD-3-Clause
> > +   * MIT: http://opensource.org/licenses/MIT
> > +   * Python-2.0: http://opensource.org/licenses/Python-2.0
> > +   * Zlib: http://opensource.org/licenses/Zlib
> > +
> > +   Contributions of code put into the public domain can also be
> > +   accepted.
> > +
> > +   Contributions using other licenses might be accepted, but further
> > +   review will be required.
> >
> >  =
> >  = Change Description / Commit Message / Patch Email =
> > --
> > 2.0.1
> 
> --
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Patch for review: StdLibPrivateInternalFiles/Include/{Ia32, X64}/arith.h

[Mcdaniel, Daryl]

Please review the attached changes.

StdLibPrivateInternalFiles/Include/{Ia32,X64}/arith.h: Use programmatically 
generated arith.h files for greater compatibility with the gdtoa library in 
StdLib.


Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Daryl McDaniel 
mailto:daryl.mcdan...@intel.com>>

Reviewed-by:


Thank You,
Daryl McDaniel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Patch for review: AppPkg/Applications/Python

[Bjorge, Erik C]

Reviewed-by: Erik Bjorge 

From: Mcdaniel, Daryl
Sent: Monday, August 18, 2014 2:30 PM
To: edk2-devel@lists.sourceforge.net
Subject: Patch for review: AppPkg/Applications/Python

Please review the attached changes.  GCC is the most affected compiler.
Both patch files and the full file are included.  In most cases just one line 
changes per file.

AppPkg/Applications/Python: Explicitly initialize variables before use to keep 
newer compilers happy.

Explicitly initialize variables before any potential use.


Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Daryl McDaniel 
mailto:daryl.mcdan...@intel.com>>

Reviewed-by:


Daryl McDaniel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Patch for review: AppPkg/Applications/Python

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

From: Mcdaniel, Daryl
Sent: Monday, August 18, 2014 2:30 PM
To: edk2-devel@lists.sourceforge.net
Subject: Patch for review: AppPkg/Applications/Python

Please review the attached changes.  GCC is the most affected compiler.
Both patch files and the full file are included.  In most cases just one line 
changes per file.

AppPkg/Applications/Python: Explicitly initialize variables before use to keep 
newer compilers happy.

Explicitly initialize variables before any potential use.


Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Daryl McDaniel 
mailto:daryl.mcdan...@intel.com>>

Reviewed-by:


Daryl McDaniel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Question for EDK II package owners - Re: [RFC 2/2] EDK II Contributions.txt: Note acceptable contribution licenses

[Jordan Justen]

This patch to Contributions.txt will update:

  AppPkg, ArmPkg, ArmPlatformPkg, BaseTools, BeagleBoardPkg,
  CryptoPkg, DuetPkg, EdkCompatibilityPkg, EdkShellBinPkg,
  EdkShellPkg, EmbeddedPkg, EmulatorPkg, FatBinPkg,
  IntelFrameworkModulePkg, IntelFrameworkPkg, MdeModulePkg, MdePkg,
  NetworkPkg, Nt32Pkg, Omap35xxPkg, OptionRomPkg, OvmfPkg,
  PcAtChipsetPkg, PerformancePkg, SecurityPkg, ShellBinPkg, ShellPkg,
  SourceLevelDebugPkg, StdLib, StdLibPrivateInternalFiles, and
  UefiCpuPkg

Do the owners of these packages have a concern with this change? (With
the BDS=>BSD spelling fix, of course.)

-Jordan

On 2014-08-04 20:32:16, Doran, Mark wrote:
> Reviewed-by: Mark Doran 
> 
> Fix "BDS" to read "BSD" (two instances) and I think it's good to go.
> --
> Cheers,
>  
> Mark.
>  
> 
> -Original Message-
> From: Justen, Jordan L 
> Sent: Friday, August 1, 2014 3:52 PM
> To: edk2-devel@lists.sourceforge.net
> Cc: Justen, Jordan L; Doran, Mark
> Subject: [RFC 2/2] EDK II Contributions.txt: Note acceptable contribution 
> licenses
> 
> We strongly prefer that contribtions be offered using the same license as the 
> project/module. But, we should document other acceptable licenses for 
> contributions.
> 
> This will allow package owners to more easily know if they can accept a 
> contribution under a different source license.
> 
> NOTE: This does not modify the wording of the "TianoCore Contribution
>   Agreement 1.0" section
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jordan Justen 
> Cc: Mark Doran 
> ---
>  MdePkg/Contributions.txt | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/MdePkg/Contributions.txt b/MdePkg/Contributions.txt index 
> dd1c6c3..66d62b3 100644
> --- a/MdePkg/Contributions.txt
> +++ b/MdePkg/Contributions.txt
> @@ -19,6 +19,20 @@ To make a contribution to a TianoCore project, follow 
> these steps.
> that the project documents on its web page.  If the process is
> not documented, then submit the code on development email list
> for the project.
> +5. It is preferred that contributions are submitted using the same
> +   copyright license as the base project. When that is not possible,
> +   then contributions using the following licenses can be accepted:
> +   * BDS (2-clause): http://opensource.org/licenses/BSD-2-Clause
> +   * BDS (3-clause): http://opensource.org/licenses/BSD-3-Clause
> +   * MIT: http://opensource.org/licenses/MIT
> +   * Python-2.0: http://opensource.org/licenses/Python-2.0
> +   * Zlib: http://opensource.org/licenses/Zlib
> +
> +   Contributions of code put into the public domain can also be
> +   accepted.
> +
> +   Contributions using other licenses might be accepted, but further
> +   review will be required.
>  
>  =
>  = Change Description / Commit Message / Patch Email =
> --
> 2.0.1

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 0/4] OvmfPkg: complete client for QEMU's ACPI loader interface

[Laszlo Ersek]

On 08/09/14 04:08, Laszlo Ersek wrote:
> This series strives to implement a client for QEMU's ACPI loader fw_cfg
> interface as completely as I can imagine at this point. The only
> shortcut it takes is that it equates the FSeg allocation hint with the
> affected blob containing the RSD PTR table at the beginning, which
> Michael (CC'd) has suggested before.
> 
> Some UEFI-specific notes for Michael that may not be obvious
> immediately:
> 
> - All blobs are allocated in EfiACPIMemoryNVS type memory. In theory,
>   most tables could be allocated in EfiACPIReclaimMemory too (which the
>   OS can release and reuse after it enables ACPI) except eg. the FACS,
>   but the fw_cfg interface doesn't allow distinguishing these two, hence
>   OVMF follows what SeaBIOS does: allocates tables in memory that is
>   permanently reserved from the OS.
> 
> - All tables are allocated under 4GB. The Zone member of the Allocate
>   command is ignored (beyond the RSD PTR determination above).
> 
> - The RSD PTR is not allocated at a particularly low address; under UEFI
>   the RSD PTR is detected by checking for one of two special GUIDs in
>   the EFI Configuration Table. The actual GUID found corresponds to the
>   version number of the RSD PTR.
> 
> - All blobs are allocated in areas that are whole multiples of pages.
>   Alignment requests greater than a page are not supported. (At the
>   moment edk2 has no memory allocation interface that supports *all* of:
>   alignment specification, memory type, and max address.)
> 
> The series depends on OrderedCollectionLib, which I had posted as:
>   [edk2] [PATCH v3 0/3] MdePkg: ordered collections, AppPkg: unit tester
>   
>   
> 
> Tested as follows:
> - Fedora 20 guest, checked tables in dmesg, S3 suspend/resume works,
>   ACPI shutdown (virtual power button) works;
> - RHEL-7, ditto;
> - Windows Server 2008 R2 with QXL driver, S3 suspend/resume works (bound
>   to ACPI power button).
> 
> Public branch: 
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (4):
>   OvmfPkg: resolve OrderedCollectionLib with base red-black tree
> instance
>   OvmfPkg: AcpiPlatformDxe: actualize QemuLoader.h comments
>   OvmfPkg: AcpiPlatformDxe: remove current ACPI table loader
>   OvmfPkg: AcpiPlatformDxe: implement QEMU's full ACPI table loader
> interface
> 
>  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |   3 +
>  OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h  |   2 +-
>  OvmfPkg/AcpiPlatformDxe/QemuLoader.h|   6 +-
>  OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c  |   2 +-
>  OvmfPkg/AcpiPlatformDxe/Qemu.c  | 593 
> +---
>  OvmfPkg/OvmfPkgIa32.dsc |   1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc  |   1 +
>  OvmfPkg/OvmfPkgX64.dsc  |   1 +
>  8 files changed, 362 insertions(+), 247 deletions(-)
> 

Ping.

Thanks,
Laszlo

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] PXE Boot Error

[Chris Cuthbert]

Hi All,

I am trying to boot an ARM core using PXE boot and I am following the steps 
mentioned in this Linaro wiki 
(https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/UEFI_Network_Booting). 
Most importantly, the DHCP server configuration part of it. It says:


Add these lines to /etc/dhcp/dhcpd.conf: allow booting;
allow bootp;

subnet 192.168.0.0 netmask 255.255.255.0 {
  range 192.168.0.3 192.168.0.253;
}

host rtsm {
  hardware ethernet 00:02:f7:ef:5c:f5;
  fixed-address 192.168.0.20;
  option host-name "rtsm";
  next-server 192.168.0.1;
  filename "efi/grub.efi";
}

When I do configure the UEFI boot manager to boot, I get error in 
"PxeBcSelectBootPrompt" function at the following check:

  if (Packet->OfferType != DHCP4_PACKET_TYPE_PXE10) {
return EFI_NOT_FOUND;
  }


Seems like the DHCP server is offering "DHCP4_PACKET_TYPE_DHCP_ONLY" and not 
"DHCP4_PACKET_TYPE_PXE10".
After looking around, it seems I need to enable option 060 in DHCP server. I 
have not been able to find a way to configure
the DHCP to allow PXE boot. The most popular configuration change suggested was 
"option vendor-class-identifier "PXEClient";".

Any suggestions ?
Thanx.

  --
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] ShellPkg: Fix EFI_SHELL_PROTOCOL to contain new members from UEFI Shell 2.1 spec

[Carsey, Jaben]

Reviewed-by: Jaben Carsey 

From: Phillips, Chris J (Plano, TX) [mailto:chr...@hp.com]
Sent: Monday, August 18, 2014 8:26 AM
To: Carsey, Jaben; edk2-devel@lists.sourceforge.net
Subject: ShellPkg: Fix EFI_SHELL_PROTOCOL to contain new members from UEFI 
Shell 2.1 spec
Importance: High


Please review and provide any feedback.



This code change removes EFI_SHELL_PROTOCOL21 and instead includes the new 
structure members from UEFI Shell 2.1 spec (RegisterGuidName, GetGuidName, 
GetGuidFromName, and GetEnvEx) into EFI_SHELL_PROTOCOL.



A comment note was added to explain that ShellProtocol MajorVersion and 
MinorVersion must be checked before attempting to use the new members (version 
check not needed when using a UEFI Shell 2.0 spec member).  This is for the 
case that a new UEFI Shell 2.1 application might be running on an older UEFI 
Shell 2.0 shell.



Any UEFI Shell 2.0 applications will be backward supported with the new 
EFI_SHELL_PROTOCOL, since new members will not be used.  I tested with a couple 
pre-built shell applications we have that use the ShellProtocol to perform 
different tasks.  No issues found.



Thanks,

Chris





ShellPkg: Fix EFI_SHELL_PROTOCOL to contain new members from UEFI Shell 2.1 spec

- Removes EFI_SHELL_PROTOCOL21

- Adds RegisterGuidName, GetGuidName, GetGuidFromName, and GetEnvEx to 
EFI_SHELL_PROTOCOL



Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Chris Phillips mailto:chr...@hp.com>>
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

[Jordan Justen]

On Mon, Aug 18, 2014 at 2:25 AM, Gao, Liming  wrote:
> Jordan:
>
> The commit message is just Mike description.

Are you saying it will look like this?
== Commit message start ==
[MdePkg] INF/DEC file updates to EDK II packages

1)  Usage information in INF file comment blocks are either
incomplete or incorrect.  This includes usage information for
Protocols/PPIs/GUIDs/PCDs/HOBs/Events/BootModes.  The syntax for usage
information in comment blocks is defined in the EDK II Module
Information (INF) Specification

2)  Add MODULE_UNI_FILE to INF [Defines] section along with UNI
file that contains the localized Abstract and Description of a module.

a.   Addresses an information gap between INF files and the UEFI
Distribution Packaging Specification XML schema

b.  There will be an associated update to UPT in BaseTools to
consume MODULE_UNI_FILE and associated UNI file during UDP creation
that performs the INF -> XML conversion.

c.   There will be an associated update to UPT in BaseTools to
produce MODULE_UNI_FILE and associated UNI file during UDP
installation that performs the XML -> INF conversion.

3)  Add [UserExtensions.TianoCore.”ExtraFiles”] section to INF
files along with associated UNI file that provides the localized Name
of a module.

a.   [UserExtensions.TianoCore.”ExtraFiles”] provides an easy
method for a module to specify extra files not listed in [Sources] or
[Binaries] sections to be added to a UDP without having to list the
files in the UPT package information data file.

b.  There will be an associated update to UPT in BaseTools to
package up files listed in [UserExtensions.TianoCore.”ExtraFiles”]
during UDP creation.

c.   UNI file contains localized name of a module to go along with
the localized Abstract and Description from the MODULE_UNI_FILE.

4)  PCD information in DEC file comment blocks are either
incomplete or incorrect.  This includes detailed description, @Prompt,
@ValidRange, @ValidList, @Expression, and [Error.]
validation error messages

5)  Add PACKAGE_UNI_FILE to DEC [Defines] section along with UNI
file that contains the localized Abstract and Description of a package
and localized strings associated with PCDs.

a.   Addresses an information gap between DEC files and the UEFI
Distribution Packaging Specification XML schema

b.  There will be an associated update to UPT in BaseTools to
consume PACKAGE_UNI_FILE and associated UNI file during UDP creation
that performs the DEC -> XML conversion.

c.   There will be an associated update to UPT in BaseTools to
produce PACKAGE_UNI_FILE and associated UNI file during UDP
installation that performs the XML -> DEC conversion.

6)  Add [UserExtensions.TianoCore.”ExtraFiles”] section to DEC
files along with associated UNI file that provides the localized Name
of a package.

a.   [UserExtensions.TianoCore.”ExtraFiles”] provides an easy
method for a package to specify extra files to be added to a UDP
without having to list the files in the UPT package information data
file.

b.  There will be an associated update to UPT in BaseTools to
package up files listed in [UserExtensions.TianoCore.”ExtraFiles”]
during UDP creation.

c.   UNI file contains localized name of a package to go along
with the localized Abstract and Description from the PACKAGE_UNI_FILE.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gao, Liming 
== Commit message end ==

Regarding the first line
"[MdePkg] INF/DEC file updates to EDK II packages"
I think this better fits the recommended format:
"MdePkg: INF/DEC file updates to EDK II packages"

But, this still leaves the patch subject as unusably vague. Instead,
if the patch was broken down more, you probably could produce a usable
subject line for your commit message.

Regarding the rest of the commit message, you can see it is quite
long. Long is not necessarily bad, but it is also not focused on a
single change or bug fix. I think this is because you are trying to do
6 things in a single patch.

> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Gao, Liming 
>
> My change mainly are in INF and DEC (Item 1 and 4). Even if we separate them, 
> the patch is still big.  For Item 2&3, 5&6, new UNI files will be added. I 
> have created ZIP for them.
> For UNI file, this has been discussed. UNI files will be changed from 
> svn:mime-type = application/octect-stream to svn:mime-type = 
> text/plain;encoding=UTF-16LE.
> For second patch, I will send it soon. Sorry for confuse.

When git send-email sends out multiple patches, it replies the
remaining patches to the first message.

So, you get two nice properties from git send-email:
1. The messages all arrive at about the same time
2. In a threaded email view, the whole series in grouped

-Jordan

> -Original Message-
> From: Jordan Justen [mailto:jljus...@gmail.com]
> Sent: Monday, August 18, 2014 3:57 PM
> To: Gao, Liming; Dong, Guo
> Cc: edk2-de

[edk2] r15816 "retire the top level makefile" - Re: no longer able to build OVMF

[Jordan Justen]

I also see a build error with this change.

Hess,

Were you able to test Linux or OS X based builds with this patch?

How long do you expect it will take to fix? Maybe we should revert the
change for now to investigate further?

-Jordan

On Mon, Aug 18, 2014 at 6:25 AM, Gabriel L. Somlo  wrote:
> Hi,
>
> I've been building OVMF successfully by running "build" in
> the edk2 top-level directory after having modified Conf/target.txt
> like so:
>
>   ACTIVE_PLATFORM = OvmfPkg/OvmfPkgX64.dsc
>   TOOL_CHAIN_TAG = GCC48
>   TARGET_ARCH = X64
>
> As of this morning, that no longer works. Running "build" results in
> the following error:
>
>
> ...
> build.py...
>  : error 7000: Failed to start command
> GenFds -f
> "/home/somlo/KVM-OSX/SCRATCH/edk2/OvmfPkg/OvmfPkgX64.fdf" -o
> "/home/somlo/KVM-OSX/SCRATCH/edk2/Build/OvmfX64/DEBUG_GCC48" -t GCC48
> -b DEBUG -p "/home/somlo/KVM-OSX/SCRATCH/edk2/OvmfPkg/OvmfPkgX64.dsc"
> -a X64  -D
> "EFI_SOURCE=/home/somlo/KVM-OSX/SCRATCH/edk2/EdkCompatibilityPkg"  -D
> "EDK_SOURCE=/home/somlo/KVM-OSX/SCRATCH/edk2/EdkCompatibilityPkg"  -D
> "TOOL_CHAIN_TAG=GCC48"  -D "TOOLCHAIN=GCC48"  -D "TARGET=DEBUG"  -D
> "WORKSPACE=/home/somlo/KVM-OSX/SCRATCH/edk2"  -D
> "EDK_TOOLS_PATH=/home/somlo/KVM-OSX/SCRATCH/edk2/BaseTools"  -D
> "ARCH=X64"  -D
> "ECP_SOURCE=/home/somlo/KVM-OSX/SCRATCH/edk2/EdkCompatibilityPkg"
> [/home/somlo/KVM-OSX/SCRATCH/edk2]
>
> - Failed -
> Build end time: 09:23:10, Aug.18 2014
> Build total time: 00:00:32
>
>
> I ran a git bisect and found the cause to be this commit:
>
> commit 03af27533236a08309b60ba1f3236234f3de46bc
> Author: Hess Chen 
> Date:   Mon Aug 18 04:59:01 2014 +
>
> This patch is going to retire the top level makefile on BaseTools
> for supporting a pure binary build without any complier.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hess Chen 
> Reviewed-by: Yingke Liu 
>
> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15816 
> 6f19259b-  4bc3-4df7-8a09-765794883524
>
>
> Any ideas much appreciated !
>
> Thanks,
> --Gabriel
>
>
> --
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] TcpIoReceive question

[Thomas Rognon]

Thanks! I see now. I overlooked the outer while loop.

Thomas Rognon


On Mon, Aug 18, 2014 at 3:11 AM, Ye, Ting  wrote:

>  Hi,
>
>
>
> TcpIoReceive() library function is defined to receive required amount of
> data in a specified period, see the function description in TcpIoLib.h:
>
>
>
>   @retval EFI_TIMEOUTFailed to receive the required amount of
> data in the
>
>  specified time period.
>
>
>
> When you set the required data length to 1024 bytes, this function will
> first receive the packet less than 1024 bytes then wait for the next
> packet. If this function cannot receive 1024 bytes data in total, it will
> return EFI_TIMEOUT.
>
>
>
>
>
> In your case, if you want to receive the packet with less than 1024 bytes
> length only, please use Tcp4->Receive () directly. Take TcpIoReceive()
> function as reference:
>
>
>
> RxData->DataLength = 1024;
>
> Status = Tcp4->Receive (Tcp4, &TcpIo->RxToken.Tcp4Token);
>
>
>
> For instance, when a packet with 1000 bytes length is received during this
> call, the ‘Status’ field will be set to EFI_SUCCESS and RxData->DataLength
> will be set to 1000, and also, the TcpIoCommonNotify() will be signaled
> thus TcpIo->IsRxDone will be set to TRUE.
>
>
>
> Best Regards,
>
> Ye Ting
>
>
>
>
>
> *From:* Ye, Ting [mailto:ting...@intel.com]
> *Sent:* Monday, August 18, 2014 3:33 PM
> *To:* edk2-devel@lists.sourceforge.net
> *Subject:* Re: [edk2] TcpIoReceive question
>
>
>
> Hi,
>
>
>
> Thanks for reporting this. We will check whether we can reproduce the
> issue.
>
>
>
> Best Regards,
>
> Ye Ting
>
>
>
> *From:* Thomas Rognon [mailto:tcrog...@gmail.com]
> *Sent:* Sunday, August 17, 2014 8:21 AM
> *To:* edk2-devel
> *Subject:* [edk2] TcpIoReceive question
>
>
>
> I'm receiving a packet of unknown length and it is less than 1024 bytes.
> I'm using TcpIoReceive. I'm expecting it to receive the packet and then
> update the NET_FRAGMENT.Len to the number of bytes received. Instead, it
> times out.
>
>
>
> I know the packet is being sent (I can see it on wireshark). Also, if the
> actual packet size and my buffer size match, then everything works fine. It
> only times out when the actual packet size is smaller than my buffer.
>
>
>
> Here is example code. What am I doing wrong?
>
>
>
> EFI_STATUS
>
> ExampleReceive (
>
>   IN EXAMPLE_PRIVATE  *Private,
>
>   IN OUT UINT32   *DataSize,
>
>   IN OUT UINT8*Data
>
>   )
>
> {
>
>   EFI_STATUSStatus;
>
>   NET_FRAGMENT  Fragment;
>
>   NET_BUF   *Packet;
>
>
>
>   Fragment.Len = *DataSize;
>
>   Fragment.Bulk = Data;
>
>   Packet = NetbufFromExt (
>
>  &Fragment,
>
>  1,
>
>  0,
>
>  0,
>
>  ExampleNbufExtFree,
>
>  NULL
>
>  );
>
>   if (Packet == NULL) {
>
> return EFI_OUT_OF_RESOURCES;
>
>   }
>
>
>
>   Status = gBS->SetTimer (
>
>   Private->RxTimeoutEvent,
>
>   TimerRelative,
>
>   5 * TICKS_PER_SECOND
>
>   );
>
>   if (EFI_ERROR (Status)) {
>
> NetbufFree (Packet);
>
> return Status;
>
>   }
>
>
>
>   Status = TcpIoReceive (
>
>  &Private->TcpIo,
>
>  Packet,
>
>  FALSE,
>
>  Private->RxTimeoutEvent
>
>  );
>
>
>
>   gBS->SetTimer (Private->RxTimeoutEvent, TimerCancel, 0);
>
>   NetbufFree (Packet);
>
>
>
>   if (!EFI_ERROR (Status)) {
>
> *DataSize = Fragment.Len;
>
>   }
>
>
>
>   return Status;
>
> }
>
>
>
> If the incoming packet is 1024 bytes, then the following code will work as
> expected. If the incoming packet is less than 1024 bytes, then it will
> return EFI_TIMEOUT after 5 seconds.
>
>
>
> DataSize = 1024; // this number is arbitrary
>
> Data = AllocatePool (DataSize);
>
> ExampleReceive (Private, &DataSize, Data);
>
>
>
> If I'm doing something wrong, then how would I receive a packet where I
> know the maximum size, but I don't know the exact size? I'm using
> UDK2010.SR1.UP1.P1. Thank you for any insight.
>
>
>
> Thomas Rognon
>
>
> --
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Missing Ping Reply

[Chris Cuthbert]

Hi Siyuan,

Here is the log again. Looks like NOT_FOUND is being returned by DispatchDpc.
Thanx.


Shell> ping -n 1 172.25.17.100
Ping StartsAPing 172.25.17.100 16 data bytes
NicVfTransmit (ARP request)
NicVfGetPacket   (ARP reply)
NicVfTransmit  (Ping 
request)
NicVfGetPacket(Ping reply)
Ip4AccpetFrame EFI_IP_PROTO_ICMP
Ip4IcmpHandle ICMP_QUERY_MESSAGE
Ip4ProcessIcmpQuery Ip4Demultiplex
Ip4Demultiplex Ip4InterfaceEnquePacket
Ip4Demultiplex Ip4InterfaceEnquePacket
Ip4Demultiplex Ip4InterfaceDeliverPacket
Ip4InstanceDeliverPacket: Before SignalEvent
Ip4InstanceDeliverPacket: After SignalEvent 0x0
Ip4Demultiplex Ip4InterfaceDeliverPacket
Ip4AccpetFrame: Before DispatchDpc
Ip4AccpetFrame: After DispatchDpc 0x800E

1 packets transmitted, 0 received, 100% packet loss, time 0ms

From: siyuan...@intel.com
To: edk2-devel@lists.sourceforge.net; nd6...@hotmail.com
Subject: RE: [edk2] Missing Ping Reply
Date: Mon, 18 Aug 2014 06:14:08 +









Hi, Chris
 
Could you please help to check the return status of the gBS->SignalEvent and 
DispatchDpc (see attached patch file)?  Ping’s call back function
 should be invoked when IP4 driver calling SignalEvent or DispatchDpc (mostly 
after SingalEvent if you execute the ping command in EFI shell).
 
Best Regards,
Siyuan
 


From: Chris Cuthbert [mailto:nd6...@hotmail.com]


Sent: Sunday, August 17, 2014 11:14 AM

To: Edk2 Devel

Subject: [edk2] Missing Ping Reply


 

Hi All,

 


I am implementing a UEFI driver for a network controller and I am producing 
Simple Network Protocol(SNP). To test this, I am using the 'ping' shell 
command. The problem is that
 I never get the first ping reply. I have debugged this all the way up the IPv4 
stack and I can see that reply packet is being passed up but the first packet 
never reaches the 'ping' command. Logs below. From the ping source code it 
looks like it is creating
 an event to get a call back on reply packet and as part of the call back, it 
registers for event again if more replies are expected. But the first reply 
never kicks the call back function.


Any suggestions ?


Thanx.


 



Shell> ping -n 1 172.25.17.100


Ping StartsAPing 172.25.17.100 16 data bytes


NicVfTransmit  (ARP 
request)


NicVfGetPacket(ARP 
reply)


NicVfTransmit  (Ping 
packet)


NicVfGetPacket(Ping 
reply)


Ip4AccpetFrame EFI_IP_PROTO_ICMP(ICMP recognized)


Ip4IcmpHandle ICMP_QUERY_MESSAGE


Ip4ProcessIcmpQuery Ip4Demultiplex(Ip4Demultiplex function 
call)


Ip4Demultiplex Ip4InterfaceEnquePacket


Ip4Demultiplex Ip4InterfaceEnquePacket


Ip4Demultiplex Ip4InterfaceDeliverPacket


Ip4Demultiplex Ip4InterfaceDeliverPacket


 


1 packets transmitted, 0 received, 100% packet loss, time 0ms


 



  --
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Wrong build.py rev 15816

[Sergey Isakov]

Hi sirs,
Commit 15816 contains broken build.py. 
I can compile after reverting the file to revision 15809.
Please consider.

Sergey

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] ShellPkg: Fix EFI_SHELL_PROTOCOL to contain new members from UEFI Shell 2.1 spec

[Phillips, Chris J (Plano, TX)]

Please review and provide any feedback.



This code change removes EFI_SHELL_PROTOCOL21 and instead includes the new 
structure members from UEFI Shell 2.1 spec (RegisterGuidName, GetGuidName, 
GetGuidFromName, and GetEnvEx) into EFI_SHELL_PROTOCOL.



A comment note was added to explain that ShellProtocol MajorVersion and 
MinorVersion must be checked before attempting to use the new members (version 
check not needed when using a UEFI Shell 2.0 spec member).  This is for the 
case that a new UEFI Shell 2.1 application might be running on an older UEFI 
Shell 2.0 shell.



Any UEFI Shell 2.0 applications will be backward supported with the new 
EFI_SHELL_PROTOCOL, since new members will not be used.  I tested with a couple 
pre-built shell applications we have that use the ShellProtocol to perform 
different tasks.  No issues found.



Thanks,

Chris





ShellPkg: Fix EFI_SHELL_PROTOCOL to contain new members from UEFI Shell 2.1 spec

- Removes EFI_SHELL_PROTOCOL21

- Adds RegisterGuidName, GetGuidName, GetGuidFromName, and GetEnvEx to 
EFI_SHELL_PROTOCOL



Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Chris Phillips mailto:chr...@hp.com>>


UefiShell21Fixes.patch
Description: UefiShell21Fixes.patch
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] no longer able to build OVMF

[Gabriel L. Somlo]

Hi,

I've been building OVMF successfully by running "build" in
the edk2 top-level directory after having modified Conf/target.txt
like so:

  ACTIVE_PLATFORM = OvmfPkg/OvmfPkgX64.dsc
  TOOL_CHAIN_TAG = GCC48
  TARGET_ARCH = X64

As of this morning, that no longer works. Running "build" results in
the following error:


...
build.py...
 : error 7000: Failed to start command
GenFds -f
"/home/somlo/KVM-OSX/SCRATCH/edk2/OvmfPkg/OvmfPkgX64.fdf" -o
"/home/somlo/KVM-OSX/SCRATCH/edk2/Build/OvmfX64/DEBUG_GCC48" -t GCC48
-b DEBUG -p "/home/somlo/KVM-OSX/SCRATCH/edk2/OvmfPkg/OvmfPkgX64.dsc"
-a X64  -D
"EFI_SOURCE=/home/somlo/KVM-OSX/SCRATCH/edk2/EdkCompatibilityPkg"  -D
"EDK_SOURCE=/home/somlo/KVM-OSX/SCRATCH/edk2/EdkCompatibilityPkg"  -D
"TOOL_CHAIN_TAG=GCC48"  -D "TOOLCHAIN=GCC48"  -D "TARGET=DEBUG"  -D
"WORKSPACE=/home/somlo/KVM-OSX/SCRATCH/edk2"  -D
"EDK_TOOLS_PATH=/home/somlo/KVM-OSX/SCRATCH/edk2/BaseTools"  -D
"ARCH=X64"  -D
"ECP_SOURCE=/home/somlo/KVM-OSX/SCRATCH/edk2/EdkCompatibilityPkg"
[/home/somlo/KVM-OSX/SCRATCH/edk2]

- Failed -
Build end time: 09:23:10, Aug.18 2014
Build total time: 00:00:32


I ran a git bisect and found the cause to be this commit:

commit 03af27533236a08309b60ba1f3236234f3de46bc
Author: Hess Chen 
Date:   Mon Aug 18 04:59:01 2014 +

This patch is going to retire the top level makefile on BaseTools
for supporting a pure binary build without any complier.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen 
Reviewed-by: Yingke Liu 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15816 6f19259b-  
4bc3-4df7-8a09-765794883524


Any ideas much appreciated !

Thanks,
--Gabriel


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

[Gao, Liming]

Jordan:

The commit message is just Mike description. 

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gao, Liming 

My change mainly are in INF and DEC (Item 1 and 4). Even if we separate them, 
the patch is still big.  For Item 2&3, 5&6, new UNI files will be added. I have 
created ZIP for them. 
For UNI file, this has been discussed. UNI files will be changed from 
svn:mime-type = application/octect-stream to svn:mime-type = 
text/plain;encoding=UTF-16LE.
For second patch, I will send it soon. Sorry for confuse. 

Thanks
Liming
-Original Message-
From: Jordan Justen [mailto:jljus...@gmail.com] 
Sent: Monday, August 18, 2014 3:57 PM
To: Gao, Liming; Dong, Guo
Cc: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

What is the commit message for this patch?

It looks like this was missing the Contributed-under and Signed-off-by too.

On Wed, Aug 13, 2014 at 7:13 PM, Gao, Liming  wrote:
> Hi, all
>
>   Could you help review this patch? It includes the following changes 
> 1-6 for MdePkg.

Why are you including 6 changes in a single patch?

> The patch is a little big.

Maybe that is because you have 6 changes include in a single patch? :)

> For new added UNI file, I zip them together.

Laszlo pointed out how to get .uni diffs for git. I wonder if it is possible 
for svn too.

> The second patch for below item 7 will be sent later

Is this why you have 1/2 in the subject?

That is really confusing, since I would expect to see 2/2 sent out along with 
1/2, and that they should be code reviewed together.

-Jordan

> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Thursday, August 07, 2014 5:32 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: [edk2] INF/DEC file updates to EDK II packages
>
>
>
> Hello,
>
>
>
> I wanted to let everyone know about a number of patch reviews for EDK 
> II packages that will be sent out over the next couple of weeks.  
> These patches impact the order of content in INF/DEC files and comment 
> blocks in INF/DEC files, and should not have any build or 
> functionality impacts.  These patches will address the following issues:
>
>
>
> 1)  Usage information in INF file comment blocks are either incomplete
> or incorrect.  This includes usage information for 
> Protocols/PPIs/GUIDs/PCDs/HOBs/Events/BootModes.  The syntax for usage 
> information in comment blocks is defined in the EDK II Module 
> Information
> (INF) Specification
>
> 2)  Add MODULE_UNI_FILE to INF [Defines] section along with UNI file
> that contains the localized Abstract and Description of a module.
>
> a.   Addresses an information gap between INF files and the UEFI
> Distribution Packaging Specification XML schema
>
> b.  There will be an associated update to UPT in BaseTools to consume
> MODULE_UNI_FILE and associated UNI file during UDP creation that 
> performs the INF -> XML conversion.
>
> c.   There will be an associated update to UPT in BaseTools to produce
> MODULE_UNI_FILE and associated UNI file during UDP installation that 
> performs the XML -> INF conversion.
>
> 3)  Add [UserExtensions.TianoCore.”ExtraFiles”] section to INF files
> along with associated UNI file that provides the localized Name of a module.
>
> a.   [UserExtensions.TianoCore.”ExtraFiles”] provides an easy method for
> a module to specify extra files not listed in [Sources] or [Binaries] 
> sections to be added to a UDP without having to list the files in the 
> UPT package information data file.
>
> b.  There will be an associated update to UPT in BaseTools to package up
> files listed in [UserExtensions.TianoCore.”ExtraFiles”] during UDP creation.
>
> c.   UNI file contains localized name of a module to go along with the
> localized Abstract and Description from the MODULE_UNI_FILE.
>
> 4)  PCD information in DEC file comment blocks are either incomplete or
> incorrect.  This includes detailed description, @Prompt, @ValidRange, 
> @ValidList, @Expression, and [Error.] validation error 
> messages
>
> 5)  Add PACKAGE_UNI_FILE to DEC [Defines] section along with UNI file
> that contains the localized Abstract and Description of a package and 
> localized strings associated with PCDs.
>
> a.   Addresses an information gap between DEC files and the UEFI
> Distribution Packaging Specification XML schema
>
> b.  There will be an associated update to UPT in BaseTools to consume
> PACKAGE_UNI_FILE and associated UNI file during UDP creation that 
> performs the DEC -> XML conversion.
>
> c.   There will be an associated update to UPT in BaseTools to produce
> PACKAGE_UNI_FILE and associated UNI file during UDP installation that 
> performs the XML -> DEC conversion.
>
> 6)  Add [UserExtensions.TianoCore.”ExtraFiles”] section to DEC files
> along with associated UNI file that provides the localized Name of a 
> package.
>
> a.   [UserExtensions.TianoCore.”Extr

Re: [edk2] TcpIoReceive question

[Ye, Ting]

Hi,

TcpIoReceive() library function is defined to receive required amount of data 
in a specified period, see the function description in TcpIoLib.h:

  @retval EFI_TIMEOUTFailed to receive the required amount of data 
in the
 specified time period.

When you set the required data length to 1024 bytes, this function will first 
receive the packet less than 1024 bytes then wait for the next packet. If this 
function cannot receive 1024 bytes data in total, it will return EFI_TIMEOUT.


In your case, if you want to receive the packet with less than 1024 bytes 
length only, please use Tcp4->Receive () directly. Take TcpIoReceive() function 
as reference:

RxData->DataLength = 1024;
Status = Tcp4->Receive (Tcp4, &TcpIo->RxToken.Tcp4Token);

For instance, when a packet with 1000 bytes length is received during this 
call, the ‘Status’ field will be set to EFI_SUCCESS and RxData->DataLength will 
be set to 1000, and also, the TcpIoCommonNotify() will be signaled thus 
TcpIo->IsRxDone will be set to TRUE.

Best Regards,
Ye Ting


From: Ye, Ting [mailto:ting...@intel.com]
Sent: Monday, August 18, 2014 3:33 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] TcpIoReceive question

Hi,

Thanks for reporting this. We will check whether we can reproduce the issue.

Best Regards,
Ye Ting

From: Thomas Rognon [mailto:tcrog...@gmail.com]
Sent: Sunday, August 17, 2014 8:21 AM
To: edk2-devel
Subject: [edk2] TcpIoReceive question

I'm receiving a packet of unknown length and it is less than 1024 bytes. I'm 
using TcpIoReceive. I'm expecting it to receive the packet and then update the 
NET_FRAGMENT.Len to the number of bytes received. Instead, it times out.

I know the packet is being sent (I can see it on wireshark). Also, if the 
actual packet size and my buffer size match, then everything works fine. It 
only times out when the actual packet size is smaller than my buffer.

Here is example code. What am I doing wrong?

EFI_STATUS
ExampleReceive (
  IN EXAMPLE_PRIVATE  *Private,
  IN OUT UINT32   *DataSize,
  IN OUT UINT8*Data
  )
{
  EFI_STATUSStatus;
  NET_FRAGMENT  Fragment;
  NET_BUF   *Packet;

  Fragment.Len = *DataSize;
  Fragment.Bulk = Data;
  Packet = NetbufFromExt (
 &Fragment,
 1,
 0,
 0,
 ExampleNbufExtFree,
 NULL
 );
  if (Packet == NULL) {
return EFI_OUT_OF_RESOURCES;
  }

  Status = gBS->SetTimer (
  Private->RxTimeoutEvent,
  TimerRelative,
  5 * TICKS_PER_SECOND
  );
  if (EFI_ERROR (Status)) {
NetbufFree (Packet);
return Status;
  }

  Status = TcpIoReceive (
 &Private->TcpIo,
 Packet,
 FALSE,
 Private->RxTimeoutEvent
 );

  gBS->SetTimer (Private->RxTimeoutEvent, TimerCancel, 0);
  NetbufFree (Packet);

  if (!EFI_ERROR (Status)) {
*DataSize = Fragment.Len;
  }

  return Status;
}

If the incoming packet is 1024 bytes, then the following code will work as 
expected. If the incoming packet is less than 1024 bytes, then it will return 
EFI_TIMEOUT after 5 seconds.

DataSize = 1024; // this number is arbitrary
Data = AllocatePool (DataSize);
ExampleReceive (Private, &DataSize, Data);

If I'm doing something wrong, then how would I receive a packet where I know 
the maximum size, but I don't know the exact size? I'm using 
UDK2010.SR1.UP1.P1. Thank you for any insight.

Thomas Rognon
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

[Jordan Justen]

What is the commit message for this patch?

It looks like this was missing the Contributed-under and Signed-off-by too.

On Wed, Aug 13, 2014 at 7:13 PM, Gao, Liming  wrote:
> Hi, all
>
>   Could you help review this patch? It includes the following changes 1-6
> for MdePkg.

Why are you including 6 changes in a single patch?

> The patch is a little big.

Maybe that is because you have 6 changes include in a single patch? :)

> For new added UNI file, I zip them together.

Laszlo pointed out how to get .uni diffs for git. I wonder if it is
possible for svn too.

> The second patch for below item 7 will be sent later

Is this why you have 1/2 in the subject?

That is really confusing, since I would expect to see 2/2 sent out
along with 1/2, and that they should be code reviewed together.

-Jordan

> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Thursday, August 07, 2014 5:32 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: [edk2] INF/DEC file updates to EDK II packages
>
>
>
> Hello,
>
>
>
> I wanted to let everyone know about a number of patch reviews for EDK II
> packages that will be sent out over the next couple of weeks.  These patches
> impact the order of content in INF/DEC files and comment blocks in INF/DEC
> files, and should not have any build or functionality impacts.  These
> patches will address the following issues:
>
>
>
> 1)  Usage information in INF file comment blocks are either incomplete
> or incorrect.  This includes usage information for
> Protocols/PPIs/GUIDs/PCDs/HOBs/Events/BootModes.  The syntax for usage
> information in comment blocks is defined in the EDK II Module Information
> (INF) Specification
>
> 2)  Add MODULE_UNI_FILE to INF [Defines] section along with UNI file
> that contains the localized Abstract and Description of a module.
>
> a.   Addresses an information gap between INF files and the UEFI
> Distribution Packaging Specification XML schema
>
> b.  There will be an associated update to UPT in BaseTools to consume
> MODULE_UNI_FILE and associated UNI file during UDP creation that performs
> the INF -> XML conversion.
>
> c.   There will be an associated update to UPT in BaseTools to produce
> MODULE_UNI_FILE and associated UNI file during UDP installation that
> performs the XML -> INF conversion.
>
> 3)  Add [UserExtensions.TianoCore.”ExtraFiles”] section to INF files
> along with associated UNI file that provides the localized Name of a module.
>
> a.   [UserExtensions.TianoCore.”ExtraFiles”] provides an easy method for
> a module to specify extra files not listed in [Sources] or [Binaries]
> sections to be added to a UDP without having to list the files in the UPT
> package information data file.
>
> b.  There will be an associated update to UPT in BaseTools to package up
> files listed in [UserExtensions.TianoCore.”ExtraFiles”] during UDP creation.
>
> c.   UNI file contains localized name of a module to go along with the
> localized Abstract and Description from the MODULE_UNI_FILE.
>
> 4)  PCD information in DEC file comment blocks are either incomplete or
> incorrect.  This includes detailed description, @Prompt, @ValidRange,
> @ValidList, @Expression, and [Error.] validation error
> messages
>
> 5)  Add PACKAGE_UNI_FILE to DEC [Defines] section along with UNI file
> that contains the localized Abstract and Description of a package and
> localized strings associated with PCDs.
>
> a.   Addresses an information gap between DEC files and the UEFI
> Distribution Packaging Specification XML schema
>
> b.  There will be an associated update to UPT in BaseTools to consume
> PACKAGE_UNI_FILE and associated UNI file during UDP creation that performs
> the DEC -> XML conversion.
>
> c.   There will be an associated update to UPT in BaseTools to produce
> PACKAGE_UNI_FILE and associated UNI file during UDP installation that
> performs the XML -> DEC conversion.
>
> 6)  Add [UserExtensions.TianoCore.”ExtraFiles”] section to DEC files
> along with associated UNI file that provides the localized Name of a
> package.
>
> a.   [UserExtensions.TianoCore.”ExtraFiles”] provides an easy method for
> a package to specify extra files to be added to a UDP without having to list
> the files in the UPT package information data file.
>
> b.  There will be an associated update to UPT in BaseTools to package up
> files listed in [UserExtensions.TianoCore.”ExtraFiles”] during UDP creation.
>
> c.   UNI file contains localized name of a package to go along with the
> localized Abstract and Description from the PACKAGE_UNI_FILE.
>
> 7)  Make sure order of DEC/INF content matches the order that UPT
> generates in the XML -> INF conversion
>
> a.   This allows UDP packages installed by UPT to be compared against
> EDK II trunk/branches using standard diff utilities.
>
>
>
> Patches for the following EDK II packages are being prepared
>
> 1)  MdePkg
>
> 2)  MdeModulePkg
>
> 3)  

Re: [edk2] TcpIoReceive question

[Ye, Ting]

Hi,

Thanks for reporting this. We will check whether we can reproduce the issue.

Best Regards,
Ye Ting

From: Thomas Rognon [mailto:tcrog...@gmail.com]
Sent: Sunday, August 17, 2014 8:21 AM
To: edk2-devel
Subject: [edk2] TcpIoReceive question

I'm receiving a packet of unknown length and it is less than 1024 bytes. I'm 
using TcpIoReceive. I'm expecting it to receive the packet and then update the 
NET_FRAGMENT.Len to the number of bytes received. Instead, it times out.

I know the packet is being sent (I can see it on wireshark). Also, if the 
actual packet size and my buffer size match, then everything works fine. It 
only times out when the actual packet size is smaller than my buffer.

Here is example code. What am I doing wrong?

EFI_STATUS
ExampleReceive (
  IN EXAMPLE_PRIVATE  *Private,
  IN OUT UINT32   *DataSize,
  IN OUT UINT8*Data
  )
{
  EFI_STATUSStatus;
  NET_FRAGMENT  Fragment;
  NET_BUF   *Packet;

  Fragment.Len = *DataSize;
  Fragment.Bulk = Data;
  Packet = NetbufFromExt (
 &Fragment,
 1,
 0,
 0,
 ExampleNbufExtFree,
 NULL
 );
  if (Packet == NULL) {
return EFI_OUT_OF_RESOURCES;
  }

  Status = gBS->SetTimer (
  Private->RxTimeoutEvent,
  TimerRelative,
  5 * TICKS_PER_SECOND
  );
  if (EFI_ERROR (Status)) {
NetbufFree (Packet);
return Status;
  }

  Status = TcpIoReceive (
 &Private->TcpIo,
 Packet,
 FALSE,
 Private->RxTimeoutEvent
 );

  gBS->SetTimer (Private->RxTimeoutEvent, TimerCancel, 0);
  NetbufFree (Packet);

  if (!EFI_ERROR (Status)) {
*DataSize = Fragment.Len;
  }

  return Status;
}

If the incoming packet is 1024 bytes, then the following code will work as 
expected. If the incoming packet is less than 1024 bytes, then it will return 
EFI_TIMEOUT after 5 seconds.

DataSize = 1024; // this number is arbitrary
Data = AllocatePool (DataSize);
ExampleReceive (Private, &DataSize, Data);

If I'm doing something wrong, then how would I receive a packet where I know 
the maximum size, but I don't know the exact size? I'm using 
UDK2010.SR1.UP1.P1. Thank you for any insight.

Thomas Rognon
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel