# There is a size limit on the files to transfer with update command via tftp? **URL:** \ **Category:** Linux\ **Tags:** tftp-update-nand-fla\ **Created:** [January 28, 2015, 10:46am UTC](https://forums.digi.com/t/there-is-a-size-limit-on-the-files-to-transfer-with-update-command-via-tftp/14263 "2015-01-28T10:46:44Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![lbouzon](https://avatars.discourse-cdn.com/v4/letter/l/58f4c7/32.png) [@lbouzon](https://forums.digi.com/u/lbouzon)\ **Post date:** [January 28, 2015, 10:46am UTC](https://forums.digi.com/t/there-is-a-size-limit-on-the-files-to-transfer-with-update-command-via-tftp/14263/1 "2015-01-28T10:46:44Z")
Hello, I used a ConnectCore i.MX51 on a JSK board (NAND: 2048 MB and DRAM: 512 MB). I’ve compiled a jffs2 debian rootfs (rootfs-512-wheezy-raw.jffs2 = 131MB) and I tried to flash it on “UserFS” partition (0x000009300000-0x000080000000) of the NAND. I use a tftp server, so I executed the following command: “update UserFS tftp rootfs-512-wheezy-raw.jffs2” =\> After loading about 50 Mb, it freezes and stops. I don’t understand why, do you have an idea of the problem? There is a size limit on the files to transfer? However i am not limited by RAM: 512MB. Thanks for your help, Lionel Bouzon ## Info: Here my partition table CCMX51 # flpart Nr | Name | Start | Size | Type | FS | Flags 0 | U-Boot | 0 | 1 MiB | U-Boot | | fixed 1 | NVRAM | 1 MiB | 2 MiB | NVRAM | | fixed 2 | KernelA | 3 MiB | 3 MiB | Unknown | | 3 | KernelB | 6 MiB | 3 MiB | Linux/Android-Kernel | | 4 | RootFSA | 9 MiB | 64 MiB | Filesystem | JFFS2 | mounted readonly 5 | RootFSB | 73 MiB | 64 MiB | Filesystem | JFFS2 | mounted readonly 6 | ConfigA | 137 MiB | 5 MiB | Filesystem | JFFS2 | 7 | ConfigB | 142 MiB | 5 MiB | Filesystem | JFFS2 | 8 | UserFS | 147 MiB | 1901 MiB | Filesystem | JFFS2 | mounted readonly rootfs ---
**Author:** ![LeonidM](https://avatars.discourse-cdn.com/v4/letter/l/d26b3c/32.png) [@LeonidM](https://forums.digi.com/u/LeonidM)\ **Post date:** [January 28, 2015, 7:33pm UTC](https://forums.digi.com/t/there-is-a-size-limit-on-the-files-to-transfer-with-update-command-via-tftp/14263/2 "2015-01-28T19:33:35Z")
yes, there is a limit, because image is first loaded in to SDRAM. It is all explained very well in U-boot reference manual: [Uboot Reference Manual](http://ftp1.digi.com/support/documentation/90001129_B.pdf) 10.3.1 Update limits The update command in U-Boot transfers files to RAM, erases the flash partition, and writes the files from RAM into flash memory. The file that is transferred is copied to a specific physical address in RAM; therefore, the maximum length of the file to update is: Update file size limit = Total RAM memory – RAM offset where the file was loaded As a general rule, U-Boot does not let you update a flash partition with a file whose size exceeds the available RAM memory. This means that, for example, if you have a module with 32MB RAM and 64MB flash and you want to update a partition with a file that is 35MB, U-Boot will not do it. Note that this limitation is due to the RAM memory size, as U-Boot first needs to transfer the file to RAM before copying it to flash. For information on updating partitions with files larger than the available RAM memory, see your OS-specific update flash tool. To overcome this problem a special TFTP on-the-fly update mechanism has been created and is used only when updating from TFTP media. 10.3.2 TFTP on-the-fly update mechanism This update mechanism solves the RAM limitation problem with firmware updates. It first erases the target flash partition and then transfers a chunk of the image file via TFTP. It writes the chunk into the flash memory, verifies it and then continues to transfer the next chunk. The on-the-fly mechanism is disabled by default and can be enabled by setting the environment variable otf-update to yes. # setenv otf-update yes # saveenv This mechanism is only recommended to write large image files (bigger than 32MB or than half the available RAM). On-the-fly update mechanism is automatically disabled when updating U-Boot partition (to prevent partial update due to a network cut). To manually disable the mechanism, simply set the variable to no: # setenv otf-update no # saveenv ---
**Author:** ![lbouzon](https://avatars.discourse-cdn.com/v4/letter/l/58f4c7/32.png) [@lbouzon](https://forums.digi.com/u/lbouzon)\ **Post date:** [January 29, 2015, 9:04am UTC](https://forums.digi.com/t/there-is-a-size-limit-on-the-files-to-transfer-with-update-command-via-tftp/14263/3 "2015-01-29T09:04:42Z")
Thank you for your reply. I tried to update the NAND with otf-update set to yes, but I still have the same problem. I continue to investigate. Lionel ---
**Author:** ![thomas.kuhlmann](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.digi.com/thomas.kuhlmann/32/7_2.png) [@thomas.kuhlmann](https://forums.digi.com/u/thomas.kuhlmann)\ **Post date:** [February 11, 2015, 3:42am UTC](https://forums.digi.com/t/there-is-a-size-limit-on-the-files-to-transfer-with-update-command-via-tftp/14263/4 "2015-02-11T03:42:23Z")
First update to the latest U-Boot binary for this platform (there might be fixes in U-Boot for this). Enable on the fly update: setenv otf-update yes;saveenv Some TFTP servers (especially under Windows) are known to have some transmission limits like 32MByte. Maybe try another TFTP server. If this does not work check the TFTP transfer with WireShark to find the root cause (TFTP host or client) of the transmission problem. ---
**Author:** ![lbouzon](https://avatars.discourse-cdn.com/v4/letter/l/58f4c7/32.png) [@lbouzon](https://forums.digi.com/u/lbouzon)\ **Post date:** [February 13, 2015, 10:05am UTC](https://forums.digi.com/t/there-is-a-size-limit-on-the-files-to-transfer-with-update-command-via-tftp/14263/5 "2015-02-13T10:05:33Z")
Thank you for your reply. Ok, we will update the U-boot. About our TFTP server, it runs on a Linux machine. Lionel