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

[Stefan Schmidt]

Hello.

On Thu, 2011-11-03 at 09:12, Andrzej Pietrasiewicz wrote:
> 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.

Yes, sorry about this. I was fouled into thinking you did not as it
was splitted out and no mentioning of Harald copyright. Having the
same state machine is a good base for further cooperation on this. :)

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

Ah, latest Ubuntu has 0.3 and hopefully they will update as well.
Already pinged the maintainer.

> > Hmm, that sounds like you only implemented the DFU mode but not the
> > run-time mode yet?
> 
> This conclusion is not correct.

Indeed. I stand corrected.

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

Correct. Sadly this is due to the standard only allowing the
functional descriptor in runtime mode. On the other hand the exposed
alt settings in run-time mode would clutter the USB device settings.

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

I did run exactly in the same problem. :) I added a detach command to
dfu-util to switch between the different modes. From run-time to dfu
and from dfu to run-time. I wanted to get the release out before
bringing it in. Pushed it to the master branch of dfu-util now. Feel
free to test and let me know if it works for you.

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

See above. Not available in run-time mode. :/

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

Agreed. This should not be handled in the dfu implementation at all.
Your split between dfu and flashing backend is a good step in the
right direction here. Invoking the dfu mode through a command is also
a nice addition.

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

After thinking more about it I agree with you here. The split makes
sense and it will allow for more flexibility when adding more flashing
backend to the implementation.

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

Good to know. :)

Brainstorming about a way going forward. Please comment if with your
view on this.

o I will send out my not ready for mainline patch to give you and
  others an impression how it is tackled in my patch.

o I like your split between dfu and flashing and also the addition of
  the dfu command. Could you split this part from the rest and send it
  as self conatining patch without other dependencies?

o And then one patch with the mmc/fat flashing backend in moved out of
  the board file (no idea what the best place is, maybe just another
  file for now) and a last patch with all the board specific changes?

o I will then rebase my code on yours and prepare patches against the
  dfu implementations as needed and also flashing backend for NAND.

o After this we need to review was is missing and bring it over.

Not all details covered in the plan but a start. Comments?

regards
Stefan Schmidt