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/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.
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
