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

[Michael Cashwell]

On Mar 7, 2013, at 6:33 PM, Tom Rini <trini at ti.com> wrote:

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

I guess what I'm not seeing is how it can chunk at all. Without being able to seek how (with dfu-util driving things) can it not just overwrite the start of the partition over and over?

I suspect I'm missing a bunch of patches. I'm just on denx mainline.

The only place DFU_DATA_BUF_SIZE is used is in the definition of dfu_buf[]. I just put it at the base of SDRAM. (I've moved u-boot to the high end for other reasons so that would work for me.)

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

Whoops! I hadn't looked at your patch closely enough. I was still recovering from the shock of what the code did originally!

I went with a (*len + dfu->data.mmc.lba_blk_size - 1) / dfu->data.mmc.lba_blk_size approach rather than ALIGN but the result is the same.

I found the dfu->data.mmc.lba_blk_size being zero because the division threw a signal #8.

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

Pandaboard ES1.1 (which is OMAP4460 with 1GB SDRAM) with a vastly different config.h. :-)

Please do let me know. If you can do "dfu mmc 0" as the first command and it works I'd love to know why your card geometry is being read but mine isn't.

(Hmmm... My environment is nowhere. Is your's (or something else) being read from the MMC card? That would do it. But dfu shouldn't rely on that.)

Thanks for the info and assistance!

-Mike