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

[Lukasz Majewski]

Hi Krishna,

Thanks for attempt to improve DFU.

I've CCed Tormod Volden, who is involved in dfu-util development.

> Hi All,
> 
> I was working with dfu-utill couple of years ago as part of my
> thesis. My task was to provide a firmware upgrade mechanism using
> USB. I had an open moko so I thought of implementing a solution based
> on it. The board I used is SAM9G45
> http://www.atmel.com/devices/sam9g45.aspx.
> 
> My observation in the current implementation was that, the partitions
> are getting listed as DFU capable devices with fixed address and  to
> change their size or address, you need to change the u-boot-env.
> Considering the requirement I tweaked the protocol and some code to
> make a fast and flexible upgrade.
> 
> I have explained about it here
> http://codelectron.wordpress.com/2014/02/28/flexible-firmware-upgrade/
> Header source code here https://github.com/codelectron/DFU-Tweak/
> 
> Let me know your comments and feedback about this idea?.

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.

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.

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

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.

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


> 
> Thanks,
> Krishna
> 


-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group