-----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 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 : 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_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: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: >>>>> >>>>>> >>>>>>> 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<mailto:edk2-devel@lists.01.org> >>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>>> _______________________________________________ >>>>> edk2-devel mailing list >>>>> edk2-devel@lists.01.org<mailto: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-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
