]> git.kernelconcepts.de Git - karo-tx-uboot.git/commit
dfu: fix some issues with reads/uploads
authorStephen Warren <swarren@nvidia.com>
Wed, 11 Jun 2014 18:47:27 +0000 (12:47 -0600)
committerTom Rini <trini@ti.com>
Sat, 9 Aug 2014 15:16:58 +0000 (11:16 -0400)
commit0e285b503c41bb53f6ef962e6f9c942c1ca47cc6
tree13afc6c76327bf9d581e141e786ac802faf9c6c5
parentcf6598193aed5de8855eaf70c1994f2bc437255a
dfu: fix some issues with reads/uploads

DFU read support appears to rely upon dfu->read_medium() updating the
passed-by-reference len parameter to indicate the remaining size
available for reading.

dfu_read_medium_mmc() never does this, and the implementation of
dfu_read_medium_nand() will only work if called just once; it hard-codes
the value to the total size of the NAND device irrespective of read
offset.

I believe that overloading dfu->read_medium() is confusing. As such,
this patch introduces a new function dfu->get_medium_size() which can
be used to explicitly find out the medium size, and nothing else.
dfu_read() is modified to use this function to set the initial value for
dfu->r_left, rather than attempting to use the side-effects of
dfu->read_medium() for this purpose.

Due to this change, dfu_read() must initially set dfu->b_left to 0, since
no data has been read.

dfu_read_buffer_fill() must also be modified not to adjust dfu->r_left
when simply copying data from dfu->i_buf_start to the upload request
buffer. r_left represents the amount of data left to be read from HW.
That value is not affected by the memcpy(), but only by calls to
dfu->read_medium().

After this change, I can read from either a 4MB or 1.5MB chunk of a 4MB
eMMC boot partion with CONFIG_SYS_DFU_DATA_BUF_SIZE==1MB. Without this
change, attempting to do that would result in DFU read returning no data
at all due to r_left never being set.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
drivers/dfu/dfu.c
drivers/dfu/dfu_mmc.c
drivers/dfu/dfu_nand.c
drivers/dfu/dfu_ram.c
include/dfu.h