Hi, On Sun, Aug 12, 2012 at 8:41 AM, Jerry Van Baren <gvb.ub...@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@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
