Hi, Thanks for your time,
Please find following comments: > > 1. Current solution (u-boot): > - It is possible to specify your own "dfu_alt_info" environment > variable when you call dfu command. > > 2. 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/bda43a52a6c5e9dcd159236553b0d5c511616e77:src/dfu_load.c#L123 https://gitorious.org/dfu-util/dfu-util/source/bda43a52a6c5e9dcd159236553b0d5c511616e77:src/dfu_load.c#L137 > 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. > > > 3. 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
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
