Hi,
I more point to add.
With the same server configuration, UBOOT bootloader is able to do tftp
successfully whereas UEFI fails.
Regards,
Shaveta
-----Original Message-----
From: Leekha Shaveta-B20052
Sent: Thursday, September 24, 2015 2:52 PM
To: 'Laszlo Ersek' <ler...@redhat.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
Hi Laszlo,
What kind of " problematic DHCP or TFTP config "? What should be the right
config for TFTP to work?
I have tftp file on TFTP server "/etc/xinetd.d/tftp" as follows :
service tftp
{
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -c -s /tftpboot
disable = no
}
Tftp done:
Shell> tftp 192.168.3.230 test t2
TCPDUMP:
===========
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
20:21:17.508537 ARP, Request who-has 192.168.3.230 tell 192.168.3.153, length 46
20:21:17.508548 ARP, Reply 192.168.3.230 is-at 68:05:ca:04:cd:99 (oui Unknown),
length 28
20:21:17.562908 IP 192.168.3.153.2012 > 192.168.3.230.tftp: 21 RRQ "test"
octet tsize 0
20:21:17.564335 IP 192.168.3.230.40029 > 192.168.3.153.2012: UDP, length 21
Does it give any hint??
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
