Thanks Laszlo for the very thorough description of the probable root-cause. It helped a lot.
One thing though, which makes me wonder if this is similar to a "Brand X USB3.0 mass storage drive doesn't work on my Brand Y USB host machine" case, as on this particular machine (also checked on a set of co-located machines), the tftp server was able to work both with u-boot Bootloader and Linux kernel for tftp based file transfer. So, while I understand this might be a tftp server version issue, do we need to fully check the explicit difference between the tftp command/packet transfer sequence when done by uefi and say Linux? Regards, Bhupesh > -----Original Message----- > From: edk2-devel [mailto:[email protected]] On Behalf Of > Leekha Shaveta > Sent: Tuesday, September 29, 2015 3:32 PM > To: Laszlo Ersek > Cc: [email protected]; Gary Ching-Pang Lin; Fu, Siyuan; Chris > Cuthbert > Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing > > Hi Laszlo, > > Many Thanks for your help !! > It actually worked well with latest tftp server (atftpd), so it turned > out to be a server issue (as you said rightly :) ) > > Some replies are inlined > > Thanks and Regards, > Shaveta > > > -----Original Message----- > From: Laszlo Ersek [mailto:[email protected]] > Sent: Monday, September 28, 2015 6:30 PM > To: Leekha Shaveta-B20052 <[email protected]> > Cc: [email protected] <[email protected]>; Fu, Siyuan > <[email protected]>; Chris Cuthbert <[email protected]>; Gary Ching- > Pang Lin <[email protected]> > Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing > > On 09/28/15 12:24, Leekha Shaveta wrote: > > Hi Laszlo, > > > > Please find the detailed "tcpdump" on my setup: > > > > test@boardfram-OptiPlex-790:/tftpboot$ sudo tcpdump -v -v -n -l -X -e > > -i eth0 > > tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size > > 65535 bytes > > 21:39:42.028524 68:05:ca:04:d5:6a > 18:03:73:15:7b:12, ethertype IPv4 > (0x0800), length 63: (tos 0x0, ttl 64, id 54858, offset 0, flags [none], > proto UDP (17), length 49) > > 192.168.3.154.1051 > 192.168.3.221.69: [udp sum ok] 21 RRQ "test" > octet tsize 0 > > 0x0000: 4500 0031 d64a 0000 4011 1baa c0a8 039a > E..1.J..@....... > > 0x0010: c0a8 03dd 041b 0045 001d d2e6 0001 7465 > .......E......te > > 0x0020: 7374 006f 6374 6574 0074 7369 7a65 0030 > st.octet.tsize.0 > > 0x0030: 00 . > > 21:39:42.030313 18:03:73:15:7b:12 > 68:05:ca:04:d5:6a, ethertype IPv4 > (0x0800), length 65: (tos 0x0, ttl 64, id 7770, offset 0, flags [DF], > proto UDP (17), length 51) > > 192.168.3.221.40480 > 192.168.3.154.1051: [udp sum ok] UDP, length > 23 > > 0x0000: 4500 0033 1e5a 4000 4011 9398 c0a8 03dd > E..3.Z@.@....... > > 0x0010: c0a8 039a 9e20 041b 001f 169a 0003 0001 > ................ > > 0x0020: 6969 6969 6964 6863 626a 7364 6320 7364 > iiiiidhcbjsdc.sd > > 0x0030: 6320 0a c.. > > 21:39:42.058922 68:05:ca:04:d5:6a > 18:03:73:15:7b:12, ethertype IPv4 > (0x0800), length 68: (tos 0x0, ttl 64, id 54859, offset 0, flags [none], > proto UDP (17), length 54) > > 192.168.3.154.1051 > 192.168.3.221.40480: [udp sum ok] UDP, length > 26 > > 0x0000: 4500 0036 d64b 0000 4011 1ba4 c0a8 039a > E..6.K..@....... > > 0x0010: c0a8 03dd 041b 9e20 0022 ed64 0005 0004 > .........".d.... > > 0x0020: 5573 6572 2061 626f 7274 6564 2064 6f77 > User.aborted.dow > > 0x0030: 6e6c 6f61 6400 nload. > > ^C > > 3 packets captured > > 3 packets received by filter > > 0 packets dropped by kernel > > > > > > Command I had run for tftp was: > > > > Shell> tftp 192.168.3.221 test t4 > > unicast promiscuous. > > PacketType 4 > > protocol 8 > > Src MAC Address: 18 3 73 15 7B 12 > > Dest MAC Address: 68 5 CA 4 D5 6A > > Failed to get the size of the file 'test' on 'eth0' - Protocol Error > > Shell> > > > > > > > > I have now compiled the code with latest ShellPkg and ran it. > > > > Does this log give any pointer, why Token state is getting "ABORTED" in > tftp? > > The reason I recommended the -X (more precisely, -l -X) options is > because the packets often contain ASCII strings that the source code can > be grepped for. (Clearly the source code that is responsible for sending > out that packet.) > > In this case, the 3rd packet (which is sent by edk2) contains "User > aborted download": > > $ git grep 'User aborted download' > > The one hit (restricting the results to IPv4) is in > "MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Rrq.c", function > Mtftp4RrqSaveBlock(). The documentation on that function is > > Deliver the received data block to the user, which can be saved in the > user provide buffer or through the CheckPacket callback. > > The textual error message is passed by Mtftp4RrqSaveBlock() to > Mtftp4SendError(), and this branch depends on the Token->CheckPacket() > callback *failing*. Thus, we can say that the Token->CheckPacket() > function call rejects the 2nd packet. > > In addition, the Mtftp4RrqSaveBlock() function documents its own > EFI_ABORTED retval like this: > > The user tells to abort by return an error through CheckPacket > > [Shaveta] > I got to this point by putting some debug logs and it was getting aborted > from here only: > if (Token->CheckPacket != NULL) { > DEBUG((EFI_D_INFO, " Check packet from HERE: %r\n", Token->Status)); > Status = Token->CheckPacket (&Instance->Mtftp4, Token, (UINT16) Len, > Packet); > > if (EFI_ERROR (Status)) { > Mtftp4SendError ( > Instance, > EFI_MTFTP4_ERRORCODE_ILLEGAL_OPERATION, > (UINT8 *) "User aborted download" > ); > > return EFI_ABORTED; > } > } > > ... As far as I can see in this directory, EfiMtftp4GetInfo() populates > the CheckPacket function pointer with the address of > Mtftp4GetInfoCheckPacket(). So let's see what Mtftp4GetInfoCheckPacket() > does: > > Apparently, this function *always* returns EFI_ABORTED (which in turn > always triggers the above branch in Mtftp4RrqSaveBlock()). However, > remember that it's only EfiMtftp4GetInfo() that sets up the CheckPacket > callback pointer like this. > > In addition, before returning EFI_ABORTED indiscriminately, > Mtftp4GetInfoCheckPacket() stores a status code in ((MTFTP4_GETINFO_STATE > *)Token->Context)->Status. > > Therefore, we can determine the following: when you use > Mtftp4RrqSaveBlock() as part of a "normal" download, the CheckPacket > callback ptr is NULL, and this doesn't happen. However, when you use the > same function as part of querying *metadata* of the remote file, ie. > initiated from EfiMtftp4GetInfo(), then the callback function is always > set to Mtftp4GetInfoCheckPacket(), which will (a) abort the transfer > invariably after the first packet -- which is valid, we only care about > the metadata in the first packet --, and (b) it will store a status code > too in the context, "for later", ie. for the actual download that is > supposed to take place after the metadata have been parsed on the edk2 > side. > > And, in your case, this "actual" download doesn't seem to be happening. > Why? > > [Shaveta] Read something similar: > Errors that are not really Errors. > TFTP is a file transfer protocol that does not have special provisions > for telling the client in advance the size of a file the client is > planning to retrieve. The client sometimes needs this information for > control or memory allocation purposes, then you will see this kind of log > sequence: > > In such particular case: > > The client requests the say "abc" file. > The client quickly aborts the transfer, but it received the "abc" file > size from the first packet transmitted by the purposely stopped transfer. > The client verifies the "abc" file size is within the expected values and > if everything is OK it requests a new transfer. > This time the transfer is completed. > > > > But I too was wondering that why Opcode that I am getting is "3" which is > incorrect, and why the actual download is not taking place. So I got > stuck :( > > Thanks for such a detailed explanation :) :) > > > > > > Well, in your UEFI shell log, I see "Protocol Error" -- in > Mtftp4GetInfoCheckPacket(), I see exactly one branch that does > > State->Status = EFI_PROTOCOL_ERROR; > > and that branch corresponds to > > NTOHS (Packet->OpCode) != EFI_MTFTP4_OPCODE_ERROR && > NTOHS (Packet->OpCode) != EFI_MTFTP4_OPCODE_OACK > > In other words, the TFTP server supposedly sends back an opcode, in the > 2nd packet, that is neither ERROR (5) nor OACK (6). > > For further analysis, we have to consult various RFCs: > > https://tools.ietf.org/html/rfc1350 -- "basic" TFTP > https://tools.ietf.org/html/rfc1782 -- TFTP Option Extension > https://tools.ietf.org/html/rfc2349 -- Transfer Size option > > Here's again the RRQ: > > > 192.168.3.154.1051 > 192.168.3.221.69: [udp sum ok] 21 RRQ "test" > octet tsize 0 > > 0x0000: 4500 0031 d64a 0000 4011 1baa c0a8 039a > E..1.J..@....... > > 0x0010: c0a8 03dd 041b 0045 001d d2e6 0001 7465 > > .......E......te > ^ ^ ^ > | | | > IPv4 header ends here UDP hdr ends here | > OpCode = RRQ > > > 0x0020: 7374 006f 6374 6574 0074 7369 7a65 0030 > > st.octet.tsize.0 > ^ ^ ^ > | | | > filename ("test") ends here | | > | | > mode ("octet") ends here | > | > first TFTP option ("tsize") ends here > > > 0x0030: 00 . > ^ > | > first TFTP option value ("0") ends here > > So, in the first packet, edk2 composes a TFTP RRQ. The basic structure is > governed by RFC 1350. Then, it appends one option (tsize=0). The general > formatting for options is described in RFC 1782; practically "append a > sequence of NUL-terminated ASCII strings". The actual option that edk2 > appends is tsize\00\0, which is described in RFC 2349. > > From RFC 2349, the meaning of tsize=0 is: > > In Read Request packets, a size of "0" is specified in the request > and the size of the file, in octets, is returned in the OACK. If the > file is too large for the client to handle, it may abort the transfer > with an Error packet (error code 3). [...] > > Meaning tsize=0 can be used to query the file size in advance. > > Now let's see how a TFTP server is allowed to answer to an RRQ that has > options (consult RFC 1782, section "Negotiation Protocol"): > > When the client appends options to the end of a Read Request packet, > three possible responses may be returned by the server: > > OACK - acknowledge of Read Request and the options; > > DATA - acknowledge of Read Request, but not the options; > > ERROR - the request has been denied. > > Looking at the second packet: > > > 21:39:42.030313 18:03:73:15:7b:12 > 68:05:ca:04:d5:6a, ethertype IPv4 > (0x0800), length 65: (tos 0x0, ttl 64, id 7770, offset 0, flags [DF], > proto UDP (17), length 51) > > 192.168.3.221.40480 > 192.168.3.154.1051: [udp sum ok] UDP, length > 23 > > 0x0000: 4500 0033 1e5a 4000 4011 9398 c0a8 03dd > E..3.Z@.@....... > > 0x0010: c0a8 039a 9e20 041b 001f 169a 0003 0001 > ................ > ^ > | > OpCode = 3 (DATA) > > > 0x0020: 6969 6969 6964 6863 626a 7364 6320 7364 > iiiiidhcbjsdc.sd > > 0x0030: 6320 0a c.. > > > This means that the TFTP server acknowledges RRQ, but not the options; > specifically, tsize=0. > > Meaning the server starts the actual data transfer, instead of just > responding with the size of the file that the client (edk2) is interested > in, at the moment. > > This is why the EFI_PROTOCOL_ERROR branch is taken in > Mtftp4GetInfoCheckPacket(): because the TFTP server is incapable of > responding with *just* the remote file size, without the actual file > contents. This makes it very impractical to implement the > EFI_MTFTP4_PROTOCOL.GetInfo() member function. > > Solution: enable option parsing (according to at least RFC 1782 and RFC > 2349) in your TFTP server, or use a more modern TFTP server. > > More details: I happen to have a debian box running on my desk. The > executable name from one of your earlier emails (from the xinetd config > file) is "/usr/sbin/in.tftpd". I ran the following command: > > $ apt-file search /usr/sbin/in.tftpd > > (I had the impression that you were using Debian or Ubuntu.) > > Three packages were returned by apt-file, as providing that binary: > "atftpd", "tftpd", and "tftpd-hpa". > > Now look at their package descriptions: > > https://packages.debian.org/atftpd > > Multi-threaded TFTP server implementing all options (option > extension and multicast) as specified in RFC1350, RFC2090, RFC2347, > RFC2348 and RFC2349. Atftpd also supports multicast protocol known > as mtftp, defined in the PXE specification. [...] > > https://packages.debian.org/tftpd > > Tftpd is a server which supports the Internet Trivial File Transfer > Protocol (RFC 783). The TFTP server operates at the port indicated > in the `tftp' service description; see services(5). The server is > normally started by inetd(8). Tftpd is not suitable for use with the > PXE bootloader; for that, use atftpd or tftpd-hpa. > > https://packages.debian.org/tftpd-hpa > > Trivial File Transfer Protocol (TFTP) is a file transfer protocol, > mainly to serve boot images over the network to other machines > (PXE). [...] > > You simply have the wrong package installed! Please install "atftpd" > instead of "tftpd", and retry. > > ... Once again, it seems proven that (a) most PXE / TFTP issues > experienced with edk2 exist on the server (or network) side, and (b) you > can fix many issues simply by reading documentation. > > Of course you can also ask others to read docs for you, and hope they are > interested... :) > > Laszlo > > > > > Thanks and Regards, > > Shaveta > > > > > > -----Original Message----- > > From: Laszlo Ersek [mailto:[email protected]] > > Sent: Friday, September 25, 2015 11:09 PM > > To: Leekha Shaveta-B20052 <[email protected]> > > Cc: [email protected] <[email protected]>; Fu, Siyuan > > <[email protected]>; Chris Cuthbert <[email protected]>; Gary > > Ching-Pang Lin <[email protected]> > > Subject: Re: [edk2] TFTP issue, Ping 1st packet reply missing > > > > On 09/25/15 12:46, Leekha Shaveta wrote: > >> > >> > >> -----Original Message----- > >> From: Laszlo Ersek [mailto:[email protected]] > >> Sent: Friday, September 25, 2015 3:11 PM > >> To: Leekha Shaveta-B20052 <[email protected]> > >> Cc: [email protected] <[email protected]>; Fu, Siyuan > >> <[email protected]>; Chris Cuthbert <[email protected]>; Gary > >> Ching-Pang Lin <[email protected]> > >> 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:[email protected]] > >>> Sent: Friday, September 25, 2015 1:04 AM > >>> To: Leekha Shaveta-B20052 <[email protected]> > >>> Cc: [email protected] <[email protected]>; Fu, Siyuan > >>> <[email protected]>; Chris Cuthbert <[email protected]>; Gary > >>> Ching-Pang Lin <[email protected]> > >>> 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/2638c111076f9a49d4766ca5acbafa > 0eb7f66a18/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. > > > > It is SVN r18553 now. > > > >> > >> 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 > > > > Unfortunately, the parameters you passed to tcpdump are not ideal -- I > had proposed parameters up-thread that are more suitable for debugging; > please use those. > > > >> 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?? > > > > Sure. You didn't pass "-n" to tcpdump (despite my recommendation :)), > hence tcpdump tries to resolve both IP addresses to domain names, and > port numbers to service names (from /etc/services, and any other sources > configured in /etc/nsswitch.conf for service name resolution). > > "ingreslock" has no particular meaning here; it is port 1524, but for > endpoints that you do not bind explicitly, the system "randomly" chooses > a port number from a suitable range. > > > > In the TFTP client case, the target port (where the TFTP server lives) > is of course well known, but the source port is not bound by the client > explicitly (there's no reason to), hence the system assigns a "random" > > source port number. In this case, it happened to be 1524, which is > "ingreslock", according to /etc/services. > > > > Service name resolution is frequently just a distraction with tcpdump, > > hence my proposal to use "-n". (Please consider the tcpdump parameters > > I had suggested before.) > > > > If, for any reason, you insist on specifying a source port number, > instead of the system-assigned one, the TFTP command's -l option can > accommodate that (see its help). > > > > ... Also, 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. > > > > Laszlo > > > > > >> > >> 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:[email protected]] > >>>>> Sent: Thursday, September 24, 2015 2:05 PM > >>>>> To: Leekha Shaveta-B20052 <[email protected]> > >>>>> Cc: [email protected] <[email protected]>; Fu, Siyuan > >>>>> <[email protected]>; Chris Cuthbert <[email protected]>; Gary > >>>>> Ching-Pang Lin <[email protected]> > >>>>> 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:[email protected]] On > >>>>>> Behalf Of Leekha Shaveta > >>>>>> Sent: Thursday, September 24, 2015 11:15 AM > >>>>>> To: [email protected] > >>>>>> 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' > >>>>>>> <[email protected]<mailto:[email protected]>>; > >>>>>>> 'Andrew Fish' <[email protected]<mailto:[email protected]>>; > >>>>>>> '[email protected]' > >>>>>>> <[email protected]<mailto:[email protected]>>; > >>>>>>> 'Tian, Feng' <[email protected]<mailto:[email protected]>> > >>>>>>> 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_0000_0000 (40 bit addressable) And its mapping on PCI bus is like: > >>>>>>> 50_0000_0000 => 0000_0000 (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:[email protected]] On > >>>>>>> Behalf Of Tian, Feng > >>>>>>> Sent: Wednesday, August 26, 2015 7:24 AM > >>>>>>> To: Benjamin Herrenschmidt > >>>>>>> <[email protected]<mailto:[email protected]>>; > >>>>>>> Andrew Fish <[email protected]<mailto:[email protected]>> > >>>>>>> Cc: [email protected]<mailto:[email protected]> > >>>>>>> <[email protected]<mailto:[email protected]>>; Tian, > >>>>>>> Feng <[email protected]<mailto:[email protected]>> > >>>>>>> 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:[email protected]] On > >>>>>>> Behalf Of Benjamin Herrenschmidt > >>>>>>> Sent: Wednesday, August 26, 2015 07:54 > >>>>>>> To: Andrew Fish > >>>>>>> Cc: [email protected]<mailto:[email protected]> > >>>>>>> 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 > >>>>>>> [email protected]<mailto:[email protected]> > >>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel > >>>>>>> _______________________________________________ > >>>>>>> edk2-devel mailing list > >>>>>>> [email protected]<mailto:[email protected]> > >>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel > >>>>>> _______________________________________________ > >>>>>> edk2-devel mailing list > >>>>>> [email protected] > >>>>>> https://lists.01.org/mailman/listinfo/edk2-devel > >>>>>> _______________________________________________ > >>>>>> edk2-devel mailing list > >>>>>> [email protected] > >>>>>> https://lists.01.org/mailman/listinfo/edk2-devel > >>>>>> > >>>>> > >>>> > >>> > >> > > > > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
