[U-Boot] [PATCH] dfu: initial implementation

[Andrzej Pietrasiewicz]

Hello Stefan,

On Wednesday, November 02, 2011 3:29 PM Stefan Shmidt wrote:

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

As you noticed in another post, the state machine is reused.

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

I used what was available in my desktop's Ubuntu 10.04 LTS, and
it happens to be version 0.1+svn :O It works, though.

> Hmm, that sounds like you only implemented the DFU mode but not the
> run-time mode yet?

This conclusion is not correct. After issuing the dfu command
my implementation begins in runtime mode. Only after using dfu-util
from the host is the mode changed to DFU mode.
Actually, as far as usage of dfu-util is concerned, I find it
inconvenient when the device is in runtime mode, because there
(at least with my version of dfu-util) is no way for the user
to guess what altsettings are actually available. I personally
do dfu-util -U <file> -a 0 or a similar command to kick the device
into DFU mode, then dfu-util -l to discover what altsettings there are.
So, it could be tempting to omit the runtime mode at all and start
in DFU mode, but, to be standard compliant, I start in runtime mode.
How do you discover with dfu-util what altsettings there are in the
device?

> While the original purpose
> of DFU was to make updating USB device easy enough for end-users as
> well.

True, that's what the standard says about the very purpose of DFU.
However, pressing keys to bring the device into a specific mode is
probably very much device-specific. It would be nice if we
are able to come up with a generic solution which only delegates
the necessary details to board-specific files.

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

Please see my comment above.

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

I think 2 and 3 don't differ too much - it seems that enriching a
setup without DFU with additional USB descriptors will do the job.
But 2 and 3 probably should not be merged, though.

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

The reason is to factor out board-specific stuff from the dfu gadget
implementation. However, in what I factored out probably there are
parts which are generic enough not to be board-specific. Since there
seems to be considerable interest in DFU implementation for u-boot,
this could be reworked.

> To make it clear, I'm happy to see somebody else working on this

"Whassssuuuup! --- Oh, man, we are not alone!" ;) I am happy to
hear from someone else who works on this, too.

Regards,

Andrzej