[U-Boot] http client?

[Ben Warren <biggerbadderben@gmail.com>]

Robin Getz wrote:
> On Wed 22 Jul 2009 16:32, Ben Warren pondered:> Robin Getz wrote:
>   
>>> On Wed 22 Jul 2009 10:04, jeffery palmer pondered:
>>>   
>>>       
>>>> We are looking for an http client now as well. Our major issue revolves 
>>>>     
>>>>         
>>> around the download times for tftp.
>>>   
>>>       
>>>>  
>>>> Can Volkmar Uhlig kindly provide the patches?
>>>>  
>>>> Our units automically update themselves inside of uboot giving us the most
>>>> control over our firmware. The issue is that it takes 20 minutes via a DSL
>>>> line in Africa to update our units. An http test showed that the same
>>>> firmware downloads in 30 seconds. We have also added things like the blksize
>>>> parameter to the uboot tftp client to get it down to 20 minutes, our
>>>> original download times were ~50 minutes.     
>>>>     
>>>>         
>>> Hmm -- I'm assuming that is  http://www.faqs.org/rfcs/rfc1783.html ?
>>>
>>> Do you have a patch to send - or that I can clean up and submit?
>>>
>>>   
>>>       
>> Requesting a bigger blocksize is already implemented and should work if 
>> the server supports it.  It's been a while since I used this, but it was 
>> added along with support for multicast TFTP, probably about a year ago.
>>     
>
> I see:
>
> #define TFTP_MTU_BLOCKSIZE 1468blksize
> static unsigned short TftpBlkSizeOption=TFTP_MTU_BLOCKSIZE;
>
>                 /* try for more effic. blk size */
>                 pkt += sprintf((char *)pkt,"blksize%c%d%c",
>                                 0,TftpBlkSizeOption,0);
>
> but that is it...
>
> No CONFIG_ options for anything else?
>
>   
Right, it's hard-coded to 1468 (maximum TFTP frame that will fit in a 
1500-byte Ethernet frame, due to UDP overhead).  By default, TFTP 
requests a blocksize that will fill the frame.  If not, it uses the 
default TFTP block size (512, I think).

Is this not good enough?

Ben