[U-Boot] A proposal/hack for an efficient USB DFU for linux based boards

[Krishna Pattabiraman]

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