No subject

[<bogus@does.not.exist.com>]

is working in mine so there is some ground for working together on
this. The main question is which of both implementation to use to
build up from. I will give you some feedback on the design high level
aspects further below. A complete review of the code and testing on
the beagleboard will hopefully happen over the next days. Testing
might be problematic as you flashing part is forced to be rewritten
for every board here it seems. Need to investigate further before I
can really comment on this. More comment inline.

On Wed, 2011-11-02 at 11:00, Andrzej Pietrasiewicz wrote:

> http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf

Have you fully implemented 1.1? With the detahc logic inside the
device implementation?

> The aim of DFU is to allow transferring data to/from selected areas of
> interest within a compliant device. In the DFU nomenclature the host->device
> direction is called download and the device->host direction is called
> upload. The areas are defined by the compliant device. In the DFU
> nomenclature the area of interest within the device is called an altsetting.
> The device is connected to the host through USB. On the host side compliant
> software must be used to initiate the data transfer. Example piece of such
> software is dfu-util package from the OpenMoko project:
> 
> http://wiki.openmoko.org/wiki/Dfu-util.

Better to use the official homepage here:
http://dfu-util.gnumonks.org/

It misses some examples but has the current informations while the
wiki is outdated.

> The DFU implementation on the device side remains in one of the two modes:
> the Run-Time mode and the DFU mode. The USB descriptor sets exported by
> the device depend on which mode is in force. While in DFU mode the device
> exports the descriptors corresponding to each available altsetting. An
> example dfu-util session when the device is in the DFU mode looks similar
> to this:
> 
> # dfu-util -l
> dfu-util - (C) 2007-2008 by OpenMoko Inc.
> This program is Free Software and has ABSOLUTELY NO WARRANTY
> 
> Found DFU: [0x0525:0xffff] devnum=46, cfg=0, intf=0, alt=0, name="bootldr"
> Found DFU: [0x0525:0xffff] devnum=46, cfg=0, intf=0, alt=1, name="kernel"

Just curious. What version of dfu-util your are using for your tests?
I released 0.5 earlier today.

> This u-boot implementation introduces a parameter-less dfu command.
> After the user finishes with dfu they can Ctrl-C to return to u-boot main
> menu.

Hmm, that sounds like you only implemented the DFU mode but not the
run-time mode yet? No addtional DFU descripto in the normal run-time
operation mode like usbtty? If yes this is a real limitation as the
update would only be possible when the user has serial access to start
the dfu command and then flash the device. While the original purpose
of DFU was to make updating USB device easy enough for end-users as
well. The implementation from OpenMoko i forward ported and cleanup
has this functionality and it works well enough. Did so on the
Freerunner from OM already.

In the end I would like to see different options available:

1) Entering DFU mode directly when a button is pressed on startup. An
update mode if you want to call it like this.

2) Normal startup, but with DFU descripton to allow dfu-util detaching
and entering the DFU mode for flashing.

3) Starting dfu mode form the command line as you did implement it.

> The implementation is split into two parts: the dfu gadget implementation
> and a "flashing backend", the interface between the two being the
> struct flash_entity. The "flashing backend"'s implementation is
> board-specific and is implemented on the Goni target.

What is your reasoning behind this split? I have it working here with
the normal nand_flashing routines taking care of bad blocks, etc.

I agree that there are several aspects that are board specific.
Partions can be read out dynamically and the alt setting generated
though. Soemthing what bothers me is the different underlaying medias
that can be flashed. Right now I only cover nand, but eMMC, USB and
other are valid as well. That is not covered in my implementation at
all right now.

To make it clear, I'm happy to see somebody else working on this as
well as my primary goal is to have good DFU support in U-Boot here not
if my implementation is merged or yours. I will clean up my patches a
bit more and send them in the next days. Also will go through your
code to understand what and how you are doing things. From there we
can go and decide how we merge our work and bring it into U-Boot
mainline. Comment from Scott for nand and Remy for USB related parts
will be helpful here.

Looking forward to work with you on this until we have good DFU
support in U-Boot.

regards
Stefan Schmidt