[U-Boot] commit 620776d causes TFTP error: 'Unsupported option(s) requested' (8)

[Bin Meng]

Hi Joe,

On Tue, Aug 25, 2015 at 12:24 PM, Joe Hershberger
<joe.hershberger at gmail.com> wrote:
> Hi Bin,
>
> On Mon, Aug 24, 2015 at 11:05 PM, Bin Meng <bmeng.cn at gmail.com> wrote:
>> Hi Joe,
>>
>> On Tue, Aug 25, 2015 at 11:42 AM, Joe Hershberger
>> <joe.hershberger at gmail.com> wrote:
>>> Hi Bin,
>>>
>>> On Mon, Aug 24, 2015 at 9:25 PM, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> With latest u-boot/master, TFTP is seriously broken.
>>>>
>>>> => tftp 100000 bzImage
>>>> Speed: 100, full duplex
>>>> Using pch_gbe device
>>>> TFTP from server 10.10.0.8; our IP address is 10.10.0.100; sending
>>>> through gateway 10.10.0.1
>>>> Filename 'bzImage'.
>>>> Load address: 0x100000
>>>> Loading: T
>>>> TFTP error: 'Unsupported option(s) requested' (8)
>>>> Starting again
>>>
>>> I'm guessing you are having an issue that the TFTP server you are
>>> using for some reason does not allow a timeout as small as 10 ms. What
>>> server are you testing against? Can you experiment and find the lowest
>>> that it accepts? Maybe there is a compromise we can reach that still
>>> works with most (all?) servers and also improves the behavior in a
>>> lossy environment.
>>
>> I am using a CentOS server, with /etc/xinetd.d/tftp configuration below.
>>
>> service tftp
>> {
>>         socket_type             = dgram
>>         protocol                = udp
>>         wait                    = yes
>>         user                    = root
>>         server                  = /usr/sbin/in.tftpd
>>         server_args             = -s /tftpboot
>>         disable                 = no
>>         per_source              = 11
>>         cps                     = 100 2
>>         flags                   = IPv4
>> }
>>
>> I don't see an entry to change timeout settings.
>
> I didn't mean to change the server settings; I meant can you adjust
> the U-Boot code until your server doesn't reject the option?
>

I would like to revert this commit before we find a solution. Even if
I find a proper value to get tftp work again in my network
environment, we don't know if this commit breaks someone else's board.
After all, this timeout value has been there for years (?), and I
believe it is a safe value for all the boards that are actively
maintained.

[snip]

Regards,
Bin