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
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
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:
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.