Hi,
Thanks for your time,
Please find following comments:
- Current solution (u-boot):
- It is possible to specify your own "dfu_alt_info" environment variable when you call dfu command.
- Speed improvement - section "Making it faster" from:
http://codelectron.wordpress.com/2014/02/28/flexible-firmware-upgrade/
- I've noticed that you are referring to following dfu-util version:
dfu-util - (C) 2007 by Openmoko Inc.
It seems to be a bit old one.
I just used the content from my old documentation, But im referring to current implementation.
The newest GIT repo can be found at: git://gitorious.org/dfu-util/dfu-util.git
I'm referring to following SHA1 (master branch): bda43a52a6c5e9dcd159236553b0d5c511616e77
The code at dfuload_do_dnload() function is already rewritten to only wait: milli_sleep(dst.bwPollTimeout);
which is correct, since non-zero values are explicitly specified in u-boot (when e.g. target expects that eMMC data will be written).
It seems that the proposed improvement is already implemented.
I dont think its implemented, you can refer here, its the block of code what I am referring to,
https://gitorious.org/dfu-util/dfu-util/source/bda43a52a6c5e9dcd159236553b0d... https://gitorious.org/dfu-util/dfu-util/source/bda43a52a6c5e9dcd159236553b0d...
As a side note: To improve transmission speed we were even trying to increase the EP0 packet size on HOST machine. Unfortunately it has some limitations (4 KiB if I'm not wrong).
Yes I do think so about the limitation, as a standard EP0 should support atleast 64 bytes and DFU is based on that.
Anyway, I'm open for potential DFU transmission speed improvements.
- Flexibility improvement - section "Making it flexible"
The idea of adding headers seems appealing - but there are as usual some corner cases:
Backward compatibility - dfu-util and dfu use number of alt settings to chose the memory region to be written. That is why you observe a lot of alt=X when you type dfu-util -l. We would need some extra switch in the dfu-util to support yours header based approach.
In u-boot we would like to have some degree of control of where and if we flash data. I personally like to specify beforehand (in envs) what parts of memory are available for flashing.
I developed it keeping in mind a situation in field where there can be a complete change in memory organisation.
Some more complicated schemes shall be considered as well. I've got some pending patches to support eMMC's bootparts flashing via DFU.
Also the header itself only assumes NAND being the backing memory. But we now also alter content of eMMC and RAM with DFU. This is missing.
The information provided by headers is already stored at "dfu_alt_info" environment variable. It is also used by other gadgets.
It was an example code based on what I had implemented some time back. It was based on nand flash, but the idea will be the same for any other type.
I just wanted to share the idea of a different type of implementation of USB DFU.
Krishna www.codelectron.com