[U-Boot] [PATCH] dfu:mmc: When doing block operations, operate on the given length

[Tom Rini <trini@ti.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/07/2013 06:19 PM, Michael Cashwell wrote:

> I was just bitten in this area today but in a different way.
> 
> Larger than DDR? Any update larger than the default 4MB dfu_buf[] 
> fails too. (As a hack I redefined dfu_buf[] to be a cast of I
> think CONFIG_SYS_SDRAM_BASE.) But I'd love to hear more about being
> able to handle updates larger than DDR.

Yes, as another problem, we can only write in chunks of
DFU_DATA_BUF_SIZE.  And for files, since we like the infrastructure to
seek in existing files, filesystem writes need to be whole, and raw
writes can be chunks.

I've taken a patch from Pantelis Antoniou that solved half of this
problem and made it buffer filesystem writes and chunk raw writes.  It
seems to be working even but I just finished it and need to test it in
a few more places before posting.

> But on the code below, (both before and after the patch) the
> amount written is the size of the mmc partition. Why write more
> data than was received from the host? Why isn't the incoming len
> value used?

Er, that's not right.  It was before but *len is the length we've been
given.  We must make it lba_blk_size aligned, but that's typically
small (512 bytes), not the whole partition like it was before :)

> Lastly, I encountered a zero dfu->data.mmc.lba_blk_size. This gets 
> initialized in the mmc_init() path from the card meta data. But if 
> you just do "dfu mmc 0" right after booting that won't have been 
> done. The MMC controller is ready but the card structures have not 
> been read.

What platform are you looking on?  I'll go and re-produce this on mine
tomorrow, but I'd have sworn I had done dfu mmc 0 prior to any mmc
rescan/etc.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJROSO1AAoJENk4IS6UOR1Wg5EP/RBY4QFlNrj47S2KLtQFA1sl
5EEN25yC0LGFPwZ118GwXLinRzgE89ALbMeXq3dPdljlyIFLD4LFjM/7mmpB80sI
GR5xcml89cFnDq4+7lhrFeqNW3jqg68soQSvVjaxdYe9sPvkDLzuNwQ77WeJFtal
7fdNOvl1ZrSHoeDQuCjqFYHuDRz+4oso5fKZcDPdhKL4mrqWhmRfrZ7RJX2iKsuC
aySnkIfh/I4dtANLvQTZta3Nqidrb4PX8kE11XNrKcTKu4yLxq/Q+sHOWlXMbqfy
oW3O0zxQD3cVedPO8T2G14gQwonG61R+XCyBlrxJqtL+ZPlzKZxJWNxiP1Sa5HUM
Axz0vDjwfB84jsK+dzJspR0UTZHZdraoWnCYOnXF2bGxxCrCAPUSbS0A1BCpZfuT
A5ayIPUQRnLgITrBip+DsYn5sHAXxRFeE6OHP3mR2PFW87ioT9iK1xFU8jVchybU
73bckJZorarUBEhSDBgaC1DScS5gF/8nPqfFiRZX/ur70opq946hMWNZNzN5kOYs
haU1r88k98jm6ktW2uFvQVxzI5LiXdrPpbCYCf1vF8+VLmTGLAezLTk4Oce+8Q4t
/A+wPKu6Xm03O87uW10kqmitAhkmbm9deFRt78oBA3ChqqR0EopuYH6FQhyboyvH
ZMjtUebCZUAJRlgb0L4F
=WWas
-----END PGP SIGNATURE-----