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