On Mon, Mar 11, 2013 at 11:03:41AM +0100, Lukasz Majewski wrote:
Hi Tom,
From: Pantelis Antoniou panto@antoniou-consulting.com
Previously we didn't support upload/download larger than available memory. This is pretty bad when you have to update your root filesystem for example.
This patch removes that limitation (and the crashes when you transfered any file larger than 4MB) by making raw image writes be done in chunks and making file maximum size be configurable.
The sequence number is a 16 bit counter; make sure we handle rollover correctly. This fixes the wrong transfers for large (> 256MB) images.
Also utilize a variable to handle initialization, so that we don't rely on just the counter sent by the host.
Signed-off-by: Pantelis Antoniou panto@antoniou-consulting.com Signed-off-by: Tom Rini trini@ti.com
Acked-by: Lukasz Majewski l.majewski@samsung.com
Test-hw: Exynos 4210 (Trats)
Tested-by: Lukasz Majewski l.majewski@samsung.com
Sorry but, I've found a regression for reading image from a file system. It happens with EXT4 mmc read (like uImage).
mmc_file_op: ext4load mmc 0:2 /uImage 0x0 0 0x7f95dc98 ** File not found 0x0 ** dfu: Read error!
ext4load params: ext4load - load binary file from a Ext4 filesystem
Usage: ext4load <interface> <dev[:part]> [addr] [filename] [bytes]
This is a bug, but this is not a regression. As I sent in another email, the issue is that ext4write takes arguments backwards from fatwrite/fatload/ext4load so the line here has always been wrong.