[U-Boot] Is there file size limiation of tftp

[Simon Glass]

Hi,

On Sun, Aug 12, 2012 at 8:41 AM, Jerry Van Baren <gvb.uboot at gmail.com> wrote:
> On 08/11/2012 09:21 PM, J.Hwan Kim wrote:
>> Hi, everyone
>>
>> Is there any limit of file size for tftpboot?
>> I have a problem downloading the file of which file size is 65MB.
>> The procedure stops in the middle of downloading.
>>
>> Thanks in advnace.
>>
>> Best Regards,
>> J.Hwan Kim
>>
>> -----------------------------------------------------------------------------------------------------------------------------
>>
>> # tftp 0xc0000000 192.168.100.10:system.img
>> smc911x: detected LAN9221 controller
>> smc911x: phy initialized
>> smc911x: MAC c3ea1460M (00405c260a5b)
>> TFTP from server 192.168.100.10; our IP address is 192.168.100.50
>> Filename 'system.img'.
>> Load address: 0xc0000000
>
> Probably what Mike said.  Note that 64MB is 0x40000000 and your load
> address is 0xC0000000... add the two together and you get 0x1_0000_0000
> which is a very suspicious number.
>
> Having said that, there are two places where TFTP implementations have
> problems.  The block number is a 16 bit unsigned integer.
>
> The easier (and less often problematic) one is where the block number
> goes from 0x7FFF to 0x8000.  If an implementation erroneously treats the
> block number as a *signed* integer, it will screw that up.
>
> The second size limit stumbling block is when the block number hits
> 0xFFFF, what is the next block number?  Some implementations just give
> up and limit the maximum file size to 64K-1 blocks[1].  If your block
> size is the default 512, that makes the maximum file size 32MB.  If your
> block size is 4K, it will make the maximum file size 256MB.

Yes. If it helps, I found a limit of about 95MB, which is something
like (the maximum tftp packet payload on Ethernet of about 1450) *
65535 or similar, caused by a buggy tftp server. When I switched to
tftpd-hpa my problems went away.

>
> RFC1350[2] is silent on the issue, probably because the authors never
> considered using TFTP with files bigger than 32MB.  TFTP does use block
> number 0 in a special way to ACK the write request and says "block
> numbers are consecutive and begin with one."  The simpler and more
> intuitive interpretation of 0xFFFF + 1 is to wrap to 0x0000.  The less
> intuitive one that honors 0 being special is to wrap to 0x0001.
>
> U-Boot wraps to 0, see net/tftp.c function update_block_number().  Your
> TFTP server needs to do the same.
>
> Best regards,
> gvb

Regards,
Simon


>
> Ref:
> [1] <http://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol#Extensions>
> [2] <http://tools.ietf.org/html/rfc1350>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot