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