Re: [edk2] [Patch] ShellPkg: Fix ifconfig hang issue with incomplete parameters

2015-12-09 Thread Leekha Shaveta
Hi,

Yes, its working now with this patch. Not showing any ASSERT now.

Results snippets are:

Shell> ifconfig -s eth0 tatic
Unknown commands. Bad command tatic is skipped.
Shell> ifconfig -s eth0 static 192.168.1.141 255.255.255.0 192.168.1.1
InstallProtocolInterface: F4B427BB-BA21-4F16-BC4E-43E416AB619C DF512A30
Shell> ping 192.168.1.1
InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF5149E0
Ping 192.168.1.1 16 data bytes.
16 bytes from 192.168.1.1 : icmp_seq=1 ttl=0 time<0ms
16 bytes from 192.168.1.1 : icmp_seq=2 ttl=0 time<0ms
16 bytes from 192.168.1.1 : icmp_seq=3 ttl=0 time<0ms
16 bytes from 192.168.1.1 : icmp_seq=4 ttl=0 time<0ms
16 bytes from 192.168.1.1 : icmp_seq=5 ttl=0 time<0ms
16 bytes from 192.168.1.1 : icmp_seq=6 ttl=0 time<0ms
16 bytes from 192.168.1.1 : icmp_seq=7 ttl=0 time<0ms
16 bytes from 192.168.1.1 : icmp_seq=8 ttl=0 time<0ms
16 bytes from 192.168.1.1 : icmp_seq=9 ttl=0 time<0ms
16 bytes from 192.168.1.1 : icmp_seq=10 ttl=0 time<0ms

10 packets transmitted, 10 received, 0% packet loss, time 0ms

Rtt(round trip time) min=0ms max=0ms avg=0ms
Shell> ifconfig -s eth0 static 192.168.2.142
Lack interface config option.
Shell>

Thanks and Regards,
Shaveta

-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com] 
Sent: Thursday, December 10, 2015 7:56 AM
To: Leekha Shaveta-B20052 <shav...@freescale.com>; Carsey, Jaben 
<jaben.car...@intel.com>; edk2-devel@lists.01.org
Cc: Ye, Ting <ting...@intel.com>
Subject: RE: [Patch] ShellPkg: Fix ifconfig hang issue with incomplete 
parameters

Hi Shaveta,
How about your test result?

Thanks.
Jiaxin

-Original Message-
From: Leekha Shaveta [mailto:shav...@freescale.com]
Sent: Tuesday, December 8, 2015 2:21 PM
To: Carsey, Jaben; Wu, Jiaxin; edk2-devel@lists.01.org
Cc: Ye, Ting
Subject: RE: [Patch] ShellPkg: Fix ifconfig hang issue with incomplete 
parameters

Hi,

Thanks for the fix, I will test it and revert in a day or two.

Regards,
Shaveta

-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Friday, December 04, 2015 11:38 PM
To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org
Cc: Leekha Shaveta-B20052 <shav...@freescale.com>; Ye, Ting 
<ting...@intel.com>; Carsey, Jaben <jaben.car...@intel.com>
Subject: RE: [Patch] ShellPkg: Fix ifconfig hang issue with incomplete 
parameters

Looks good to me.  I think we should wait for Leekha for up to a few days to 
confirm that this fixes the problem at their location.

Reviewed-by: Jaben Carsey <jaben.car...@intel.com>

-Jaben

> -Original Message-
> From: Wu, Jiaxin
> Sent: Thursday, December 03, 2015 5:27 PM
> To: edk2-devel@lists.01.org
> Cc: Leekha Shaveta <shav...@freescale.com>; Carsey, Jaben 
> <jaben.car...@intel.com>; Ye, Ting <ting...@intel.com>
> Subject: [Patch] ShellPkg: Fix ifconfig hang issue with incomplete 
> parameters
> Importance: High
> 
> This patch is used to fix ifconfig hang issue with incomplete 
> parameters. In addition, some error related output information is 
> added to increase the interactivity.
> 
> Cc: Leekha Shaveta <shav...@freescale.com>
> Cc: Carsey Jaben <jaben.car...@intel.com>
> Cc: Ye Ting <ting...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu <jiaxin...@intel.com>
> ---
>  .../UefiShellNetwork1CommandsLib/Ifconfig.c|  61 --
> ---
>  .../UefiShellNetwork1CommandsLib.uni   | Bin 21094 -> 21256 bytes
>  2 files changed, 47 insertions(+), 14 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> index fb6f575..f8dbc88 100644
> --- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> +++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> @@ -826,10 +826,11 @@ IfConfigClearInterfaceInfo (
>  Ip4Config2DataTypePolicy,
>  sizeof (EFI_IP4_CONFIG2_POLICY),
>  
>  );
>  if (EFI_ERROR (Status)) {
> +  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ERR_AD),
> gShellNetwork1HiiHandle, L"ifconfig");
>ShellStatus = SHELL_ACCESS_DENIED;
>break;
>  }
>}
> 
> @@ -902,10 +903,11 @@ IfConfigSetInterfaceInfo (
>NULL,
>NULL,
>
>);
>if (EFI_ERROR (Status)) {
> +ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ERR_AD),
> gShellNetwork1HiiHandle, L"ifconfig");
>  ShellStatus = SHELL_ACCESS_DENIED;
>  goto ON_EXIT;
>}
> 
>Status = 

Re: [edk2] [Patch] ShellPkg: Fix ifconfig hang issue with incomplete parameters

2015-12-07 Thread Leekha Shaveta
Hi,

Thanks for the fix, I will test it and revert in a day or two.

Regards,
Shaveta

-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com] 
Sent: Friday, December 04, 2015 11:38 PM
To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org
Cc: Leekha Shaveta-B20052 <shav...@freescale.com>; Ye, Ting 
<ting...@intel.com>; Carsey, Jaben <jaben.car...@intel.com>
Subject: RE: [Patch] ShellPkg: Fix ifconfig hang issue with incomplete 
parameters

Looks good to me.  I think we should wait for Leekha for up to a few days to 
confirm that this fixes the problem at their location.

Reviewed-by: Jaben Carsey <jaben.car...@intel.com>

-Jaben

> -Original Message-
> From: Wu, Jiaxin
> Sent: Thursday, December 03, 2015 5:27 PM
> To: edk2-devel@lists.01.org
> Cc: Leekha Shaveta <shav...@freescale.com>; Carsey, Jaben 
> <jaben.car...@intel.com>; Ye, Ting <ting...@intel.com>
> Subject: [Patch] ShellPkg: Fix ifconfig hang issue with incomplete 
> parameters
> Importance: High
> 
> This patch is used to fix ifconfig hang issue with incomplete 
> parameters. In addition, some error related output information is 
> added to increase the interactivity.
> 
> Cc: Leekha Shaveta <shav...@freescale.com>
> Cc: Carsey Jaben <jaben.car...@intel.com>
> Cc: Ye Ting <ting...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu <jiaxin...@intel.com>
> ---
>  .../UefiShellNetwork1CommandsLib/Ifconfig.c|  61 --
> ---
>  .../UefiShellNetwork1CommandsLib.uni   | Bin 21094 -> 21256 bytes
>  2 files changed, 47 insertions(+), 14 deletions(-)
> 
> diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> index fb6f575..f8dbc88 100644
> --- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> +++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ifconfig.c
> @@ -826,10 +826,11 @@ IfConfigClearInterfaceInfo (
>  Ip4Config2DataTypePolicy,
>  sizeof (EFI_IP4_CONFIG2_POLICY),
>  
>  );
>  if (EFI_ERROR (Status)) {
> +  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ERR_AD),
> gShellNetwork1HiiHandle, L"ifconfig");
>ShellStatus = SHELL_ACCESS_DENIED;
>break;
>  }
>}
> 
> @@ -902,10 +903,11 @@ IfConfigSetInterfaceInfo (
>NULL,
>NULL,
>
>);
>if (EFI_ERROR (Status)) {
> +ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ERR_AD),
> gShellNetwork1HiiHandle, L"ifconfig");
>  ShellStatus = SHELL_ACCESS_DENIED;
>  goto ON_EXIT;
>}
> 
>Status = gBS->CreateEvent (
> @@ -914,10 +916,11 @@ IfConfigSetInterfaceInfo (
>IfConfigManualAddressNotify,
>,
>
>);
>if (EFI_ERROR (Status)) {
> +ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN (STR_GEN_ERR_AD),
> gShellNetwork1HiiHandle, L"ifconfig");
>  ShellStatus = SHELL_ACCESS_DENIED;
>  goto ON_EXIT;
>}
> 
>//
> @@ -972,10 +975,11 @@ IfConfigSetInterfaceInfo (
>  //
>  if (StrCmp(VarArg->Arg, L"dhcp") == 0) {
>if (IfCb->Policy == Ip4Config2PolicyDhcp) {
>  Status = IfConfigStartIp4 (IfCb->NicHandle, gImageHandle);
>  if (EFI_ERROR(Status)) {
> +  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 
> + (STR_GEN_ERR_AD),
> gShellNetwork1HiiHandle, L"ifconfig");
>ShellStatus = SHELL_ACCESS_DENIED;
>goto ON_EXIT;
>  }
>} else {
>  //
> @@ -987,74 +991,100 @@ IfConfigSetInterfaceInfo (
>  Ip4Config2DataTypePolicy,
>  sizeof (EFI_IP4_CONFIG2_POLICY),
>  
>  );
>  if (EFI_ERROR(Status)) {
> +  ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN 
> + (STR_GEN_ERR_AD),
> gShellNetwork1HiiHandle, L"ifconfig");
>ShellStatus = SHELL_ACCESS_DENIED;
>goto ON_EXIT;
>  }
>}
> 
>VarArg= VarArg->Next;
> 
>  } else if (StrCmp (VarArg->Arg, L"static") == 0) {
> -  //
> -  // Set manual config policy.
> -  //
> -  Policy = Ip4Config2PolicyStatic;
> -  Status = IfCb->IfCfg->SetData (
> -   

Re: [edk2] ifconfig command issue in edk2

2015-12-02 Thread Leekha Shaveta
Thanks Jiaxin!

Shell> ifconfig -s eth0 static 192.168.112 ifconfig -s eth0 static 
Shell> 192.169 con
'con' is not recognized as an internal or external command, operable program, 
or script file.

These were actually not the issues.

I have just quoted some examples, where we give incomplete parameters to 
ifconfig, still it doesn't hang.

Thanks and Regards,
Shaveta

-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com] 
Sent: Thursday, December 03, 2015 6:33 AM
To: Ye, Ting <ting...@intel.com>; Leekha Shaveta-B20052 
<shav...@freescale.com>; edk2-devel@lists.01.org
Cc: Sharma Bhupesh-B45370 <bhupesh.sha...@freescale.com>
Subject: RE: ifconfig command issue in edk2

Hi Shaveta,
Thanks for your finding, we have rootcause the hang issue in ifconfig , and 
will fix it as soon as possible.

Thanks.
Jiaxin

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ye, Ting
Sent: Wednesday, December 2, 2015 9:21 AM
To: Leekha Shaveta; edk2-devel@lists.01.org
Cc: Sharma Bhupesh
Subject: Re: [edk2] ifconfig command issue in edk2

Hi Shaveta,

We will try to reproduce the ASSERT issue at first. We will investigate how to 
fix it as soon as we can reproduce this, or back to you once we fail to 
reproduce.

For below one, it seems you split the ifconfig command to two parts, and shell 
does not recognize the second part as 'con' is not a command.

Shell> ifconfig -s eth0 static 192.168.112 ifconfig -s eth0 static 
Shell> 192.169 con
'con' is not recognized as an internal or external command, operable program, 
or script file.

Best Regards,
Ye Ting

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leekha 
Shaveta
Sent: Tuesday, December 01, 2015 7:53 PM
To: edk2-devel@lists.01.org
Cc: Sharma Bhupesh
Subject: [edk2] ifconfig command issue in edk2

Hi,

I am observing one issue while using "ifconfig" command.

When ifconfig command is used with incomplete parameters like below, it hangs 
the system by throwing an ASSERT:

Shell> ifconfig -s eth0 static 192.168.2.142
ASSERT 
/home/jenkins/ci/sdk/sdk-ls1043a/ls1043ardb/ls1043a-uefi/MdePkg/Library/BaseLib/String.c(173):
 ((UINTN) String & 0x0001) == 0


Whereas in some other cases, it simply returns to prompt:
Shell> ifconfig -s eth0 static 192.168.112 ifconfig -s eth0 static 
Shell> 192.169 con
'con' is not recognized as an internal or external command, operable program, 
or script file.
Shell>


Is this some known issue or any pointer why is this happening?

Regards,
Shaveta

-Original Message-
From: Leekha Shaveta-B20052
Sent: Thursday, September 24, 2015 1:17 PM
To: 'Ye, Ting' <ting...@intel.com>; edk2-devel@lists.01.org
Subject: RE: Ping 1st packet reply missing

Hi Ye Ting

Ping issue is resolved now.

I found in some old edk2 mails that it was some issue in Ping command 
implementation(Snippet pasted below).
After making TxRing ready beforehand, this issue get resolved now.

But TFTP issue is the one, I am still facing, any pointers on that?

Thanks and Regards,
Shaveta

Snippet of that mail chain issue :

Re: [edk2] Missing Ping Reply
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 function "PingSendEchoRequest", the ICMP message is sent out first 
before the entry is inserted into TxList. The reply comes back before the call 
comes back from "Transmit" function of the IPV4 protocol. 

-Original Message-
From: Ye, Ting [mailto:ting...@intel.com]
Sent: Thursday, September 24, 2015 1:01 PM
To: Leekha Shaveta-B20052 <shav...@freescale.com>; edk2-devel@lists.01.org
Subject: RE: Ping 1st packet reply missing

We did not meet this error before. Could you please share your captured packet 
and network topology for analysis? 

Best Regards,
Ye Ting

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leekha 
Shaveta
Sent: Thursday, September 24, 2015 1:45 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Ping 1st packet reply missing


Hi,

My ping is working  with Intel's E1000 driver code.

But everytime 1st packet is not getting received successfully, is there some 
known issue here, or something to be set/missing?

Regards,
Shaveta

Ping Snippet:
===
Shell> ping 192.168.3.1ping 192.168.3.1 -n 16
InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF56EA60 Ping 
192.168.3.1 16 data bytes.
GigAdapter->cur_rx_ind: 0
GigAdapter->cur_rx_ind: 1
16 bytes from 192.168.3.1 : icmp_seq=2 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 2
16 bytes from 192.168.3.1 : icmp_seq=3 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 3
16 byt

[edk2] ifconfig command issue in edk2

2015-12-01 Thread Leekha Shaveta
Hi,

I am observing one issue while using "ifconfig" command.

When ifconfig command is used with incomplete parameters like below, it hangs 
the system by throwing an ASSERT:

Shell> ifconfig -s eth0 static 192.168.2.142
ASSERT 
/home/jenkins/ci/sdk/sdk-ls1043a/ls1043ardb/ls1043a-uefi/MdePkg/Library/BaseLib/String.c(173):
 ((UINTN) String & 0x0001) == 0


Whereas in some other cases, it simply returns to prompt:
Shell> ifconfig -s eth0 static 192.168.112
Shell> ifconfig -s eth0 static 192.169
Shell> con
'con' is not recognized as an internal or external command, operable program, 
or script file.
Shell>


Is this some known issue or any pointer why is this happening?

Regards,
Shaveta

-Original Message-
From: Leekha Shaveta-B20052 
Sent: Thursday, September 24, 2015 1:17 PM
To: 'Ye, Ting' <ting...@intel.com>; edk2-devel@lists.01.org
Subject: RE: Ping 1st packet reply missing

Hi Ye Ting

Ping issue is resolved now.

I found in some old edk2 mails that it was some issue in Ping command 
implementation(Snippet pasted below).
After making TxRing ready beforehand, this issue get resolved now.

But TFTP issue is the one, I am still facing, any pointers on that?

Thanks and Regards,
Shaveta

Snippet of that mail chain issue :

Re: [edk2] Missing Ping Reply
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 function "PingSendEchoRequest", the ICMP message is sent out first 
before the entry is inserted into TxList. The reply comes back before the call 
comes back from "Transmit" function of the IPV4 protocol. 

-Original Message-
From: Ye, Ting [mailto:ting...@intel.com]
Sent: Thursday, September 24, 2015 1:01 PM
To: Leekha Shaveta-B20052 <shav...@freescale.com>; edk2-devel@lists.01.org
Subject: RE: Ping 1st packet reply missing

We did not meet this error before. Could you please share your captured packet 
and network topology for analysis? 

Best Regards,
Ye Ting

-Original Message-----
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leekha 
Shaveta
Sent: Thursday, September 24, 2015 1:45 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Ping 1st packet reply missing


Hi,

My ping is working  with Intel's E1000 driver code.

But everytime 1st packet is not getting received successfully, is there some 
known issue here, or something to be set/missing?

Regards,
Shaveta

Ping Snippet:
===
Shell> ping 192.168.3.1ping 192.168.3.1 -n 16
InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF56EA60 Ping 
192.168.3.1 16 data bytes.
GigAdapter->cur_rx_ind: 0
GigAdapter->cur_rx_ind: 1
16 bytes from 192.168.3.1 : icmp_seq=2 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 2
16 bytes from 192.168.3.1 : icmp_seq=3 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 3
16 bytes from 192.168.3.1 : icmp_seq=4 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 4
16 bytes from 192.168.3.1 : icmp_seq=5 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 5
16 bytes from 192.168.3.1 : icmp_seq=6 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 6
16 bytes from 192.168.3.1 : icmp_seq=7 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 7
16 bytes from 192.168.3.1 : icmp_seq=8 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 0
16 bytes from 192.168.3.1 : icmp_seq=9 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 1
16 bytes from 192.168.3.1 : icmp_seq=10 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 2
16 bytes from 192.168.3.1 : icmp_seq=11 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 3
16 bytes from 192.168.3.1 : icmp_seq=12 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 4
16 bytes from 192.168.3.1 : icmp_seq=13 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 5
16 bytes from 192.168.3.1 : icmp_seq=14 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 6
16 bytes from 192.168.3.1 : icmp_seq=15 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 7
16 bytes from 192.168.3.1 : icmp_seq=16 ttl=0 time=1ms

16 packets transmitted, 15 received, 6% packet loss, time 15ms

Rtt(round trip time) min=1ms max=1ms avg=1ms

 Sent 1 packet:
Shell> ping 192.168.3.1 -n 1
InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF56EA60 Ping 
192.168.3.1 16 data bytes.
GigAdapter->cur_rx_ind: 4

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

> -Original Message-
> From: Leekha Shaveta-B20052
> Sent: Saturday, September 12, 2015 11:34 PM
> To: 'Benjamin Herrenschmidt' 
> <b...@kernel.crashing.org<mailto:b...@kernel.crashing.org>>; 'Andrew 
> Fish' <af...@apple.com<mailto:af...@apple.com>>;
> 'edk2-devel@lists.01.org' 
> <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>; 'Tian, 
> Feng' <feng.t...@intel.com<mailto:feng.t...@

Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-28 Thread Leekha Shaveta
Hi,

I am not using DHCP

I am setting IP statically using command:

Shell> ifconfig -s eth0 static 192.168.3.154 255.255.252.0 192.168.3.1
InstallProtocolInterface: F4B427BB-BA21-4F16-BC4E-43E416AB619C DF5118B0
Shell> ping 192.168.3.221
InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF5129E0
Ping 192.168.3.221 16 data bytes.
16 bytes from 192.168.3.221 : icmp_seq=1 ttl=0 time<0ms

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

Rtt(round trip time) min=0ms max=0ms avg=0ms
Shell>


Thanks and Regards,
Shaveta


-Original Message-
From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo Bonzini
Sent: Monday, September 28, 2015 4:57 PM
To: Leekha Shaveta-B20052 <shav...@freescale.com>; Laszlo Ersek 
<ler...@redhat.com>
Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Gary Ching-Pang Lin 
<g...@suse.com>; Fu, Siyuan <siyuan...@intel.com>; Chris Cuthbert 
<nd6...@hotmail.com>
Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing



On 28/09/2015 12:24, Leekha Shaveta wrote:
> Hi Laszlo,
> 
> Please find the detailed "tcpdump" on my setup:

You still aren't following Laszlo's instructions: "your dump is missing the 
DHCP packets that should be captured while the ifconfig program (launched from 
the UEFI shell) brings up the interface on which you later use TFTP"

Paolo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-25 Thread Leekha Shaveta


-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Friday, September 25, 2015 1:04 AM
To: Leekha Shaveta-B20052 <shav...@freescale.com>
Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
<siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary Ching-Pang Lin 
<g...@suse.com>
Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing

On 09/24/15 13:08, Laszlo Ersek wrote:

> BTW when I wrote that I had just tested PXE boot, I didn't use the 
> UEFI shell utility; it was a network boot option instead.

Now I tested the shell command too, in my usual virtual network environment; it 
works fine for me.

Thanks
Laszlo

I Too faced compilation issues, so I picked up "Guid/NicIp4ConfigNvData.h" file 
from tianocore site
" 
http://sourceforge.net/p/tianocore/edk2/ci/2638c111076f9a49d4766ca5acbafa0eb7f66a18/tree/MdeModulePkg/Include/Guid/NicIp4ConfigNvData.h;
Copied it in Guid folder and my code compiled.

Is this the correct file to compile the code with?

Regards,
Shaveta

> 
> ... I tried to build the TFTP shell command into OVMF now, just to 
> test it, but it failed to compile, and the patch that supposedly fixes 
> it is not readable on the list. :(
> 
> Thanks
> Laszlo
> 
>>
>> Thanks and regards,
>> Shaveta
>>
>> -Original Message-----
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Thursday, September 24, 2015 2:05 PM
>> To: Leekha Shaveta-B20052 <shav...@freescale.com>
>> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
>> <siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary 
>> Ching-Pang Lin <g...@suse.com>
>> Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing
>>
>> On 09/24/15 08:04, Leekha Shaveta wrote:
>>> Hi,
>>>
>>> Tftp is also giving issues.
>>>
>>> During tftp, as one of its step it calls " GetFileSize"
>>> Which go through Mtftp4 protocol and calls " Mtftp4->GetInfo"
>>>
>>> And this fails.
>>>
>>> Any idea what is the issue with tftp command? Has anyone tested it 
>>> successfully?
>>
>> I frequently retest TFTP, and I just did it right now as well, on top of 
>> current master. It works fine. My test environment is a virtual network, 
>> where OVMF runs in a virtual machine, and DHCP and TFTP are configured by 
>> libvirt and served by dnsmasq. The edk2 PXE client downloads shim, then shim 
>> downloads grub (with the PXE Base Code protocol), then grub downloads the 
>> kernel and the initial ramdisk, for a networked linux installation.
>>
>> I have encountered and/or investigated quite a few TFTP issues, and 
>> most of the time they have occurred due to problematic DHCP or TFTP 
>> config, or problems in UEFI applications, or lower level network 
>> driver implementations. (In several other cases though, people 
>> contributed edk2 fixes ultimately.)
>>
>> Anyhow, the first thing to in such cases is to capture a detailed packet log 
>> with tcpdump or wireshark, and analyze the packets against the DHCP / TFTP 
>> server config, the DHCP / PXE specs, and the edk2 code. Usually (again, in 
>> my experience, although I don't claim to be an expert), the DHCP / TFTP 
>> server config, or -- possibly -- the network is the culprit.
>>
>> Please capture some packets, and analyze them. Analyzing DHCP packets 
>> against the specs and the server config takes forever, but I've found it to 
>> be the only way. Good luck.
>>
>> Thanks
>> Laszlo
>>
>>
>>>
>>> Thanks and Regards,
>>> Shaveta
>>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
>>> Of Leekha Shaveta
>>> Sent: Thursday, September 24, 2015 11:15 AM
>>> To: edk2-devel@lists.01.org
>>> Subject: [edk2] Ping 1st packet reply missing
>>>
>>>
>>> Hi,
>>>
>>> My ping is working  with Intel's E1000 driver code.
>>>
>>> But everytime 1st packet is not getting received successfully, is there 
>>> some known issue here, or something to be set/missing?
>>>
>>> Regards,
>>> Shaveta
>>>
>>> Ping Snippet:
>>> ===
>>> Shell> ping 192.168.3.1ping 192.168.3.1 -n 16
>>> InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF56EA60 
>>> Ping 192.168.3.1 16 data bytes.
>>> GigAdapter->cur_rx_ind: 0
>>> GigAdapter->cur_rx_ind: 1
>>> 

Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-25 Thread Leekha Shaveta


-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Friday, September 25, 2015 3:11 PM
To: Leekha Shaveta-B20052 <shav...@freescale.com>
Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
<siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary Ching-Pang Lin 
<g...@suse.com>
Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing

On 09/25/15 09:21, Leekha Shaveta wrote:
> 
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, September 25, 2015 1:04 AM
> To: Leekha Shaveta-B20052 <shav...@freescale.com>
> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
> <siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary 
> Ching-Pang Lin <g...@suse.com>
> Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing
> 
> On 09/24/15 13:08, Laszlo Ersek wrote:
> 
>> BTW when I wrote that I had just tested PXE boot, I didn't use the 
>> UEFI shell utility; it was a network boot option instead.
> 
> Now I tested the shell command too, in my usual virtual network environment; 
> it works fine for me.
> 
> Thanks
> Laszlo
> 
> I Too faced compilation issues, so I picked up 
> "Guid/NicIp4ConfigNvData.h" file from tianocore site " 
> http://sourceforge.net/p/tianocore/edk2/ci/2638c111076f9a49d4766ca5acbafa0eb7f66a18/tree/MdeModulePkg/Include/Guid/NicIp4ConfigNvData.h;
> Copied it in Guid folder and my code compiled.
> 
> Is this the correct file to compile the code with?

No. Please pull the new commits; Jaben checked in the patch that fixes the 
build (on Windows at least, and I have a pending patch that fixes it with gcc 
too).

Thanks
Laszlo


Thanks Laszlo!

I am not working on windows, so will wait for the patch that you are going to 
send to fix this.

I had captured TCPDUMP during TFTP on server:
test@boardfram-OptiPlex-790:/tftpboot$ sudo tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
22:04:50.929700 ARP, Request who-has 192.168.3.221 tell 192.168.3.154, length 46
22:04:50.929720 ARP, Reply 192.168.3.221 is-at 18:03:73:15:7b:12 (oui Unknown), 
length 28
22:04:50.988247 IP 192.168.3.154.ingreslock > 192.168.3.221.tftp:  21 RRQ 
"test" octet tsize 0
22:04:50.990025 IP 192.168.3.221.50033 > 192.168.3.154.ingreslock: UDP, length 
23
22:04:51.013103 IP 192.168.3.154.ingreslock > 192.168.3.221.50033: UDP, length 
26

Any idea what is this "ingreslock"  in these dump??

Regards,
Shaveta


> 
> Regards,
> Shaveta
> 
>>
>> ... I tried to build the TFTP shell command into OVMF now, just to 
>> test it, but it failed to compile, and the patch that supposedly 
>> fixes it is not readable on the list. :(
>>
>> Thanks
>> Laszlo
>>
>>>
>>> Thanks and regards,
>>> Shaveta
>>>
>>> -Original Message-
>>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>>> Sent: Thursday, September 24, 2015 2:05 PM
>>> To: Leekha Shaveta-B20052 <shav...@freescale.com>
>>> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
>>> <siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary 
>>> Ching-Pang Lin <g...@suse.com>
>>> Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing
>>>
>>> On 09/24/15 08:04, Leekha Shaveta wrote:
>>>> Hi,
>>>>
>>>> Tftp is also giving issues.
>>>>
>>>> During tftp, as one of its step it calls " GetFileSize"
>>>> Which go through Mtftp4 protocol and calls " Mtftp4->GetInfo"
>>>>
>>>> And this fails.
>>>>
>>>> Any idea what is the issue with tftp command? Has anyone tested it 
>>>> successfully?
>>>
>>> I frequently retest TFTP, and I just did it right now as well, on top of 
>>> current master. It works fine. My test environment is a virtual network, 
>>> where OVMF runs in a virtual machine, and DHCP and TFTP are configured by 
>>> libvirt and served by dnsmasq. The edk2 PXE client downloads shim, then 
>>> shim downloads grub (with the PXE Base Code protocol), then grub downloads 
>>> the kernel and the initial ramdisk, for a networked linux installation.
>>>
>>> I have encountered and/or investigated quite a few TFTP issues, and 
>>> most of the time they have occurred due to problematic DHCP or TFTP 
>>> config, or problems in UEFI applications, or lower level network 
>>> driver im

Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-24 Thread Leekha Shaveta
Hi,

I more point to add.

With the same server configuration, UBOOT bootloader is able to do tftp 
successfully whereas UEFI fails.

Regards,
Shaveta

-Original Message-
From: Leekha Shaveta-B20052 
Sent: Thursday, September 24, 2015 2:52 PM
To: 'Laszlo Ersek' <ler...@redhat.com>
Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
<siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary Ching-Pang Lin 
<g...@suse.com>
Subject: RE: [edk2] TFTP issue, Ping 1st packet reply missing

Hi Laszlo,

 What kind of " problematic DHCP or TFTP config "? What should be the right 
config for TFTP to work?

I have tftp file on TFTP server  "/etc/xinetd.d/tftp"  as follows :

service tftp
{
protocol= udp
port= 69
socket_type = dgram
wait= yes
user= root
server  = /usr/sbin/in.tftpd
server_args =  -c -s /tftpboot
disable = no
}

Tftp done:
Shell> tftp 192.168.3.230 test t2

TCPDUMP:
===
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
20:21:17.508537 ARP, Request who-has 192.168.3.230 tell 192.168.3.153, length 46
20:21:17.508548 ARP, Reply 192.168.3.230 is-at 68:05:ca:04:cd:99 (oui Unknown), 
length 28
20:21:17.562908 IP 192.168.3.153.2012 > 192.168.3.230.tftp:  21 RRQ "test" 
octet tsize 0
20:21:17.564335 IP 192.168.3.230.40029 > 192.168.3.153.2012: UDP, length 21

Does it give any hint??

Thanks and regards,
Shaveta

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Thursday, September 24, 2015 2:05 PM
To: Leekha Shaveta-B20052 <shav...@freescale.com>
Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
<siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary Ching-Pang Lin 
<g...@suse.com>
Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing

On 09/24/15 08:04, Leekha Shaveta wrote:
> Hi,
> 
> Tftp is also giving issues.
> 
> During tftp, as one of its step it calls " GetFileSize"
> Which go through Mtftp4 protocol and calls " Mtftp4->GetInfo"
> 
> And this fails.
> 
> Any idea what is the issue with tftp command? Has anyone tested it 
> successfully?

I frequently retest TFTP, and I just did it right now as well, on top of 
current master. It works fine. My test environment is a virtual network, where 
OVMF runs in a virtual machine, and DHCP and TFTP are configured by libvirt and 
served by dnsmasq. The edk2 PXE client downloads shim, then shim downloads grub 
(with the PXE Base Code protocol), then grub downloads the kernel and the 
initial ramdisk, for a networked linux installation.

I have encountered and/or investigated quite a few TFTP issues, and most of the 
time they have occurred due to problematic DHCP or TFTP config, or problems in 
UEFI applications, or lower level network driver implementations. (In several 
other cases though, people contributed edk2 fixes ultimately.)

Anyhow, the first thing to in such cases is to capture a detailed packet log 
with tcpdump or wireshark, and analyze the packets against the DHCP / TFTP 
server config, the DHCP / PXE specs, and the edk2 code. Usually (again, in my 
experience, although I don't claim to be an expert), the DHCP / TFTP server 
config, or -- possibly -- the network is the culprit.

Please capture some packets, and analyze them. Analyzing DHCP packets against 
the specs and the server config takes forever, but I've found it to be the only 
way. Good luck.

Thanks
Laszlo


> 
> Thanks and Regards,
> Shaveta
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Leekha Shaveta
> Sent: Thursday, September 24, 2015 11:15 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Ping 1st packet reply missing
> 
> 
> Hi,
> 
> My ping is working  with Intel's E1000 driver code.
> 
> But everytime 1st packet is not getting received successfully, is there some 
> known issue here, or something to be set/missing?
> 
> Regards,
> Shaveta
> 
> Ping Snippet:
> ===
> Shell> ping 192.168.3.1ping 192.168.3.1 -n 16
> InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF56EA60 Ping 
> 192.168.3.1 16 data bytes.
> GigAdapter->cur_rx_ind: 0
> GigAdapter->cur_rx_ind: 1
> 16 bytes from 192.168.3.1 : icmp_seq=2 ttl=0 time=1ms
> GigAdapter->cur_rx_ind: 2
> 16 bytes from 192.168.3.1 : icmp_seq=3 ttl=0 time=1ms
> GigAdapter->cur_rx_ind: 3
> 16 bytes from 192.168.3.1 : icmp_seq=4 ttl=0 time=1ms
> GigAdapter->cur_rx_ind: 4
> 16 bytes from 192.168.3.1 : icmp_seq=5 ttl=0 time=1ms
> GigAdapter->cur_rx_ind: 5
> 16 bytes from 192.168.3.1 : icmp_seq=6 ttl=0 time=1ms
> GigAdapter->cur_rx_ind: 6
> 16 bytes from 192.168.3.1 : icmp_seq=7 ttl=0 t

Re: [edk2] TFTP issue, Ping 1st packet reply missing

2015-09-24 Thread Leekha Shaveta
Hi Laszlo,

 What kind of " problematic DHCP or TFTP config "? What should be the right 
config for TFTP to work?

I have tftp file on TFTP server  "/etc/xinetd.d/tftp"  as follows :

service tftp
{
protocol= udp
port= 69
socket_type = dgram
wait= yes
user= root
server  = /usr/sbin/in.tftpd
server_args =  -c -s /tftpboot
disable = no
}

Tftp done:
Shell> tftp 192.168.3.230 test t2

TCPDUMP:
===
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
20:21:17.508537 ARP, Request who-has 192.168.3.230 tell 192.168.3.153, length 46
20:21:17.508548 ARP, Reply 192.168.3.230 is-at 68:05:ca:04:cd:99 (oui Unknown), 
length 28
20:21:17.562908 IP 192.168.3.153.2012 > 192.168.3.230.tftp:  21 RRQ "test" 
octet tsize 0
20:21:17.564335 IP 192.168.3.230.40029 > 192.168.3.153.2012: UDP, length 21

Does it give any hint??

Thanks and regards,
Shaveta

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, September 24, 2015 2:05 PM
To: Leekha Shaveta-B20052 <shav...@freescale.com>
Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Fu, Siyuan 
<siyuan...@intel.com>; Chris Cuthbert <nd6...@hotmail.com>; Gary Ching-Pang Lin 
<g...@suse.com>
Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing

On 09/24/15 08:04, Leekha Shaveta wrote:
> Hi,
> 
> Tftp is also giving issues.
> 
> During tftp, as one of its step it calls " GetFileSize"
> Which go through Mtftp4 protocol and calls " Mtftp4->GetInfo"
> 
> And this fails.
> 
> Any idea what is the issue with tftp command? Has anyone tested it 
> successfully?

I frequently retest TFTP, and I just did it right now as well, on top of 
current master. It works fine. My test environment is a virtual network, where 
OVMF runs in a virtual machine, and DHCP and TFTP are configured by libvirt and 
served by dnsmasq. The edk2 PXE client downloads shim, then shim downloads grub 
(with the PXE Base Code protocol), then grub downloads the kernel and the 
initial ramdisk, for a networked linux installation.

I have encountered and/or investigated quite a few TFTP issues, and most of the 
time they have occurred due to problematic DHCP or TFTP config, or problems in 
UEFI applications, or lower level network driver implementations. (In several 
other cases though, people contributed edk2 fixes ultimately.)

Anyhow, the first thing to in such cases is to capture a detailed packet log 
with tcpdump or wireshark, and analyze the packets against the DHCP / TFTP 
server config, the DHCP / PXE specs, and the edk2 code. Usually (again, in my 
experience, although I don't claim to be an expert), the DHCP / TFTP server 
config, or -- possibly -- the network is the culprit.

Please capture some packets, and analyze them. Analyzing DHCP packets against 
the specs and the server config takes forever, but I've found it to be the only 
way. Good luck.

Thanks
Laszlo


> 
> Thanks and Regards,
> Shaveta
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Leekha Shaveta
> Sent: Thursday, September 24, 2015 11:15 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Ping 1st packet reply missing
> 
> 
> Hi,
> 
> My ping is working  with Intel's E1000 driver code.
> 
> But everytime 1st packet is not getting received successfully, is there some 
> known issue here, or something to be set/missing?
> 
> Regards,
> Shaveta
> 
> Ping Snippet:
> ===
> Shell> ping 192.168.3.1ping 192.168.3.1 -n 16
> InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF56EA60 Ping 
> 192.168.3.1 16 data bytes.
> GigAdapter->cur_rx_ind: 0
> GigAdapter->cur_rx_ind: 1
> 16 bytes from 192.168.3.1 : icmp_seq=2 ttl=0 time=1ms
> GigAdapter->cur_rx_ind: 2
> 16 bytes from 192.168.3.1 : icmp_seq=3 ttl=0 time=1ms
> GigAdapter->cur_rx_ind: 3
> 16 bytes from 192.168.3.1 : icmp_seq=4 ttl=0 time=1ms
> GigAdapter->cur_rx_ind: 4
> 16 bytes from 192.168.3.1 : icmp_seq=5 ttl=0 time=1ms
> GigAdapter->cur_rx_ind: 5
> 16 bytes from 192.168.3.1 : icmp_seq=6 ttl=0 time=1ms
> GigAdapter->cur_rx_ind: 6
> 16 bytes from 192.168.3.1 : icmp_seq=7 ttl=0 time=1ms
> GigAdapter->cur_rx_ind: 7
> 16 bytes from 192.168.3.1 : icmp_seq=8 ttl=0 time=1ms
> GigAdapter->cur_rx_ind: 0
> 16 bytes from 192.168.3.1 : icmp_seq=9 ttl=0 time=1ms
> GigAdapter->cur_rx_ind: 1
> 16 bytes from 192.168.3.1 : icmp_seq=10 ttl=0 time=1ms
> GigAdapter->cur_rx_ind: 2
> 16 bytes from 192.168.3.1 : icmp_seq=11 ttl=0 time=1ms
> GigAdapter->cur_rx_ind: 3
> 16 bytes from 192.168.3.1 : icmp_seq=12 ttl=0 time=1ms
> GigAdapter->cur_rx_ind: 4
> 16 bytes from 192.168.3.1 : ic

[edk2] TFTP issue, Ping 1st packet reply missing

2015-09-24 Thread Leekha Shaveta
Hi,

Tftp is also giving issues.

During tftp, as one of its step it calls " GetFileSize"
Which go through Mtftp4 protocol and calls " Mtftp4->GetInfo"

And this fails.

Any idea what is the issue with tftp command? Has anyone tested it successfully?

Thanks and Regards,
Shaveta

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leekha 
Shaveta
Sent: Thursday, September 24, 2015 11:15 AM
To: edk2-devel@lists.01.org
Subject: [edk2] Ping 1st packet reply missing


Hi,

My ping is working  with Intel's E1000 driver code.

But everytime 1st packet is not getting received successfully, is there some 
known issue here, or something to be set/missing?

Regards,
Shaveta

Ping Snippet:
===
Shell> ping 192.168.3.1ping 192.168.3.1 -n 16
InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF56EA60 Ping 
192.168.3.1 16 data bytes.
GigAdapter->cur_rx_ind: 0
GigAdapter->cur_rx_ind: 1
16 bytes from 192.168.3.1 : icmp_seq=2 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 2
16 bytes from 192.168.3.1 : icmp_seq=3 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 3
16 bytes from 192.168.3.1 : icmp_seq=4 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 4
16 bytes from 192.168.3.1 : icmp_seq=5 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 5
16 bytes from 192.168.3.1 : icmp_seq=6 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 6
16 bytes from 192.168.3.1 : icmp_seq=7 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 7
16 bytes from 192.168.3.1 : icmp_seq=8 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 0
16 bytes from 192.168.3.1 : icmp_seq=9 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 1
16 bytes from 192.168.3.1 : icmp_seq=10 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 2
16 bytes from 192.168.3.1 : icmp_seq=11 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 3
16 bytes from 192.168.3.1 : icmp_seq=12 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 4
16 bytes from 192.168.3.1 : icmp_seq=13 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 5
16 bytes from 192.168.3.1 : icmp_seq=14 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 6
16 bytes from 192.168.3.1 : icmp_seq=15 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 7
16 bytes from 192.168.3.1 : icmp_seq=16 ttl=0 time=1ms

16 packets transmitted, 15 received, 6% packet loss, time 15ms

Rtt(round trip time) min=1ms max=1ms avg=1ms

 Sent 1 packet:
Shell> ping 192.168.3.1 -n 1
InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF56EA60 Ping 
192.168.3.1 16 data bytes.
GigAdapter->cur_rx_ind: 4

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

> -Original Message-
> From: Leekha Shaveta-B20052
> Sent: Saturday, September 12, 2015 11:34 PM
> To: 'Benjamin Herrenschmidt' 
> <b...@kernel.crashing.org<mailto:b...@kernel.crashing.org>>; 'Andrew 
> Fish' <af...@apple.com<mailto:af...@apple.com>>; 
> 'edk2-devel@lists.01.org' 
> <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>; 'Tian, 
> Feng' <feng.t...@intel.com<mailto:feng.t...@intel.com>>
> Subject: Re: PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root 
> bridge IOMap and IoAllocateBuffer)
>
> Hi
>
> I was implementing PCI RootBridgeIo protocol and have some doubts in "IoMap" 
> and "AllocateBuffer" functions of this protocol.
>
> In our platform, PCI space is starting form address 0x50__ (40 bit 
> addressable) And its mapping on PCI bus is like:
> 50__ => _ (32 bit)
>
> From where the "AllocateBuffer" function should allocate memory when asked by 
> any PCI device?
> What is the meaning of "Allocates pages that are suitable for an 
> EfiPciOperationBusMasterCommonBuffer or
> EfiPciOperationBusMasterCommonBuffer64 mapping"
>
> How to manage mapping in "RootBridgeIoMap" function?
>
> Thanks and Regards,
> Shaveta
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tian, Feng
> Sent: Wednesday, August 26, 2015 7:24 AM
> To: Benjamin Herrenschmidt 
> <b...@kernel.crashing.org<mailto:b...@kernel.crashing.org>>; Andrew 
> Fish <af...@apple.com<mailto:af...@apple.com>>
> Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org> 
> <edk2-de...@ml01.01.org<mailto:edk2-de...@ml01.01.org>>; Tian, Feng 
> <feng.t...@intel.com<mailto:feng.t...@intel.com>>
> Subject: Re: [edk2] PCI and non-1:1 mapping of MMIO space
>
> Hi, Ben & Andrew
>
> The GetBarAttributes() returns a set of ACPI 2.0 resource descriptors that 
> describe the current configuration of the BARs of the PCI controller.
>
> What I understood is the returned value of GetBarAttributes() is a CPU 
> address rather than a PCI address. From the view of PciIo, nobody needs to 
> know/use Bar's PCI address.
>
> Thanks
>

[edk2] Ping 1st packet reply missing

2015-09-23 Thread Leekha Shaveta

Hi,

My ping is working  with Intel's E1000 driver code.

But everytime 1st packet is not getting received successfully, is there some 
known issue here, or something to be set/missing?

Regards,
Shaveta

Ping Snippet:
===
Shell> ping 192.168.3.1ping 192.168.3.1 -n 16
InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF56EA60
Ping 192.168.3.1 16 data bytes.
GigAdapter->cur_rx_ind: 0
GigAdapter->cur_rx_ind: 1
16 bytes from 192.168.3.1 : icmp_seq=2 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 2
16 bytes from 192.168.3.1 : icmp_seq=3 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 3
16 bytes from 192.168.3.1 : icmp_seq=4 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 4
16 bytes from 192.168.3.1 : icmp_seq=5 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 5
16 bytes from 192.168.3.1 : icmp_seq=6 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 6
16 bytes from 192.168.3.1 : icmp_seq=7 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 7
16 bytes from 192.168.3.1 : icmp_seq=8 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 0
16 bytes from 192.168.3.1 : icmp_seq=9 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 1
16 bytes from 192.168.3.1 : icmp_seq=10 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 2
16 bytes from 192.168.3.1 : icmp_seq=11 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 3
16 bytes from 192.168.3.1 : icmp_seq=12 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 4
16 bytes from 192.168.3.1 : icmp_seq=13 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 5
16 bytes from 192.168.3.1 : icmp_seq=14 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 6
16 bytes from 192.168.3.1 : icmp_seq=15 ttl=0 time=1ms
GigAdapter->cur_rx_ind: 7
16 bytes from 192.168.3.1 : icmp_seq=16 ttl=0 time=1ms

16 packets transmitted, 15 received, 6% packet loss, time 15ms

Rtt(round trip time) min=1ms max=1ms avg=1ms

 Sent 1 packet:
Shell> ping 192.168.3.1 -n 1
InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF56EA60
Ping 192.168.3.1 16 data bytes.
GigAdapter->cur_rx_ind: 4

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

> -Original Message-
> From: Leekha Shaveta-B20052
> Sent: Saturday, September 12, 2015 11:34 PM
> To: 'Benjamin Herrenschmidt' 
> <b...@kernel.crashing.org<mailto:b...@kernel.crashing.org>>; 'Andrew Fish' 
> <af...@apple.com<mailto:af...@apple.com>>; 'edk2-devel@lists.01.org' 
> <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>; 'Tian, Feng' 
> <feng.t...@intel.com<mailto:feng.t...@intel.com>>
> Subject: Re: PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge 
> IOMap and IoAllocateBuffer)
>
> Hi
>
> I was implementing PCI RootBridgeIo protocol and have some doubts in "IoMap" 
> and "AllocateBuffer" functions of this protocol.
>
> In our platform, PCI space is starting form address 0x50__ (40 bit 
> addressable) And its mapping on PCI bus is like:
> 50__ => _ (32 bit)
>
> From where the "AllocateBuffer" function should allocate memory when asked by 
> any PCI device?
> What is the meaning of "Allocates pages that are suitable for an 
> EfiPciOperationBusMasterCommonBuffer or
> EfiPciOperationBusMasterCommonBuffer64 mapping"
>
> How to manage mapping in "RootBridgeIoMap" function?
>
> Thanks and Regards,
> Shaveta
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tian, 
> Feng
> Sent: Wednesday, August 26, 2015 7:24 AM
> To: Benjamin Herrenschmidt 
> <b...@kernel.crashing.org<mailto:b...@kernel.crashing.org>>; Andrew Fish 
> <af...@apple.com<mailto:af...@apple.com>>
> Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org> 
> <edk2-de...@ml01.01.org<mailto:edk2-de...@ml01.01.org>>; Tian, Feng 
> <feng.t...@intel.com<mailto:feng.t...@intel.com>>
> Subject: Re: [edk2] PCI and non-1:1 mapping of MMIO space
>
> Hi, Ben & Andrew
>
> The GetBarAttributes() returns a set of ACPI 2.0 resource descriptors that 
> describe the current configuration of the BARs of the PCI controller.
>
> What I understood is the returned value of GetBarAttributes() is a CPU 
> address rather than a PCI address. From the view of PciIo, nobody needs to 
> know/use Bar's PCI address.
>
> Thanks
> Feng
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Benjamin Herrenschmidt
> Sent: Wednesday, August 26, 2015 07:54
> To: Andrew Fish
> Cc: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Subject: Re: [edk2] PCI and non-1:1 mapping of MMIO space
>
> (Argh, I keep sending these from my IBM address which isn't the one on the 
> list. Sorry Andrew for the duplicates).
>
> On Tue, 2015-08-25 at 14:48 -0700, Andrew Fish wrote:
&

[edk2] FW: [PATCH V2] ShellPkg: Add optional 'tftp' EFI Shell command.

2015-09-21 Thread Leekha Shaveta
Hi

I am trying to run tftp on my setup (ping is working fine),
But I am getting following error:

Shell> tftp 192.168.3.230 test test4
InstallProtocolInterface: 7AB33A91-ACE5-4326-B572-E7EE33D39F16 DF570940
InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD DF589B20
InstallProtocolInterface: 3AD9DF29-4501-478D-B1F8-7F7FE70E50F3 DF58ABF8
InstallProtocolInterface: 78247C57-63DB-4708-99C2-A8B4A9A61F6B DF570930
e1000_Transmit
TFTP error code 512
Failed to get the size of the file 'test' on 'eth0' - TFTP Error
Shell>

Any idea what's missing here?

Thanks and Regards,
Shaveta


-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Wednesday, July 15, 2015 9:02 PM
To: Olivier Martin 
Cc: Ronald Cron ; edk2-de...@lists.sourceforge.net
Subject: Re: [edk2] [PATCH V2] ShellPkg: Add optional 'tftp' EFI Shell command.

Looks good to me.
Reviewed-by: Jaben Carsey 

> -Original Message-
> From: Olivier Martin [mailto:olivier.mar...@arm.com]
> Sent: Wednesday, July 15, 2015 8:12 AM
> To: Carsey, Jaben
> Cc: edk2-de...@lists.sourceforge.net; Ronald Cron; Ronald Cron
> Subject: [PATCH V2] ShellPkg: Add optional 'tftp' EFI Shell command.
> Importance: High
> 
> From: Ronald Cron 
> 
> This 'tftp' command allows to download a file from a TFTP server.
> A specific network interface can be chosen in case there are multiple 
> interfaces.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ronald Cron 
> Reviewed-by: Olivier Martin 
> ---
>  ShellPkg/Include/Guid/ShellLibHiiGuid.h|   7 +
>  ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c| 880
> +
>  .../UefiShellTftpCommandLib.c  |  97 +++
>  .../UefiShellTftpCommandLib.h  |  63 ++
>  .../UefiShellTftpCommandLib.inf|  61 ++
>  .../UefiShellTftpCommandLib.uni| Bin 0 -> 8748 bytes
>  ShellPkg/ShellPkg.dec  |   1 +
>  ShellPkg/ShellPkg.dsc  |   3 +
>  8 files changed, 1112 insertions(+)
>  create mode 100644 ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
>  create mode 100644
> ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.c
>  create mode 100644
> ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.h
>  create mode 100644
> ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.inf
>  create mode 100644
> ShellPkg/Library/UefiShellTftpCommandLib/UefiShellTftpCommandLib.uni
> 
> diff --git a/ShellPkg/Include/Guid/ShellLibHiiGuid.h
> b/ShellPkg/Include/Guid/ShellLibHiiGuid.h
> index dc694f2..62c2e72 100644
> --- a/ShellPkg/Include/Guid/ShellLibHiiGuid.h
> +++ b/ShellPkg/Include/Guid/ShellLibHiiGuid.h
> @@ -54,6 +54,12 @@
>{ \
>  0xf3d301bb, 0xf4a5, 0x45a8, { 0xb0, 0xb7, 0xfa, 0x99, 0x9c, 0x62, 
> 0x37, 0xae } \
>}
> +#define SHELL_TFTP_HII_GUID \
> +  { \
> +0x738a9314, 0x82c1, 0x4592, { 0x8f, 0xf7, 0xc1, 0xbd, 0xf1, 0xb2, 
> +0x0e,
> 0xd4 } \
> +  }
> +
> +
>  #define SHELL_BCFG_HII_GUID \
>{ \
>  0x5f5f605d, 0x1583, 0x4a2d, {0xa6, 0xb2, 0xeb, 0x12, 0xda, 0xb4, 
> 0xa2,
> 0xb6 } \
> @@ -67,6 +73,7 @@ extern EFI_GUID gShellLevel1HiiGuid;  extern 
> EFI_GUID gShellLevel2HiiGuid;  extern EFI_GUID gShellLevel3HiiGuid; 
> extern EFI_GUID gShellNetwork1HiiGuid;
> +extern EFI_GUID gShellTftpHiiGuid;
>  extern EFI_GUID gShellBcfgHiiGuid;
> 
>  #endif
> diff --git a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> new file mode 100644
> index 000..b872afd
> --- /dev/null
> +++ b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> @@ -0,0 +1,880 @@
> +/** @file
> +  The implementation for the 'tftp' Shell command.
> +
> +  Copyright (c) 2015, ARM Ltd. All rights reserved.
> +
> +  This program and the accompanying materials  are licensed and made 
> + available under the terms and conditions of the BSD
> License
> +  which accompanies this distribution.  The full text of the license 
> + may be
> found at
> +  http://opensource.org/licenses/bsd-license.php.
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +**/
> +
> +#include "UefiShellTftpCommandLib.h"
> +
> +/*
> +   Constant strings and definitions related to the message indicating 
> +the
> amount of
> +   progress in the dowloading of a TFTP file.
> +*/
> +
> +// Frame for the progression slider
> +STATIC CONST CHAR16 mTftpProgressFrame[] = L"[   
>  ]";
> +
> +// Number of steps in the progression slider #define 
> +TFTP_PROGRESS_SLIDER_STEPS  ((sizeof (mTftpProgressFrame) /
> sizeof (CHAR16)) - 3)
> +
> +// Size in number of characters plus one (final zero) of the message 
> +to // 

Re: [edk2] PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge IOMap and IoAllocateBuffer)

2015-09-16 Thread Leekha Shaveta

Thanks Ben! Some Replies and doubts  inlined.

Regards,
Shaveta

-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Sunday, September 13, 2015 4:39 AM
To: Leekha Shaveta-B20052 <shav...@freescale.com>; Andrew Fish 
<af...@apple.com>; edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Tian, Feng 
<feng.t...@intel.com>
Subject: Re: PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge 
IOMap and IoAllocateBuffer)

On Sat, 2015-09-12 at 18:04 +, Leekha Shaveta wrote:
> Hi
> 
> I was implementing  PCI RootBridgeIo protocol and have some doubts in 
> "IoMap" and "AllocateBuffer" functions of this protocol.
> 
> In our platform, PCI space is starting form address 0x50__
> (40 bit addressable)
> And its mapping on PCI bus is like:
>   50__ => _ (32 bit)

Is the above the mapping of MMIO or DMA ? Because AllocateBuffer/IoMap are all 
about DMA, not MMIO 

[Shaveta] It is MMIO mapping ...

Note that regarding the issue of non-1:1 mappings vs.
GetBarAttributes(), I have patches to fix that in the core by enabling us to 
use the mTranslationOffset field of the ACPI descriptor. I will be able to post 
these some time next week.


[Shaveta] What does those patches does?
As I my case also, CPU address 50_4000_ is being translated to PCI bus 
address 0x4000_  For memory transactions. So its also a case of non- 1:1 
mapping

For Mem.Read/Mem.Write I have added a translation offset.
For BARs programming also, do we need to handle it?

How have you handled it? 


> > From where the "AllocateBuffer" function should allocate memory when 
> > asked by any PCI device?
> What is the meaning of "Allocates pages that are suitable for an 
> EfiPciOperationBusMasterCommonBuffer or
>EfiPciOperationBusMasterCommonBuffer64 mapping"
> 
> How to manage mapping in "RootBridgeIoMap" function?

Well, it depends if the mapping you provided above is an MMIO mapping or a DMA 
mapping ... I to looks like MMIO to me in which case it has strictly nothing to 
do with IoMap/AllocateBuffer 

[Shaveta] then what kind of mapping IoMap function should do when PCI NIC card 
ask for this IoMap during its "ping" operation ??


Cheers,
Ben

> Thanks and Regards,
> Shaveta
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tian, Feng
> Sent: Wednesday, August 26, 2015 7:24 AM
> To: Benjamin Herrenschmidt <b...@kernel.crashing.org>; Andrew Fish < 
> af...@apple.com>
> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Tian, Feng < 
> feng.t...@intel.com>
> Subject: Re: [edk2] PCI and non-1:1 mapping of MMIO space
> 
> Hi, Ben & Andrew
> 
> The GetBarAttributes() returns a set of ACPI 2.0 resource descriptors 
> that describe the current configuration of the BARs of the PCI 
> controller.
> 
> What I understood is the returned value of GetBarAttributes() is a CPU 
> address rather than a PCI address. From the view of PciIo, nobody 
> needs to know/use Bar's PCI address.
> 
> Thanks
> Feng
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Benjamin Herrenschmidt
> Sent: Wednesday, August 26, 2015 07:54
> To: Andrew Fish
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] PCI and non-1:1 mapping of MMIO space
> 
> (Argh, I keep sending these from my IBM address which isn't the one on 
> the list. Sorry Andrew for the duplicates).
> 
> On Tue, 2015-08-25 at 14:48 -0700, Andrew Fish wrote:
> 
> > 
> > > So if we stick to the definition of GetBarAttributes() only 
> > > returning a BAR value, then it's impossible to implement a PCI GOP 
> > > driver by following the spec.
> > > 
> > I came to that conclusion too. 
> 
> :(
> 
> > > Now, there's one thing that might work, which would be to exploit 
> > > the "AddressTranslationOffset" field of the ACPI resource 
> > > descriptor.
> > > 
> > How do you represent a system like this in ACPI? It might be a good 
> > idea to solve it in a similar way.
> 
> Unfortunately, I am not familiar with the details of ACPI, I only have 
> a high level understanding of it. Our platforms have been Open 
> Firmware based for as far as I've been involved with them and lately, 
> we use C -generated flat device-tree along with a custom runtime 
> firmwarealled a  OPAL).
> 
> At this point I'm not (yet) considering a move to ACPI. I'm doing a 
> proof of concept ppc64 UEFI port to get a feel of the water 
> temperature more than anything else (though I'll be happy to 
> contribute things 

Re: [edk2] PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge IOMap and IoAllocateBuffer)

2015-09-12 Thread Leekha Shaveta
Thanks Andrew.

Replies inlined.

Regards, Shaveta

-Original Message-
From: af...@apple.com [mailto:af...@apple.com] 
Sent: Saturday, September 12, 2015 11:51 PM
To: Leekha Shaveta-B20052 <shav...@freescale.com>
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>; edk2-devel@lists.01.org; 
Tian, Feng <feng.t...@intel.com>
Subject: Re: PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge 
IOMap and IoAllocateBuffer)


> On Sep 12, 2015, at 11:04 AM, Leekha Shaveta <shav...@freescale.com> wrote:
> 
> Hi
> 
> I was implementing  PCI RootBridgeIo protocol and have some doubts in "IoMap" 
> and "AllocateBuffer" functions of this protocol.
> 
> In our platform, PCI space is starting form address 0x50__ (40 
> bit addressable) And its mapping on PCI bus is like:
>   50__ => _ (32 bit)
> 
> From where the "AllocateBuffer" function should allocate memory when asked by 
> any PCI device?
> What is the meaning of "Allocates pages that are suitable for an 
> EfiPciOperationBusMasterCommonBuffer or
>   EfiPciOperationBusMasterCommonBuffer64 mapping"
> 
> How to manage mapping in "RootBridgeIoMap" function?
> 

That is platform dependent. These buffers are for doing DMA. On x86 normal 
memory just works, for ARM you needed an uncached buffer, and you have to do 
some cache management to maintain coherency. 

[Shaveta] yes, I am working on an ARM platform. On ARM, "AllocateBuffer" 
function should return uncached buffer area? 
>From where this area need to be allocated? I mean from system memory or from 
>PCI space?
DDR/DRAM is DDR_ATTRIBUTES_CACHED
PCI space is " ARM_MEMORY_REGION_ATTRIBUTE_DEVICE"

Thanks,
Shaveta

Thanks,

Andrew Fish

> Thanks and Regards,
> Shaveta
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Tian, Feng
> Sent: Wednesday, August 26, 2015 7:24 AM
> To: Benjamin Herrenschmidt <b...@kernel.crashing.org>; Andrew Fish 
> <af...@apple.com>
> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Tian, Feng 
> <feng.t...@intel.com>
> Subject: Re: [edk2] PCI and non-1:1 mapping of MMIO space
> 
> Hi, Ben & Andrew
> 
> The GetBarAttributes() returns a set of ACPI 2.0 resource descriptors that 
> describe the current configuration of the BARs of the PCI controller.
> 
> What I understood is the returned value of GetBarAttributes() is a CPU 
> address rather than a PCI address. From the view of PciIo, nobody needs to 
> know/use Bar's PCI address.
> 
> Thanks
> Feng
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Benjamin Herrenschmidt
> Sent: Wednesday, August 26, 2015 07:54
> To: Andrew Fish
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] PCI and non-1:1 mapping of MMIO space
> 
> (Argh, I keep sending these from my IBM address which isn't the one on the 
> list. Sorry Andrew for the duplicates).
> 
> On Tue, 2015-08-25 at 14:48 -0700, Andrew Fish wrote:
> 
>> 
>>> So if we stick to the definition of GetBarAttributes() only 
>>> returning a BAR value, then it's impossible to implement a PCI GOP 
>>> driver by following the spec.
>>> 
>> I came to that conclusion too. 
> 
> :(
> 
>>> Now, there's one thing that might work, which would be to exploit 
>>> the "AddressTranslationOffset" field of the ACPI resource 
>>> descriptor.
>>> 
>> How do you represent a system like this in ACPI? It might be a good 
>> idea to solve it in a similar way.
> 
> Unfortunately, I am not familiar with the details of ACPI, I only have a high 
> level understanding of it. Our platforms have been Open Firmware based for as 
> far as I've been involved with them and lately, we use C -generated flat 
> device-tree along with a custom runtime firmwarealled a  OPAL).
> 
> At this point I'm not (yet) considering a move to ACPI. I'm doing a proof of 
> concept ppc64 UEFI port to get a feel of the water temperature more than 
> anything else (though I'll be happy to contribute things back once I get the 
> appropriate legalese sorted internally to IBM).
> 
>> The PCI IO was designed to not required the 1:1 mapping. The direct 
>> access to the Framebuffer came along later, as was mostly a fallback 
>> for the OS on a safe mode boot kind of thing. I think we missed 
>> passing the frame buffer out on a system that was not 1:1.
> 
> Ok. Well, it will be needed even on non-1:1 systems, we will have similar 
> requirements of the OS needing an early boot framebuffer etc...
> and I su

Re: [edk2] PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge IOMap and IoAllocateBuffer)

2015-09-12 Thread Leekha Shaveta
Hi

I was implementing  PCI RootBridgeIo protocol and have some doubts in "IoMap" 
and "AllocateBuffer" functions of this protocol.

In our platform, PCI space is starting form address 0x50__ (40 bit 
addressable)
And its mapping on PCI bus is like:
50__ => _ (32 bit)

>From where the "AllocateBuffer" function should allocate memory when asked by 
>any PCI device?
What is the meaning of "Allocates pages that are suitable for an 
EfiPciOperationBusMasterCommonBuffer or
   EfiPciOperationBusMasterCommonBuffer64 mapping"

How to manage mapping in "RootBridgeIoMap" function?

Thanks and Regards,
Shaveta

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tian, 
Feng
Sent: Wednesday, August 26, 2015 7:24 AM
To: Benjamin Herrenschmidt ; Andrew Fish 

Cc: edk2-devel@lists.01.org ; Tian, Feng 

Subject: Re: [edk2] PCI and non-1:1 mapping of MMIO space

Hi, Ben & Andrew

The GetBarAttributes() returns a set of ACPI 2.0 resource descriptors that 
describe the current configuration of the BARs of the PCI controller.

What I understood is the returned value of GetBarAttributes() is a CPU address 
rather than a PCI address. From the view of PciIo, nobody needs to know/use 
Bar's PCI address.

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Benjamin 
Herrenschmidt
Sent: Wednesday, August 26, 2015 07:54
To: Andrew Fish
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] PCI and non-1:1 mapping of MMIO space

(Argh, I keep sending these from my IBM address which isn't the one on the 
list. Sorry Andrew for the duplicates).

On Tue, 2015-08-25 at 14:48 -0700, Andrew Fish wrote:

> 
> > So if we stick to the definition of GetBarAttributes() only 
> > returning a BAR value, then it's impossible to implement a PCI GOP 
> > driver by following the spec.
> > 
> I came to that conclusion too. 

:(

> > Now, there's one thing that might work, which would be to exploit 
> > the "AddressTranslationOffset" field of the ACPI resource 
> > descriptor.
> > 
> How do you represent a system like this in ACPI? It might be a good 
> idea to solve it in a similar way.

Unfortunately, I am not familiar with the details of ACPI, I only have a high 
level understanding of it. Our platforms have been Open Firmware based for as 
far as I've been involved with them and lately, we use C -generated flat 
device-tree along with a custom runtime firmwarealled a  OPAL).

At this point I'm not (yet) considering a move to ACPI. I'm doing a proof of 
concept ppc64 UEFI port to get a feel of the water temperature more than 
anything else (though I'll be happy to contribute things back once I get the 
appropriate legalese sorted internally to IBM).

> The PCI IO was designed to not required the 1:1 mapping. The direct 
> access to the Framebuffer came along later, as was mostly a fallback 
> for the OS on a safe mode boot kind of thing. I think we missed 
> passing the frame buffer out on a system that was not 1:1.

Ok. Well, it will be needed even on non-1:1 systems, we will have similar 
requirements of the OS needing an early boot framebuffer etc...
and I suspect the desire to directly access BARs (at least prefetchable
ones) from the CPU isn't going away in other areas either.

So maybe we should try to address this. I'm trying to figure out how to join 
the appropriate working groups etc... so I can participate in the spec side 
discussion as well (which I'll need to do for other reasons anyway if we are 
ever going to officially defining the ppc64 ABI in the spec).

Cheers,
Ben.

> Thanks,
> 
> Andrew Fish
> 
> > Cheers,
> > Ben.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] PCI Bus scanning

2015-08-11 Thread Leekha Shaveta
Hi,

During PCI bus scanning, my execution hanged at 
ProcessOptionRom (RootBridgeDev, Mem32Base, RootBridgeDev-RomSize);

So I am commented this, and it went well.

Will there be any difference in PCI networking tests (ping/ifconfig/tftp), if I 
keep this
ProcessOptionRom code commented?

Thanks and Regards,
Shaveta

-Original Message-
From: Leekha Shaveta-B20052 
Sent: Saturday, August 08, 2015 10:48 PM
To: 'Ye, Ting'; 'edk2-devel@lists.01.org'
Subject: RE: Error on executing shell command ifconfig

Does anyone tested network(ping/tftp) using E1000/NIC PCI card on Juno board?
Which LAN E1000 driver(source or any link) is used and tested for Intel NIC 
card?

Thanks and Regards,
Shaveta

-Original Message-
From: Leekha Shaveta-B20052 
Sent: Friday, August 07, 2015 10:59 AM
To: 'Ye, Ting'; edk2-devel@lists.01.org
Subject: RE: Error on executing shell command ifconfig

Thanks Ting!

I have one LanIntelE1000Dxe code and using it, but this code is not yet 
tested on UEFI.
And as my network (ping/ifconfig) is not working, I am clueless about what 
exactly causing the issue.

Thanks and Regards,
Shaveta

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ye, Ting
Sent: Friday, August 07, 2015 10:54 AM
To: Leekha Shaveta-B20052; Sharma Bhupesh-B45370; edk2-devel@lists.01.org
Subject: Re: [edk2] Error on executing shell command ifconfig

Hi Shaveta,

The upper layer drivers since SNP are available for several years and validated 
in multiple UEFI enabled platforms.
Sorry I don't know whether you can get the UEFI Intel E1000 NIC card driver. 
You may search the download center in Intel.com? Hope other guys in the mailing 
list know.

Best Regards,
Ting

-Original Message-
From: Leekha Shaveta [mailto:shav...@freescale.com] 
Sent: Friday, August 07, 2015 1:18 PM
To: Ye, Ting; Sharma Bhupesh; edk2-devel@lists.01.org
Subject: RE: Error on executing shell command ifconfig


Upper layer drivers like SNP/MNP are also taken from EDK2 and not been tested 
on UEFI.

From where can I get the complete code of Intel E1000 NIC card driver for UEFI?

Is such tested code available for use for UEFI?

Thanks and Regards,
Shaveta

-Original Message-
From: Ye, Ting [mailto:ting...@intel.com]
Sent: Thursday, August 06, 2015 10:50 AM
To: Leekha Shaveta-B20052; Sharma Bhupesh-B45370; edk2-devel@lists.01.org
Subject: RE: Error on executing shell command ifconfig

The #D and #C are zero which mean that this driver does not manage any device 
or child device. It looks the driver not function well.
You can also double check whether upper layer drivers like SNP, MNP, etc. ever 
manage any devices.

Best Regards,
Ye Ting

-Original Message-
From: Leekha Shaveta [mailto:shav...@freescale.com]
Sent: Thursday, August 06, 2015 12:56 PM
To: Ye, Ting; Sharma Bhupesh; edk2-devel@lists.01.org
Subject: RE: Error on executing shell command ifconfig

Hi Ye Ting,

Thanks for the reply.

This driver has not been tested on UEFI, but said to be tested on edk2.

On running drivers command I get following output:
Shell drivers
 T   D
 Y C I
 P F A
DRV VERSION  E G G #D  #C  DRIVER NAME IMAGE PATH
===  = = = === === === ==
39 04040600 ? Y Y   0   0 Intel(R) PRO/1000 4.4.06 PCI-E  
MemoryMapped(0xB,0xFF80D000,0xFFBEA167)/FvFile(BB801A52-C90F-4EDE-91B2-82520888CBC3)

It seems that E1000 driver is getting loaded properly.
Correct understanding?

Thanks and Regards,
Shaveta

-Original Message-
From: Ye, Ting [mailto:ting...@intel.com]
Sent: Thursday, August 06, 2015 5:56 AM
To: Sharma Bhupesh-B45370; edk2-devel@lists.01.org; Leekha Shaveta-B20052
Subject: RE: Error on executing shell command ifconfig

Do you know whether the LanIntelE1000Dxe works properly? 
You may type drivers in shell to check connecting status of UEFI network 
drivers.

Best Regards,
Ye Ting


-Original Message-
From: Sharma Bhupesh [mailto:bhupesh.sha...@freescale.com]
Sent: Wednesday, August 05, 2015 6:43 PM
To: Ye, Ting; edk2-devel@lists.01.org; Leekha Shaveta
Subject: RE: Error on executing shell command ifconfig

Hi Ye Ting,

Thanks for your inputs.

I tried adding the same as well and the following packages are now being added 
to the .dsc file:

  #
  # Networking stack
  #
  MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf
  MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
  MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
  MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
  MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
  MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
  MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
  MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
  MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf

Re: [edk2] Error on executing shell command ifconfig

2015-08-08 Thread Leekha Shaveta
Does anyone tested network(ping/tftp) using E1000/NIC PCI card on Juno board?
Which LAN E1000 driver(source or any link) is used and tested for Intel NIC 
card?

Thanks and Regards,
Shaveta

-Original Message-
From: Leekha Shaveta-B20052 
Sent: Friday, August 07, 2015 10:59 AM
To: 'Ye, Ting'; edk2-devel@lists.01.org
Subject: RE: Error on executing shell command ifconfig

Thanks Ting!

I have one LanIntelE1000Dxe code and using it, but this code is not yet 
tested on UEFI.
And as my network (ping/ifconfig) is not working, I am clueless about what 
exactly causing the issue.

Thanks and Regards,
Shaveta

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ye, Ting
Sent: Friday, August 07, 2015 10:54 AM
To: Leekha Shaveta-B20052; Sharma Bhupesh-B45370; edk2-devel@lists.01.org
Subject: Re: [edk2] Error on executing shell command ifconfig

Hi Shaveta,

The upper layer drivers since SNP are available for several years and validated 
in multiple UEFI enabled platforms.
Sorry I don't know whether you can get the UEFI Intel E1000 NIC card driver. 
You may search the download center in Intel.com? Hope other guys in the mailing 
list know.

Best Regards,
Ting

-Original Message-
From: Leekha Shaveta [mailto:shav...@freescale.com] 
Sent: Friday, August 07, 2015 1:18 PM
To: Ye, Ting; Sharma Bhupesh; edk2-devel@lists.01.org
Subject: RE: Error on executing shell command ifconfig


Upper layer drivers like SNP/MNP are also taken from EDK2 and not been tested 
on UEFI.

From where can I get the complete code of Intel E1000 NIC card driver for UEFI?

Is such tested code available for use for UEFI?

Thanks and Regards,
Shaveta

-Original Message-
From: Ye, Ting [mailto:ting...@intel.com]
Sent: Thursday, August 06, 2015 10:50 AM
To: Leekha Shaveta-B20052; Sharma Bhupesh-B45370; edk2-devel@lists.01.org
Subject: RE: Error on executing shell command ifconfig

The #D and #C are zero which mean that this driver does not manage any device 
or child device. It looks the driver not function well.
You can also double check whether upper layer drivers like SNP, MNP, etc. ever 
manage any devices.

Best Regards,
Ye Ting

-Original Message-
From: Leekha Shaveta [mailto:shav...@freescale.com]
Sent: Thursday, August 06, 2015 12:56 PM
To: Ye, Ting; Sharma Bhupesh; edk2-devel@lists.01.org
Subject: RE: Error on executing shell command ifconfig

Hi Ye Ting,

Thanks for the reply.

This driver has not been tested on UEFI, but said to be tested on edk2.

On running drivers command I get following output:
Shell drivers
 T   D
 Y C I
 P F A
DRV VERSION  E G G #D  #C  DRIVER NAME IMAGE PATH
===  = = = === === === ==
39 04040600 ? Y Y   0   0 Intel(R) PRO/1000 4.4.06 PCI-E  
MemoryMapped(0xB,0xFF80D000,0xFFBEA167)/FvFile(BB801A52-C90F-4EDE-91B2-82520888CBC3)

It seems that E1000 driver is getting loaded properly.
Correct understanding?

Thanks and Regards,
Shaveta

-Original Message-
From: Ye, Ting [mailto:ting...@intel.com]
Sent: Thursday, August 06, 2015 5:56 AM
To: Sharma Bhupesh-B45370; edk2-devel@lists.01.org; Leekha Shaveta-B20052
Subject: RE: Error on executing shell command ifconfig

Do you know whether the LanIntelE1000Dxe works properly? 
You may type drivers in shell to check connecting status of UEFI network 
drivers.

Best Regards,
Ye Ting


-Original Message-
From: Sharma Bhupesh [mailto:bhupesh.sha...@freescale.com]
Sent: Wednesday, August 05, 2015 6:43 PM
To: Ye, Ting; edk2-devel@lists.01.org; Leekha Shaveta
Subject: RE: Error on executing shell command ifconfig

Hi Ye Ting,

Thanks for your inputs.

I tried adding the same as well and the following packages are now being added 
to the .dsc file:

  #
  # Networking stack
  #
  MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf
  MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
  MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
  MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
  MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
  MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
  MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
  MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
  MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
  MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
  MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf

Also e1000/NIC card driver's efi is getting loaded .
  # Intel E1000 driver
  INF LS1043aRdbPkg/Drivers/LanIntelE1000Dxe/LanIntelE1000Dxe.inf

Still I am getting same error:

Shell ifconfig -l
Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and not found 
(3B95AA31-3793-434B-8667-C8070892E05E).

Can it be related to shell source/version? Or Lan/NIC/E1000 card driver?

Any hints would

Re: [edk2] Error on executing shell command ifconfig

2015-08-06 Thread Leekha Shaveta
Thanks Ting!

I have one LanIntelE1000Dxe code and using it, but this code is not yet 
tested on UEFI.
And as my network (ping/ifconfig) is not working, I am clueless about what 
exactly causing the issue.

Thanks and Regards,
Shaveta

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ye, Ting
Sent: Friday, August 07, 2015 10:54 AM
To: Leekha Shaveta-B20052; Sharma Bhupesh-B45370; edk2-devel@lists.01.org
Subject: Re: [edk2] Error on executing shell command ifconfig

Hi Shaveta,

The upper layer drivers since SNP are available for several years and validated 
in multiple UEFI enabled platforms.
Sorry I don't know whether you can get the UEFI Intel E1000 NIC card driver. 
You may search the download center in Intel.com? Hope other guys in the mailing 
list know.

Best Regards,
Ting

-Original Message-
From: Leekha Shaveta [mailto:shav...@freescale.com] 
Sent: Friday, August 07, 2015 1:18 PM
To: Ye, Ting; Sharma Bhupesh; edk2-devel@lists.01.org
Subject: RE: Error on executing shell command ifconfig


Upper layer drivers like SNP/MNP are also taken from EDK2 and not been tested 
on UEFI.

From where can I get the complete code of Intel E1000 NIC card driver for UEFI?

Is such tested code available for use for UEFI?

Thanks and Regards,
Shaveta

-Original Message-
From: Ye, Ting [mailto:ting...@intel.com]
Sent: Thursday, August 06, 2015 10:50 AM
To: Leekha Shaveta-B20052; Sharma Bhupesh-B45370; edk2-devel@lists.01.org
Subject: RE: Error on executing shell command ifconfig

The #D and #C are zero which mean that this driver does not manage any device 
or child device. It looks the driver not function well.
You can also double check whether upper layer drivers like SNP, MNP, etc. ever 
manage any devices.

Best Regards,
Ye Ting

-Original Message-
From: Leekha Shaveta [mailto:shav...@freescale.com]
Sent: Thursday, August 06, 2015 12:56 PM
To: Ye, Ting; Sharma Bhupesh; edk2-devel@lists.01.org
Subject: RE: Error on executing shell command ifconfig

Hi Ye Ting,

Thanks for the reply.

This driver has not been tested on UEFI, but said to be tested on edk2.

On running drivers command I get following output:
Shell drivers
 T   D
 Y C I
 P F A
DRV VERSION  E G G #D  #C  DRIVER NAME IMAGE PATH
===  = = = === === === ==
39 04040600 ? Y Y   0   0 Intel(R) PRO/1000 4.4.06 PCI-E  
MemoryMapped(0xB,0xFF80D000,0xFFBEA167)/FvFile(BB801A52-C90F-4EDE-91B2-82520888CBC3)

It seems that E1000 driver is getting loaded properly.
Correct understanding?

Thanks and Regards,
Shaveta

-Original Message-
From: Ye, Ting [mailto:ting...@intel.com]
Sent: Thursday, August 06, 2015 5:56 AM
To: Sharma Bhupesh-B45370; edk2-devel@lists.01.org; Leekha Shaveta-B20052
Subject: RE: Error on executing shell command ifconfig

Do you know whether the LanIntelE1000Dxe works properly? 
You may type drivers in shell to check connecting status of UEFI network 
drivers.

Best Regards,
Ye Ting


-Original Message-
From: Sharma Bhupesh [mailto:bhupesh.sha...@freescale.com]
Sent: Wednesday, August 05, 2015 6:43 PM
To: Ye, Ting; edk2-devel@lists.01.org; Leekha Shaveta
Subject: RE: Error on executing shell command ifconfig

Hi Ye Ting,

Thanks for your inputs.

I tried adding the same as well and the following packages are now being added 
to the .dsc file:

  #
  # Networking stack
  #
  MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf
  MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf
  MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf
  MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf
  MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf
  MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf
  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf
  MdeModulePkg/Universal/Network/Ip4ConfigDxe/Ip4ConfigDxe.inf
  MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
  MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
  MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
  MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
  MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf

Also e1000/NIC card driver's efi is getting loaded .
  # Intel E1000 driver
  INF LS1043aRdbPkg/Drivers/LanIntelE1000Dxe/LanIntelE1000Dxe.inf

Still I am getting same error:

Shell ifconfig -l
Error. The protocol 'gEfiIp4ConfigProtocolGuid' was required and not found 
(3B95AA31-3793-434B-8667-C8070892E05E).

Can it be related to shell source/version? Or Lan/NIC/E1000 card driver?

Any hints would be helpful.

Regards,
Bhupesh


 -Original Message-
 From: Ye, Ting [mailto:ting...@intel.com]
 Sent: Wednesday, August 05, 2015 2:14 PM
 To: Sharma Bhupesh-B45370; edk2-devel@lists.01.org; Leekha
 Shaveta-B20052
 Subject: RE: Error on executing shell command ifconfig
 
 It looks SNP driver is missing.
 
 MdeModulePkg\Universal\Network\SnpDxe\SnpDxe.inf
 
 Best Regards,
 Ye