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

Jerry Van Baren gvb.uboot at gmail.com
Sun Aug 12 17:41:37 CEST 2012


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.

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

Ref:
[1] <http://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol#Extensions>
[2] <http://tools.ietf.org/html/rfc1350>


More information about the U-Boot mailing list