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