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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot